IMS Backup and Recovery Utilities | An Introduction to IMS: Your Complete Guide to IBMs Information Management System

IMS provides the following utilities for recovering a database:

"Database Image Copy Utility" on page 154

The Database Image Copy utility creates image copies of databases.

"Database Image Copy 2 Utility" on page 157

The Database Image Copy 2 utility takes image copies of IMS databases by using the concurrent copy function of the Data Facility Storage Management Subsystem (DFSMS).

"Online Database Image Copy Utility" on page 157

The Online Database Image Copy utility creates an as-is image copy of the database while it is being updated by the online system.

"Database Change Accumulation Utility" on page 158

The Database Change Accumulation utility accumulates database changes from DL/I log tapes since the last complete image copy.

Log Archive Utility

The Log Archive utility (DFSUARC0) produces an SLDS from a filled OLDS or a batch IMS SLDS. The utility runs as a z/OS batch job, and multiple log archive utility jobs can execute concurrently. For more information about the Log Archive utility, see "Archiving an OLDS" on page 370.

"Database Recovery Utility" on page 161

The Database Recovery utility restores the database, using a prior database image copy and the accumulated changes from DL/I log tapes.

"Batch Backout Utility" on page 163

The Batch Backout utility removes changes made to databases by a specific application program.

Another utility program, the Log Recovery utility (DFSULTR0), produces a usable log data set in the event of an operating system or hardware failure, thus enabling use of the log by the four principal programs of the recovery system.

For those databases that consist of multiple data sets, recovery is done by individual data set. To recover a complete database composed of multiple data sets, database recovery must be performed for each of its component data sets.

Figure 11-2 on page 155 illustrates the relationship between the backup and recovery utilities.

Figure 11-2. Overview of the Recovery Utilities

Database Image Copy Utility

The Database Image Copy utility (DFSUDMP0) creates a copy of each data set within the database. This copy is not an exact duplicate of the database data set, but it can be used to recover the database data set. The set of output data sets from the Database Image Copy utility is called an image copy. Each data set in the image copy is a sequential data set and can be only used as input to the Database Recovery utility (DFSURDB0). The Database Image Copy utility does not use DL/I to process the database, but uses track I/O instead. There is no internal checking to determine if all the IMS internal pointers are correct. There are tools available to run as part of the image copy process to do this checking. IBM recommends that you periodically check the validity of the internal pointers.

There can be no changes to the DBD when this database is recovered using the Database Recovery utility. In order to make changes to the DBD, a database reorganization is needed to implement those changes.

Multiple databases and data sets can be copied with one execution of the Database Image Copy utility. All data sets of a database should be copied at the same time: when there is no intervening database processing.

The IMS Database Recovery Control (DBRC) facility can be used to generate the JCL to run the Database Image Copy utility, if required.

Figure 11-3. Inputs to and Outputs from the Database Image Copy Utility

Database Image Copy 2 Utility

The Database Image Copy 2 utility (DFSUDMT0) is very similar to the Database Image Copy utility (DFSUDMP0). The Database Image Copy 2 utility has several advantages, however, in that it can take image copies with databases being unavailable for a very short time.

The IMS Database Image Copy 2 utility (DFSUDMT0) calls the concurrent copy function of the Data Facility Storage Management Subsystem (DFSMS) to make consistent image copies (that is, with no updates occurring while the utility is making the copy) or concurrent image copies (called fuzzy image copies) of an IMS database data set. Database Image Copy utility (DFSUDMP0) cannot make concurrent image copies.

The concurrent copy function of DFSMS is a hardware and software solution that allows you to back up a database or any collection of data at a point in time and with minimum down time for the database. The database is unavailable only long enough for DFSMS to initialize a concurrent copy session for the data, which is a very small fraction of the time that the complete backup takes.

Related Reading: For more information about DFSMS, see DFSMS V1R5 DFSMSdss Storage Administration Guide, or DFSMS V1R5 DFSMSdss Storage Administration Reference.

The Database Image Copy 2 utility differs from the Database Image Copy utility in the following ways:

