RECOVER

Start of change The RECOVER utility recovers data to the current state or to a previous point in time by restoring a copy and then applying log records. The RECOVER utility can also recover data to a previous point in time by backing out committed work. End of change

The largest unit of data recovery is the table space or index; the smallest is the page. You can recover a single object or a list of objects. The RECOVER utility recovers an entire table space, index, a partition or data set, pages within an error range, or a single page. Start of change You can recover data from sequential image copies of an object, a FlashCopy® image copy of an object, a system-level backup, or the log. End of change Point-in-time recovery with consistency automatically detects the uncommitted transactions that are running at the recover point in time and rolls back their changes on the recovered objects. So after recover, objects will be left in their transactionally consistent state.

Output

Output from RECOVER consists of recovered data (a table space, index, partition or data set, error range, or page within a table space).

Authorization required

To run this utility, you must use a privilege set that includes one of the following authorities:

RECOVERDB privilege for the database
DBADM or DBCTRL authority for the database. If the object on which the utility operates is in an implicitly created database, DBADM authority on the implicitly created database or DSNDB04 is required.
System DBADM authority
DATAACCESS authority
SYSCTRL or SYSADM authority

An ID with installation SYSOPR authority can also run RECOVER, but only on a table space in the DSNDB01 or DSNDB06 database.

Restrictions on running RECOVER

The following restrictions apply to the general use of the RECOVER utility. Additional restrictions apply to point-in-time recoveries and are documented in Restrictions for point-in-time recoveries.

RECOVER cannot recover a table space or index that is defined to use a storage group that is defined with mixed specific and nonspecific volume IDs. If you specify such a table space or index, the job terminates and you receive error message DSNU419I.
RECOVER cannot recover an index that was altered to PADDED or NOT PADDED. Instead, you need to rebuild the index.
RECOVER cannot recover a table space or an index to a point in time that is before a REORG operation that materializes pending definition changes.
RECOVER cannot recover a table space or index to a point in time if pending definition changes on that object were materialized by the REORG utility after that point in time.

Execution phases of RECOVER

The RECOVER utility operates in these phases:

Phase: Description
UTILINIT: Performs initialization and setup.
RESTORE: Locates and merges any appropriate sequential image copies and restores the table space to a backup level; processes a list of objects in parallel if you specify the PARALLEL keyword.
RESTORER: If you specify the PARALLEL keyword, reads and merges the sequential image copies.
RESTOREW: If you specify the PARALLEL keyword, writes the pages to the object.
PRELOGC: Preliminary LOGCSR phase. Determines uncommitted work that was backed out when the recovery base for an object is a FlashCopy image copy with consistency.
PRELOGA: Preliminary LOGAPPLY phase. Applies the uncommitted work up to the point of consistency for the object with a FlashCopy image copy with consistency recovery base.
LOGAPPLY: Applies any outstanding log changes to the object that is restored from the previous phase or step. If a recover job fails in the middle of the LOGAPPLY phase, it can be restarted from last commit point.
LOGCSR: Analyzes log records and constructs information about inflight, indoubt, inabort, and postponed abort units of recovery. This phase is executed if either the TORBA and TOLOGPOINT option was specified. If a recover job fails in the middle of the LOGCSR phase, it can be restarted from the beginning of the LOGCSR phase. DB2® members that finished the LOGCSR phase before the RECOVER job failure go through the LOGCSR phase again.
For BACKOUT YES processing, LOGCSR analyzes log records and constructs information about committed and canceled units of recovery.
LOGUNDO: Rolls back any uncommitted changes that the active units of recovery made to the recovered objects. This phase is executed if either the TORBA and TOLOGPOINT option was specified. If you need to restart the recover job after it enters into the LOGUNDO phase, objects that were not changed by URs that were active during the recover to point in time will be marked as finished and no need for further processing.
For BACKOUT YES processing, the LOGUNDO phase backs out committed changes from the current state of the object to the prior point in time specified. In addition, any uncommitted changes at the point in time specified are rolled back.
UTILTERM: Performs cleanup.

