Bind Facts

Table of Contents
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

What is Performed at bind time? What is the difference between a plan and a packages? Should I only use one plan containing all packages? Should I use RELEASE(COMMIT) or RELEASE(DEALLOCATE) on my package bind? What does the bind paramter CURRENDATA have to do with lock avoidance? When should I use uncommiteed read (UR)? What is the best locking option if I need to read or update an entire table? When should I rebind my packages? How often should I commit? Should online transactions commit? Is there a way to prevent lock escalation caused by programs?

What is Performed at bind time?

During the Bind process, the syntax of each SQL, statement in the database request model (DBRM) is validated for table and colulmn difinitions and optionally, authorizations. If all ot the previous check are successful, the optimal access path of each SQL statement is determined by the optimizer and placed int the database. Each package or plan will have an entry in the database that contains segments with individual access paths for every executable SQL statement within the plan or package. The optimizer determines the optimal access path. The access path is based on DB2 catalog statistics gathered on indexes, data organization, and table size, as well as buffer pool specifications, number of processors, and other pertinent information.

What is the difference between a plan and a packages?

A DBRM can be bound in a package or directly into a plan. In addition, packages can be bound into logical groups called collections. These packages or collections can then be ound into a plan. A package can be bound for only a single SQL statement, for a subset of the program, or for an entire program, and it will contain information representing optimized SQL, which may just be an access path for the SQL to use to process the data required, or it could be information representing an SQL statement that was first rewritten by the optimizer. A plan can be bound for multiple packages, collections, and/or DBRMs. Each package can be bound independently of a plan, If a DBRM is bound to a plan and then is rebound, all DBRMs are rebound as well.

Should I only use one plan containing all packages?

It is extremely diffcult to justify the use on ibe one plan containing all the packages for an installation or even all CICS transactions or batch jobs. Plans need to be granular, the same as all other definitions. Large cumbersome plans cause performance degradation, buffer pool problems, and EDM pool problems. The number of packages put into a single plan need to be based on fuctinality, such as all the packages supporting a particular function of an on-line application. Generally, each batch job should bave a separate plan, which could be comprized of certain collections, but should be as specific as possible.

Should I use RELEASE(COMMIT) or RELEASE(DEALLOCATE) on my package bind?

Using the RELEASE(COMMIT) optionon the bind package statement will release table and tablespace intent locks (IS IX) at each commit point. Use of this parameter will destroy information required to help performance. One area is which this can occur is in programs doing multiple inserts and updates against the sam table. DB2 will monitor the inserts and then after every third insert, it internally builds an executable procedure to perfrom this process so that is does not have to continually build the code necessary to perform subsequent inserts. This procedure is referred to as an IPROC. There is a similar concept used for updates called a UPROC. If you used the RELEASE(COMMIT) parameter in conjuction with a frequently

committing program the IPROCs/UPROCs are built and then destroyed before they provide very much benefit, but after the overhead to them was incureed. ALso, the cache used for sequential detection to determine the cache used for sequential detection to determine when to turn on dynamic prefetch is also erased, as well as the cache used for index lookaside operations to help DB2 avoid index probes. Losing the special code created by using RELEASE(COMMIT) can cause performance degradationin programs with heavy inset/update operations. Binding a program with the RELEASE(DEALLOCATE) option will solve this problem; this option should be used for the majority of batch programs and for some online programs. This will allow for the UPROCs/IPROCs and caches to remain until the end of the program despite the commits. The DEALLOCATE option will hold intent lock through to the end of program; however this will not cause any concurrency problems because page locks and row locks are still released when a commit is performed. When choosing to bind programs with RELEASE(DEALLOCATE), be careful and approachthis wisely. If CICS thread reuse is used and you rebind the heavily used transactions with RELEASE(DEALLOCATE) you will begin to equire more memor in the EDM pool. Do not just perform a mass rebind using RELEASE(DEALLOCATE) bring into play maybe as 80/20 rule for program rebinds. (80% of the processing is normallly consumed by only 20% of the programs or transactions).

What does the bind paramter CURRENDATA have to do with lock avoidance?
DB2 will check to be sure that a lock is probably necessary for data integrity before acquiring a lock. In order to achieve lock avoidance, you need to have your programs bound with CURRENDATA(NO).

When should I use uncommiteed read (UR)?

The most practical use of UR is retrieving read-only data, and the more the better. Up to 30 percent of CPU time can be saved from longrunning queries. Another use for UR is estimating. This occurs when summary

information is needed, but the answer does not have to be exact. Browsing rows of data is another good use of UR; for example, an online application tht is displaying a list of rows. Ater the list is displayed on the of the rows is selected, a second screen can retrieve the detail using a stricter isolation to enforce proper locking.

What is the best locking option if I need to read or update an entire table?
You can save the overhead of multiple lock acquisitions needed for locking table data by using the LOCK TABLE statement. This statement will allow you to lock an entire table in either share mode or exclusive mode. This lock will be held until the end of the transaction. This will not allow concurrent transactions to either read/update the table, the transaction that issued the lock-table statement may finish more quickly because it will not have to wait on locks or find that data is unavailable due to locks held by other transactions.

When should I rebind my packages?

Packages should be rebound when any of the following are true, based on current statistics from the catalog: Changes greater then 20% (NLEAF,NPAGES,NACTIVE) Clusterratio less then 80% NLEVELS increasesgreater then 2 HIGH2KEY and LOW@KEY ranges change greater then 10% Cardinality and ROW Count change greater then 20%

How often should I commit?

There are two good reasons to commit: to improve concurrency and to prevent massive, long-running rollbacks when abnormal terminations occur. Even programs that have no concurrency problems should at least to a commit every 10 minutes as a general rule.

When you do commit processing, you have to identify the unit of work in your program and also design the batch program such that it is restartable. When concurrency is an issue you probablly want a commit frequency somwhere between 2 seconds and 20 seconds. A very good practice is to make sure the commit frequency can be influenced fromt he outside. Identify a logical lunit of work in lyou program an execute this x number of times before doing a commit. The magic number x could come forma control card to your program or from an heuristic control table. This way, programs that cause concurrency problems can be tuned, and you could also have separate settings depending on the time of day.

Should online transactions commit?

No, it is not good practice to do intermittent committing in online transactons rater than commit at the end of the transaction.

Is there a way to prevent lock escalation caused by programs?

If you need to lock and cannot frequently commit, consider the use of SQL LOCK TABLE statemetns. Your program will have an S or X lock on the table so you will not have the problem of page or row locks escalating to table locks automatically, potentially causing problems with lock contention.