Availability Guide for Application Design

Data Protection and Recovery
Availability Guide for Application Design—525637-004
4-8
Transaction Backout
The audit trail is kept on a separate disk or mirrored disk volume to ensure that the
same failure does not destroy the database file or table and the active audit volume.
The audit trail can span multiple volumes, if so configured, and thus reduce the chance
of the application becoming unavailable if the audit trail fills up.
TMF also provides overflow audit volumes to allow expansion without causing
application downtime during periods of increased audit generation.
Application developers need to know which database files and tables will be audited,
although control of which database files and tables are audited is in the hands of the
system administrator. Audit trails do take up additional disk space but, because of the
benefits of automatic cache buffering and optional audit compression, require little, if
any, extra processing time.
Transaction Backout
For transactions that do not successfully finish, it is necessary to leave the database as
if the transaction had never happened. For example, if a data-entry clerk in an airline
reservation system discovers, while entering a reservation, that part of the journey is
unacceptable to the customer, then those parts of the itinerary already entered might
need to be backed out.
Again, the application programmer is responsible for providing the points at which the
user can abort the transaction. To support this feature, TMF keeps a before-image log
of all data records or rows affected by the transaction. In other words, it keeps a copy
of all data records or rows before they were modified by the transaction. If the
transaction is aborted, TMF simply writes the before-image records or rows back to the
database; the database looks like the transaction never happened.
Backout also occurs if the process that started the transaction or its processor fails; in
this case, TMF aborts the transaction. Also, if a primary disk process or its processor
fails, the backup disk process aborts the transaction. If both members of a disk process
pair fail, TMF aborts all transactions in the local system. These are examples of
system-generated unilateral aborts. Unilateral aborts are described in the TMF
Application Programmer’s Guide.
Volume Recovery
Volume recovery can take place if a disk volume becomes unavailable for any reason,
including a system failure, a multiple hardware failure, or operator action. In either
case, applications might be executing transactions at the time of the failure. When the
system or the disk volume comes back online, the application cannot know how much
of the transaction has executed.
To ensure that all transactions either execute entirely or not at all, TMF rolls back the
database by backing out all transactions that were in process at the time of the failure.
TMF uses the status records in the audit trail to find out which transactions were still in
progress and then uses the before images for those transactions to roll back the
database.