Availability Guide for Application Design

Data Protection and Recovery
Availability Guide for Application Design—525637-004
4-7
Audit Trails
•
File recovery
Figure 4-2 summarizes these protection mechanisms with respect to the transaction
paradigm. It shows which mechanisms protect the data associated with one
transaction, depending on whether the transaction has not yet begun, has started but
not yet finished, or has already committed. An overview of these mechanisms follows.
For more details, refer to the Introduction to TMF.
Audit Trails
The audit trail keeps a record of all transaction activity by keeping records of:
•
Transaction status information
•
Before images
•
After images
Transaction status information contains general bookkeeping data such as timestamps
and whether the transaction is active or in one of the commit phases.
Before images are copies of records or rows from the database, taken before the
transaction applies changes to those records or rows. These images can be used to
back out changes made by an uncommitted transaction when an operator or data entry
clerk intentionally requests a transaction abort; the program logic determines that the
transaction cannot finish; or a failure leaves the database in an inconsistent state.
After images contain a record of all changes made to the database by committed
transactions. This feature provides protection against multiple failures, such as a total
system failure or losing both members of a mirrored disk volume.
Figure 4-2. Protecting Transaction Data
Transaction
Processing
Application
Start
Transaction
.
.
.
End Transaction
No data to protect
for this transaction
Data consistency protected from operator
abort by transaction backout and from
component or system failure by volume
recovery
Data protected from site or media
failure by online dumps, audit
dumps,
and file recovery
VST302.vdd