Running a redirected recovery

Before you begin

Before you can run a 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.

Recommendation: FL 503 If a row change timestamp column was added to a table with existing rows, ensure that the REORG utility was subsequently run on the containing table space to materialize the row change timestamp value for existing rows to be included in subsequent image copies. Otherwise, if REORG was not run, the row change timestamp value for recovered rows in the target table might be different than the row change timestamp value for the corresponding rows in the source table.

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 MEMBER CLUSTER 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) COMPRESS 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.
   Table	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 FL 503 Default value, except for row change timestamp columns that were added by ALTER TABLE statements VARCHAR maximum length Generated column definition Column names can differ. Limit key values for partition boundaries for table-controlled partitioning (PBR) CCSID encoding scheme
   Index	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 UNIQUE or UNIQUE WHERE NOT NULL BUSINESS_TIME WITHOUT OVERLAPS INCLUDE COLUMNS PADDED or NOT PADDED INCLUDE NULL KEYS or EXCLUDE NULL KEYS 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:

   LOGONLY

   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.

   TOLOGPOINT, TORBA, TOCOPY, TOLASTCOPY, or TOLASTFULL COPY

   Use one of these options to identify the recovery point if you want to do a point-in-time recovery.

   VERIFYSET NO

   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.

   ENFORCE NO

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

   You must complete this step before the data is accessed or copied or the indexes are rebuilt.

   For non-XML tables: REPAIR CATALOG rectifies data version information in the Db2 catalog.

   For XML tables: REPAIR CATALOG rectifies the XML table space versioning information.

   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.