A description of the fields in the Program Summary report follows:
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.
Indicates the number of times the program was run.
Indicates the average number of pages physically read from disk for each run of the program.
Indicates the average number of pages physically written to disk for each run of the program.
Indicates the average number of calls to IDMSDBMS issued for each run of the program.
Indicates the average number of database records requested by IDMSDBMS for each run of the program.
Indicates the ratio of number of pages requested to pages read.
Interpretation: This ratio indicates 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 may be random or that the buffer-pool size may be too small.
Particular attention should be given to frequently used programs. If the ratio for a program is below 2.0, users can look at the statistics generated by JREPORT 003 to determine whether the number of pages requested and pages read were 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.
Indicates the ratio of records requested to records made current-of-run-unit.
Interpretation: The effectiveness ratio indicates the amount of work CA IDMS/DB is doing for the programmer (that is, how many records IDMSDBMS has to examine to find the one requested). The lower the ratio the better. If the ratio is very high, examine set options (for example, sort order or next pointers only) for appropriateness. If the options are correct, examine the program logic for accurate use of currency.
Indicates the ratio of the number of CALC records stored on their target page to the total stored (that is, hits plus overflows). The ratio reflects the efficiency of the CALC algorithm.
Interpretation: The CALC cluster ratio is especially important when the database is loaded or restructured. Ideally, the ratio should be 1, which indicates no overflow. Ratios less than 1 or less than the norm indicate that space utilization is getting high and database tuning should be performed.
Indicates the ratio of records requested by IDMSDBMS to pages read from the database.
Interpretation: The space management ratio measures how well space is allocated (for example, VIA options, CALC distribution, and buffering). The higher the ratio the better. Ratios less than 4 or less than the norm indicate that the size of the buffer should be increased and database tuning should be performed.
Note: The space management 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.
Specifies the ratio of VIA records stored on the same page as their owner to the total number of VIA records stored (that is, hits plus overflows). The ratio reflects how well VIA records cluster around their owner.
Interpretation: The VIA cluster ratio gives an indication of VIA storage requirements and is an indirect measure of the amount of space still available in the area. Ideally, the ratio should be 1, which indicates no overflow. Ratios less than 1 or less than the norm indicate very large data clusters, high utilization of space, or small page size. The cause may be a database design in which there are too many VIA records (of a particular record type) or in which the VIA records are too large.
|
Copyright © 2013 CA.
All rights reserved.
|
|