DB2 10.5 for Linux, UNIX, and Windows

Rebinding existing packages with the REBIND command

Rebinding is the process of recreating a package for an application program that was previously bound. You must rebind packages if they were marked invalid or inoperative or if the database statistics changed since the last binding. In some situations, however, you might want to rebind packages that are valid. For example, you might want to take advantage of a newly created index, or use updated statistics after executing the RUNSTATS command.

Packages can be dependent on certain types of database objects such as tables, views, aliases, indexes, triggers, referential constraints, and table check constraints. If a package is dependent on a database object (such as a table, view, trigger, and so on), and that object is dropped, the package is placed into an invalid state. If the object that is dropped is a UDF, the package is placed into an inoperative state.

When the package is marked inoperative, the next use of a statement in this package causes an implicit rebind of the package using non-conservative binding semantics in order to be able to resolve to SQL objects considering the latest changes in the database schema that caused that package to become inoperative.

For static DML in packages, the packages can rebind implicitly, or by explicitly issuing the REBIND command (or corresponding API), or the BIND command (or corresponding API). The implicit rebind is performed with conservative binding semantics if the package is marked invalid, but uses non-conservative binding semantics when the package is marked inoperative.

You must use the BIND command to rebind a package for a program which was modified to include more, fewer, or changed SQL statements. You must also use the BIND command if you need to change any bind options from the values with which the package was originally bound. The REBIND command provides the option to resolve with conservative binding semantics (RESOLVE CONSERVATIVE) or to resolve by considering new routines, data types, or global variables (RESOLVE ANY, which is the default option). The RESOLVE CONSERVATIVE option can be used only if the package was not marked inoperative by the database manager (SQLSTATE 51028). You should use REBIND whenever your situation does not specifically require the use of BIND, as the performance of REBIND is significantly better than that of BIND.

When multiple versions of the same package name coexist in the catalog, only one version can be rebound at a time.

In IBM® Data Studio Version 3.1 or later, you can use the task assistant for rebinding packages. Task assistants can guide you through the process of setting options, reviewing the automatically generated commands to perform the task, and running these commands. For more details, see Administering databases with task assistants.