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.
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:
|
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:
|
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:
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:
|
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:
|
PKLIST, specifying individual packages | Authorization ID of the process must include one
of the following authorities:
|
PKLIST, specifying (*), indicating all packages in the collection | Authorization ID of the process must include one
of the following authorities:
|
Syntax
- 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.
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.