Blog
DB2utor

Categories

August 19, 2008

Recovery After Using RFTL

I’ve written several articles about how to design systems that can store large volumes of data and how to take advantage of new DB2 V9 features like alter-table-rotate-first-to-last (RFTL). Two of my related articles from IBM Systems Magazine, Mainframe edition are here and here.

As a DBA it's important to understand your backup and recovery options when using REORG or other features that may change your data. The same applies when cataloging meta data changes through features like RFTL. RFTL changes the meta data stored in the DB2 catalog to associate a logical partition with a physical partition. It also modifies the limit key values that determine what keys can be stored in a given partition. Because of the logical-to-physical partition and limit key changes, determining how to recover to a given point in time gets tricky.

A reader recently asked me if it's possible to recover to a point in time before the RFTL operation. Yes and no. You cannot recover to a point in time before the RFTL if you start with an index-controlled partitioned table space. However, if you start with a table-controlled partitioned table space, you can recover a partition that's not involved in the RFTL operation. But you cannot recover the partition that was rotated back to a point in time prior to the rotation.

Let's consider three scenarios. The first is a recovery when starting with an index-controlled table space. The second and third scenarios use a table-controlled partitioned table space. Scenario 2 recovers a partition to a point in time prior to the last rotation, but the partition being recovered hasn't been rotated. In scenario 3, I provide the message you'd see if you pick the rotated partition instead of the non-rotated partition from scenario 2.

Scenario 1: Index-controlled partitioned table space recovery

Before starting the rotation, take a complete set of image copies and run the QUIESCE utility to get a to point in time relative byte address (RBA) to recover to if you have problems. 

Then issue the ALTER DDL to rotate the first partition to the last:

ALTER TABLE CSBPDAT.INVOICE                                                   
  ROTATE PARTITION FIRST TO LAST                                             
     ENDING AT ('2008-03-31') RESET

Notice the message produced by the ALTER statement, since this is an index-controlled partitioned table space:

DSNT404I
     SQLCODE = 20272, WARNING:  TABLE SPACE CSBPTS1A HAS BEEN
     CONVERTED TO USE TABLE-CONTROLLED PARTITIONING INSTEAD OF
     INDEX-CONTROLLED PARTITIONING, ADDITIONAL INFORMATION: *N

By issuing the –DISPLAY DB(*) SPACE(*) RESTRICT after the ALTER, you see the table space in REORGP status:

DSNT397I  -DB8G                                                         
NAME      TYPE PART STATUS      
--------   -------  -------- ----------------- ---------   
CSBPTS1A TS 0002 RW                                                   
    -THRU        0003                                                      
CSBPTS1A  TS     0004 RW,REORP                                             
CSBPTS1A  TS     0001 RW,REORP                                             
INVOICER  IX     0002 RW                                                   
    -THRU        0004                                                      
INVOICER  IX     0001 RW

Looking at the recovery information in SYSIBM.SYSCOPY:
Line 1-4 are entries for full imacopy taken before the alter RFTL.
Line 5-8 are entries for a quiesce to establish a common recovery point.
Line 9 is the entry generated by the ALTER RFTL.
Line 10-11 are entries generated by the REORG to remove the REORGP status.

L# DBNAME    TSNAME    ICT  ICDATE  ICTIME  SHRL   LP        RBA       
---+-----------+--------------+-----+----------+----------+---------+----+--------------------
11 CSBPDAT   CSBPTS1A  W    080730   114821                  3      004CE8D6FD8D
10 CSBPDAT   CSBPTS1A  W    080730   114821                  4      004CE8D6FD8D
  9 CSBPDAT   CSBPTS1A  A     080730   114625                  4      004CE8D5F2BC
  8 CSBPDAT   CSBPTS1A  Q     080730   114419                  2      004CE8D5B473
  7 CSBPDAT   CSBPTS1A  Q     080730   114419                  1      004CE8D5B473
  6 CSBPDAT   CSBPTS1A  Q     080730   114419                  4      004CE8D5B473
  5 CSBPDAT   CSBPTS1A  Q     080730   114419                  3      004CE8D5B473
  4 CSBPDAT   CSBPTS1A  F     080730    114408   R            4      004CE8D54C8F
  3 CSBPDAT   CSBPTS1A  F     080730    114407   R            3      004CE8D42552
  2 CSBPDAT   CSBPTS1A  F     080730    114407   R            2      004CE8D2FE2D
  1 CSBPDAT   CSBPTS1A  F     080730    114406   R            1      004CE8D1D758

