IBM Support

Hints and tips for efficient database recovery

General Page

In today’s world, IT infrastructure has become a cornerstone for business management, and it is essential to maintain IT infrastructure to conduct operations. In this environment, it is important to develop an efficient plan to prepare for situations that require recovery of IMS databases. To do so, it is also necessary to estimate the time needed for recovery.

However, providing an estimate of recovery time is difficult because it depends on a wide range of factors.

This document introduces how to manage your IMS resources to reduce recovery time of IMS databases.

Note: Other factors such as CPU performance and storage volume are also key factors, but this document focuses solely on IMS resources.
Factors that affect recovery time
In general, a database recovery job restores a database using a backup (image copy), IMS log data sets, and Change Accumulation (CA) data sets as input. Once the database is recovered, the recovery job rebuilds index database and ILDS (for HALDB only). The recovery time depends on a range of factors such as database size, frequency of backups which impacts the number of log records required for recovery, frequency of database updates, number of indexes, and whether logical relationships exist.
The following factors affect the time required for recovery:
  • Number of database data sets/area data sets to be recovered in one recovery job, including indexes and secondary indexes.
  • Type of database, configuration, and definition (whether logical relationships exist.)
  • Physical size of each database data set/area data set.
  • Time elapsed since the last backup.
  • Number of RECON records.
  • Method to create backups.
  • Number of transactions, including database updates, and frequency of database updates.
  • Whether a recovery point exists between the specified recover-to time and the creation time of the CA data sets closest to the specified recovery time.
This document provides hints and tips on IMS system management, database management and backup methodologies to reduce recovery time.
Considerations for IMS systems management
To shorten database recovery time, it is effective to reduce the number of physical log records used as input. The following sections explain how to reduce the number of physical logs that the system reads for recovery.
Creating recovery log data set (RLDS)
The Recovery Log Data Set (RLDS) contains only the log records required for recovery, so its size is smaller than the System Log Data Set (SLDS). Because the RLDS does not contain log records that are unnecessary for recovery, the use of RLDS is expected to reduce recovery time.
RLDS information is recorded in the PRILOG and SECLOG records in the DBRC RECON data sets. If possible, always use RLDS instead of SLDS when you recover a database and run the Change Accumulation utility.
By using the Log Archive utility, you can create the RLDS at the same time that you create the SLDS.
Optimizing system log data set (SLDS)
When creating the SLDS by using the Log Archive utility, you can create the SLDS without log records that are unnecessary for recovery by using the NOLOG option.

When archived, the following five types of log records can be removed:

X'10'           Security violation records

X'45'           Statistics records written during checkpoint

X'5F'           Call trace record

X'67'           Communications (SNAP) trace records

X'69'           Unauthorized ID record (for 3275 display terminal)

The SLDS contains records that may be required for batch backout or IMS restart, so it is more effective to use RLDS when you want to reduce the number of log records that the system reads for recovery.
Creating Change Accumulation (CA) data sets
CA data sets contain simplified database update information to be passed to database recovery utilities. CA data sets have only the recovery information that is necessary for the database defined in a DBRC CAGROUP with the SLDS or RLDS as input. For each database, information from multiple logs is merged into one record and sorted in physical order. This reduces the number of update log records to be read during recovery, thus shortening the recovery time.
Running change accumulations frequently can be an effective method to shorten recovery time. However, you should consider multiple factors in your decision about how often or if you will run change accumulations:
  • For IMS to use a CA data set as input to recovery, a recovery point must be created after each change accumulation is executed.
  • Change accumulations are required for recovery in data sharing environments if you are using the base IMS recovery utilities.
  • Performing change accumulations regularly will consume MSUs to create data sets that will only be used if you need to recover. Consider the benefit of creating change accumulations versus the system resources that it consumes.
  • If you decide to run regular change accumulations, IBM IMS High Performance Change Accumulation can help reduce MSU consumption by:
    • Running multiple change accumulation groups in parallel while reading the logs only once.
    • Streaming the logs that have been read to each group simultaneously.
  • An alternative to running regular change accumulations is to run image copies more frequently.
    • IBM IMS High Performance Image Copy can reduce MSU consumption for image copies by using advanced copy technology, such as FlashCopy, in your storage hardware. This offloads the I/O to the storage device.
    • Running image copies more frequently will consume more storage.
  • Consider running change accumulations only during a recovery process and only if it will add value based on testing in your environment.
Database management and backup
Another factor impacting recovery time is database definition and backup method, as described below.
Setting index databases as nonrecoverable
Creating a backup as a concurrent image copy does not support KSDS data sets except in some cases. Therefore, recovery of an index database requires an older batch image copy and a large amount of subsequent log records, which results in longer recovery time. 
Primary index databases of HIDAM and secondary index databases can be rebuilt using IMS Index Builder, which is faster than recovering from backup data sets and log records. This also means you can reduce MSU consumption by not backing up the index databases.
To improve recovery time by making index databases non-recoverable, specify nonrecoverable (NONRECOV) for index databases in DBRC and specify NOICREQ for the IMAGE COPY NEEDED option. By specifying nonrecoverable, each time the data in the database is updated, IMS logs only the data as it exists before the update. IMS does not log the data as it exists after the update. This reduces the amount of data in both the SLDS and RLDS, which helps shorten the recovery time. It can also help reduce MSU consumption.
Exceptions:
  1. PHIDAM primary indexes are always nonrecoverable, so no updates to DBRC are needed for these indexes.
  2. When rebuilding indexes during recovery for a PSINDEX database, the system scans all partitions while rebuilding indexes. This can be a lengthy process if the number of HALDB partitions is large. Consider specifying recoverable for PSINDEX databases for HALDB databases with a large number of partitions.
