The RECOVER Utility

 <  Day Day Up  >  

The RECOVER Utility

RECOVER can be used to recover table spaces or indexes by restoring data from an image copy data set and then applying subsequent changes from the log files.

The RECOVER TABLESPACE Utility

The RECOVER TABLESPACE utility restores table spaces to a current or previous state. It first reads the DB2 Catalog to determine the availability of full and incremental image copies, and then reads the DB2 logs to determine interim modifications. The utility then applies the image copies and the log modifications to the table space data set being recovered. The DBMS maintains the recovery information in the DB2 Catalog. This enables the RECOVER utility to automate tasks such as the following:

  • Retrieving appropriate image copy data set names and volume serial numbers

  • Retrieving appropriate log data set names and volume serial numbers

  • Coding the DD statements for each of these in the RECOVER JCL

Data can be recovered for a single page, pages that contain I/O errors, a single partition of a partitioned table space, or a complete table space.

Recovery to a previous point can be accomplished by specifying a full image copy or a specific log RBA. Recovery to the current point can be accomplished by simply specifying only the table space name as a parameter to the RECOVER utility.

Listing 32.6 shows an example of full recovery to the current point for a table space. Listing 32.7 shows the recovery of the same table space to a previous point using the TOCOPY option to specify an image copy, and the recovery of a different table space to a previous point using the TORBA option to specify a log RBA. This applies the log records only up to, not including, the specified RBA. Note that when using the TOCOPY option with GDG datasets, the relative GDG reference is not allowed.

Listing 32.6. JCL for Full Recovery
 //DB2JOBU JOB (UTILITY),'FULL RECOVERY',CLASS=X,MSGCLASS=X, //NOTIFY=USER //* //**************************************************************** //* //*        DB2 RECOVER UTILITY  ::  FULL RECOVERY //* //**************************************************************** //* //RCVR EXEC DSNUPROC,SYSTEM=DSN,UID='FULLRECV',UTPROC=" //* //*  UTILITY INPUT CONTROL STATEMENTS //*    1. The first RECOVER statement recovers the //*       DSN8D81A.DSN8S81C table space to the current point //*       in time. //*    2. The second RECOVER statement recovers all indexes //*       in the table space. //* //DSNUPROC.SYSIN    DD  *     RECOVER TABLESPACE DSN8D81A.DSN8S81C DSNUM ALL     REBUILD INDEX(ALL) TABLESPACE DSN8D81A.DSN8S81C /* // 

Listing 32.7. JCL for Partial Recovery
 //DB2JOBU JOB (UTILITY),'PRTL RECOVERY',CLASS=X,MSGCLASS=X, //         NOTIFY=USER //* //**************************************************************** //* //*        DB2 RECOVER UTILITY  ::  PARTIAL RECOVERY //* //**************************************************************** //* //RCVR EXEC DSNUPROC,SYSTEM=DSN,UID='PRTLRECV',UTPROC=" //* //*  UTILITY INPUT CONTROL STATEMENTS //*    1. The first RECOVER statement recovers the //*       DSN8D81A.DSN8S81D table space to the named //*       image copy data set. //*    2. The second RECOVER statement recovers the //*       DSN8D81A.DSN8S81C table space to the specified //*       log RBA. //* //DSNUPROC.SYSIN    DD  *     RECOVER TABLESPACE DSN8D81A.DSN8S81D             TOCOPY CAT.FULLCOPY.DATASETD.G0001V00     RECOVER TABLESPACE DSN8D81A.DSN8S81C             TORBA X'0000EF2C66F4' /* // 

The RECOVER INDEX (or RECOVER INDEXSPACE ) Utility

RECOVER INDEX (or alternatively RECOVER INDEXSPACE ) is executed to restore DB2 indexes to a current or previous state. The utility first reads the DB2 Catalog to determine the availability of image copies, and then reads the DB2 logs to determine interim modifications. The utility then applies the image copies and the log modifications to the index space data set of the index being recovered.

RECOVER INDEXSPACE is similar to RECOVER TABLESPACE , except that it operates on DB2 indexes instead of DB2 table spaces. DB2 V6 is the first release of DB2 that enabled recovery of indexes from image copy data sets. The JCL to run the RECOVER INDEXSPACE utility is provided in Listing 32.8.

Listing 32.8. RECOVER INDEXSPACE JCL
 //DB2JOBU  JOB (UTILITY),'DB2 RECVR INDEX',MSGCLASS=X,CLASS=X, //          NOTIFY=USER //* //**************************************************************** //* //*         DB2 RECOVER INDEXSPACE UTILITY //* //**************************************************************** //* //UTIL EXEC DSNUPROC,SYSTEM=DSN,UID='RCVRINDX',UTPROC=" //* //*  UTILITY WORK DATASETS //* //* //*  UTILITY INPUT CONTROL STATEMENTS //*     Recovers the XPROJ1 index from an image copy. //* //DSNUPROC.SYSIN    DD  *     RECOVER INDEXSPACE DSN8D81A.XPROJ1 /* // 

