As application programs run, the expectation is that these programs will process the data correctly, and the devices on which the files are stored will also work correctly. Unfortunately, not all programs are perfect, and not all disk devices work correctly forever. This means that a database might at some point need to be processed to either back out some erroneous updates, or a database might need to be rebuilt from a backup point forward to a device failure.
This is a process known as Backward Recovery (to roll back some updates) or Forward Recovery (to recover forward from a fixed starting point.). In order to accomplish this, you will recover the problem databases using the RXX records produced from a DBUTLTY SPILL of the log file (LXX) to a recovery file (RXX). This document will cover some of the primary points and questions that users have when using this utility.
Component : Datacom/DB
Component : Datacom/AD
The RECOVERY function of DBUTLTY protects the integrity of the database. It provides the ability to restore a database or a portion of a database from a previously stable point (forward recovery), or to undo the transactions of one or more jobs that contaminated the database (backward recovery). With either forward or backward recovery, logging must be active for the tables to be recovered. Changes to the data in the database table are logged in the Log Area (LXX), and periodically moved to more permanent storage in Recovery files (RXX).
If forward or backward recovery will need to process transactions from more than one Recovery File (RXX), it is important that the files be coded in the JCL in the correct order to ensure they are processed correctly. Regardless of the type of recovery, the files allocated to the RXX DD Statement must be entered in the order they were created, from oldest to most recent.
For example, if using a GDG, and if three RXX files are needed, you might code it this way:
//RXX DD DISP=SHR,DSN=MY.RXX.FILE(-2),. . .
// DD DISP=SHR,DSN=MY.RXX.FILE(-1),. . .
// DD DISP=SHR,DSN=MY.RXX.FILE(0),. . .
or if using the absolute filenames:
//RXX DD DISP=SHR,DSN=MY.RXX.FILE.G0143v00,. . .
// DD DISP=SHR,DSN=MY.RXX.FILE.G0144v00,. . .
// DD DISP=SHR,DSN=MY.RXX.FILE.G0145v00,. . .
Next, we need to identify the date/time range of the records to process if using forward recovery. This is always of the format from.date.time/to.date.time. Typically, Backward Recovery will be used to reverse changes for a particular TSN (Transaction Sequence Number), or possibly for a job, so the time range is not necessarily needed here.
At this point, we have identified the RXX input source in order from oldest to latest, and we have determined the range of RXX records to process, from oldest to most recent. Now, we can do either a Forward or Backward recovery - internally, we start at the oldest.date.time and bring the updates forward for Forward Recovery, and for Backward Recovery we start at the recent.date.time (or end of the file) and process backwards.
Assumptions about this process:
There are many other options, settings and selection criteria that can be specified to provide a great amount of flexibility and power to update your databases as you desire.
For more information about these settings and about the process, please refer to the Datacom/DB Database and System Administration documentation section called "Using Recovery" and the DBUTLTY Reference section called "RECOVERY Command (RECOVERY)."
As always, please contact Broadcom support for Datacom if you have further questions.