Strategies for using copies

Image copy data set contents

An image copy data set that is not a cabinet copy never contains pages from more than one table space or index space. However, using DSNUM ALL in the image copy utility (the default) makes a copy for all of the partitions or data sets of a table space. You might override this option by making copies by using DSNUM integer or by using the BMC AMI Copy for Db2  (BMC AMI Copy) product DSNUM PART feature and dynamic allocation.

Cabinet copy data set contents

A cabinet copy contains copies from multiple table or index spaces. A cabinet copy might contain DSNUM ALL copies of copies by data set.

Copies containing multiple data sets

When you need to recover a partitioned or multi-data-set space, use of a copy containing all of the data sets has the following ramifications:

• An attempt to recover the data sets in separate jobs will cause contention for this copy.
• For image copies, the recover utility must read the pages of all previous data sets to recover a specific data set. For cabinet copies, BMC AMI Recover positions to the desired data set.
• If you always recover all of the data sets or have a very small partitioned space and have no need to run separate concurrent recoveries for data sets, an image copy for all data sets might be appropriate. If you have several small table or index spaces that need to be recovered together, a cabinet copy might be appropriate.
• The use of index-controlled partitioning or table-space-controlled partitioning has no ramifications for multi-data-set processing.

For more information about multi-data-set processing for a specific BMC AMI Recover syntax option, see the option description in Command-and-syntax-reference.

Data sets stacked on tape

BMC AMI Recover accommodates stacked tape input copies by appropriately ordering the phases of recover and using the data sets in order without dismounting wherever possible.

DD statements for the input image copy data sets should not be included in the JCL; BMC AMI Recover will dynamically allocate them in the correct order. In contrast, IBM Db2 RECOVER requires DD statements with appropriate volume references and retention and label ordering of table spaces in the statements.

You can create stacked copies with the IBM Db2 COPY utility by ordering copy statements and coding appropriate references in the JCL or by using the dynamic allocation capabilities of BMC AMI Copy. If you use wildcarding with BMC AMI Copy, stacked data sets for table spaces are ordered by database name, table space name, and data set number or partition.

BMC AMI Recover can also create output stacked image copies. If DD statements are coded in the JCL for the output image copies, they determine the output stacking order. If dynamic allocation is used, BMC AMI Recover orders the output stacked copies to match the order of any input stacked copies. If no input stacked copies are used, BMC AMI Recover follows the BMC AMI Copy ordering conventions for the output stacked copies.

If you are recovering table spaces and indexes that were copied with BMC AMI Copy by using wildcarding and specifying copies for all partitions, the following example illustrates the order of the stacking supported:

In the example, the following representations are made:

• DB.TS is a partitioned table space.
• DB.IXP is a partitioning index space.
• DB.IXN is a secondary index space.

Image copies and log records for indexes

This topic describes some of the strategies that use image copies and log records to recover indexes.

INDEXLOG AUTO and IXSIZE

BMC AMI Recover, BMC AMI Copy, and BMC AMI Recovery Manager for Db2 (BMC AMI Recovery Manager) have options that automate the creation of index image copies and the use of index image copies in recovery.

With IXSIZE option in BMC AMI Copy you can specify a threshold at which index copies will be made. IXSIZE is also supported by BMC AMI Recovery Manager.

By using the INDEXLOG AUTO option that is supported by BMC AMI Recover and BMC AMI Recovery Manager, you can specify the use of an index copy if one is available for recovery. If recovery from an image copy is not possible, BMC AMI Recover and BMC AMI Recovery Manager will fallback to rebuild the index.

Making and using copies with BMC AMI Copy

BMC AMI Copy and BMC AMI Recover coordinate copies of indexes by registering events in the BMCXCOPY table. Registration of these events in BMCXCOPY is supported for all supported versions of Db2.

For more information, see the examples in Examples-of-BMC-AMI-Recover-jobs. You can, for example, recover an entire application by using TOCOPY LASTCOPY if BMC AMI Copy has copied all of the objects.

Using log records for indexes

BMC AMI Recover can use index log records for recovery.

For media failure recovery, recovery after a failed LOAD or REORG, or disaster recovery situations, it is necessary to make copies of the index spaces by using BMC AMI Copy, the IBM Db2 COPY utility, DSN1COPY, or pack dumps. If you make copies with BMC AMI Copy or the IBM Db2 COPY utility, they can be used automatically with BMC AMI Recover and log records rolled forward from the registration point. DSN1COPY and pack dump copies must be restored to the space and BMC AMI Recover LOGONLY used to apply log records.

For point-in-time recoveries where the spaces are intact and no LOAD or REORG occurred after the point in time, you can use the BMC AMI Recover BACKOUT feature to reverse index log records to the point in time