Product features

Full, roll-forward, and backout recovery methods

The Recovery utility offers a variety of recovery methods for a variety of recovery scenarios:

• The full recovery method is used when a database is damaged by a hardware failure, software failure, application error, or disaster. Full recovery uses a copy of the database and records of database changes to return the database to its condition before the problem occurred.

  The Recovery utility can perform a full recovery in a single-phase or two-phase process. In certain situations, a two-phase recovery might be faster than a single-phase recovery. Two-phase recovery also supports recovery from an Instant Snapshot copy produced by the BMC Image Copy utility or a T0 copy produced by the Data Base Image Copy 2 utility from IBM.

• The roll-forward recovery method is used to maintain a duplicate database or to recover a database from type of copy that is not recognized by the Recovery utility. Roll-forward recovery uses the existing database data sets and merges change records to bring the database data sets up to its current condition.

• The backout recovery method (also known as physical backout) can be used if the database to be recovered is still viable and relatively few changes have been made since the time when the problem occurred. Backout recovery uses the existing database data sets and reverses (backs out) changes to return the database to its condition before the problem occurred. Backout recovery can save a significant amount of time and processing resources over forward recovery methods.

Point-in-time recoveries

A point-in-time (PIT) recovery allows you to recover a database to any point on a log, even a point at which the database was allocated for updates.

Any in-flight updates at the time of recovery will not be applied. The Recovery utility can use change accumulation input for a PIT recovery; generally, two logs from each IMS subsystem are also required for this type of PIT recovery. The Recovery utility can also use a PIT change accumulation that is produced by the BMC Change Accumulation utility; for this type of PIT recovery, no log input is required. The Recovery utility can use the recovery log data set (RLDS) as input.

Database group processing

The Recovery utility can process all data set groups and areas that are defined to DBRC within a change accumulation group, a database data set group, or a recovery group.

The utility can also process Recovery Manager (RMGR) groups similarly to the way that it processes change accumulation groups. RMGR groups are available through the Recovery Extensions feature. For more information about the Recovery Extensions feature, see the RECOVERY MANAGER for IMS documentation .

Recovery of multiple database data sets with one pass of the input

The Recovery utility recovers multiple database data sets while processing the change accumulation and log data sets only once.

When multiple logs are input to the recovery process, they can be read in parallel.

Exploitation of the zIIP

The Recovery utility can exploit the IBM System z Integrated Information Processor (zIIP) as follows:

• The utility can use the zIIP enablement component of the EXTENDED BUFFER MANAGER (XBM) product or the SNAPSHOT UPGRADE FEATURE (SUF) component. When the zIIP enablement component is available, the utility can use enclave service request blocks (SRBs) to enable zIIP processing while running jobs. If a zIIP is available, XBM attempts to offload eligible processing to the zIIP. If the zIIP is busy or not available, normal processing continues on a general-purpose processor.

• The utility can use the 64-Bit zIIP Sort Enablement feature for sorting log records. This technology exploits 64-bit memory (also known as virtual storage above the bar) and specialty features of IBM z9 and z10 processors (including the zIIP). Using the 64-Bit zIIP Sort Enablement feature instead of a standard sort program can reduce standard CPU time and elapsed time for the utility job step.

Automatic Restart

The Automatic Restart feature tracks completed tasks during a utility job step execution.

If the job step fails and is resubmitted, the feature automatically informs the utility that these completed tasks do not need to be repeated; you do not make any changes to the JCL or control statements before the job step is resubmitted.

The Automatic Restart feature can save substantial elapsed time and processing resources by preventing reprocessing of completed work and by making JCL and control statement changes unnecessary when a utility job step fails. This feature can be especially useful in disaster recovery scenarios in which you are recovering large numbers of databases.

Log extract data sets and CA extract data sets

The Recovery utility can create log extract data sets and change accumulation (CA) extract data sets to prevent reprocessing of log and CA data during a restart after a failure, to overlap task processing, and to improve performance.