The ALTER rotate took physical partition 1 and made it logical partition 4. Now partition 2 becomes 1, 3 becomes 2, and 4 becomes 3.

Let's see if we can recover partition 2 back to the QUIESCE RBA of x'004CE8D5B473'. 

The answer is NO. The recover table space to RBA failed with these error messages:

DSNU050I    DSNUGUTC -  RECOVER TABLESPACE CSBPDAT.CSBPTS1A DSNUM 2 X'004CE8D5B473' REUSE
DSNU556I  -DB8G DSNUCASA - RECOVER CANNOT PROCEED FOR
                      TABLESPACE CSBPDAT.CSBPTS1A DSNUM 2 BECAUSE
                      A SYSIBM.SYSCOPY RECORD HAS BEEN ENCOUNTERED
                      WHICH HAS DBNAME=CSBPDAT TSNAME=CSBPTS1A DSNUM=2
                       ICTYPE=W STARTRBA=X'004CE8D6FD8D' LOWDSNUM=3
                       HIGHDSNUM=3         
DSNU500I    DSNUCBDR - RECOVERY COMPLETE, ELAPSED TIME=00:00:00               
DSNU012I    DSNUGBAC - UTILITY EXECUTION TERMINATED, HIGHEST
                      RETURN CODE=8    

So with index-controlled partitioning, you cannot recover any partition to a point in time prior to the ALTER. The best thing to do is convert to table-controlled prior to using the ALTER RFTL statement.

Scenario 2: Recover non-rotated partition

This scenario takes a table-controlled partitioned table space and recovers a partition that isn't involved in the rotation back to a point prior to the last rotation.

Similarly to the first scenario, before starting the rotation, take a complete backup of all the partitions and run QUIESCE. Then issue the ALTER DDL command to rotate the first partition to the last:

ALTER TABLE CSBPDATD.INVOICE                                                   
  ROTATE PARTITION FIRST TO LAST                                             
     ENDING AT ('2008-03-31') RESET

Notice there are no conversion messages. And if you display the status of the table space, you don't see objects being restricted as they are with the index-controlled scenario.

DSNT397I  -DB8G                                                          
NAME      TYPE PART STATUS            
--------------  ------- -------- ----------------- -------- --   
CSBPTS1A  TS     0002  RW                                                   
    -THRU        0004                                                      
CSBPTS1A  TS     0001  RW                                                   
INVOICER  IX     L*    RW

L# DBNAME    TSNAME      ICT  ICDATE  ICTIME  SHRL    LP        RBA       
---+--------------+---------------+-----+-----------+----------+---------+----+--------------------
9  CSBPDATT  CSBPTS1A  A      080731     094102                  4     004CE94C1174
8  CSBPDATT  CSBPTS1A  Q      080731     093859                  2     004CE94B279D
7  CSBPDATT  CSBPTS1A  Q      080731     093859                  1     004CE94B279D
6  CSBPDATT  CSBPTS1A  Q      080731     093859                  4     004CE94B279D
5  CSBPDATT  CSBPTS1A  Q      080731     093859                  3     004CE94B279D
4  CSBPDATT  CSBPTS1A  F       080731     093700   R            4     004CE949A651
3  CSBPDATT  CSBPTS1A  F       080731     093659   R            3     004CE94876BF
2  CSBPDATT  CSBPTS1A  F       080731     093658   R            2     004CE9474C3D
1  CSBPDATT  CSBPTS1A  F       080731     093657   R            1     004CE94624F0

A look at SYSCOPY tells you that the recovery RBA before the ALTER is x'004CE94B279D'. Run the RECOVER utility and you see these SYSOUT messages:

DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = CSBPDATT.RECVR                  
DSNUGTIS - PROCESSING SYSIN AS EBCDIC                                        
DSNUGUTC -  RECOVER TABLESPACE CSBPDATT.CSBPTS1A DSNUM 2 TORBA X'004CE94B279D'
DSNUCBAL - THE IMAGE COPY DATA SET CSBP.IC.CSBPDATT.CSBPTS1A.P2.T0935 WITH DAT
           IS PARTICIPATING IN RECOVERY OF TABLESPACE CSBPDATT.CSBPTS1A DSNUM
DSNUCBMD - MERGE STATISTICS FOR TABLESPACE CSBPDATT.CSBPTS1A DSNUM 2 -       
           NUMBER OF COPIES=1                                                
           NUMBER OF PAGES MERGED=3                                          
           ELAPSED TIME=00:00:02                                             
DB8G DSNUCARS - INDEX CSBPDATT.INVOICE_IX1 PARTITION 2 IS IN REBUILD PENDING ST
DB8G DSNUCALA - FAST LOG APPLY WAS NOT USED FOR RECOVERY                      
DSNUCBDR - LOG APPLY PHASE COMPLETE, ELAPSED TIME = 00:00:00                  
DSNUCBDR - RECOVERY COMPLETE, ELAPSED TIME=00:00:02                           
DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4   

The return code of 4 indicates a warning. Look closely at the above messages -- the indexes have been put into a rebuild pending status.

It's always a good idea to display the database status after completing the alter operation. As you can see in the display output below, index space INVOICER logical part 2 is in RBDP status. This is because DB2 needs to rebuild logical partition 2 with the keys of what you just restored.

DSNT360I  -DB8G ***********************************                         
DSNT361I  -DB8G *  DISPLAY DATABASE SUMMARY                                 
                *    GLOBAL                                                 
DSNT360I  -DB8G ***********************************                         
DSNT362I  -DB8G     DATABASE = CSBPDATT  STATUS = RW                        
                   DBD LENGTH = 4028                                        
DSNT397I  -DB8G                                                             
NAME      TYPE PART  STATUS            
----------  ----  ------- ------------      
CSBPTS1A  TS     0002 RW                                                      
    -THRU        0004                                                         
CSBPTS1A  TS     0001  RW                                                      
INVOICER  IX    L0002 RW,RBDP*                                                
INVOICER  IX    L0003 RW                                                      
    -THRU        0004                                                         
INVOICER IX    L0001 RW                                                      
******* DISPLAY OF DATABASE CSBPDATT ENDED   *******************      

Scenario 3: Recover a rotated partition

The purpose here is to show that you cannot recover a rotated partition back to a point in time prior to the rotation. The image copy taken before the rotation contains data that's no longer valid for the partition since the limit keys have changed. This message confirms that partition 1 cannot be recovered because of the ICTYPE=A row found in SYSCOPY:

DSNU000I    DSNUGUTC - OUTPUT START FOR UTILITY,
                       UTILID = CSBPDATT.RECVR       
DSNU1044I  DSNUGTIS - PROCESSING SYSIN AS EBCDIC                              
DSNU050I    DSNUGUTC -  RECOVER TABLESPACE CSBPDATT.CSBPTS1A
                      DSNUM 1 TORBA X'004CEB0ECA33' REUSE
DSNU556I  -DB8G DSNUCASA - RECOVER CANNOT PROCEED FOR
                      TABLESPACE CSBPDATT.CSBPTS1A DSNUM 1
                      BECAUSE A SYSIBM.SYSCOPY RECORD HAS BEEN
                      ENCOUNTERED WHICH HAS
                      DBNAME=CSBPDATT TSNAME=CSBPTS1A DSNUM=1 ICTYPE=A         
                      STARTRBA=X'004CEB0F0E66' LOWDSNUM=0 HIGHDSNUM=0         
DSNU500I    DSNUCBDR - RECOVERY COMPLETE, ELAPSED TIME=00:00:00                
DSNU012I    DSNUGBAC - UTILITY EXECUTION TERMINATED,
                      HIGHEST RETURN CODE=8      

I hope you find this information helpful. Please post questions and comments, and thanks to the readers who've previously sent me technical questions like this.