Start of change

Autobind phase-in for packages with statement-level invalidation

Db2 uses autobind phase-in for packages that are marked with statement-level invalidation. Packages with invalid statements can be allocated, and valid statements can execute without waiting for the rebind to complete. However, invalid statements must go through incremental bind before they execute.

FL 504 With statement-level dependencies and statement-level invalidation, applications can execute a package that is invalidated at a statement level without waiting for the completion of the automatic rebind (autobind). The application thread can execute the valid statements immediately. Any invalid statements go through incremental bind in the application thread before execution. Concurrently, Db2 initiates a special autobind, which is called autobind phase-in. When the autobind phase-in finishes successfully, the subsequent executing threads can use the new valid copy of the package, and they no longer use incremental bind for any statements.

Exception: If a package depends on a dropped user-defined function, the DROP FUNCTION statement always causes a package-level invalidation, even if the package is bound with the DEPLEVEL(STATEMENT) bind option.

The autobind phase-in process runs concurrently with executing application threads, and the old invalid copy becomes a phased-out copy, which is stored in the SYSIBM.SYSPACKCOPY table. The new copy of the package becomes the current copy. Subsequent executions of the package use the new valid copy. Threads that existed prior to autobind phase-in completing can also use the new current copy when they release the phased-out copy (based on the RELEASE(COMMIT) or RELEASE(DEALLOCATE) bind options) In this respect, autobind phase-in is the same as rebind phase-in. However, unlike other phase-in rebinds, autobind phase-in does not require the PLANMGMT subsystem parameter to be set to EXTENDED. For more about rebind-phase in, see Phase-in of package rebinds.

If an autobind phase-in operation fails, Db2 marks the package rebind-advisory status by setting SYSPACKAGE.OPERATIVE='R'. Db2 also issues message DSNT500I with reason code '00E30305'X and resource type '804'X. This failure situation can occur when the maximum number of package copy IDs is reached autobind phase-in generates package copies. After the package is marked in rebind-advisory status, it can still be allocated and executed, and invalid statements continue to be incrementally bound. If an autobind phase-in does not succeed, Db2 retries it a few times. However, an explicit rebind is best for a package that is marked in rebind-advisory status. The explicit rebind can be eligible for rebind phase-in, depending on the PLANMGMT bind option and PLANMGMT subsystem parameter value.

When a package uses statement-level dependencies to record database objects referenced by static SQL statements in the package, more rows are recorded in the Db2 catalog. As a result, more storage space is used, and certain Db2 operations such as BIND, REBIND, and package invalidation might impact performance because more records must be processed. Also, when more statements in a package are invalidated, incremental bind is more costly when a package that was not yet processed with autobind executes. As a result, not all packages benefit from using statement-level dependencies.

End of change