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 NGT 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, NGT 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 NGT Recover syntax option, see the option description in Command and syntax reference.

Data sets stacked on tape

NGT 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; NGT Recover will dynamically allocate them in the correct order. In contrast, 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 DB2 COPY utility by ordering copy statements and coding appropriate references in the JCL or by using the dynamic allocation capabilities of BMC Next Generation Technology Copy for DB2 for z/OS. If you use wildcarding with NGT Copy, stacked data sets for table spaces are ordered by database name, table space name, and data set number or partition.

NGT 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, NGT Recover orders the output stacked copies to match the order of any input stacked copies. If no input stacked copies are used, NGT Recover follows the NGT Copy ordering conventions for the output stacked copies.


To recover a space, NGT Recover requires parallel access to all required copies for a merge operation. NGT 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. NGT Recover issues the following message in this case:


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 NGT 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.


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 NGT 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.


NGT Recover, NGT Copy, and 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 NGT Copy you can specify a threshold at which index copies will be made. IXSIZE is also supported by RECOVERY MANAGER.

By using the INDEXLOG AUTO option that is supported by NGT Recover and 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, NGT Recover and RECOVERY MANAGER will fallback to rebuild the index.

Making and using copies with NGT Copy

NGT Copy and NGT 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 NGT Recover jobs. You can, for example, recover an entire application by using TOCOPY LASTCOPY if NGT Copy has copied all of the objects.


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

Using log records for indexes

NGT 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 NGT Copy, the DB2 COPY utility, DSN1COPY, or pack dumps. If you make copies with NGT Copy or the DB2 COPY utility, they can be used automatically with NGT Recover and log records rolled forward from the registration point. DSN1COPY and pack dump copies must be restored to the space and NGT 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 NGT Recover BACKOUT feature to reverse index log records to the point in time.

Related topic

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