Syntax and options of the RECOVER control statement
The RECOVER utility control statement, with its multiple options, defines the function that the utility job performs.
Before running RECOVER
Certain activities might be required before you run the RECOVER utility, depending on your situation.
Recovering with a system-level backup
You can take system-level backups by using the BACKUP SYSTEM utility. In some cases, the RECOVER utility can use a system-level backup of the database copy pool as a recovery base.
How to determine which system-level backups DB2 recovers
DB2 recovers different system level backups, depending on your situation.
Determining which recovery base DB2 uses
The recovery base is the copy that the RECOVER utility starts with when recovering an object. RECOVER then applies logs as needed.
Determining whether the system-level backups reside on disk or tape
Restoring data sets for objects in the database copy pool that are to be recovered from a system-level backup on disk occurs virtually instantaneously. Restoring data sets for objects that are to be recovered from a system-level backup on tape volumes takes much longer.
Recovering a table space
Each table space that is involved is unavailable for most other applications until recovery is complete. If you make image copies by table space, you can recover the entire table space, or you can recover a data set or partition from the table space. If you make image copies separately by partition or data set, you must recover the partitions or data sets by running separate RECOVER operations.
Recovering a list of objects
You can recover table spaces, table space partitions, pieces of a nonpartitioned table space, index spaces, index space partitions, and indexes.
Recovering a data set or partition
You can use the RECOVER utility to recover individual partitions and data sets. The phases for data set recovery are the same as for table space recovery.
Recovering with incremental copies
The RECOVER utility merges all incremental image copies that were taken since the last full image copy.
Recovering with FlashCopy image copies
Recovering from a FlashCopy image copy is potentially faster than recovering from a traditional image copy. If an appropriate FlashCopy image copy is available, the RECOVER utility can use it to instantaneously restore an image copy.
Recovering a page
Using RECOVER PAGE enables you to recover data on a page that is damaged.
Recovering an error range
By using the ERROR RANGE option of RECOVER, you can repair pages with reported I/O errors. DB2 maintains a page error range for I/O errors for each data set; pages within the range cannot be accessed. The DISPLAY DATABASE command displays the range.
Effect on RECOVER of the NOT LOGGED or LOGGED table space attributes
You can recover NOT LOGGED table spaces to any recoverable point.
Recovering with a data set copy that is not made by DB2
You can restore a data set to a point of consistency by using a data set copy that was not made by the COPY utility.
Recovering catalog and directory objects
If you need to recover the catalog and directory, you must recover them before you recover user table spaces. Also, you must recover catalog and directory objects in a specific order.
Reinitializing DSNDB01.SYSUTILX
You need to reinitialize the DSNDB01.SYSUTILX directory table space if you cannot successfully execute the DISPLAY UTILITY and TERMINATE UTILITY commands. In this case, DSNDB01.SYSUTILX is damaged and you cannot recover DSNDB01.SYSUTILX, because errors occur in the LOGAPPLY phase.
Recovering a table space that contains LOB or XML data
The RECOVER utility can set the auxiliary warning status for a LOB table space or XML table space if it finds at least one invalid LOB or XML column.
Recovering a table space that contains clone objects
The recovery guidelines and considerations for a cloned table space or cloned index are the same as for a base table space or base index except in the point-in-time recovery case.
Point-in-time recovery
Recovering data to a prior time is a point-in-time recovery. You can recover objects to a particular RBA, LRSN, or image copy. You can do this type of recovery by using the RECOVER utility point-in-time recovery options. These options are TOCOPY, TOLOGPOINT, TOLASTCOPY, TORBA, and TOLASTFULLCOPY.
Avoiding specific image copy data sets during a recovery
You might accidentally lose an image copy, or you might want to avoid a specific image copy data set. Because the corresponding row is still present in SYSIBM.SYSCOPY, the RECOVER utility always attempts to allocate the data set.
How to improve RECOVER performance
You can improve the performance of the RECOVER utility by taking certain actions.
Optimizing the LOGAPPLY phase
The time that is required to recover a table space depends also on the time that is required to read and apply log data. You can take several steps to optimize the process. If possible, DB2 reads the required log records from the active log to provide the best performance.
Recovering image copies in a JES3 environment
You can recover sequential or concurrent image copies in a JES3 environment.
Resetting RECOVER-pending or REBUILD-pending status
Several possible operations on a table space can place the table space in the RECOVER-pending status and the index space in REBUILD-pending status.
How the RECOVER utility allocates incremental image copies
RECOVER attempts to dynamically allocate all required incremental image copy data sets.
How the RECOVER utility performs fallback recovery
The RECOVER utility attempts to use the latest primary copy data set as a starting point for recovery. If the latest primary copy data set is not available, RECOVER attempts to use the backup copy data set, if one is available.
How the RECOVER utility retains tape mounts
The RECOVER utility can automatically retain the tape volumes for the input image copies when a list of objects is being recovered.
Avoiding damaged media
When a media error is detected, DB2 prints a message that indicates the extent of the damage. If an entire volume is bad and storage groups are being used, you must remove the bad volume first. If you don't remove the volume the RECOVER utility might re-access the damaged media.
Termination or restart of RECOVER
You can terminate and restart the RECOVER utility.
Effects of running RECOVER
The effects of running the RECOVER utility vary depending on your situation.
Sample RECOVER control statements
Use the sample control statements as models for developing your own RECOVER control statements.

Parent topic: DB2 online utilities