Allows the user to recreate a package stored in the database without the need for a bind file.
The authorization ID logged in the BOUNDBY column of the SYSCAT.PACKAGES system catalog table, which is the ID of the most recent binder of the package, is used as the binder authorization ID for the rebind, and for the default schema for table references in the package. This default qualifier can be different from the authorization ID of the user executing the rebind request. REBIND will use the same bind options that were specified when the package was created.
Database. If no database connection exists, and if implicit connect is enabled, a connection to the default database is made.
>>-REBIND--+---------+--package-name----------------------------> '-PACKAGE-' >--+-----------------------+--+------------------+--------------> '-VERSION--version-name-' '-APREUSE--+-YES-+-' '-NO--' >--+---------------------------+--+-------------------+---------> '-RESOLVE--+-ANY----------+-' '-REOPT--+-NONE---+-' '-CONSERVATIVE-' +-ONCE---+ '-ALWAYS-' >--+---------------------------+------------------------------->< | .-,-----------. | | V | | '-FUNCPATH----schema_name-+-'
REBIND does not automatically commit the transaction following a successful rebind. The user must explicitly commit the transaction. This enables "what if" analysis, in which the user updates certain statistics, and then tries to rebind the package to see what changes. It also permits multiple rebinds within a unit of work.
The REBIND command will commit the transaction if auto-commit is enabled.
If multiple versions of a package (many versions with the same package name and creator) exist, only one version can be rebound at once. If not specified in the VERSION option, the package version defaults to be "". Even if there exists only one package with a name that matches, it will not be rebound unless its version matches the one specified or the default.
REBIND is supported by DB2 Connect™.
If REBIND is executed on a package that is in use by another user, the rebind will not occur until the other user's logical unit of work ends, because an exclusive lock is held on the package's record in the SYSCAT.PACKAGES system catalog table during the rebind.
When REBIND is executed, the database manager recreates the package from the SQL statements stored in the SYSCAT.STATEMENTS system catalog table.
If REBIND encounters an error, processing stops, and an error message is returned.
REBIND will re-explain packages that were created with the EXPLSNAP bind option set to YES or ALL (indicated in the EXPLAIN_SNAPSHOT column in the SYSCAT.PACKAGES catalog table entry for the package) or with the EXPLAIN bind option set to YES or ALL (indicated in the EXPLAIN_MODE column in the SYSCAT.PACKAGES catalog table entry for the package). The Explain tables used are those of the REBIND requester, not the original binder.
If an SQL statement was found to be in error and the BIND option SQLERROR CONTINUE was specified, the statement will be marked as invalid even if the problem has been corrected. REBIND will not change the state of an invalid statement. In a package bound with VALIDATE RUN, a statement can change from static to incremental bind or incremental bind to static across a REBIND depending on whether or not object existence or authority problems exist during the REBIND.
Rebinding a package with REOPT ONCE | ALWAYS might change static and dynamic statement compilation and performance.
If REOPT is not specified, REBIND will preserve the existing REOPT value used at precompile or bind time.
Every compiled SQL object has a dependent package. The package can be rebound at any time by using the REBIND_ROUTINE_PACKAGE procedure. Explicitly rebinding the dependent package does not revalidate an invalid object. Revalidate an invalid object with automatic revalidation or explicitly by using the ADMIN_REVALIDATE_DB_OBJECTS procedure. Object revalidation automatically rebinds the dependent package.