NOTE

Prior to V6, all indexes had to be rebuilt from the data, not an image copy. Additionally, prior to DB2 V6, the RECOVER utility performed this index rebuilding. But as of V6, the REBUILD INDEX utility is used to rebuild indexes from table data, not the RECOVER utility.


RECOVER Phases

The RECOVER utility has up to six phases:

UTILINIT

Sets up and initializes the RECOVER utility.

RESTORE

Locates and merges all appropriate image copy data sets, after which the table space or index space is restored to the given point using the merged image copy data; processes a list of objects in parallel if you specified the PARALLEL keyword.

RESTORER

For RECOVER with the PARALLEL option, this phase reads and merges the image copies.

RESTOREW

For RECOVER with the PARALLEL option, this phase writes the pages to the object.

LOGAPPLY

Locates outstanding modifications from the log and applies them to the table space or index space being recovered.

UTILTERM

Performs the final utility cleanup.


The RESTORE phase is bypassed if the LOGAPPLY option is specified.

RECOVER Locking Considerations

The RECOVER utility can run concurrently with the following utilities:

  • DIAGNOSE

  • REPORT

  • STOSPACE

Additionally, unless RECOVER TOCOPY or TORBA is specified, RECOVER can run concurrently with REORG INDEX and REPAIR LOCATE INDEX .

The RECOVER utility drains all claim classes for the table space, partition, or index being recovered, regardless of the options specified. However, if the ERROR-RANGE option is specified, the locking level is downgraded to a write claim during the UTILINIT phase.

If either the TORBA or TOCOPY option is specified, RECOVER will drain all claim classes for the index or index partition, as well as any non-partitioned index.

RECOVER Guidelines

Be sure to implement the following guidelines when you are recovering table spaces.

Retain Tape Mounts

When using RECOVER with image copies on one or more tape volumes , you do not need to code JCL statements to retain the tape mounts. You can use the PARALLEL and TAPEUNITS keywords to control the allocation of tape devices for the job. At times RECOVER will not be able to retain all tape mounts causing tapes to be deallocated, even when specifying PARALLEL and TAPEUNITS .

Do Not Specify Work Data Sets

The RECOVER utility does not require work data sets to recover DB2 table spaces and indexes.

Improve Recovery Performance by Avoiding SHRLEVEL CHANGE Copies

If RECOVER TABLESPACE is used for a table space in which an image copy data set was created with the SHRLEVEL CHANGE specification, the performance of the RECOVER utility degrades. The log RBA stored for an image copy taken with SHRLEVEL CHANGE is at an earlier portion of the log because the table space can be modified during the execution of the COPY utility. Therefore, the RECOVER utility reads the log RBA recorded with the image copy in the SYSIBM.SYSCOPY table and scans the active and archive logs for changes starting with that RBA. Performance can degrade because more log records are read.

Recover SHRLEVEL CHANGE Copies Appropriately

Image copies taken using SHRLEVEL CHANGE must be recovered to the current point in time or to a specific point in time using TORBA (not TOCOPY ). If a SHRLEVEL CHANGE image copy is recovered using the TOCOPY option, it will be in an indeterminate stage.

Be Aware of Underlying VSAM Data Set Deletions

The underlying VSAM data sets for STOGROUP -defined table spaces are deleted and defined by the RECOVER TABLESPACE utility. If the table space has been user-defined, the corresponding VSAM data set is not deleted.

Recover Multiple Objects with a Single RECOVER

When multiple table spaces must be recovered, code the utility control cards with multiple table spaces assigned to one RECOVER keyword. For example, code this

 

 RECOVER TABLESPACE  DSN8D81A.DSN8S81C         TABLESPACE  DSN8D81A.DSN8S81D         TABLESPACE  DSN8D81A.DSN8S81E 

instead of

 

 RECOVER TABLESPACE  DSN8D81A.DSN8S81C RECOVER TABLESPACE  DSN8D81A.DSN8S81D RECOVER TABLESPACE  DSN8D81A.DSN8S81E 

Coding the control cards the first way ensures that the archive and active logs are read only once. If the control cards are coded as shown in the second example, the RECOVER TABLESPACE utility runs three times, causing the archive and active logs to be read separately for each invocation of the utility. This reduces CPU time, elapsed time, and time spent waiting for an operator to load the archive tapes.

Consider Restoring in Parallel

If multiple objects are to be recovered, consider using the PARALLEL parameter to restore the objects concurrently. When the PARALLEL option is specified, the RECOVER utility will perform parallel processing during the RESTORE phase. Additionally, you can specify a limit for the number of objects to restore in parallel ”for example, PARALLEL(4) indicates that four objects should be restored at a time.

NOTE

