Automatic binds in coexistence

Changes to package structures that are introduced in Db2 12 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 11, but cannot run without an automatic rebind in Db2 12. To identify those packages, run job DSNTIJPM, and examine the premigration reports on package copies and plans that are not supported after migration to Db2 12. For details, see Run premigration queries (DSNTIJPM).
Important: Start of changeApply APAR PI87675 to eliminate the possibility of repeating automatic remigration binds during release coexistence.End of change

Migration-related automatic binds (also called autobinds) occur in Db2 12 because it cannot use runtime structures from a plan or package that was last bound in a release earlier than DB2 10. Plans and packages that were bound in Db2 11 can run in Db2 12, without the risk of migration-related autobinds. However, plans and packages that are bound in Db2 12 cannot run on Db2 11 members without an autobind in Db2 11.

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 12, 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 12, which is any time until the plan or package first runs in Db2 12.

The best approach is to bind all packages and plans that might be subject to migration-related autobinds in Db2 11 with good performance before you start the migration to Db2 12. 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 11 member, causing applications to fail on the Db2 12 member.

    Successful autobinds on Db2 12 in a coexistence environment also create a package or plan that Db2 11 members cannot run without another autobind. The autobind might also fail if the plan or package is in use by a Db2 12 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 12 might also occur in Db2 11.

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

The migration process binds new packages in Db2 12, 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 12 load and execute those programs from the Db2 12 SDSNLOAD library. Data sharing members on Db2 11 continue to load this packages from the SNDSNLOAD library for Db2 11.

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