/INBerkeley DB Reference Guide: Transaction Protected Applications[PH

Berkeley DB Reference Guide: Transaction Protected Applications



)

Recovery procedures



GThe fourth component of the infrastructure, recovery procedures,Fconcerns the recoverability of the database. After any application orGsystem failure, there are two possible approaches to database recovery.

IIf there is no need to retain state across the failure, and all databasesHcan be recreated from scratch, the database home directory can simply beremoved and recreated.

CIf it is necessary to retain persistent state across failures, thenrecovery (using the db_recover utility, or the DB_RECOVERor DB_RECOVER_FATAL flags to db_appinit) must beMperformed on each Berkeley DB application environment, that is, each databasehome directory.

FPerforming 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 performHtransaction recovery. Database applications must not be restarted untilDrecovery completes. During recovery, all changes made by aborted orDunfinished transactions are undone and all changes made by committed@transactions are redone, as necessary. After recovery runs, theJenvironment is properly initialized so that applications may be restarted.HAny time an application crashes or the system fails, recovery processingIshould be performed on any database environments that were active at thattime.

EAdditionally, there are two forms of recovery: normal recoveryBand catastrophic recovery. The Berkeley DB package definesIcatastrophic failure to be failure where either the database or log filesJhave been destroyed or corrupted from the point of view of the filesystem.HFor example, catastrophic failure includes the case where the disk driveDon which either the database or logs are stored has crashed, or whenFfilesystem recovery is unable to bring the database and log files to a0consistent state with respect to the filesystem.

HIf the failure is non-catastrophic, i.e., the database files and log areCaccessible on a filesystem that has recovered cleanly, the recoveryBprocess will review the logs and database files to ensure that allGcommitted transactions appear and that all uncommitted transactions areundone.

HIf the failure is catastrophic, a snapshot of the database files and theGarchived log files must be restored onto the system. Then the recoveryHprocess will review the logs and database files to bring the database toFa consistent state as of the date of the last archived log file. OnlyDtransactions committed before that date will appear in the database.

PAO