Creating VSO DEDB backup and managing database
When VSO DEDB is used in a common buffer, updated data in database records is not written to the physical data sets even when the data has already been committed. When a backup is created as a concurrent image copy, the latest data is not stored in backup. This increases the amount of log records that need to be merged during recovery and affects the recovery time. Therefore, if you create a concurrent image copy, remember to regularly create a backup after reflecting the VSO data to the physical data sets.
Using HALDB Online Reorganization (OLR)
When the OLR is used for HALDB reorganization, IMS does not require a backup of the database after the OLR is completed. This is because when OLR is used, all records in the database being reorganized and updates by application programs are recorded in the log. However, this means that if a recovery is needed and there is no backup after the OLR, all of the database records for the target database are recovered from the log, which results in longer recovery time. Even when CA data sets are created, all the database records are recorded in the CA data sets, so the volume of data the system reads during recovery becomes large.
To shorten recovery time of HALDBs, be sure to create an image copy after each OLR is completed. Since there is a backup, the system only needs to recover from the image copy and subsequent update log records.
Considerations for running a recovery job
Considerations for creating a recovery plan using IMS Database Recovery Facility are explained in this section. 
Considerations for HALDB
HALDB ILDS/primary index are the data sets that always need to be rebuilt. Consider the following points when you run a recovery job using IMS Database Recovery Facility and IMS Index Builder.
The ILDS is not used for HALDB without PSINDEX or logical relationships, but ILDS must be initialized. For recovery of HALDB without PSINDEX or logical relationships, you can reduce the time to scan the database during index building by specifying the INITONLY option in IMS Index Builder.
The ILDS must be rebuilt for a HALDB that has a PSINDEX or logical relationships. If the primary index, PSINDEX, and the ILDS are all built within the IMS Database Recovery Facility steps, system load for the sort process may become extremely high and the index building process may end abnormally because of insufficient storage. To avoid this, consider using IMS Database Recovery Facility to recover PSINDEX from a backup and logs, or building PSINDEX as a post-process after the recovery by using an index rebuild utility such as IMS Index Builder.

Considerations for backup data sets as input

When image copies of multiple database data sets or area data sets are stacked across more than one physical tape, IMS Database Recovery Facility recovers all databases by processing each data set sequentially in a single address space. When processing multiple tapes, consider creating one IMS Database Recovery Facility job for each stacked tape volume and manually processing each job concurrently.
When image copies of multiple database data sets or area data sets are stored in one data set by using IC2 and when database data sets or area data sets that are not to be recovered are also included, IMS Database Recovery Facility restores the necessary data sets by reading ICDS records from the start by using DFSMSdss. You should consider this point when you plan image copy creation.
Summary
There are many factors to consider when configuring your IMS system and defining your processes to reduce recovery time. The key points are summarized as follows:
  • If possible, prepare Recovery Log Data Sets (RLDS).
  • Consider MSU consumption, physical storage consumption, and recovery time when you decide if or how often you will create CA data sets versus how often you will create image copies.
  • Set index databases as non-recoverable.
  • When using HALDB OLR, create an image copy after each OLR.
  • Select how to recover HALDB ILDS/PSINDEX.
  • When image copy data sets are stored on tape, consider running IMS Database Recovery Facility job in one step or splitting a job into multiple jobs based on the number of physical or virtual tape volumes.
References
IMS System administration
Introduction to IMS operations and recovery > Understanding the recovery task > The mechanisms of recovery in IMS
https://www.ibm.com/docs/en/ims/15.5.0?topic=task-mechanisms-recovery-in-ims
IMS System utilities
IMS commands
IMS component and z/OS commands > DBRC commands
https://www.ibm.com/docs/en/ims/15.5.0?topic=commands-dbrc
 
Release planning for IMS
IBM IMS Tools support for IMS 15.5 > IMS backup and recovery management tools
https://www.ibm.com/docs/en/ims/15.5.0?topic=155-ims-backup-recovery-management-tools
 
IMS Recovery Solution Pack for z/OS
IMS Recovery Solution Pack for z/OS 2.1.0
https://www.ibm.com/docs/en/ims-rcvsolutionpack/2.1

[{"Type":"MASTER","Line of Business":{"code":"LOB70","label":"Z TPS"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSS8TR","label":"IMS Recovery Solution Pack for z\/OS"},"ARM Category":[{"code":"a8m0z000000cvZPAAY","label":"IMS Recovery Solution Pack for z\/OS"}],"Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"All Versions"}]

Document Information

Modified date:
04 September 2024

UID

ibm17149810

Page Feedback