Performing backout integrity checking

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.

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:

Phase 3: Take table spaces offline and recover them

The following figure illustrates the recovery step:

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.