The data sets to be copied must reside on a subsystem that supports DFSMS concurrent copy. The Database Image Copy 2 utility requires that the databases be registered to DBRC. For fuzzy KSDS copies, the database define cluster must specify BWO(TYPIMS) and the KSDS data sets must be managed by SMS.
An image copy created by the Database Image Copy 2 utility is in DFSMS dump format, rather than standard batch image copy format. The copy is registered with DBRC as an SMSNOCIC or SMSCIC image copy, depending on the parameters specified when the image copy was taken.
Up to four copies of a data set can be created. Only the primary and secondary (first and second) copies are recorded in the RECON data set.

Related Reading: For more information about the Database Image Copy 2 utility, see IMS Version 9: Utilities Reference: Database and Transaction Manager.

A flow diagram of the Database Image Copy 2 utility is shown in Figure 11-4 on page 158.

Figure 11-4. Inputs to and Outputs from the Database Image Copy 2 Utility

Online Database Image Copy Utility

The Online Database Image Copy utility (DFSUICP0) creates an as-is image copy of the database while it is being updated by the online system. The Online Database Image Copy utility runs as a BMP program. You can use it only for HISAM, HIDAM, and HDAM databases. If IMS updates these databases while the utility is running, IMS requires all logs for any subsequent recovery, including the log in use when you started this utility. IMS requires the logs because the image copy is not an image of the database at any particular point in time.

The output from the Online Database Image Copy utility is used as input to the Database Recovery utility.

Related Reading: For more information about the Online Database Image Copy utility, see IMS Version 9: Utilities Reference: Database and Transaction Manager.

A flow diagram of the Online Database Image Copy utility is shown in Figure 11-5 on page 159.

Figure 11-5. Inputs to and Outputs from the Online Database Image Copy Utility

Database Change Accumulation Utility

The Database Change Accumulation utility (DFSUCUM0) creates a sequential data set that contains only the database log records from all the log data sets that are necessary for recovery. This change accumulation log data set is used by the Database Recovery utility. The accumulation is done by sorting only the required log records in physical record within data set sequence. Change accumulation provides efficient database recovery whenever needed. The number of log data sets that need to be kept is significantly reduced.

The Database Change Accumulation utility can be run independently of DL/I application programs.

IBM highly recommends that you use DBRC to create the JCL for each execution of the Database Change Accumulation utility. DBRC will ensure that a complete set of log data sets is used to create the change accumulation log data set. The log records must be supplied to the Database Change Accumulation utility in the correct sequence.

Related Reading: For more information about the Database Change Accumulation utility, see IMS Version 9: Utilities Reference: Database and Transaction Manager.

A flow diagram of the Database Change Accumulation utility is shown in Figure 11-6 on page 160.

Figure 11-6. Inputs to and Outputs from the Database Change Accumulation Utility

The input to the Database Change Accumulation utility consists of:

All log data sets created since either the last execution of an image copy utility or the last execution of the Database Change Accumulation utility.
The old (previously created) change accumulation log data set. This data set would be the output from the last execution of the Database Change Accumulation utility. The first change accumulation run after a new image copy must not include any old change accumulation data set, that is, those created during the previous period.
Control statements that specify any purge dates and how the database log records are to be processed.

The output from the Database Change Accumulation utility consists of a new change accumulation data set, a sequential data set that contains the combined database records for all database data sets.

Database Recovery Utility

The Database Recovery utility (DFSURDB0) restores a database data set. The Database Recovery utility does not provide a means of recovery from application logic errors: you must ensure the logical integrity of the data in the database.

The process for recovering a HALDB data set that is not being reorganized online is different from recovering a HALDB data set that is being reorganized online. For more information, see "Recovering HALDB Data Sets During Online Reorganization."

Unlike the image copy utilities, the Database Recovery utility recovers one database data set per job step. Thus, to recover multiple data sets for a database, the Database Recovery utility must be run once for each data set.

Recommendation:

Use DBRC to create the JCL for each execution of the Database Recovery utility. DBRC ensures that all the correct inputs are supplied.

You can run the Database Recovery utility in a number of ways, depending on what input is required. Generally, the main input to the Database Recovery utility is the image copy data set. Other input can consist of any log data sets or change accumulation data sets that might be needed. You can run the Database Recovery utility with only the log information as input. In this case, the database that already exists is used as input.

A flow diagram of the Database Recovery utility is shown in Figure 11-7 on page 162.

Figure 11-7. Inputs to and Outputs from the Database Recovery Utility

The input to the Database Recovery utility consists of an image copy data set and, optionally, a change accumulation data set and any log data sets that are not included in the change accumulation data set.

