X hits on this document





202 / 236

Database I/O Waits

Database I/O Waits


Many database DL/I requests can be satisfied from records already in a buffer pool. Others, however, require that IMS perform physical I/O. MDEX and PDEX show a subtotal for database I/O. Then, if you specified that such statistics be kept by the collector, it shows the breakdown of the I/O by database. No further breakdown, such as by dataset group or individual dataset, is available from Bottleneck Analysis.

The individual execution states within this category are the DMB names of each database to which a thread did I/O.

A wait reason of INDEXPCB indicates I/O activity caused by secondary index maintenance. When maintenance is performed on a secondary index, IMS constructs a PCB to that index. Although you may not be processing in secondary sequence, I/Os to a secondary index may be caused by:

Designing your database so that the segment or fields used as the key in secondary sequence are updated heavily by other applications.

Changes to the primary database. Even if the application program is not using the secondary index, maintenance must be performed on the index, and a PCB constructed for it, when the primary database is changed.

Also, there is no way to tell from the Database I/O Waits statistic alone which stages of I/O processing (for example, active on the UCB or waiting in the logical channel queue) the I/O operations for the databases were in. A tool such as Bottleneck Analysis can give you some view of this.

In addition to IMS/VS full-function databases, physical I/O operations performed to data entry databases (DEDBs) are also reported. If statistics by database are requested, the area name is shown as the execution state.


OMEGAMON II for DBCTL Historical Component (EPILOG) Reference Manual Version 510

Document info
Document views1440
Page views1440
Page last viewedSat Jan 21 02:47:59 UTC 2017