Start of change

Running a redirected recovery

A redirected recovery is when the RECOVER utility redirects the recovery of an object (the source) to another object (the target). Specifically, the target table space, index space, or index is recovered by using image copies and log records of the associated source object. The data or index keys in the source object and the applications on the source object are unaffected by the recovery.

Redirected recoveries are useful for testing recovery procedures and data analysis. By running a redirected recovery, you can verify that the recovery procedure is valid and determine an estimated time for the recovery. You can also determine whether recovering indexes from image copies is faster than rebuilding the indexes. Additionally, you can use redirected recovery to generate production data at specific points in time with consistency. All of these tasks can be performed without impacting data availability.

Before you begin

Before you can run a redirected recovery, take the following actions:

  • If you plan to run redirected recovery on a table space, ensure that PTFs for PI86880 and PI88940 have been applied and the REORG TABLESPACE utility has been run on the source table spaces since those PTFs were applied. These actions ensure that the source table spaces have the necessary self-describing schema information that is needed for redirected recovery.
  • Ensure that the source objects are recoverable.

    In general, events on source objects that affect recovery have the same effect on a redirected recovery to target objects. Conversely, events on target objects that normally restrict recovery are ignored during redirected recovery. For a list of actions that affect recoverability, see Actions that can affect recovery status.

    To determine if any events occurred that could affect recovery, run the REPORT utility with the RECOVERY option on the source object and analyze the output.

About this task

You can run redirected recovery to the current state or to a previous point in time. In both cases, redirected recovery leaves objects in a transactionally consistent state.

Restriction: Redirected recovery to a point in time before REORG materialized the following pending definition changes on the source objects is not allowed:
  • DSSIZE (for a partition-by-range table space with absolute page numbers)

For example, suppose the following operations were run on a source object:

  1. ALTER TABLESPACE BUFFERPOOL (This operation is a pending definition change to the page size.)
  2. REORG TABLESPACE (The utility materialized the change.)

Redirected recovery from the source object to a point in time prior to step 2 is not allowed.

You can run redirected recovery on multiple table spaces, index spaces, or indexes at the space level or the partition level. Piece level (data set level) recovery for LOB table spaces is also supported.

LISTDEF lists are not supported, because association of the source and target objects must be done explicitly for each object pair.

Recommendation: Although redirected recovery is allowed for partitions and pieces, recover all of the partitions or pieces when possible. If partitions of an object are recovered in different jobs, they should all be recovered to the same recovery point.

During a redirected recovery, the source objects are available to applications for read and write access. However, the target objects are placed in the exclusive utility state, UTUT, and are not available for read or write access.

If the table in a target table space contains an identity column or an XML column or columns, the MAXASSIGNEDVAL column value in SYSIBM.SYSSEQUENCES is set to the MAXASSIGNEDVAL value in the corresponding row in SYSIBM.SYSSEQUENCES for the source.

Real-time statistics information for the target objects will be invalidated by redirected recovery.

The restore of sequential image copies and FlashCopy® image copies to target objects is supported. For restore of a FlashCopy image copy using FlashCopy during redirected recovery, the target object and the FlashCopy image copy must reside in the same ESS (Enterprise Storage Server®) subsystem. If z/OS® determines that FlashCopy cannot be used, the FlashCopy image copy is restored using traditional I/O methods when the REC_FASTREPLICATION subsystem parameter is set to PREFERRED or NONE. If FlashCopy cannot be used and REC_FASTREPLICATION is set to REQUIRED, the restore of the FlashCopy image copy fails. For more information about considerations when using FlashCopy image copies, see FlashCopy image copies and Recovering with FlashCopy image copies.

Restore of concurrent copies and system-level backups is not supported; these types of backups are ignored by redirected recovery.

Restriction: After you run a redirected recovery, a real recovery (FROM is not specified) of the target objects to a point in time prior to the redirected recovery is not allowed.

You can run multiple redirected recoveries on target objects either to the current state or to a point in time. These recoveries are supported, because the image copies and log records from the source objects are used to recover the target objects each time.


