Overview of recovery of databases

You perform a forward recovery of a database by restoring a backup copy of the database and then reapplying all of the logged database changes that occurred after the backup copy was made.

While these two basic steps are common to all forward recoveries of databases, the specific steps of a forward recovery can vary depending on the type of database you are recovering and whether you are operating in a data-sharing environment or a non-data-sharing environment.

A backup copy of an IMS database is usually an image copy of the database. Image copies are created by one of the IMS image copy utilities or a separate image copy tool. The IMS image copy utilities automatically register the image copies they create with the Database Recovery Control facility (DBRC). Image copies created by some other means, or with DBRC=N specified on the image copy utility EXEC parameter list, might need to be registered with DBRC before DBRC and the Database Recovery utility (DFSURDB0) can use them for recovery.

The logs that contain the database changes can be processed before recovery by the Change Accumulation utility (DFSUCUM0), to consolidate all of the database change records and optimize them for recovery. In a data-sharing environment, you are required to use the Change Accumulation utility. In a non-data-sharing environment, using the Change Accumulation utility is optional, although it can be beneficial to use for performance reasons.

DBRC manages the forward recovery process and can generate the required JCL for all of the backup and recovery related utilities, except in cases in which the database being recovered is not registered with DBRC. The JCL that is generated by the DBRC command GENJCL.RECOV for the Database Recovery utility automatically identifies and includes the correct image copies, logs, DBD names, ddnames and time stamps.

The process for recovering the database data sets, that is, the data sets that contain the database records, is the same across most database types, including full-function, HALDB partitioned full-function, and Fast Path DEDB database types. The same process is used for a primary index of a HIDAM database in the same way as you recover a database data set: using image copies and logs.

For HALDB databases, however, the PHIDAM primary indexes and indirect list data sets (ILDSs) are not backed up or recovered; instead, after the database data sets they support are recovered, HALDB primary indexes and ILDSs are rebuilt by using the HALDB Index/ILDS Rebuild utility (DFSPREC0).

Another difference about recovering HALDB databases is that the DBRC command GENJCL.RECOV can generate JCL to recover all of the partitions of the HALDB database at once or to recover only a single partition. The GENJCL.RECOV command also provides a similar option for recovering entire Fast Path DEDB databases or individual DEDB areas.

When rebuilding HALDB primary indexes and ILDSs, consider using the DBRC command GENJCL.USER to create skeletal JCL members to allocate the necessary data sets. A separate skeletal JCL member is required for primary index data sets and ILDSs. When rebuilding the ILDS, use the free space option of the HALDB Index/ILDS Rebuild utility by specifying either ILEF or BOTHF on the utility control statement. The free space option uses VSAM load mode, which includes the free space called for in the VSAM DEFINE CLUSTER command.

Forward recovery in a data-sharing environment requires additional steps to consolidate the logs of all of the IMS systems sharing the database to be recovered.

A forward recovery can be either a full recovery or a time-stamp recovery. A full recovery restores a DBDS or area data set to its current state as recorded in the RECON data set. A time-stamp recovery restores a DBDS or area data set to the contents it had at the time you specify.

The following topics include examples of the steps for performing full forward recoveries of HIDAM and PHIDAM databases. Because the recovery process for database data sets is the same across database types, the steps presented for the recovery of HIDAM and PHIDAM DBDSs also apply to HDAM, PHDAM, and DEDB database data sets. Similarly, the recovery steps for an ILDS in a PHIDAM also apply to an ILDS in a PHDAM.