Using the roll-forward recovery method

It reads either a change accumulation data set, system/recovery log data sets, or both, merges the appropriate data with the records from the existing database, and writes the updated records back to the database.

Roll-forward recovery is most beneficial in the following circumstances:

• To maintain a duplicate production database. This duplicate database might be used by high-volume, inquiry-only batch applications when running these applications against the production database would cause degraded performance.
• To maintain a backup for disaster recovery. The duplicate database could be located off-site and be used in case of a disaster at the production site.
• To apply the changes from the change accumulation and log files when a non-standard image copy (such as FDR or DF/DSS) has been used to restore the database data set.

Because the Recovery utility does not access the entire database and retrieves only the database blocks that have update records in the change accumulation and/or log data sets, the roll-forward recovery method cannot produce output image copies or invoke the Concurrent Pointer Checking feature to validate pointers.

During a roll-forward recovery with the Recovery utility, primary indexes for HIDAM and PHIDAM databases cannot be rebuilt, as specified with the BLDINDEX(Y) keyword, or recovered, as specified with the REC command.