Previous Topic: JREPORT 003 - Program I/O StatisticsNext Topic: JREPORT 004 - Program Summary


Field Descriptions

A description of the fields in the Program I/O Statistics report follows:

PROGRAM

Identifies the name of the program to which the information applies.

Note: For non-SQL transactions, the subschema control supplies the name of the program. If the program name is blank, then the program issued a BIND RUN UNIT before moving its name to the name field in the subschema control.

For SQL transactions, the RCM for the program initiating the transaction supplies the name of the program.

NODE

Specifies the node name of the central version on which the transaction executed. If the journal being analyzed was created in local mode, this field will contain *local*.

TRANSACTION ID

Is the unique identifier (LID) assigned to each transaction associated with the program. Transactions that terminate abnormally are flagged as ABORT.

PAGES READ

Indicates the number of pages physically read from disk for the transaction.

PAGES WRITTEN

Indicates the number of pages physically written to disk for the transaction. A page can be updated several times before it is actually written back to the database.

PAGES REQUESTED

Indicates the number of pages requested by IDMSDBMS (including pages found in a buffer). A page request does not result in a page read if the page is in the buffer pool.

Interpretation: The ratio of pages requested to pages read is the buffer utilization ratio. It measures the effectiveness of the buffer-pool size and design of the database (for example, CALC and VIA clustering). The higher the ratio the better. Ratios consistently below 2.0 indicate that processing is random or that the buffer-pool size is too small. The information in JREPORT 003 indicates whether the ratio is constant for all executions of the program or only for certain transactions.

Note: The buffer utilization ratio may be artificially high for transactions that keep locks. IDMSDBMS cannot hold a buffer while waiting for a lock; therefore, when locks are kept, IDMSDBMS must free and request a page each time a lock is requested for which a wait must occur.