If you specify PARALLEL(0) or do not indicate a value (that is, you specify simply PARALLEL ), RECOVER will determine the optimal number of objects to process in parallel.


Consider Explicitly Allocating Image Copy Data Sets

DB2 dynamically allocates image copy and log data sets during the execution of the RECOVER utility to minimize an analyst's work during recovery. However, the image copy input to the RECOVER utility can be specified explicitly in the JCL by simply coding a DD statement for each full and incremental image copy to be used. The DD statement can use any name not already used by the RECOVER JCL. DB2 will not dynamically allocate an image copy data set if it finds a DD statement with a matching data set name specified in the RECOVER JCL.

If image copy data sets are explicitly allocated as just described, the UNIT=AFF parameter can be coded to single-thread the image copy input to the RECOVER utility.

Use DB2's Capability to Fall Back to Previous Image Copies

Current point-in-time recovery attempts to allocate the most recent full image copy for processing. If an error is encountered for that image copy, the RECOVER utility uses the previous full image copy.

If a tape image copy data set is unavailable, the operator can reply NO to the tape mount message to cause DB2 to use a previous image copy.

Take Incremental Image Copies to Reduce Log Reading

If incremental image copies exist, the RECOVER TABLESPACE utility attempts to use them to reduce the number of log data sets and records that must be processed to accomplish the recovery.

It is not possible to use COPY to make incremental image copies for indexes, so this guideline is not applicable to indexes.

Remember to Recover Indexes

Execute the REBUILD INDEX utility for all table spaces recovered using the partial recovery options TOCOPY or TORBA . For indexes defined using COPY YES , execute the RECOVER INDEX utility to bring the indexes up to the same point as the table spaces. Failure to REBUILD or RECOVER indexes results in invalid indexes.

Avoid Relative Generation Numbers for GDG Image Copies

The TOCOPY option of the RECOVER TABLESPACE utility is used to explicitly name an image copy data set to which the named table space will be recovered. If the image copy data set is a GDG, the fully qualified data set name must be specified, including the absolute generation and version number. Relative generation number specification is not supported by the RECOVER utility.

Specify a Valid Image Copy Data Set

When the TOCOPY option is used, the image copy data set specified must be recorded in the SYSIBM.SYSCOPY table. If it is not, the recovery fails.

Recover Table Spaces As Appropriate for the Image Copy

Recovery must be processed according to the type of image copy available. For example, if image copies were taken for a partitioned table space at the DSNUM level, RECOVER TABLESPACE must operate at the DSNUM level.

Recover Only Complete Units of Work

Avoid recovering table spaces to an RBA other than an RBA recorded in the SYSIBM.SYSCOPY table as a result of the QUIESCE utility. Recovery to an RBA other than a quiesce point RBA may cause recovery to the middle of a unit of work, resulting in inconsistent data.

Recover Only Consistent Image Copies

Avoid using the TOCOPY option to recover table spaces to an image copy created with SHRLEVEL CHANGE . Doing so can cause data integrity problems because the image copy may reflect partial unit of work changes. Because the table space might have been modified during the execution of the COPY utility, the image copy without the corresponding log changes represents data in an inconsistent state.

Consider Using RECOVER with DFSMS Copies

DB2 provides the capability to recover from backup copies of DB2 data sets taken using the concurrent copy feature of DFSMS. Follow these steps to accomplish this:

  1. STOP all table spaces to be recovered.

  2. START the objects in utility mode or read-only mode; ACCESS(UT) or ACCESS(RO) .

  3. Use DFSMS to restore the data sets for the table spaces in question.

  4. Use RECOVER with the LOGONLY option to apply only log records and not RESTORE from an image copy.

  5. START the table spaces in RW mode.

Consider Using CURRENTCOPYONLY with Concurrent Copies

The CURRENTCOPYONLY parameter can be used to improve the performance of RECOVER while restoring concurrent copies. It specifies that RECOVER should use only the most recent primary copy for each object in the list. The RECOVER utility will build a DFSMSdss RESTORE command for each group of objects associated with the concurrent copy data set name. But if the RESTORE fails, the object fails (and RECOVER will not automatically use the next most recent copy or the backup copy).

Restart the RECOVER Utility As Needed

RECOVER TABLESPACE is a re-startable utility. No special consideration is necessary because work data sets are not required when recovering a table space alone. The utility can be restarted by changing the DSNUTILB JCL parameter to UTPROC=RESTART .

Consult the IBM Manual When Recovering System Table Spaces

The DB2 Catalog and DB2 Directory table spaces can be recovered using the RECOVER TABLESPACE utility, but the recovery must be performed in a specific order. Consult the DB2 Database Administration Guide for details.

 <  Day Day Up  >  


DB2 Developers Guide
DB2 Developers Guide (5th Edition)
ISBN: 0672326132
EAN: 2147483647
Year: 2004
Pages: 388

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net