Overview of DEDB analysis and tuning
DEDB tuning typically involves setting the database and area attributes to minimize the physical I/O requirements.
Subsections:
Understanding the parts of a DEDB area
- Root addressable area part (RAA)
- Independent overflow part (IOVF)
- Sequential dependent part (SDEP)
A UOW consists of a user-specified number of CIs located physically contiguous. Each UOW in the RAA part is further divided into a base section (BASE or RAA BASE) and a dependent overflow section (DOVF).
The BASE section contains CIs of a UOW that are addressed by the randomizing module by using the root anchor point (RAP) that is allocated for each of those CIs. These CIs are often referred to as RAP CIs.
The DOVF section is used as a logical extension of a CI within that UOW, and are shared by all RAP CIs in the UOW. Root and direct dependent segments are stored in the BASE section. However, both can be stored in the DOVF section if free space in the RAP CI for the root segment is not enough.
The IOVF part contains CIs that can be used by any UOW in the area. When a UOW gets a CI from the IOVF part, the CI can be used only by that UOW. A CI in the IOVF part (IOVF CI) can be considered an extension of the DOVF section in the RAA part. The IOVF CI remains allocated to a specific UOW unless, after a reorganization, it is no longer required, at which time it is freed.
Physical I/O requirements typically depend on how these parts and sections are used.
For more information about the parts of DEDB areas, see the topic "Parts of a DEDB area" in IMS Database Administration.
Major tuning factors
DEDB tuning is a subjective process. Tuning decisions that you make depend on application activities that were performed and that will be performed against the database. Generally, however, you must consider the following factors:
- Free space utilization
- Predetermining the reorganization criteria to maximize the free space utilization
- Definition and sizing of UOW and overflow
- Selecting the optimal CI size and the UOW and ROOT parameter values to minimize the overflow to IOVF
- Randomizing efficiency
- Tuning the randomizer to optimize utilization of RAP CIs and to minimize overflow of database records
Typical performance characteristics
A tuned DEDB area has certain performance characteristics. A well-tuned area typically has the following characteristics:
- No or modest use of IOVF
- The percentage of UOWs that use IOVF is low or zero.
- The average and maximum numbers of IOVF CIs that are used by a UOW are low.
- The percentage of database records that use IOVF is low.
- Sufficient free space in RAA for each UOW
- The percentage of free space in each section of the area—that is, the RAA BASE section, the DOVF section, and the IOVF section—is sufficient after a free space reorganization.
- The percentage of available IOVF CIs is sufficient so that IOVF CIs are not used up during application activities.
- Minimum I/O to access both root segments and database records
- The average and maximum physical I/O that is required to retrieve a root segment are few.
- The average and maximum physical I/O that is required to retrieve a database record are few.
DEDB tuning involves understanding how each DEDB area satisfies the criteria that you set on these performance characteristics and determining the best approach to resolve exceptions to achieve the ideal state of the area.
Criteria for triggering tuning activities
The following criteria are good indicators of how efficiently space is being used and of the overall performance of a DEDB area.
- Overflow usage
- Free space availability
- Free space relationship
- Root I/O
- Record I/O
- Synonym chain
You can use Policy Services to set rules for these six types of criteria. Policy Services uses these rules to detect exceptions based on the criteria and thresholds that you defined for measuring space and performance characteristics. Exceptions that are detected indicate that you likely need to start analyzing and tuning the database with the exception condition. You can also use rules for detecting free space fragmentation exceptions, which identify the need for free space reorganization.
The rules are defined in reorganization policies through Policy Services. Autonomics Director automates the process of exception detection based on the defined policies. For a scenario of policy-based database monitoring, see Scenario: Policy-based database monitoring and tuning.