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.

Using R+/CHANGE ACCUM with BMC AMI Recover

The following information pertains to the BMC R+/CHANGE ACCUM for Db2 product.

This product is designed to work with BMC AMI Recover to streamline normal and disaster recovery processes. R+/CHANGE ACCUM accumulates log record data for a specified object or group of objects. Log record data for specified objects is extracted and stored in a change accumulation file. For detailed information about using this product, see the R+/CHANGE ACCUM documentation .

Using change accumulation files for multiple objects

Using R+/CHANGE ACCUM, you can select several specific table spaces and define them as a group.

When you run a R+/CHANGE ACCUM batch job on the group, you create a change accumulation file of log record data for all of the table spaces in the group. You may elect to include log record data for all of the indexes on all of the table spaces in the group.

You may want to create change accumulation files for multiple objects if you are writing change accumulation files to tape or want to avoid creating too many disk data sets. Objects defined as a group are ordered alphabetically by database name and then table space name. Data sets or partitions are ordered within the same space.

When you need to recover an object that shares a change accumulation data set with other objects, consider the following ramifications:

  • An attempt to recover the objects on a file in separate jobs will cause contention for this change accumulation file.

  • BMC AMI Recover must read the log records of all previous objects (sequentially) to recover a specific object.

If you always recover all of the objects or do not anticipate many log records between copies and have no need for separate recovers for the objects, a change accumulation file for multiple objects may be entirely appropriate.

You should attempt to coordinate stacked tape copies and change accumulation containing multiple objects so that, if you use them, you combine objects in a similar order. Target table spaces (table spaces targeted for change accumulation) are ordered by the following items:

  • Database name

  • Table space name

  • Data set number

Indexes for each table space follow the table space in order by partitioned indexes first, and then nonpartitioned indexes, in order by database name and index space name. You should use this order when stacking image copies on tape.

The BMC AMI Copy for Db2  product orders objects in a similar fashion when using wildcards and dynamic stacking. BMC AMI Recover optimizes access for shared resources, but cannot create an optimal plan if both stacked copies and change accumulation files for multiple objects are used and the stacking is not alphabetical.

Using separate change accumulation files for separate data sets

If you generate separate change accumulation files for separate data sets of a table space, you should use caution in also combining other objects in the same change accumulation file.

Some situations could cause BMC AMI Recover to create a less than optimal plan for recovering objects.

If a particular data set of a table space shares a change accumulation file with other objects and BMC AMI Recover attempts to use a copy including all data sets or to unload keys for a nonpartitioned index on a partitioned space, the plan may use more tape drives or have to reread parts of a copy or change accumulation file to process.


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

Comments