RECOVER

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.

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. 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. 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. After recovery, objects will be left in their transactionally consistent state.

Start of change You can use the RECOVER utility in conjunction with z/OS® DFSMS data set encryption to encrypt or decrypt table spaces or indexes. End of change

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.

Authorization required for redirected recovery

If you are using redirected recovery (the RECOVER utility with the FROM option), certain authorizations are required for both source and target objects.

Target objects: You must use a privilege set that includes one of the following authorities on the target objects:

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 DSNDB04 or the implicitly created database is required.
System DBADM authority
DATAACCESS authority
SYSCTRL or SYSADM authority

Source objects: You must use a privilege set that includes one of the following authorities on the source objects:

Ownership of the base table
UNLOAD privilege on the base table
DBADM authority for the database. If the object on which the utility operates is in an implicitly created database, DBADM authority on DSNDB04 or the implicitly created database is required.
DATAACCESS authority
SYSADM authority

Additionally, when multilevel security is used on source objects, consider defining the same security on target objects.

Restrictions on running RECOVER

Start of change 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. End of change

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.
Partition level recovery is required when the recovery base is an inline copy that was created by a REORG that pruned partitions.

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.
TRANSLAT: Translates the object identifiers (OBIDs) in the recovered data during redirected recovery. The source OBIDs in the pages of the target objects are changed to the target OBIDs.
UTILTERM: Performs cleanup.