Bypassed change accumulation

Because the Recovery utility recovers multiple databases with one pass of the log data sets, you don’t need to run a change accumulation utility before you recover the database even when running in a block level data sharing environment.

Recovery of DEDB multiple area data sets

The Recovery utility can recover multiple area data sets for DEDBs during the recovery step.

You do not need a post-processing utility.

IDCAMS support

The Recovery utility supports IDCAMS processing for both VSAM and OSAM data sets.

Encrypted image copies

The Image Copy utility, the Change Accumulation utility, and the Recovery utility of the BMC AMI Backup and Recovery for IMS product can write and read image copy data sets in encrypted format.

Business continuity plans usually involve sending an organization’s important data to a remote recovery site. Transmission and storage of offsite data increase the probability that this data could be lost or stolen. As more organizations implement disaster recovery plans, incidents involving data security breaches are increasingly frequent. These incidents are also increasingly costly in the harm that they cause to organizations and their customers, clients, and associates. Even if the data is not misused, the potential for harm is costly because of the notification, alerts, and other measures that must be taken in the aftermath of a breach.

By encrypting image copy data sets that are sent offsite, you reduce the possibility of unauthorized access to sensitive information. If the data set is lost or stolen, it is unusable without the key and the means to use the key.

Automated creation, registry, and use of additional recovery assets

Your backup and recovery strategy might call for the production of additional copies of recovery assets.

You might need more copies of an image copy data set beyond the two copies that DBRC supports and more copies of a change accumulation data set than the one copy that DBRC supports. Perhaps you need to maintain two copies on DASD for local recovery and send a third and fourth copy on tape offsite for disaster recovery. It is easy and efficient to produce additional copies of output data sets with the BMC Backup and Recovery utilities.

The Backup and Recovery utilities can work with the Recovery Extensions feature to record and maintain information about additional copies in the Recovery Manager (RMGR) repository. The Recovery Extensions feature provides automated access to additional image copy data sets and change accumulation data sets during processing of the following utility functions:

• the Recovery function of the Recovery utility

• the Incremental Image Copy function of the Image Copy utility and Change Accumulation utility

• the Change Accumulation function of the Change Accumulation utility

For more information about the Recovery Extensions feature, see the RECOVERY MANAGER for IMS documentation .

Input image copies

As input to the recovery, the Recovery utility supports all standard image copies. It automatically supports Instant Snapshot copies produced by the BMC Image Copy utility. It also supports T0 copies produced by the Data Base Image Copy 2 utility from IBM. The Recovery utility can read the compressed image copy data sets produced by the BMC Image Copy utility or the Recovery utility. The utility supports image copy data sets that are written with block sizes larger than 32 KB.

Output image copies

The Recovery utility can create output image copy data sets of the recovered database concurrently with full recovery processing.

If image copies for multiple databases are created in the job step, they can be stacked on the same tape volume. The Recovery utility can produce compressed image copies like those produced by the BMC Image Copy utility. The utility can write output image copy data sets that have block sizes larger than 32 KB.

Log data sets

When dual system or recovery logs are recorded in DBRC, either log data set can be used as input to the Recovery utility.

You can use several techniques to control which logs you want to use. If you specify an alternate log, the Recovery utility automatically uses the alternate in case the preferred log data set is flagged in error by DBRC.

If you use a timestamp point-in-time (PIT) change accumulation (produced by the BMC Change Accumulation utility) as input to a PIT recovery, no log data sets are used as input. The recovery may be faster because logs do not need to be processed.

Dynamic allocation

The Recovery utility can dynamically allocate all of the data sets necessary to perform recoveries.

When certain predefined allocation errors occur, the Recovery utility can notify the operator that a problem exists and wait for it to be corrected, thereby avoiding an abend.

• For input, the Recovery utility can dynamically allocate the image copy, change accumulation, and log data sets using information provided by DBRC. Both cataloged and uncataloged data sets are supported.

