NonStop Systems Introduction

Transaction Management
NonStop Systems Introduction—527825-001
5-10
Volume Recovery
Similarly, assume that before the transaction began, the accounts-receivable record for
the customer showed that the customer owed a total of $1500 for all orders placed to
date. After the current transaction recorded a new order of $500 in the sales-order
database, it updated the accounts-receivable record to show that the new total owed
by the customer stands at $2000.
TMF backs out this change by replacing the after-image of this field ($2000) with the
before-image ($1500). Like the sales-order database, the accounts-receivable
database now looks exactly the way it did before the transaction began.
Note that TMF does not need to back out any changes from the database at the
warehouse because the transaction failed before it could make these changes. Thus,
all three databases affected by the transaction are now in exactly the same state they
were in before the transaction began: a consistent state. TMF has backed out the
transaction successfully and preserved database consistency. Now that the
transaction is undone, TMF releases all the record locks associated with the
transaction.
The program now goes into a routine that reports shortages and logs additional orders
(saves them in a file for later processing) until the stock is replenished.
Volume Recovery
TMF is very effective in backing out individual transactions that have failed. But it
sometimes must deal with a more serious problem: the failure of many transactions at
the same time. Various types of hardware failures can cause the failure of multiple
transactions.
For example, a city-wide power outage could cause a complete system failure together
with the failure of all current transactions in the system.
Similarly, the accidental loss of a single disk volume or accidental damage to the
volume could cause the failure of all transactions that were accessing data on the
volume.
TMF responds to such failures with a recovery procedure known as volume recovery.
Suppose that an extended power failure brings down the system at the warehouse in
our distributed order-entry example. In this case, not only our order-entry transaction,
but all other transactions that are updating the warehouse database at the time of the
failure, must be backed out or redone.
•
Transactions that were not finished or had not committed their changes at the time
of failure must be backed out.
•
Transactions that committed their changes before the failure must be redone.
It makes sense that incomplete or uncommitted transactions have to be backed out.
But why do the committed transactions need to be reapplied?
The reason is that the system does not write changed database records to disk as
soon as they are updated. Instead the system allows a number of changed records to