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. 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.