The Database Recovery utility is run in a DL/I batch region and will allocate the database in exclusive mode so that there can be no other database activity at the time.

Recovering HALDB Data Sets During Online Reorganization

After DBRC sets the cursor-active status for the partition in the RECON data sets, and until the copying phase completes and DBRC resets the cursor-active status, you can recover any of the input or output data sets using the Database Recovery utility. To restore the output data sets, the Database Recovery utility uses the database change records (type X'50' log records) and applies them to empty output data sets.

Recommendation:

Make an image copy of the output data sets as soon as possible after the online reorganization completes. Recovering from this image copy is faster than recovering from the database change records that are logged during the online reorganization. However, you cannot make an image copy while the partition is in cursor-active status.

To recover an output data set before the online reorganization completes, perform the following tasks:

Stop the online reorganization by using the TERMINATE OLREORG command. If the online reorganization encountered an abend, it is stopped automatically.
Issue the /DBR or the UPDATE DB command for the HALDB partition.
Run database change accumulation, as necessary. You can create the JCL by issuing the GENJCL.CA command, or you can run the Database Change Accumulation utility (DFSUCUM0) from your own JCL. The purge time for the change accumulation must be equal to the time of the beginning of the online reorganization to represent restoring from the initial empty state of the data set.
Create the output data set to be recovered, either by using a JCL DD statement or by using Access Method Services, as appropriate.
Recover the database changes. You can create the JCL by issuing the GENJCL.RECOV command. Alternatively, you can run the Database Recovery utility from your own JCL with the DD statement for DFSUDUMP specified as DUMMY to indicate that there is no image copy from which to restore.
Run the Batch Backout utility (DFSBBO00), because you might need to back out uncommitted data.
After you have recovered, and possibly backed out, all of the required data sets of the HALDB partition, issue the /STA DB or the UPDATE DB command for the HALDB partition.
Issue the INITIATE OLREORG command to resume the online reorganization.

You can also recover an output data set after the online reorganization completes but before an image copy has been made. Follow the same steps as for recovering an output data set before the online reorganization completes, except the steps for stopping and restarting the online reorganization.

In addition, you can recover an output data set from a point other than the beginning of the online reorganization, such as from a full dump of a DASD volume, using existing procedures if the online reorganization is either completed or terminated.

Related Reading: For more information, see "Recovery for HALDB Online Reorganization" in IMS Version 9: Administration Guide: Database Manager.

Batch Backout Utility

Batch backout, in its simplest form, is the reading of log data sets to back out all database updates after an abnormal termination. Backout is done by using the before image data in the log record to re-update the database segments. Backout has the effect of undoing the previous updates.

Note:

The Batch Backout utility is needed only for full-function and HALDB databases.

The Batch Backout utility removes changes in the database that were made by a specific failing program. The following limitations apply:

The log data set of the failing program must be on DASD.
No other update programs can have been executed against the same database between the time of the failure and the backout.

The Batch Backout utility operates as a normal DL/I batch job and uses the PSB that is used by the program whose changes are to be backed out. All databases updated by the failed program must be available to the Batch Backout utility.

Figure 11-8 illustrates the inputs and outputs for the Batch Backout utility.

Figure 11-8. Inputs to and Outputs from the Batch Backout Utility

A log data set is created during the backout process. This log data set, preceded by the log data set produced for the failing job, must be included in the next change accumulation run, as any other log data set, and must not be used as input to any subsequent backout attempt.

Usage Notes for the Batch Backout Utility

Keep the following items in mind when using the Batch Backout utility:

If checkpoint/restart is not used, then the Batch Backout utility always backs out all the database changes of the program. For an overview of checkpoint/restart, see "IMS Checkpoints" on page 111.
If checkpoint/restart is used (program uses XRST and CHKP-ID calls), then backout will only perform a backout if the specified CHKP-ID is found on the log data set during read forward. If no CHKP-ID is specified, then the last one on the log data set is used (the first one encountered during read backward).
If, when using checkpoint/restart, you want to be able to completely back out a job (steps), you must issue a CHKP call immediately after the XRST call, that is, before any real database activity. The CHKP-ID of this call can then be used for a full backout operation.
To run batch backout for a DB batch that had completed successfully, the DBRC=C parameter must be added to the EXEC PARM keyword if online backout failed, but only to the prior checkpoint.