The Runtime Profile (RPROF) Table for DB2 › How to Build RPROF Tables

How to Build RPROF Tables

The BLDRPROF job builds an RPROF table and indexes. CEINSTAL builds the BLDRPROF job when you set the Install Construction flag on the Set Encyclopedia Variables screen to Y.

One RPROF table can serve all applications on a DB2 subsystem, and possibly an entire business system. Although an RPROF can appear to be a bottleneck, a large, properly maintained RPROF can support over 400,000 transactions per day, without the contention.

The strategy that you deploy to recover the RPROF table or other table that is used by an application using RPROF determines how many RPROF tables you create. For example:

• If a CA Gen style transaction restart is important, synchronize the point of RPROF table recovery with the remaining application tables. This type of RPROF is considered a user table because other applications cannot share it, and they remain synchronized after a recovery.
• If a CA Gen style transaction restart is unimportant, many applications can share the RPROF table and it is considered a system table.

A damaged or destroyed RPROF table must be recovered because an empty RPROF causes contention problems.

When you build a new RPROF table, execute the CEJOB15R job to bind the runtime DBRM TIRPROFD to access the new RPROF table.

When you use an RPROF table that is created in a previous version of CA Gen, still execute the CEJOB15R job to bind the current version of the runtime DBRM TIRPROFD to use the existing RPROF table.