Automatic binds in coexistence

Changes to package structures that are introduced in Db2 13 are not available to members of the group that have not migrated. You must plan accordingly when developing your migration plan.

Important: To reduce coexistence problems, rebind all packages and plans that can run in Db2 12, but cannot run without an automatic rebind in Db2 13. To identify those packages, run the DSNTIJPE premigration queries job, and examine the premigration reports on package copies and plans that are not supported after migration to Db2 13. For details, see Run premigration queries (DSNTIJPE).
Important: Apply APAR PI87675 to eliminate the possibility of repeating automatic remigration binds during release coexistence.

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.

For more information about avoiding automatic binds during or after the Db2 13 migration process, see Rebind old plans and packages in Db2 12 to avoid disruptive autobinds in Db2 13.

The migration process binds new packages in Db2 13, including packages for Db2-supplied stored procedures, user defined functions, and tools such as SPUFI and the Db2 REXX language support. Data sharing members in the Db2 13 load and execute those programs from the Db2 13 SDSNLOAD library. Data sharing members on Db2 12 continue to load this packages from the SNDSNLOAD library for Db2 12.

If you must rebind some of your application packages in Db2 13 while coexistence with Db2 12 continues, you must consider how to handle the resulting binds and automatic rebinds while the different releases coexist.