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:

1. There is no need for recoverability and all databases can be recreated from scratch. While these applications may still need transaction protection for other reasons, recovery will usually consist of removing the Berkeley DB environment home directory and all files it contains, and then restarting the application.

2. It is necessary to recover information after system or application failure. In this case, recovery processing must be performed on any database environments that were active at the time of the failure. Recovery processing involves running the db_recover utility or calling the DBENV->open function with the DB_RECOVER or DB_RECOVER_FATAL flags, for each Berkeley DB environment.

   During recovery processing, all database changes made by aborted or unfinished transactions are undone and all database changes made by committed transactions are redone, as necessary. Database applications must not be restarted until recovery completes. After recovery finishes, the environment is properly initialized so that applications may be restarted.

If recovery is to be performed, there are two possible types of recovery processing:

1. catastrophic recovery. The Berkeley DB package defines catastrophic failure to be failure where either the database or log files have been destroyed or corrupted. For example, catastrophic failure includes the case where the disk drive on which either the database or logs are stored has been physically destroyed, or when the system's normal filesystem recovery on startup is unable to bring the database and log files to a consistent state. This is often difficult to detect, and perhaps the most common sign of the need for catastrophic recovery is when the normal recovery procedures fail.

   If the failure is catastrophic, the most recent snapshot of the database files and any archived log files must be restored onto the system. If any log files since the last snapshot are available, they should be placed into the Berkeley DB environment directory where recovery will be performed. Then run the db_recover utility, specifying its -c option, or call the DBENV->open function specifying the DB_RECOVER_FATAL flag. The catastrophic recovery process will review the logs and database files to bring the environment's database to a consistent state as of the time of the last uncorrupted log file that is found. It is important to realize that only transactions committed before that date will appear in the databases.

2. normal or non-catastrophic recovery. If the failure is non-catastrophic and the database files and log are both accessible on a filesystem that has recovered cleanly, run the db_recover utility without the -c option or call the DBENV->open function specifying the DB_RECOVER flag. The normal recovery process will review the logs and database files to ensure that all changes associated with committed transactions appear in the databases and that all uncommitted transactions do not.

Copyright Sleepycat Software