Software: Apache/2.0.54 (Unix) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.54 OpenSSL/0.9.7l DAV/2 FrontPage/5.0.2.2635 PHP/4.4.0 mod_gzip/2.0.26.1a 

uname -a: Linux snow.he.net 4.4.276-v2-mono-1 #1 SMP Wed Jul 21 11:21:17 PDT 2021 i686 

uid=99(nobody) gid=98(nobody) groups=98(nobody) 

Safe-mode: OFF (not secure)

/usr/doc/db-3.3.11/ref/program/   drwxr-xr-x
Free 318.32 GB of 458.09 GB (69.49%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     recimp.html (3.12 KB)      -rw-r--r--

Berkeley DB Reference Guide: Programmer Notes

Recovery implementation

The physical recovery process works as follows:

First, find the last checkpoint that completed. Because 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, 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 previously.

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, 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, 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, it is aborted as any other transactions would be.

Copyright Sleepycat Software