To run a redirected recovery:

  1. Create the target objects with the same attributes as the source objects.

    The characteristics listed in the following table must be the same in the current definition of the source and target objects.

    Notes for redirected recovery on indexes:
    • The characteristics and definition of the underlying table space for the index at the target must match the underlying table space for the index at the source. Additionally, the characteristics and definition of the target and source table columns in the index key must be the same. The number of columns in the target and source table can differ if a column that is not indexed was added to the target or source table.
    • When an index space or index is specified for redirected recovery, both index space and index attributes are checked.
    • RECOVER checks the characteristics and definitions at the following levels in the given order: table space, index space and index. When a difference is found, one or more error messages are issued, and checking does not proceed to the next level. Therefore, all errors might not be detected after an error is found.
    Table 1. Characteristics that must match in the source and target objects for redirected recovery
    Object type Characteristics that must match in the source and target
    Table space
    • Type and organization: partition-by-growth (PBG), partition-by-range (PBR), partition-by-range with relative page numbering (PBR RPN), LOB, or XML
    • Page size
    • Data set size (DSSIZE)
    • SEGSIZE, if not a LOB table space
    • CCSID encoding scheme triplet (for SBCS, DBCS, and MIXED)
    • For a PBR or PBR RPN:
      • Logical to physical partition mapping if the source has rotated or added partitions
      • Partition boundary limit keys
      • Number of partitions
    • For PBG:
      • The MAXPARTITIONS value for the target must be equal to or greater than source
      • For table space level recovery (DSNUM ALL), the number of active partitions for the target must be equal to or greater than source
      • For partition level recovery (DSNUM n), the physical partition must exist.
    Index space
    • Type and organization: nonpartitioned index (NPI), partitioned index (PI), data partitioned secondary index (DPSI), or partitioned RPN index
    • Page size
    • Data set size (DSSIZE)
    • For PI, DPSI, or PI on PBR RPN:
      • Partition boundary limit keys for index-controlled or table-controlled partitioning
      • Logical to physical partition mapping if the underlying source PBR table space has rotated or added partitions
      • For index space level recovery (DSNUM ALL), the number of partitions must match.
      • For partition level recovery (DSNUM n), the physical partition must exist.
    • Existence of the table (either created or not yet created)
    • Columns:
      • Number of columns
      • Data type, length, precision, scale, subtype
      • Inline length of LOB columns
      • XML indicator length
      • Column CCSID encoding scheme
      • Default value
      • VARCHAR maximum length
      • Generated column definition
      Column names can differ.
    • Limit key values for partition boundaries for table-controlled partitioning (PBR)
    • CCSID encoding scheme
    • Key:
      • Number of key columns
      • Order of key columns
      • ASC, DESC, RANDOM ordering attributes
    • RID size
    • The underlying table must have same definition. (See the preceding list of table characteristics.)
    • Limit key values for partition boundaries
    • Data type for extended indexes (such as XML indexes and indexes on expressions)

    When creating target objects, consider the following tips and recommendations:

    • You can use a tool to generate the DDL for the source object and then modify the DDL to create the target object.
    • You can use the CREATE TABLE statement with the LIKE clause to create a target table with the same columns (names and definitions) as the source table. However, the newly created table does not inherit other characteristics of the source table, such as the partitioning scheme and auxiliary relationships.
    • For target tables that contain XML columns, the XML table spaces are created implicitly by Db2 with the same characteristics and attributes as the base table space.
    • When creating a new target partition-by-growth (PBG) table space, specify the same MAXPARTITIONS value as the source table space and specify NUMPARTS n, where n is the number of currently active partitions for the source. (Although specifying the same MAXPARTITIONS value is recommended, it is not required.)

    When redirected recovery is executed, both source and target objects must exist and be defined, meaning that the underlying VSAM linear data sets must exist. For the underlying linear data sets for the target table spaces or index spaces, the VSAM attributes, such as EA, compressed, and KEYLABEL, should be the same as the corresponding source objects.

  2. Optional: If you do not want to use RECOVER to restore the backups, restore the chosen backups to the target objects by using DSN1COPY or another method.

    If you use DSN1COPY to restore the backup, do not use the RESET option. This option sets the starting point for log apply that RECOVER LOGONLY uses within the page set to zero. You also do not need to specify the translate OBID option, OBIDXLAT, because redirected recovery translates the source OBIDs to the target OBIDs in target objects after the log records have been applied.

  3. Run RECOVER with the FROM option.

    For details on the syntax requirements and restrictions, see Syntax and options of the RECOVER control statement.

    For an example of a RECOVER statement with the FROM option, see Example 12: Performing a redirected recovery to the current state.

    Add OPTIONS EVENT (ITEMERROR, SKIP) before the RECOVER statement to skip errors with mismatched characteristics.

    Specify the following additional RECOVER options as needed:

    Specify this option only if you restored the data by using DSN1COPY or another method. When you specify LOGONLY, RECOVER applies only the log records for the source objects to the target objects.
    Use one of these options to identify the recovery point if you want to do a point-in-time recovery.
    Specify this option if you need to recover only the auxiliary target objects or only the base table space in LOB, XML, history, or archive relationships for target objects.
    Specify this option in the following situations:
    • You need to recover only the base table space in referential integrity (RI) relationships for target objects. Specifying this option avoids CHECK-pending status on dependent table spaces.
    • You need to recover only the base table space in LOB or XML auxiliary relationships for target objects. Specifying this option avoids auxiliary CHECK-pending status on the base table spaces.

    Recovery point: After you submit the RECOVER job, DSNU1569I reports the recovery point for the redirected recovery, even if you are recovering to the current state. For redirected recovery to the current state, the recovery point is the current Db2 log point (RBA or LRSN) after RECOVER has set the UTRW (utility restrictive state, read-write access allowed) status on the source objects during initialization.

    After redirected recovery completes, the following restrictive states are set:

    • Target table spaces are placed in COPY-pending status.
    • Target index spaces are placed in informational COPY-pending status.
    • If indexes were not recovered at the same time as the corresponding table spaces, they are placed in REBUILD-pending status.
    • If not all partitions of an index space were recovered, the unrecovered partitions are placed in REBUILD-pending status.
    • Indexes that are recovered without the corresponding table spaces are placed in CHECK-pending status. Run the CHECK INDEX utility to verify that the indexes are consistent with the table spaces.
    • For referential integrity (RI) relationships, if the entire set of related objects is not specified for redirected recovery within one RECOVER statement, CHECK-pending status is set on dependent table spaces when one of the following situations is true:
      • The table space is a target without a parent.
      • The parent table is a target without its dependents.
    Recommendation: If related target objects were recovered to different recovery points in separate jobs with VERIFYSET NO and ENFORCE NO, use the CHECK DATA, CHECK INDEX, and CHECK LOB utilities to check the data before accessing it.

    If the redirected recovery fails, it cannot be restarted. You must terminate the utility with the TERM UTIL command.

  4. Run REPAIR CATALOG on the target table spaces, except for LOB or XML table spaces.

    You must complete this step before the data is accessed or copied or the indexes are rebuilt. REPAIR CATALOG rectifies data version information in the Db2 catalog.

    This step is not necessary for target index spaces, because the version information for indexes is rectified during the redirected recovery.

  5. If recoverability of the target objects is needed, create a new recovery base for the target objects.
    Because redirected recovery places target objects in COPY-pending status and informational COPY-pending status, a real recovery (FROM is not specified) of target objects is not allowed until a new recovery base is created. A recovery base can be a full image copy, a REORG LOG YES operation, a LOAD REPLACE LOG YES operation, or a system-level backup. Target objects can be recovered by using a real recovery (without the FROM specification) only to the current state or to a point in time after the redirected recovery.
  6. If the target indexes are in REBUILD-pending status and are needed, rebuild them by using the REBUILD INDEX utility.

What to do next

After you run redirected recovery, you can calculate the estimated recovery time by using the formulas in "Estimate recovery time using redirected recovery" in Tips for maximizing data availability during backup and recovery .

End of change