Using R+/CHANGE ACCUM with BMC AMI Recover
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 might elect to include log record data for all of the indexes on all of the table spaces in the group.
You might 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 might 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 might use more tape drives or have to reread parts of a copy or change accumulation file to process.