Space announcements


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.

Performing backout integrity checking

Backout integrity checking is the process of checking for anomalies before backing out problem transactions.

An anomaly is a potential data conflict that can occur between a transaction within a time frame (that Log Master may UNDO or REDO) and another transaction outside of the time frame that updates the same data. This section explains how anomalies can occur, and how to handle them when backing out application transactions.

The following types of anomalies can occur when you back out application transactions:

  • Anomalies between problem transactions (that need to be backed out) and good transactions (that need to be preserved)

  • Anomalies between transactions that are to be re-done, and transactions that have been entered after the recoveries are performed in preparation for the redo procedure

Phase 1: Identify and analyze problem transactions

The following figures describe an example problem with a set of transactions. The figures illustrate the point of discovery and problem analysis.

Identify problem transactions

Analyze problem transactions

Phase 2: Identify table space, locate point of consistency, and generate REDO SQL

The following figure illustrates the next steps to take before performing a recovery:

Locate a point of consistency

Phase 3: Take table spaces offline and recover them

The following figure illustrates the recovery step:

Stop and recover the table spaces

Phase 4: Execute REDO SQL

At this point, you execute the generated REDO SQL.

The following figure depicts possible points at which anomalies could occur:

  • Anomaly example 1: Anomalies can occur in this area of the log between a good update and one of the problem updates (which the DBA does not plan to redo); for example, an update to a row that was originally inserted by a problem transaction. The DBA and other personnel must analyze these anomalies either as they generate the REDO SQL, or as a stand-alone operation.

    In addition to performing a backout integrity check for the anomalies in example 1, you can direct the SQL processor to control responses to this type of error. For more information, see SQL code handling during SQL execution.

  • Anomaly example 2: Anomalies can occur in this area of the log between the transactions that the DBA will redo, and any changes made during the time when these transactions were 'erased' by the recovery action. For example, a user might notice a missing row and insert it again before the REDO SQL can be applied. To avoid the problem, the DBA must take steps to prevent any updates between the end of the recovery and the end of the execution of the REDO SQL.

Points in the log where anomalies can occur

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