Overview of backing out transactions
In addition, you might need to preserve transactions that were not in error but affected the same rows as the problem transactions. These type of problems can require complex analysis.
The following table lists the Log Master solutions for handling problem transactions.
Backout integrity checking
Backout integrity checking compares changes of interest to any subsequent updates and shows problems and potential solutions in concise reports.
The Log Master SQL generator offers features to undo or redo specific transactions. The WHERE clauses that the product generates are based on available index information. You can control whether updates resulting from referential integrity or trigger activity are a part of the correction process.
The High-speed Apply Engine 1distributed with Log Master executes the product’s generated SQL statements. Two methods of executing SQL are available in the Log Master online interface, but these methods provide only a subset of High-speed Apply features. To access all features of High-speed Apply, independently code JCL and define configuration parameters to run the product. Some important High-speed Apply features include:
Use the Log Master online interface to enter values for a subset of High-speed Apply configuration parameters and generate High-speed Apply JCL.
The product can execute any set of SQL statements accepted by the target database (generated either by Log Master or by some other process).
For more information, see Running SQL or see the .
1 The Log Master installation process includes the required installation of High-speed Apply. The High-speed Apply Engine honors passwords for Log Master, the Recovery Management for DB2 solution, or itself.
What to consider when selecting a backout strategy
The Log Master for DB2 product provides several features for backing out problem transactions.
Backout procedures usually include the following tasks:
Identifying and analyzing problem transactions
Creating UNDO SQL to back out transactions
Creating REDO SQL to reapply transactions after a recovery
The following table summarizes the factors involved in each backout procedure.
Selecting a backout strategy
Factors to consider
Procedure used: UNDO
Procedure used: REDO
How many SQL statements will be generated to undo problem transactions?
How many SQL statements will be generated for the table spaces from the point of consistency selected to CURRENT, excluding the problem transaction?
State of the system
Transactions can continue to access the table space during this process.
The DB2 table space must be stopped at least for REDO generation and the recovery phase of process.
How much time will be needed to recover table spaces and indexes.
Execution of SQL statements
How much time will be needed to execute UNDO SQL?
How much time will be needed to execute REDO SQL?
You can generate both UNDO and REDO SQL at the same time, and then compare the volume of statements generated and review any anomalies, before making a decision. For more information about anomalies, see Performing backout integrity checking.
If you choose REDO SQL, the table space involved must be stopped during generation and remain stopped until you complete the recovery.
Special considerations in the DB2 log
As you plan and implement a backout action, be aware of special circumstances that can occur in the DB2 log that you might need to accommodate.
For example, when Log Master scans the DB2 log records resulting from certain load actions, it can encounter log records that cause it to generate SQL statements that, when executed, result in negative SQL codes. Similarly, if the load action includes duplicate rows in the data that is loaded, you can encounter negative SQL codes. For more information about special considerations for output files and SQL, see the section about Considerations for output files and SQL.