Using BACKOUT

When you must recover to a point in time, the table spaces and index spaces are normally undamaged and up-to-date, but the spaces contain the results of unwanted updates. For this scenario,

BMC AMI Recover

provides an additional alternative for point-in-time recovery. The following figure illustrates copies that are taken on a weekend, archive logs that are created during the week, and a batch job that runs on Friday night, updating a set of table spaces and indexes. If this job runs incorrectly, a point-in-time recovery is needed to a point before the job.

A point-in-time recovery normally uses image copies and archive and active logs to recover the table spaces. Unless you make image copies of the indexes, you must rebuild the indexes. BACKOUT allows BMC AMI Recover to use the active logs only in this case. Tape mounts are completely avoided and only the parts of the index and table spaces that need to be updated are read and written.

The following figure shows the BACKOUT recovery uses the spaces and logs

Preparing for a BACKOUT recovery

All that is required for a BACKOUT recovery is a point of consistency.

You may quiesce your spaces before a batch job and prepare a RECOVER with the BACKOUT option to use in a batch job failure situation. If you want a copy before the batch job to protect against a media failure or for disaster recovery, use BMC AMI Copy with the Snapshot Copy capability. You may start your batch job after the COPY has obtained a quiesce point for your application group. You can send the copies, when completed, to your disaster storage vault. If the batch job fails, you can use the RECOVER with BACKOUT strategy. The batch job can then be restarted, or normal activity can resume without the batch run.

Executing a BACKOUT recovery

The following sample syntax illustrates a RECOVER with BACKOUT:

RECOVER TABLESPACE PAYROLL.EMPLOYEE
        TABLESPACE PAYROLL.TAXRATES
        TABLESPACE PAYROLL.BENEFITS
        INDEXSPACE PAYROLL.EMPNUMIN
        INDEXSPACE PAYROLL.EMPNAMIN
        INDEXSPACE PAYROLL.TAXSTSIN
        INDEXSPACE PAYROLL.BENEPLIN TOLOGPOINT LASTQUIESCE BACKOUT

When the BACKOUT option is used for point-in-time recovery, no copies are used. The log records from the current point of the log to the TOLOGPOINT requested are used to back out changes. This recovery is often far cheaper in terms of resources than a conventional forward recovery.

When you use the BACKOUT facility for a point-in-time recovery, you can use log records to recover the indexes. Because no copies are needed, you do not need to make copies of indexes to use this facility. For large indexes, this strategy can be much more efficient than rebuilding the indexes from the recovered table space. This facility also allows BMC AMI Recover to read and write only the portions of the table spaces and index spaces that are affected by the log records backed out.

After a BACKOUT recovery of an index, you cannot recover the index to the current point in time. You must perform one of the following actions:

Execute the BACKOUT with OUTCOPY YES to create a copy to be used in a later recovery from media damage.
Run BMC AMI Copy for Db2 after the BACKOUT. You can make a SHRLEVEL CHANGE copy to reduce the impact on your applications.
Rebuild the index if it becomes damaged before its next image copy.

When is BACKOUT recovery allowed?

The following restrictions apply to a recovery that uses the BACKOUT option:

Your space must be undamaged and up to date to use BACKOUT. You cannot use BACKOUT if a LOAD or REORG occurred at or after the log point that is requested. You can, however, use BACKOUT with a TOLOGPOINT after a LOAD or REORG, effectively recovering to points after such an event even if no image copy was made.
If a mass delete on a segmented table that is not defined with DATA CAPTURE CHANGES is backed out, BMC AMI Recover will discover that there is data loss if data pages have been reused and will terminate with an error message.
If a prior point-in-time recovery has occurred, you cannot request a point-in-time recovery between the PIT_RBA and the START_RBA of the earlier recovery.
Exception statuses such as RECP are not allowed on a space that is subject to BACKOUT. However, if you are restarting the BACKOUT, the RECP status is allowed.
The BACKOUT option cannot be used with INDEP OUTSPACE, OUTCOPY ONLY, DROPRECOVERY, or OBIDXLAT.
You cannot use RECOVER INDEX or RECOVER INDEXSPACE through a point in time that is created by BACKOUT.
BACKOUT is not valid for
- LOB spaces
- NOT LOGGED spaces
- Hash spaces

BACKOUT and indexes

The BACKOUT feature operates on table spaces and indexes.

When you recover a table space to a previous point in time, you must also recover all indexes that are defined on that table space to the same point in time or you must rebuild them. This recovery or rebuild is required whether or not BACKOUT is used. Because BACKOUT operates on indexes and does not require an image copy, you can usually use it to avoid expensive rebuild operations, even on indexes that are never image copied.

An exception occurs when you recover an individual partition of a partitioned table space to a previous point in time. In this case, you will need to rebuild any nonpartitioned indexes (NPIs) that are defined on the table space.

BACKOUT recovery and restart

You can restart a job that was using BACKOUT, but you must not change the TOLOGPOINT. You must not rerun such a job because BMC AMI Recover does not accept the exception statuses, such as RECP, except in restart.