Analyze the optimization exceptions that were detected
for HIDAM and PHIDAM databases.
Before you begin
Ensure that you can access the Sensor Data
Statistics report that contains the latest sensor data. If you cannot
access this report, run the FF DB Sensor Printing utility to generate
the report.
About this task
In the following procedure, you will analyze
each optimization exception that you received for HIDAM databases
or PHIDAM partitions.
For each exception that
was reported, you will first identify the relevant data elements to
understand the condition of the database. Then you will analyze the
relevant IMS Tools reports to
learn more about the database state. Finally, if you use Management Console
or Administration Console and if
relevant sensor data charts are available, you will analyze historical
trends of sensor data to understand the trend characteristics of the
sensor data that was obtained from the database or partition.
By
completing these steps, you will determine the possible causes of
the optimization exception. The causes can be the block or CI size
not matching the average database record length, the existence of
long database records, or both.
Procedure
Follow the instruction to analyze the AVERAGE_DB_RECORD_LENGTH exception.
- Exception class name: AVERAGE_DB_RECORD_LENGTH
- This exception indicates that the average length of database records has exceeded the
threshold.
- This exception does not always indicate a problem in the database. When the database record
length is long, the segments that belong to a same database record might be spread across multiple
CIs or blocks, and might be causing extra I/O operations.
- You can identify whether extra I/O operations are required by reviewing the
DB_ESTIMATED_DBREC_IO data element value. When the value is small, you do not need to analyze this
exception. The smallest value, which typically is the optimal value, is the number of data sets. If
this value is large, you can improve the condition by reorganizing the database; however, you might
be able to improve the condition even further by performing optimization tuning (that is,
determining optimal DBD definitions and applying the changes).
- The method that you use to analyze the database depends on the number of database data sets:
- Single data set
- When a database has one data set, all segments reside in that data set. In the most optimized
condition, all the segments that belong to a same database record reside in the same CI or block.
However, when fragmented IMS free space is shorter than the
database record, which means that all segments that belong to the database record cannot be stored
in a single CI or block, IMS places some of the segments in
other CIs or blocks. This state can cause extra I/O operations.
- To determine if extra I/O operations are occurring, locate the following data elements in the
Sensor Data Statistics report:
- DB_AVG_DBREC_LENGTH
- The value for this data element indicates the average length of database records.
- DB_NUM_ROOT
- The value for this data element indicates the number of root segments (that is, the number of
database records).
- DB_BLOCK_SIZE
- The value for this data element indicates the CI or block size.
- DB_ESTIMATED_DBREC_IO
- The value for this data element indicates the estimated number of I/O operations that are
required to read a database record (that is, the average number of reading different CIs or blocks
to read the root segment and all dependent segments by tracking the hierarchical path).
Note: The
value is an estimated value; the actual I/O count might be different.
To obtain more information about the segment distribution, run the HD Pointer Checker utility
of IMS HP Pointer Checker, or IMS HP Image Copy with the HDPC=YES option, and generate the DB Record Distribution Statistics
report.
- By reviewing the Distribution of dependent segments by segment code part, you can determine, for
each segment type, the number of segments that are not in the block or CI where its root segment is
stored, and the distribution of these segments across different CIs or blocks.
- The information in this report can be a good indicator for tuning the CI or block size to
prevent database records being spread across different CIs or blocks.
- Multiple data sets
- When a database has multiple data sets, the segments that belong to a same database record can
be stored across multiple data sets. Therefore, reviewing the average database record length will
not help you identify the data sets in which the segments that increased the database record length
reside. To identify the data set that has the most occurrences of scattered segments, follow the
analysis steps for the EXCESSIVE_SEGMENT_SCATTERING exception (a fragmentation exception).
- If you identify excessive segment scattering in data set group 1 (DSG1), obtain more information
about the segment distribution by running the HD Pointer Checker utility of IMS HP Pointer Checker, or IMS HP Image
Copy with the HDPC=YES option, and generate the DB Record Distribution Statistics report.
- By reviewing the Distribution of dependent segments by segment code part, you can determine, for
each segment type, the number of segments that are not in the block or CI where its root segment is
stored, and the distribution of these segments across different CIs or blocks within DSG1.
- Together with the CI or block size, this information can be a good indicator for tuning the CI
or block size to prevent segments being spread across different CIs or blocks.
- If excessive segment scattering was not observed in DSG1, you do not need to perform
optimization tuning. Reorganizing the database will resolve the exception.
- The average database record length can be a trigger to start database analysis.
In the following sensor data charts of Management Console
or Administration Console,
you can review the trend of the average database record length and the number of database
records:
- Average Database Record Length chart
- Number of Database Records chart
Understanding the trend over time can help you anticipate
the future behavior of the data sets. Use this knowledge to determine
when you might need to take preventative action and to establish efficient
maintenance plans.
- You have now obtained information about the current database state that caused this exception.
You will use this information later to determine the appropriate action to resolve the
exception.
- You also identified the sensor data charts that can help you establish maintenance plans to
prevent this exceptional state from occurring in the future.
What to do next
If you received other exceptions that belong to other
exception categories, see the following topics to determine your next
step:
If the only exceptions that you received are optimization
exceptions, continue with Resolving optimization exceptions for HIDAM and PHIDAM databases.