Avoid automatic binds at migration to Db2 11 or Db2 12 for z/OS

By Patrick Bossman and Paul McWilliams

Automatic binds of plans and packages for applications that run on Db2 for z/OS introduce avoidable risk to online and offline migrations. During and after migration, automatic binds can cause costly problems, including performance regression and even application outages.

However, you can take action before migration to avoid such automatic binds and costly outages that might result. We recently added information about Avoiding automatic binds at migration, to help you understand when Db2 uses automatic binds during migration, and the actions that you can take to avoid their disruptive effects.

Performance regressions and even application outages can result from migration-related automatic binds when the following problems occur:

  • Application failures, when automatic binds fail because of contention between different releases in coexistence because an up-level member needs to automatically bind a plan or package (which DSNTIJPM identified as a candidate for rebind before migration) that is in use by a down-level member.
  • Application failures, when automatic binds fail for access control authorization exit users because the authorization ID for the automatic bind has insufficient privileges, compared to the owner of the package or the plan.
  • Performance regressions that are difficult resolve because the automatic bind destroys the prior packages, eliminating REBIND with SWITCH or APREUSE as a viable query performance recovery options.
  • The "autobind ping-pong" of repeating automatic re-migration binds, each time that the other release in coexistence runs the application again.

After you migrate to Db2 12, any plan or package that was last bound or rebound in a release earlier than Db2 10 is automatically bound. The same is true at migration to Db2 11 for plans and packages last bound or rebound in releases earlier than Db2 9. These automatic binds occur because the new Db2 release cannot use the run-time structures from plans or packages that were last bound in the earlier release.

Such problems can occur any time during the "first impression window" for the new Db2 release. That is, they can occur any time after migration, until the plan or package first runs in the new release, and as long as release coexistence continues.  For more information, see Automatic binds in coexistence.

Actions to take
To avoid automatic binds and substantially reduce migration risk, take the following actions well before migration to the new release:

  • Run the premigration queries (job DSNTIJPM) to identify any plans and packages that are subject to automatic binds in the new release.
  • Rebind any plans that DSNTIJPM identifies. Automatic binds of plans can be particularly disruptive for  application workloads that depend on very few or even a single large plan.
  • Free inactive package copies, then rebind any packages that DSNTIJPM identifies with the PLANMGMT(EXTENDED) option.  (Performing FREE INACTIVE then REBIND moves the current package copy, which is presumably performing well, to the original slot, making it available to be restored with REBIND SWITCH, if a performance regression occurs after REBIND.)
  • In data sharing, set ABIND=COEXIST. This setting prevents the "autobind ping-pong" of automatic re-migration binds.  For an upcoming solution to this problem, watch for APAR PI87675, which will eliminate re-migration binds completely.  Ultimately, the APAR will make ABIND=YES behave like ABIND=COEXIST, and you should use ABIND=COEXIST until it is available.
  • In non-data sharing Db2 subsystems, set ABIND=YES because coexistence is not an issue.
  • When fallback occurs in non-data sharing Db2 subsystems, explicitly rebind any package that was bound on the up-level release. Then rebind any packages or plans that were automatically bound after fallback.  Without explicit rebinds, automatic bind occurs for those packages and plans at re-migration to the up-level release.
  • Bind or rebind most packages and plans on the new release only after the migration is complete for all members, and automatic rebinds on down-level members in release coexistence are no longer a concern.

For more information, see:
Avoid automatic binds at migration to Db2 12
Automatic binds in coexistence
Automatic rebinds

Views: 779

Add a Comment

You need to be a member of The World of DB2 to add comments!

Join The World of DB2

Comment by Robert Plata on October 3, 2017 at 15:52

Hello, the link for avoiding autorebind in Db2 12 at migration should be: https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/inst/src/...


Bringing Db2 enthusiasts together virtually. Expert or novice, distributed or mainframe, this is the place for everything DB2.


z/OS DB2 V11 to V12 and CICS?

Started by Tom Burkholder in What's hot ? on Friday. 0 Replies

Hello DB2 users...I apologize in advance if this is not the place to post this question; however, I thought I would sign up and give it a try.  My background is with systems support and middleware (z/OS, MQ, WebSphere, distributed DB2 jdbc configs)…Continue

Db2 LUW 11.1 - GET_LINE procedure - NO_DATA_FOUND exception SQLSTATE

Started by Gagan Kakkar in Application Development and DB2. Last reply by Douglas J. Partch, Jr. Jan 6. 1 Reply

Hi there,I am testing this stored procedure using Db2 11.1 on Windows 10 64-bit.Informational tokens are "DB2 v11.1.4050.859", "s1911120100","DYN1911120100WIN64", and Fix Pack "5".For NO_DATA_FOUND exception I am getting SQLSTATE = 'ORANF' but in…Continue

Tags: modules, Built-in, LUW, Db2

© 2020   Created by Surekha Parekh.   Powered by

Badges  |  Report an Issue  |  Terms of Service