Space announcement

   

This space provides the same content as before, but the organization of the home page has changed. The content is now organized based on logical branches instead of legacy book titles. We hope that the new structure will help you quickly find the content that you need.

Strategies for using copies

This topic describes strategies for using image copies and cabinet 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 may 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 may 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 may be appropriate. If you have several small table or index spaces that need to be recovered together, a cabinet copy may 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.

Note

To recover a space, BMC AMI Recover requires parallel access to all required copies for a merge operation. BMC AMI Recover does not support recovery requests where two or more required copies, such as a full and an incremental copy, are on the same stacked tape. BMC AMI Recover issues the following message in this case:

BMC40087S REQUIRED INPUT COPIES SHARE THE STACKED TAPE AND CAN NOT BE USED FOR MERGE OPERATION

Ensure that input copies that are required to recover any single space do not share a stacked tape.

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:

DB.TS DSNUM ALL
DB.IXP PART 1
.
.
.
DB.IXP PART n
DB.IXN

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.

Note

If you use stacked image copy tapes and also plan to use R+/CHANGE ACCUM to create change accumulation files, you can use BMC products to coordinate the order for maximum efficiency. R+/CHANGE ACCUM orders log records for multiple table spaces by database name, table space name, and DSNUM. Log records for table spaces and indexes are ordered like the preceding copies made by BMC AMI Copy.

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.

Note

Copies of indexes with the BMC AMI Copy attribute are registered in the SYSIBM.SYSCOPY table. BMC AMI Recover can also use these copies for recovery.

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.

Related topic










Was this page helpful? Yes No Submitting... Thank you

Comments