Db2 for z/OS and its ecosystem

 View Only

Db2 for z/OS Redirected Recovery Extended to Indexes

By Kate Wheat posted Tue October 26, 2021 12:22 PM

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

We wrote last year about the new support in Db2 12 for redirected recovery of data in Db2 table spaces with APAR PH27043. Now the RECOVER utility also supports redirected recovery of index spaces and indexes. You can start using this feature in Db2 12 function level 500 or higher after you apply the PTF for APAR PH35266. Redirected recovery is allowed on indexes with the COPY YES attribute on universal table spaces and indexes on the corresponding LOB table spaces. 

The ability to use redirected recovery on indexes completes the support for users who copy their indexes today.  You can now use redirected recovery on your indexes along with your table spaces for estimating recovery time, testing and validating your recovery procedures, or analyzing your production data.   

To use redirected recovery on an index or index space, use the same FROM syntax that you use for table spaces. For example: 

RECOVER  
TABLESPACE TESTDB1.TESTTS2 FROM PRODDB3.PRODTS1 
INDEXSPACE TESTDB1.TESTIS2 FROM PRODDB3.PRODIS1 

This example is testing the recovery of table space PRODDB3.PRODTS1 and the associated index space PRODDB3.PRODIS1. The table space will be recovered into TESTDB1.TESTTS2, and the index space will be recovered into TESTDB1.TESTIS2. In this case, the source and target objects are as follows: 

  • PRODTS1 is the source table space 
  • PRODIS1 is the source index space 
  • TESTTS2 is the target table space 
  • TESTIS2 is the target index space 

You can use redirected recovery on indexes to evaluate whether index recovery is faster than index rebuild without impacting production objects and workloads. The general process is as follows: 

  1. Follow the steps for redirected recovery on table spaces from our previous blog post: Db2 for z/OS Redirected Recovery with the RECOVER utility 
  2. Choose several large mission critical production indexes. 
  3. If these indexes do not already have the COPY YES attribute, use SQL ALTER statements to set this attribute on these indexes. 
  4. Use the COPY utility to create full image copies of the indexes. 
  5. Create the target indexes with the COPY YES attribute, if not already created. 
  6. Use RECOVER with the FROM clause to recover to the target indexes using the image copies from step 4 and the logs for the associated source index. 
  7. If not already done, use the REBUILD INDEX utility to rebuild the same target indexes from the data. (You might have already completed this step as part of the optional step 4 in our previous blog post about redirected recovery of table spaces.)  
  8. Compare the performance of the redirected recovery with the rebuild index operation. To calculate recovery time estimates, see the formulas in  
    Estimate recovery time using redirected recovery in IBM Documentation. 

For more specific information about redirected recovery of indexes, including the RECOVER FROM syntax and specific requirements and restrictions, see the following topics in IBM Documentation:  

Running a redirected recovery 

Syntax and options of the RECOVER control statement 

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

Laura Kunioka-Weis is a Principal Engineer, Db2 for z/OS Utilities development.  

Haakon Roberts is a Distinguished Engineer (DE) and CTO for IBM z Data & AI.






#Db2forz/OS
#db2news
#db2z/os
#Db2Zutilities
0 comments
34 views

Permalink