More information:

http://www.ibmdatabasemag.com/story/showArticle.jhtml?articleID=15300107

http://www.ibmdatabasemag.com/story/showArticle.jhtml?articleID=17602333

The bind process establishes a relationship between an application program and its relational data. This step is necessary before you can execute your program. Currently,DB2 allows you two basic ways of binding a program: to a package, or
directly to an application plan.

BIND PACKAGE subcommand allows you to bind DBRMs individually. It gives you the ability to test different versions of an application without extensive rebinding.

BIND PLAN establishes the relationship between DB2 and all DBRMs or packages in that plan. Plans can specify explicitly named DBRMs, packages,collections of packages, or a combination of these elements. The plan contains information about the designated DBRMs or packages and about the data the application program intends to use. It is stored in the DB2 catalog.

one program with sql-statements gives one dbrm, which must be bound (BIND), for db2 will recognize it. Thus, if you have a run-unit with, let's suppose 10 subprograms with sql-statements, you will also have 10 packages in db2 (one dbrm gives one package after the BIND).

in the package, there is the optimized access path for the desired data requests upon the last RUNSTATS (i.e. data statistics)

in the plan you define which package-lists are allowed to access,
therefore if you have all existing package-lists in your plan defined,
you will never need to BIND your plan again.

arlier version of DB2 had only bind plan.New versions have both.

package is not executable, while plan is the executable path to access your database in an optimized way.

Difference is that, if you have a program A and a sub pgm B.
If you have separate packages for both, when you change sub pgm you have to compile and bind only the sum program.Not the pgm A. Basically it makes the sub program independent.

[@more@]A plan may contain multiple packages and pointers to packages. The one program would then exist in a package that could be referenced in two different plans.

It is compulsary to use plan name for every DB2 program because the Cobol we are using dont know how to access the DB2 resources. That Information will be there in Packages and Plans.

A plan is an executable module containing the access path logic produced by the DB2 optimizer. It can be composed of one or more DBRMs and packages. Before a DB2 for z/OS program (with static SQL) can be run, it must have a plan associated with it.

Plans are created by the BIND command. The plan is stored in the DB2 directory and accessed when its program is run. Information about the plan is stored in the DB2 catalog.

A package is a single, bound DBRM with optimized access paths. By using packages, the table access logic is "packaged" at a lower level of granularity than a plan -- at the package (or program) level.

To execute a package, you first must include it in the package list of a plan. Packages are not directly executed, they are only indirectly executed when the plan in which they are contained executes -- as discussed previously, UDFs and triggers are exceptions to this rule. A plan can consist of one or more DBRMs, one or more packages or, a combination of packages and DBRMs.

ITPub博客

What the difference between Bind plan and Bind package?

最新文章