Default language.

Space announcement The Using section of the MainView for DB2 documentation is now available in Japanese. The displayed language is dependent on your browser language. You can switch languages from the Language menu.

Contents of performance data tables


The performance data tables are the main source of historical information for Performance Reporter.

These tables can be created initially as detailed accounting, statistics, buffer, and audit tables. Each table contains:

  • One row for each accounting record (DMRACDTL)
  • One row for each package in accounting records with class 7/8 active (optional) (DMRAPDTL)
  • One row for each buffer pool accessed (optional) (DMRABDTL)
  • One row for each DDF destination location (optional) (DMRADDTL)
  • One row for each dynamic and group buffer pool attribute (DMRDGPDT)
  • One row for each statistics interval generated by a DB2 system, including buffer pool data summarized into totals for all pools (DMRSTAT)
  • One row for each statistics interval per single buffer pool (optional) (DMRSBFDT)
  • One row for each statistics interval per DDF destination location (optional) (DMRSTDF)
  • One row for each audit record (DMRAUxxx)
  • One row for each statistics system storage records (DMRSTSDT)
  • One row for each statistics Address space storage records (DMRSTADT)
  • One row for each statistics simulated Buffer pool records (DMRSYDTL)
  • One row for each statistics accelerator records (DMRSXDTL)
  • One row for each statistics DDF records (DMRSTDF)
  • One row for each accelerator accounting records (DMRAXDTL)

Definitions are also provided for two sets of accounting summary tables. For example, DMRACDTL can be summarized into DMRACSUM (perhaps hourly), which could be summarized into DMRACSM2 (perhaps daily). Accounting records, which might occur in high volumes, can be loaded into a DB2 detail table or summarized first and loaded directly into a summary table.

Table release dependencies and migration

The table contents can change from one release of MVDB2 to another, mainly to add columns supporting new DB2 release information.

When migrating to a new release of MVDB2, you must usually define the new tables with unique names. All related jobs and reports must be run only with the tables created by that release of MVDB2.

When you are ready to move a new release into production use, you may want to migrate the data in the previous tables to the new table format. The member DPJMIGR in BBSAMP contains a sample job to migrate tables from the previous release. For more information, see Preparing-tables-for-Performance-Reporter.



 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*