REBIND PLAN command (DSN)

The DSN subcommand REBIND PLAN rebinds an application plan when you make changes to the attributes of the plan, such as the package list.

For example, you can use REBIND PLAN when you change authorizations, modify package lists for the plan, or use RUNSTATS. If the rebind is successful, the process prepares an application plan and updates its description in the catalog table SYSPLAN.

REBIND PLAN is generally faster and more economical than BIND PLAN. But if you change the SQL statements or recompile a program, you should use BIND PLAN with the option ACTION(REPLACE).

Environment

You can use REBIND PLAN through DB2I, or enter the REBIND PLAN subcommand from a DSN session running in foreground or background.

Data sharing scope: Group

Authorization

The plan owner must be a role to execute REBIND PLAN in a trusted context with role ownership.

If you use the PKLIST keyword, you must have EXECUTE authority for the packages or collections specified on PKLIST.

The following table explains the authorization required to run REBIND PLAN, depending on the options specified.

Table 1. Summary of privileges for REBIND PLAN
Option Authorization required to run REBIND PLAN
REBIND PLAN with no change in ownership because the OWNER keyword is not specified. The authorization IDs of the process must have one of the following authorities:
  • Ownership of the plan
  • BIND privilege on the plan
  • BINDAGENT privilege from the owner of the plan
  • SYSADM or SYSCTRL or System DBADM authority
REBIND PLAN with no change in ownership, although the original owner is specified for the OWNER keyword. The authorization IDs of the process must have one of the following authorities:
  • OWNER authorization-id must be one of the primary or secondary authorization IDs of the binder
  • BINDAGENT privilege from the owner of the plan
  • SYSADM or SYSCTRL or System DBADM authority
REBIND PLAN with change of ownership. (An authorization ID that is not the original owner is specified in the OWNER keyword.) The new OWNER must have one of the following authorities:
  • BIND privilege on the plan
  • SYSADM or SYSCTRL or System DBADM authority

If any of the authorization IDs or roles of the process has SYSADM authority, SYSCTRL authority, or system DBADM authority, OWNER authorization-id can be any value, when subsystem parameter SEPARATE_SECURITY is set to NO. If any of the authorization IDs has the BINDAGENT privilege granted from the owner, authorization-id can specify the grantor as OWNER. Otherwise, the OWNER authorization-id must be one of the primary or secondary authorization IDs of the binder.

If you specify OWNER authorization-id , Db2 first checks the OWNER and then the binder for the necessary bind privilege.

If the binder does not have SYSADM, SYSCTRL, or system DBADM authority, the authorization ID or role of the OWNER must have one of the following to add a new package or new version of an existing package to a collection:

  • The BINDADD system privilege and either the CREATE IN privilege or PACKADM authority on the collection or on all collections
  • SYSADM, SYSCTRL, or system DBADM authority
COLLID, specifying (*), indicating all packages in the collection You do not need any authorization privileges for this option.
COLLID, specifying individual packages Authorization ID of the process must include one of the following authority:
  • CREATEIN privilege on the COLLID you specified.
PKLIST, specifying individual packages Authorization ID of the process must include one of the following authorities:
  • EXECUTE privilege on each package specified in the PKLIST
  • PACKADM authority on specific collections containing packages or on collection *
  • SYSADM or DATAACCESS authority
PKLIST, specifying (*), indicating all packages in the collection Authorization ID of the process must include one of the following authorities:
  • EXECUTE privilege on collection-id .*
  • PACKADM authority on collection-id or on *
  • SYSADM or DATAACCESS authority

Syntax

