Rebind old plans and packages in Db2 12 to avoid disruptive autobinds in Db2 13
By taking appropriate actions in Db2 12 well before migration to Db2 13, you can minimize the risk of disruptive automatic binds of application plans and packages during and after migration to Db2 13.
Before you begin
Identify plans and packages that are subject to autobind at migration to Db2 13 because they were last bound in a release earlier than Db2 11. See Verify Db2 13 premigration activities and activate function level 510 in Db2 12.
About this task
Migration-related automatic binds (also called autobinds
) occur in Db2 13 because it cannot use runtime structures from a plan or package that was last bound in a release earlier than Db2 11. Plans and packages that were bound in Db2 12 can run in Db2 13, without the risk of migration-related autobinds. However, plans and packages that are bound in Db2 13 cannot run on Db2 12 members without an autobind in Db2 12.
If the autobinds are allowed to occur, they are inevitably disruptive for rolling online migrations, or any time that different releases coexist in data sharing environments. During and after migration, such autobinds can result in costly problems, including performance regression and even application outages.
Autobinds occur the first time that any plan or package runs in Db2 13, which means that the autobinds, and resulting problems and application outages, can occur well after a migration window. That is, such problems and resulting outages can occur any time in the first impression
window in Db2 13, which is any time until the plan or package first runs in Db2 13.
The best approach is to bind all packages and plans that might be subject to migration-related autobinds in Db2 12 with good performance before you start the migration to Db2 13. Doing so reduces the risk of the following problems that can result from autobinds:
- Application failures because of contention between releases. For any migration that brings into release coexistence, autobinds might fail for plans or packages that are in use by a Db2 12 member, causing applications to fail on the Db2 13 member.
Successful autobinds on Db2 13 in a coexistence environment also create a package or plan that Db2 12 members cannot run without another autobind. The autobind might also fail if the plan or package is in use by a Db2 13 member.
- Application failures, when autobinds fail for access control authorization exit users because the authorization ID for the autobind has insufficient privileges, compared to the owner of the package or the plan.
- Difficult to resolve performance regressions. For packages, a migration-related autobind also destroys the current package. If the autorebind succeeds but introduces an access path regression, REBIND SWITCH is not possible. Any performance regression that occurs in Db2 13 might also occur in Db2 12.
Procedure
To avoid autobinds during or after the Db2 13 migration process, take the following actions. For best results, complete these actions well before migration to Db2 13 (months if possible) so that you have sufficient time to run the applications and resolve any performance issues that might occur after the rebinds.