Db2 for z/OS and its ecosystem

By Kate Wheat, Laura Kunioka-Weis, and Haakon Roberts

With the new redirected recovery feature of Db2 for z/OS, you can test and validate your recovery procedures and performance without impacting the availability of production systems or applications. This feature can eliminate the need to set up test subsystems for recovery testing.

Redirected recovery is the process by which the RECOVER utility redirects the recovery of an object (the source) to another object (the target).  This recovery can be done to a prior point in time or to the current state and is always done with transactional consistency. You can use redirected recovery on table spaces to perform the following tasks:

• Validate your recovery procedure and check for any issues
• Determine an accurate recovery time
• Analyze your production data
• Generate a copy of your production data at a previous point in time with transactional consistency

The redirected recovery feature for table spaces is delivered in APAR PH27043 in Db2 12. You can use this feature with function level 500 or higher. As with many new Db2 features, redirected recovery supports only universal table spaces (UTSs) and the corresponding LOB table spaces.

To use redirected recovery, specify the new FROM syntax in the RECOVER utility statement. For example:

RECOVER TABLESPACE TESTDB1.TESTTS1 FROM PRODDB1.PRODTS1

In this example, the recovery of table space PRODDB1.PRODTS1 is being tested. This table space will be recovered into TESTDB1.TESTTS1. In this case, PRODTS1 is the source table space, and TESTTS1 is the target table space.

When you use this new syntax, the target table space is recovered by using image copies and log records of the associated source table space. The data in the source object and the applications on the source object are unaffected by the recovery. The object identifiers in the target table space will be automatically translated in a new TRANSLAT phase.

Testing your recovery procedure:
You can use redirected recovery to test that your procedure works and meets the recovery time objectives in your service level agreement (SLA).

General process:

1. Create the target objects to match the definition of the source objects.
   
   
2. Run RECOVER with the new FROM syntax to redirect the recovery of the table space to a different target.
   
   
3. Run REPAIR CATALOG on the target table space to rectify data version information.
   
   
4. Optional: Rebuild any indexes on target objects.
   Perform this step if you need to determine the elapsed time of rebuilding indexes or if you need the indexes to verify the data.
   
   
5. Validate the content of the target objects’ data.
   
   
6. Analyze the RECOVER output to check the overall elapsed time and elapsed time for each phase. If more detailed analysis is needed, you can analyze the accounting trace records.

For detailed instructions on running a redirected recovery, including the requirements for the source and target objects, see Running a Redirected Recovery in IBM Knowledge Center.

For the specific formulas to use when calculating recovery time estimates, see Estimate recovery time using redirected recovery in IBM Knowledge Center.

Analyzing your production data:  
If you suspect problems with production data, you can use redirected recovery to analyze your data for any necessary corrections while minimizing data loss and application outages. You can also review, analyze, or validate data for regulatory purposes without impacting production data.

General process:

1. Run a redirected recovery: Run RECOVER with the new FROM syntax to recover the data to a different target so that the data can be analyzed. You can recover the data either to a point in time or to the current state. You can also do this recovery multiple times to different points in time for comparison.
   
   
2. Perform an in-depth analysis: Use SQL queries to compare the recovered data in the target object with the production data in the source object.
   
   
   

Generating a copy of your production data with transactional consistency
You can use redirected recovery to generate a copy of your production data at a point in time. RECOVER ensures that the data has transactional consistency. After you run RECOVER, you can use the data in the target object for development testing, generating reports, review by the business application team, and for transport to another Db2 subsystem using the UNLOAD utility.

Kate Wheat is an information developer for Db2 for z/OS Utilities.

Laura Kunioka-Weis is a Senior Software Engineer for Db2 for z/OS Utilities development.  

Haakon Roberts is a Distinguished Engineer for Db2 for z/OS development.