Read syntax diagramSkip visual syntax diagramREBIND PLAN(,plan-name*)COLLID(*)COLLID( collection-id)OWNER( authorization-id)QUALIFIER( qualifier-name)enable-blockpklist-block NODEFER(PREPARE)DEFER(PREPARE)ACQUIRE(USEALLOCATE)CACHESIZE( decimal-value)CURRENTDATA(NOYES)CURRENTSERVER( location-name)DBPROTOCOL(DRDA)DEGREE(1ANY)DISCONNECT(EXPLICITAUTOMATICCONDITIONAL)DYNAMICRULES(RUNBIND)ENCODING(ASCIIEBCDICUNICODEccsid)EXPLAIN(NOYES)FLAG(IWEC)IMMEDWRITE(NOYES)ISOLATION(RRRSCSUR)KEEPDYNAMIC(NOYES)REOPT(NONE1ALWAYS2ONCEAUTO)OPTHINT(' hint-id')PATH(,schema-nameUSER)PATHDEFAULT3RELEASE(COMMITDEALLOCATE)ROUNDING(CEILINGDOWNFLOORHALFDOWNHALFEVENHALFUPUP)SQLRULES(DB2STD)VALIDATE(RUNBIND)CONCURRENTACCESSRESOLUTION(USECURRENTLYCOMMITTEDWAITFOROUTCOME)PROGAUTH(DISABLEENABLE)
Notes:
  • 1 REOPT(VARS) can be specified as a synonym of REOPT(ALWAYS)
  • 2 NOREOPT(VARS) can be specified as a synonym of REOPT(NONE)
  • 3 The PATHDEFAULT keyword cannot be specified with the PATH keyword.

enable-block

Read syntax diagramSkip visual syntax diagramENABLEDISABLE(,BATCHDLIBATCHDB2CALLCICSIMSIMSBMPIMSMPPRRSAF)ENABLE( *)DLIBATCH(,connection-name)CICS(,applid)IMSBMP(,imsid)IMSMPP(,imsid)

pklist-block

Read syntax diagramSkip visual syntax diagramPKLIST(,location-name*.collection-id*.package-id*)NOPKLIST

Descriptions for REBIND PLAN

(plan-name)
Specifies the name of the application plan to rebind, as stored in the NAME column in SYSPLAN catalog table.
(*)
Rebinds all plans for which the applicable authorization ID has the BIND privilege. The applicable authorization ID is:
  • The value of OWNER, if you specify it. See OWNER bind option.
  • The authorization ID of the process running the bind, if you specify the OWNER option.
Other options for REBIND PLAN

For descriptions of the options shown in the syntax diagram, see the topic BIND and REBIND options for packages, plans, and services.

Usage notes

Rebinding multiple plans
If you rebind multiple plans, Db2 commits each successful rebind before rebinding the next plan.
When you cannot rebind a plan
You cannot rebind a plan while that plan is executing.
Trace information for data sharing members
When this command with group scope is issued in a Db2 data sharing member, it also runs on all other active members. IFICID 090 trace records for other group members can show that the same command was issued by the SYSOPR authorization ID from the 016.TLPKN5F correlation ID, in addition to the trace records from the member where the original command was issued. See Command scope in Db2 data sharing.

Examples

Example: Rebinding a plan to replace the package list
Suppose that PLANA uses package list COLLA.* Suppose that you want to replace that package list with COLLB.* Issue a command like this one:
REBIND PLAN (PLANA) -
  PKLIST(COLLB.*) -
  FLAG(W) -
  VALIDATE(BIND) -
  ISOLATION(CS)

This REBIND command also does the following things:

  • Uses FLAG(W) to issue warning, error, and completion messages, but not informational messages.
  • Uses VALIDATE(BIND) to point out any error conditions during the bind process.
  • Uses ISOLATION(CS) to prevent other applications from changing the database values that this application uses only while the application is using them. This isolation level protects changed values until the application commits or terminates. In this example, the isolation is not set for the packages, so ISOLATION(CS) becomes the isolation level for the plan and the packages.
  • Omits the OWNER keyword to leave the plan's owner authorization ID the same.
  • Omits the ENABLE or DISABLE keywords to use the connections previously defined for the plan.