This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
Log Master for DB2
Log Master for DB2
What is the Backout Integrity Report (BIC), and what are the implications of running it
Provides information about changes in data that would complicate an UNDO or REDO action. For each change that is part of an UNDO or REDO action, the report shows information about the change and about
subsequent changes that would be affected if the original change is executed. The report also supplies information about the set of affected objects and the volume of information affected by the changes.
The report presents only data associated with committed transactions.
(The following is IMPORTANT TO REMEMBER as customers are often surprised when the logscan is scanning to CURRENT when they has specified an ENDPOINT well before CURRENT)
To generate a Backout Integrity report, Log Master scans the DB2 log to the current time, even if you do not specify CURRENT as your end point.
Log Master takes this action because the log records that you select might be affected by subsequent transactions that occur after your time frame.
Log Master defines the current time as the last relative byte address (RBA) or log record sequence number (LRSN) that DB2 has written to the log when the Log Master job begins executing.
Log Master can produce the Backout Integrity report in two formats:
Detail (including field data and all URID information) or Summary (a more concise report, omitting field data and some URID information).
Use the SUMMARY keyword to generate the concise version of the Backout Integrity report.
Log Master cannot produce either version of a Backout Integrity report when the input source of your log scan is individual DB2 log files (INPUTDB2LOG).
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
For a detailed description on how to Identify and analyze problem transactions see the Log Master Users Guide starting on page 171.