• For input or output, the Recovery utility can dynamically allocate the database data sets by using the dynamic allocation members that were created using the DFSMDA macro. For HALDBs, the Recovery utility uses the partition data set names recorded in DBRC. For DEDB databases, the Recovery utility uses the area data set names recorded in DBRC.

• The Recovery utility can dynamically allocate the optional output image copy data sets using information you specify about the data set name, unit type, and retention period.

To simplify and reduce the specification and maintenance requirements for the parameters that are associated with dynamically allocated output data sets (other than database data sets), you can set up and refer to dynamic allocation models. Models allow complete control over the data set name, device type, and other allocation parameters to be used for an individual output data set. They are especially helpful when you have requested that the utility produce multiple copies of an output data set and you want to use different parameters for each copy. For example, one copy can be allocated to a disk device while another copy is stacked on a tape device with other output data sets. The Automatic Restart feature and extract data sets support the use of models.

The Recovery utility also simplifies specifications when recovering to alternate database data sets.

DBRC interface

The Recovery utility can validate all recovery processing using DBRC and records all events in the RECON data sets.

When recovering multiple data set groups or indexes, the Recovery utility concurrently obtains authorization for all of them.

Copies of production databases

The Recovery utility allows you to create a copy of a production database by using specific keywords, bypassing DBRC authorization, and using a different database data set name.

Concurrent Pointer Checking feature for full-function databases

The Recovery utility can invoke the Concurrent Pointer Checking feature for full function databases to validate the pointers in each recovered database.

To use this feature, you must be using the full recovery method.

Concurrent Pointer Checking feature for DEDBs

The Recovery utility can invoke the Concurrent Pointer Checking feature for DEDBs to validate the pointers in each recovered DEDB. To use this feature, you must be using the full recovery method.

Index Rebuild function

The Recovery utility can invoke the Index Rebuild function to rebuild the primary index and all secondary indexes for a recovered DL/I database. The function rebuilds all indexes associated with a database using only the database as input rather than recovering these indexes from an image copy.

Recovery simulation

The Recovery utility can perform a simulated recovery.

The utility reads all input data sets (logs, change accumulations, and image copies), but it does not write the output databases, and it does not obtain authorization for registered databases. You can request simulation for the full recovery, single-phased method (the roll-forward and two-phase methods are not supported). A simulated recovery can help you verify that the recovery job will produce the desired outcome, and you may find it especially useful for testing a large, complex recovery job before using it in a production environment.

Recovery time estimates

You can use the recovery time estimate feature to get a quick estimate of how long a recovery should take to execute.

This feature estimates the total elapsed time based on input that the recovery will use, such as:

• Image copy data set size
• Change accumulation data set size
• Log data set size
• Real-time data set allocation/deallocation speed
• Real-time I/O speeds
• Access speeds for RECON data sets

You use the TYPERUN(ESTIMATE) keyword to obtain the quick estimate. Because this process neither allocates nor reads actual input data sets, the process is quick but not always accurate. The utility strives to achieve accuracy within 25 to 30 percent of the actual recovery time; however, variations in any of the recovery's parameters, conditions, or unknowns can affect the actual recovery time. The estimated value can be more or less than the actual recovery time.

Automated Operator Interface

The Recovery utility can interact with the operating system console operator, the IMS MTO, and the IMS or DBCTL system to control and synchronize database authorization and allocation.

IMS command entry

The Recovery utility can issue IMS commands that synchronize IMS with the recovery process.

Customized return codes, recovery monitoring, and reporting

The Recovery utility provides a method that you can use to customize the utility job step return code or cause a user abend in response to a specific message (as identified with the message number or a text string in the message).

The utility can also produce status messages about recovery processing and can generate valuable statistical reports about the recovered databases.

ISPF interface

The Recovery utility provides a set of ISPF panels that can be used to manage the recovery environment.

This ISPF interface offers full LIBDEF support.

Statistics file

The Recovery utility maintains an optional data set that can be used to collect and maintain information about the recovery environment.