Recovering databases

The recovery process for IMS databases can include these three basic steps, although the details of the process can vary with the type of database to be recovered.

Procedure

  1. Restore the database to the most current image copy.
    Attention: Skip this step if an HALDB Online Reorganization is being used because all the database changes are on log data sets.
  2. Use the log data sets (or change accumulation data sets) to restore changes made to the database since the image copy was made.
    Definition: Change accumulation is the process of creating a compacted version of one or more IMS log data sets by eliminating records not related to recovery, and by merging multiple changes to a single segment into a single change. For more information about change accumulation, see Log record change accumulation.
  3. Back out any incomplete changes.
When the recovery completes successfully, DBRC records information about the recovery in the RECON data set. If you performed a time-stamp recovery, DBRC records information about the range of omitted changes.
Requirement: If a time-stamp recovery is performed within a database allocation interval, you must immediately create an image copy to ensure a valid starting point for subsequent recovery attempts. DBRC then prevents the changes from being reapplied on any subsequent recovery.

The following figure illustrates a simple database recovery.

Figure 1. IMS database recovery process
begin figure description. This figure is described in the surrounding text. end figure description.

Information for a database recovery can come from any or all of the following sources:

  • Image copies of the database
  • Database reorganization data sets
  • Log data sets (SLDSs and RLDSs)
  • Change accumulation data sets

You can use DBRC to track all of these information sources, greatly simplifying the task of database recovery.

Related reading:  Refer to Understanding the recovery task for more information about the recovery process.

If you register recoverable databases in the RECON data set, DBRC records the association of the databases to the log data sets containing database change records.

DBRC also records information about:

  • Database image copies
  • Reorganizations (except DEDB online reorganizations)
  • Recoveries
  • Change accumulations
  • Backout

DBRC can generate JCL for executing a database recovery, because DBRC records this information in the RECON data set. Whether you use the GENJCL commands to generate JCL or provide the JCL yourself, DBRC uses information in the RECON data set to determine exactly which data sets are required for input. The Database Recovery utility runs only if DBRC verifies that the JCL is correct.

You can omit all logged changes after a certain time from the input by performing a time-stamp recovery. A time-stamp recovery is equivalent to backing out the omitted changes from the database.

Most time-stamp recoveries require DBRC in order to be successful. When you involve DBRC in your request for a time-stamp recovery, DBRC selects the correct logs and, at execution time, communicates to the Database Recovery utility where to stop processing the input to correctly perform your request.

The following figure shows how DBRC works with the Database Recovery utility.

Figure 2. How DBRC works with the Database Recovery utility
begin figure description. Unload file (for KSDSs) or log data sets and most recent image copy are inputs to the RECON data set. Change accumulation. and the RECON data set are inputs to DBRC. Log data sets, DBRC, the most recent image copy, and JCL are inputs to the Database Recovery utility. The utility creates a recovered data set and SYSPRINT messages. end figure description
Recommendation: Implement DBRC in phases, defining at first only a few recoverable databases in the RECON data set. This allows you to gain experience in the use of DBRC, and gives you an opportunity to assess, make, and test any changes needed in your backup, recovery, and operational procedures.