- Berkeley DB Reference Guide:
- Transaction Protected Applications
|
|
The physical recovery process works as follows:
First, find the last checkpoint that completed. Since the system may have crashed while writing a checkpoint, this implies finding the second-to-last checkpoint in the log files. Read forward from this checkpoint, opening any database files for which modifications are found in the log.
Then, read backward from the end of the log. For each commit record encountered, record its transaction ID. For every other data update record, find the transaction ID of the record. If that transaction ID appears in the list of committed transactions, do nothing; if it does not appear in the committed list, then call the appropriate recovery routine to undo the operation.
In the case of catastrophic recovery, this roll-backward pass continues through all the present log files. In the case of normal recovery, this pass continues until we find a checkpoint written before the second-to-last checkpoint described above.
When the roll-backward pass is complete, the roll-forward pass begins at the point where the roll-backward pass ended. Each record is read and if its transaction id is in the committed list, then the appropriate recovery routine is called to redo the operation if necessary.
In a distributed transaction environment, there may be transactions that are prepared, but not yet committed. If these transactions are XA transactions, then they are rolled forward to their current state, and an active transaction corresponding to it is entered in the transaction table so that the XA transaction manager may call either transaction abort or commit, depending on the outcome of the overall transaction. If the transaction is not an XA transaction, then it is aborted like any other transactions would be.
|
|