Berkeley DB Reference Guide: Transaction Protected Applications
Recovery procedures
The fourth component of the infrastructure, recovery procedures, concerns the recoverability of the database. After any application or system failure, there are two possible approaches to database recovery.
If there is no need to retain state across the failure, and all databases can be recreated from scratch, the database home directory can simply be removed and recreated.
If it is necessary to retain persistent state across failures, then recovery (using the db_recover utility, or the DB_RECOVER or DB_RECOVER_FATAL flags to db_appinit) must be performed on each Berkeley DB application environment, that is, each database home directory.
Performing recovery will remove all the shared regions (which may have been corrupted by the failure), establish the end of the log by identifying the last record written to the log, and then perform transaction recovery. Database applications must not be restarted until recovery completes. During recovery, all changes made by aborted or unfinished transactions are undone and all changes made by committed transactions are redone, as necessary. After recovery runs, the environment is properly initialized so that applications may be restarted. Any time an application crashes or the system fails, recovery processing should be performed on any database environments that were active at that time.
Additionally, there are two forms of recovery: normal recovery and catastrophic recovery. The Berkeley DB package defines catastrophic failure to be failure where either the database or log files have been destroyed or corrupted from the point of view of the filesystem. For example, catastrophic failure includes the case where the disk drive on which either the database or logs are stored has crashed, or when filesystem recovery is unable to bring the database and log files to a consistent state with respect to the filesystem.
If the failure is non-catastrophic, i.e., the database files and log are accessible on a filesystem that has recovered cleanly, the recovery process will review the logs and database files to ensure that all committed transactions appear and that all uncommitted transactions are undone.
If the failure is catastrophic, a snapshot of the database files and the archived log files must be restored onto the system. Then the recovery process will review the logs and database files to bring the database to a consistent state as of the date of the last archived log file. Only transactions committed before that date will appear in the database.
