The Runtime Profile (RPROF) Table for DB2 › How to Improve Concurrency

How to Improve Concurrency

The RPROF is designed for the maximum concurrency by ensuring there is no less than one logical RPROF record per DB2 data page, and one index record per DB2 index subpage.

The following techniques improve concurrency:

• Reorganize RPROF weekly to keep data and index in sequence.
• Embed FREEPAGEs in data and leave 90 percent of the index free.
• Do not make RPROF too small. A small RPROF can cause serious concurrency problems, due to too few entries in the index.
• For most applications, an RPROF table with at least 625 rows allows a satisfactory level of availability. In the applications with an high transaction volume, it is necessary to prepopulate an RPROF to add permanent rows that establish the index tree structure.
• Prepopulation is unnecessary when you use type 2 indexes.

One way to prepopulate an RPROF table is to load rows for each unique user ID, that is, IETUID. The prepopulated rows have an application ID, that is, an IETAPPID, outside the range of valid application ID numbers, so the application reset does not remove the row.

The permanent rows provide an index structure that eliminates most contention, because the high-level key entries already exist, and applications do not have to wait for index page splits or abend with a DB2 -911 error.