head 1.2; access; symbols RPM_4_2_1:1.1.1.5 RPM_4_2:1.1.1.5 RPM_4_1_1:1.1.1.5 RPM_4_1:1.1.1.4 RPM_4_0_5:1.1.1.3 RPM_4_0_4:1.1.1.2 RPM_4_0_3:1.1.1.1 RPM:1.1.1; locks; strict; comment @# @; 1.2 date 2008.01.02.09.55.44; author rse; state dead; branches; next 1.1; commitid z4cpSiAhOCXk5PLs; 1.1 date 2001.07.23.20.45.38; author rse; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2001.07.23.20.45.38; author rse; state Exp; branches; next 1.1.1.2; 1.1.1.2 date 2002.01.08.00.30.12; author rse; state Exp; branches; next 1.1.1.3; 1.1.1.3 date 2003.01.18.13.49.03; author rse; state Exp; branches; next 1.1.1.4; 1.1.1.4 date 2001.12.06.00.08.19; author rse; state Exp; branches; next 1.1.1.5; 1.1.1.5 date 2003.01.18.14.05.00; author rse; state Exp; branches; next ; desc @@ 1.2 log @remove the ancient RPM 4.2.1 source tree copy @ text @ Berkeley DB Reference Guide: Recovery procedures

Berkeley DB Reference Guide:
Berkeley DB Transactional Data Store Applications

 PrevRefNext

Recovery procedures

The fifth 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 re-created from scratch. Although these applications may still need transaction protection for other reasons, recovery usually consists 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 DB_ENV->open function with the DB_RECOVER or DB_RECOVER_FATAL flags.

    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 you intend to do recovery, there are two possible types of recovery processing:

  1. catastrophic recovery. A failure that requires catastrophic recovery is a failure where either the database or log files are 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 cannot bring the database and log files to a consistent state. This is often difficult to detect, and is perhaps the most common sign of the need for catastrophic recovery is when the normal recovery procedures fail.

    To restore your database environment after catastrophic failure, take the following steps:

    1. Restore the most recent snapshots of the database and log files from the backup media into the system directory where recovery will be performed.

    2. If any log files were archived since the last snapshot was made, they should be restored into the Berkeley DB environment directory where recovery will be performed. Make sure that you restore them in the order in which they were written. The order is important because it's possible that the same log file appears on multiple backups, and you want to run recovery using the most recent version of each log file.

    3. Run the db_recover utility, specifying its -c option; or call the DB_ENV->open function, specifying the DB_RECOVER_FATAL flag. The catastrophic recovery process will review the logs and database files to bring the environment databases 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.

      It is possible to re-create the database in a location different from the original by specifying appropriate pathnames to the -h option of the db_recover utility. In order for this to work properly, it is important that your application refer to files by names relative to the database home directory or the pathname(s) specified in calls to DB_ENV->set_data_dir, instead of using full pathnames.

  2. non-catastrophic or normal recovery. If the failure is non-catastrophic and the database files and log are both accessible on a stable filesystem, run the db_recover utility without the -c option or call the DB_ENV->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 appear.

PrevRefNext

Copyright Sleepycat Software @ 1.1 log @Initial revision @ text @d1 1 a1 1 @ 1.1.1.1 log @Import: RPM 4.0.3 @ text @@ 1.1.1.2 log @Import: RPM 4.0.4 @ text @d1 1 a1 1 d14 1 a14 1 PrevRefNext d40 14 a53 21

If performing recovery, there are two types of recovery processing: normal and catastrophic. Which you choose depends on the source for the database and log files you are using to recover.

If up-to-the-minute database and log files are accessible on a stable filesystem, normal recovery is sufficient. Run the db_recover utility or call the DB_ENV->open function specifying the DB_RECOVER flag. Note this case never includes recovery using archival snapshots of the database environment. For example, you cannot archive databases and log files, restore the backup and then run normal recovery -- you must always run catastrophic recovery when using archived files.

