Making SHRLEVEL CHANGE copies

The disadvantage of a SHRLEVEL CHANGE copy is that it does not represent a consistent view of the space or partition, because update transactions might have been in progress when the copy was made.

Transactions in progress are resolved during recovery using information in the log as well as in the copy. The log RBA (or LRSN) used in the registration of the table space copy tells BMC AMI Recover (or IBM Db2 RECOVER) where to begin processing log records for that copy. Using a SHRLEVEL CHANGE copy to do a point-in-time recovery (using the TORBA option or TOLOGPOINT option with BMC AMI Recover or IBM Db2 RECOVER) requires log processing in addition to restoring from the image copy.

Predicting recovery time and finding a consistent point for a point-in-time recovery with a SHRLEVEL CHANGE copy can be difficult. The amount of log records that must be processed significantly impacts the recovery time relative to the time needed to restore from the image copy. The amount of log is related to the activity on the system at the time of the copy, which might vary from day to day. It can be difficult to determine a recovery point that is useful with a SHRLEVEL CHANGE copy, because you cannot easily determine the last update included in the copy.

The QUIESCE BEFORE and QUIESCE AFTER options of BMC AMI Copy can be particularly useful for SHRLEVEL CHANGE copies. Using the QUIESCE BEFORE option ensures that the copy will not be registered at an RBA (or LRSN) before the QUIESCE. This puts a limit on how far back in the log the BMC AMI Recover (or the IBM Db2 RECOVER) utility needs to begin (when using the copy) to catch all update transactions that were in progress at the beginning of the copy. Using the QUIESCE AFTER option ensures a consistent state for the space or partition immediately after the copy, which establishes a known point of recovery for the copy in case a point-in-time recovery is necessary.

If GROUP YES is used, the QUIESCE will be done for the group to establish a common point of consistency for later recovery. BMC AMI Recovery Manager can recognize this point.

Of course, the IBM Db2 QUIESCE step can be coded in a job step separate from BMC AMI Copy. However, when this step is coded as part of the COPY command, BMC AMI Copy provides wait and retry logic that decreases the need for manual intervention if the QUIESCE fails due to a time-out or other factors.

If SLCHGRESET is YES, BMC AMI Copy will process the COPY command natively. If SHRLEVEL CHANGE RESETMOD YES is specified and the option SLCHGRESET is NO, BMC AMI Copy passes the COPY command to the IBM Db2 COPY utility. When the COPY command is passed to the IBM Db2 COPY utility, many BMC AMI Copy options are ignored since they are not supported by the IBM Db2 COPY utility. These options are the same as those documented for the special spaces, which are also passed to the IBM Db2 COPY utility. (See Copying-the-Db2-catalog-and-directory for the options not supported.) This capability lets you use BMC AMI Copy for dynamic allocation and wild carding.

For more information about copy registration in a data sharing environment, see Copy registration in a data sharing environment for SHRLEVEL CHANGE.