DB2 BIND

                                              BIND

1.         Two method of BIND

l         Bind all DBRMs directly into one application plan as below

BIND PLAN(PLAN1) MEMBER( Main ,Sub1,Sub2)

l         Bind each DBRM separately into a package, and then associate these packages with an application plan as below

BIND PACKAGE(COL1) MEMBER( Main )

 BIND PACKAGE(COL1) MEMBER(Sub1)

BIND PACKAGE(COL2) MEMBER(Sub2)

BIND PLAN(PLAN2) PKLIST(COL1.*,COL2.Sub2)

The advantage of the second method is if you change one source program, you only have to precompile it and bind the corresponding package, not the whole plan.

The Access Path are determined at BIND Package and stored with each package.

2.         Let BIND determine object to be accessed

Assume that your test and production environments run on the same DB2 subsystem. When you want to promote your application from the tables with the TEST qualifier to tables with PROD qualifier, and you won’t want to change all your source programs, what should you do?

Omit the table qualifiers in SQL statements in your source programs and specify the qualifiers at bind time.

l         BIND PLAN(PLAN1) MEMBER(PROG1)

When you specify neither the plan OWNER nor the table QUALIFIER then the bind userid becomes the qualifier of non-qualified table name in your program.

l         BIND PLAN(PLAN1) MEMBER(PROG1) OWNER(TEST)

When you only specify the plan OWNER, the plan owner is used as the qualifier for all non-qualified table name

l         BIND PLAN(PLAN1) MEMBER(PROG1) OWNER(TEST) QUALIFIER(PROD)

When you specify the plan QUALIFIER, this parameter becomes the qualifier of non-qualified table name in your program. This is so for both packages and plans.