If the database or log files have been destroyed or corrupted, or normal recovery fails, catastrophic recovery is required. For example, catastrophic failure includes the case where the disk drive where the database or log files are stored has been physically destroyed, or when the underlying filesystem is corrupted and the operating system's normal filesystem checking procedures cannot bring that filesystem to a consistent state. This is often difficult to detect, and a common sign of the need for catastrophic recovery is when normal Berkeley DB recovery procedures fail. When catastrophic recovery is necessary, take the following steps: d56 2 a57 1 the backup media into the directory where recovery will be performed. d59 5 a63 9 should be restored into the directory where recovery will be performed.

If any log files are available from the database environment that failed (for example, the disk holding the database files crashed, but the disk holding the log files is fine), those log files should be copied into the directory where recovery will be performed.

Be sure to restore all log files in the order they were written. The order is important because it's possible the same log file appears on multiple backups, and you want to run recovery using the most recent version of each log file. d79 10 a88 1

PrevRefNext @ 1.1.1.3 log @Import: RPM 4.0.5 @ text @d1 2 a2 2 a3 1 d31 1 a31 1 calling the DB_ENV->open method with the DB_RECOVER or d44 6 a49 6 filesystem, normal recovery is usually sufficient. Run the db_recover utility or call the DB_ENV->open method specifying the DB_RECOVER flag. Note this case never includes recovery using archival snapshots of the database environment. For example, you cannot archive databases and log files, restore the backup and then run normal recovery -- you must always run catastrophic recovery when using d53 7 a59 8 catastrophic failure includes the case where the disk drive on which the database or log files are stored has been physically destroyed, or when the underlying filesystem is corrupted and the operating system's normal filesystem checking procedures cannot bring that filesystem to a consistent state. This is often difficult to detect, and a common sign of the need for catastrophic recovery is when normal Berkeley DB recovery procedures fail, or when checksum errors are displayed during normal database procedures. When catastrophic recovery is necessary, take the d75 1 a75 1 or call the DB_ENV->open method, specifying the DB_RECOVER_FATAL @ 1.1.1.4 log @Import: RPM 4.1 @ text @d1 2 a2 2 d4 1 d32 1 a32 1 calling the DB_ENV->open function with the DB_RECOVER or d45 6 a50 6 filesystem, normal recovery is sufficient. Run the db_recover utility or call the DB_ENV->open function specifying the DB_RECOVER flag. Note this case never includes recovery using archival snapshots of the database environment. For example, you cannot archive databases and log files, restore the backup and then run normal recovery -- you must always run catastrophic recovery when using d54 8 a61 7 catastrophic failure includes the case where the disk drive where the database or log files are stored has been physically destroyed, or when the underlying filesystem is corrupted and the operating system's normal filesystem checking procedures cannot bring that filesystem to a consistent state. This is often difficult to detect, and a common sign of the need for catastrophic recovery is when normal Berkeley DB recovery procedures fail. When catastrophic recovery is necessary, take the d77 1 a77 1 or call the DB_ENV->open function, specifying the DB_RECOVER_FATAL @ 1.1.1.5 log @Import: RPM 4.1.1 @ text @d1 2 a2 2 a3 1 d31 1 a31 1 calling the DB_ENV->open method with the DB_RECOVER or d44 6 a49 6 filesystem, normal recovery is usually sufficient. Run the db_recover utility or call the DB_ENV->open method specifying the DB_RECOVER flag. Note this case never includes recovery using archival snapshots of the database environment. For example, you cannot archive databases and log files, restore the backup and then run normal recovery -- you must always run catastrophic recovery when using d53 7 a59 8 catastrophic failure includes the case where the disk drive on which the database or log files are stored has been physically destroyed, or when the underlying filesystem is corrupted and the operating system's normal filesystem checking procedures cannot bring that filesystem to a consistent state. This is often difficult to detect, and a common sign of the need for catastrophic recovery is when normal Berkeley DB recovery procedures fail, or when checksum errors are displayed during normal database procedures. When catastrophic recovery is necessary, take the d75 1 a75 1 or call the DB_ENV->open method, specifying the DB_RECOVER_FATAL @