Difference between Package and Plan in DB2.

[Ruchi2 T]

Hi,

I know that Package is the executable access path code for the sql statements in the DBRM while plan contains package list which is nothing but pointers to packages. But they were same long back, so for the binding process, is there a difference between binding Package and binding a Plan?

[nicc]

But they were same long back

No they were not - "long back" (I assume you mean back in time) packages did not exist and were introduced to better handle some of the intricacies of application design.

[Ruchi2 T]

Yea, I meant that. Is there a difference in saying "long back" and "back in time"??

But back to my question... is there a difference between binding Package and binding a Plan?

[Akatsukami]

Absolutely; packages have a one-to-one relationship to source modules. A plan is a group of packages; it will correspond to one or more load modules.

[Anuj Dhawan]

is there a difference between binding Package and binding a Plan?

When you write a BIND parameters for PALN or PACKAGE, you can specify many bind parameters in DB2. Among them, some of them are for PLANs, some are for PACKAGEs and some are for both. Some are for PACKAGEs and triggers. Which object type you’re attempting to bind controls which parameters you can work with. But, as such, the command spells the same.

The bind process, BIND PLAN or BIND PACKAGE, establishes a relationship between an application program and its relational data. This step is necessary before you can execute your program. DB2 allows you two basic ways of binding a program: to a package, or directly to an application plan - as you've also stated about it in your question itself.

A package is an executable representation of a single DBRM. The story about PLANs goes back to the era when the DBRMs, representing the programs, linked into a single load module were all bound into a single plan. A single DBRM is changed and the entire plan had to be bound. If the DBRM was used in more than one plan, all plans containing that DBRM had to be bound. Depending on the number of DBRMs included in a plan, this could be a lengthy, disruptive process. We needed something to solve it and PACKAGEs came to rescue. I think this all should be enough for that one line of statement quoted above, yes/no?