Product benefits

The Recovery utility offers the following benefits:

Improved database availability

The BMC Recovery utility can recover one or more databases substantially faster than the IBM IMS Database Recovery utility.

It can also recover multiple database data sets simultaneously and with one pass of the log and change accumulation data sets. Because the recovery job can optionally include concurrent image copy creation and database pointer checking, the overall time required for the recovery process is reduced. Additional time is saved because it is not necessary to run a change accumulation step before the recovery. Indexes can be rebuilt using the Index Rebuild function. If the input image copy is an Instant Snapshot copy produced by the BMC Image Copy utility, the restore process is nearly instantaneous. All of these features contribute to faster recovery processing and increased database availability.

Improved enterprise-wide recovery

Because the Recovery utility can recover databases to any point in time, recovery points across database management systems can be better coordinated.

The Automatic Restart feature helps you manage large-scale recoveries by keeping track of completed recovery tasks and automatically handling failed tasks.

Improved control over the recovery process

The Automatic Restart feature, the Recovery Extensions feature, and the command entry, Automated Operator Interface, DBRC interface, and asynchronous processing options provide more control over the database recovery process and make the process more flexible.

Improved data integrity

By verifying pointers concurrently with the database recovery process, you are assured that the recovered database is valid before you put it back online.

Improved change control

By defining user-defined options in a global options module and by using dynamic allocation, you can reduce or eliminate changes to your recovery job streams when the environment changes.

Duplicate databases

Although many companies recognize the need to maintain duplicate databases, few have done so because traditional recovery methods are extremely slow and inefficient.

Recovering all critical databases would take many hours or possibly days. More and more companies are recognizing this problem and are looking for solutions to preserve their critical data and to help reduce the recovery window.

Using the Recovery utility roll-forward recovery method, you can efficiently maintain duplicate or backup copies of critical production databases. The duplicate database can be used for offline processing or as a backup that is brought online if there is a failure of the primary database. This feature can become an important part of disaster recovery procedures.

Reduced tape handling costs

Handling tapes can be quite costly, both in resources and in productivity.

The Recovery utility reduces the number of times a tape must be mounted by recovering multiple database data sets with one pass of the change accumulation and/or log data sets. For example, you might need to recover five database data sets with update records located on six log tapes. Only six tape mounts would be required when recovering with the Recovery utility, while thirty mounts (six tapes mounted once for each of the five database data sets) would be required with conventional utilities.

In addition, after failure of a job that uses extract data sets and the Automatic Restart feature, the job does not need to reprocess log and change accumulation data (if the tasks that were writing the extract data sets had completed before the failure occurred).

Less time and skill required to create and maintain JCL

The Recovery utility requires less time and skill to create and maintain JCL than conventional recovery utilities because it can dynamically allocate all the data sets it needs for recovery.

Dynamic allocation models provide a simple and flexible method for dynamically allocating output data sets. The Automatic Restart feature eliminates the need to modify JCL to handle failed recovery tasks. The Recovery Extensions feature makes it easy to specify the use of a copy of a recovery asset (input image copy or change accumulation data set) other than the primary copy.

With the Automatic Restart feature, no JCL or control statement changes are needed for you to resubmit a recovery job step after one or more recovery tasks failed during the previous execution.

When you use secondary image copies or log data sets at either the primary or the backup location, they can be used as input for recovery processing. You do not need to flag the primary image copy or log data set as 'In error' to DBRC.

Reduced log switching

The Recovery utility does not require you to periodically switch logs to establish recovery points.

This can improve database availability by reducing online overhead. By switching logs less frequently, fewer log tapes or cartridges are created and IMS lockouts are less likely to happen because of insufficient online logs.

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.

Was this page helpful? Yes No Submitting... Thank you

Comments