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.54; 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.04; author rse; state Exp; branches; next 1.1.1.4; 1.1.1.4 date 2001.07.23.20.09.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: Upgrading Berkeley DB installations

Berkeley DB Reference Guide:
Upgrading Berkeley DB Applications

 PrevRefNext

Upgrading Berkeley DB installations

The following information describes the general process of upgrading Berkeley DB installations. There are four areas to be considered when upgrading Berkeley DB applications and database environments: the application API, the database environment's region files, the underlying database formats, and, in the case of transactional database environments, the log files. The upgrade procedures required depend on whether or not the release is a major or minor release (in which either the major or minor number of the version changed), or a patch release (in which only the patch number in the version changed). Berkeley DB major and minor releases may optionally include changes in all four areas, that is, the application API, region files, database formats, and log files may not be backward-compatible with previous releases.

Each Berkeley DB major or minor release has information in this chapter of the Reference Guide, describing how to upgrade to the new release. The section describes any API changes made in the release. Application maintainers should review the API changes and update their applications as necessary before recompiling with the new release. In addition, each section includes a page specifying whether the log file format or database formats changed in non-backward-compatible ways as part of the release. Because there are several underlying Berkeley DB database formats, and they do not all necessarily change in the same release, changes to a database format in a release may not affect any particular application.

A Berkeley DB patch release will never modify the API, regions, log files, or database formats in incompatible ways, and so applications need only be relinked (or, in the case of a shared library, pointed at the new version of the shared library) to upgrade to a new release. Note that internal Berkeley DB interfaces may change at any time and in any release (including patch releases) without warning. This means the library must be entirely recompiled and reinstalled when upgrading to new releases of the library because there is no guarantee that modules from one version of the library will interact correctly with modules from another release.

If the release is a patch release, do the following:

  1. Shut down the old version of the application.
  2. Install the new version of the application by relinking or installing a new version of the Berkeley DB shared library.
  3. Restart the application.

Otherwise, if the application does not have a Berkeley DB transactional environment, the application may be installed in the field using the following steps:

  1. Shut down the old version of the application.
  2. Remove any Berkeley DB environment using the DB_ENV->remove function or an appropriate system utility.
  3. Recompile and install the new version of the application.
  4. If the database format has changed, upgrade the application's databases. See Upgrading databases for more information.
  5. Restart the application.

Otherwise, if the application has a Berkeley DB transactional environment, but neither the log file nor database formats have changed, the application may be installed in the field using the following steps:

  1. Shut down the old version of the application.
  2. Run recovery on the database environment using the DB_ENV->open function or the db_recover utility.
  3. Remove any Berkeley DB environment using the DB_ENV->remove function or an appropriate system utility.
  4. Recompile and install the new version of the application.
  5. Restart the application.

If the application has a Berkeley DB transactional environment, and the log file format has changed, but the database formats have not, the application may be installed in the field using the following steps:

  1. Shut down the old version of the application.
  2. Run recovery on the database environment using the DB_ENV->open function or the db_recover utility.
  3. Remove any Berkeley DB environment using the DB_ENV->remove function or an appropriate system utility.
  4. Archive the database environment for catastrophic recovery. See Archival procedures for more information.
  5. Recompile and install the new version of the application.
  6. Restart the application.

Otherwise, if the application has a Berkeley DB transactional environment and the database format has changed, the application may be installed in the field using the following steps:

  1. Shut down the old version of the application.
  2. Run recovery on the database environment using the DB_ENV->open function or the db_recover utility.
  3. Remove any Berkeley DB environment using the DB_ENV->remove function or an appropriate system utility.
  4. Archive the database environment for catastrophic recovery. See Archival procedures for more information.
  5. Recompile and install the new version of the application.
  6. Upgrade the application's databases. See Upgrading databases for more information.
  7. Archive the database for catastrophic recovery again (using different media than before, of course). Note: This archival is not strictly necessary. However, if you have to perform catastrophic recovery after restarting the application, that recovery must be done based on the last archive you have made. If you make this second archive, you can use it as the basis of that catastrophic recovery. If you do not make this second archive, you have to use the archive you made in step 4 as the basis of your recovery, and you have to do a full upgrade on it before you can apply log files created after the upgrade to it.
  8. Restart the application.

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 @ 1.1.1.3 log @Import: RPM 4.0.5 @ text @d1 2 a2 2 a3 1 d39 1 a39 3 application. Further, database and log file formats may have changed but be entirely backward-compatible, in which case no upgrade will be necessary. d62 1 a62 1

  • Remove any Berkeley DB environment using the DB_ENV->remove method or an d65 2 a66 2
  • If necessary, upgrade the application's databases. See Upgrading databases for more d71 1 a71 1 but neither the log file nor database formats need upgrading, the d75 1 a75 1
  • Run recovery on the database environment using the DB_ENV->open method d77 1 a77 1
  • Remove any Berkeley DB environment using the DB_ENV->remove method or an d83 2 a84 2 files needs upgrading but the databases do not, the application may be installed in the field using the following steps: d87 1 a87 1
  • Run recovery on the database environment using the DB_ENV->open method d89 1 a89 1
  • Remove any Berkeley DB environment using the DB_ENV->remove method or an d98 2 a99 2 the databases need upgrading, the application may be installed in the field using the following steps: d102 1 a102 1
  • Run recovery on the database environment using the DB_ENV->open method d104 1 a104 1
  • Remove any Berkeley DB environment using the DB_ENV->remove method or an @ 1.1.1.4 log @Import: RPM 4.1 @ text @d1 2 a2 2 d4 1 d40 3 a42 1 application. d65 1 a65 1
  • Remove any Berkeley DB environment using the DB_ENV->remove function or an d68 2 a69 2
  • If the database format has changed, upgrade the application's databases. See Upgrading databases for more d74 1 a74 1 but neither the log file nor database formats have changed, the d78 1 a78 1
  • Run recovery on the database environment using the DB_ENV->open function d80 1 a80 1
  • Remove any Berkeley DB environment using the DB_ENV->remove function or an d86 2 a87 2 file format has changed, but the database formats have not, the application may be installed in the field using the following steps: d90 1 a90 1
  • Run recovery on the database environment using the DB_ENV->open function d92 1 a92 1
  • Remove any Berkeley DB environment using the DB_ENV->remove function or an d101 2 a102 2 the database format has changed, the application may be installed in the field using the following steps: d105 1 a105 1
  • Run recovery on the database environment using the DB_ENV->open function d107 1 a107 1
  • Remove any Berkeley DB environment using the DB_ENV->remove function or an @ 1.1.1.5 log @Import: RPM 4.1.1 @ text @d1 2 a2 2 a3 1 d39 1 a39 3 application. Further, database and log file formats may have changed but be entirely backward-compatible, in which case no upgrade will be necessary. d62 1 a62 1
  • Remove any Berkeley DB environment using the DB_ENV->remove method or an d65 2 a66 2
  • If necessary, upgrade the application's databases. See Upgrading databases for more d71 1 a71 1 but neither the log file nor database formats need upgrading, the d75 1 a75 1
  • Run recovery on the database environment using the DB_ENV->open method d77 1 a77 1
  • Remove any Berkeley DB environment using the DB_ENV->remove method or an d83 2 a84 2 files needs upgrading but the databases do not, the application may be installed in the field using the following steps: d87 1 a87 1
  • Run recovery on the database environment using the DB_ENV->open method d89 1 a89 1
  • Remove any Berkeley DB environment using the DB_ENV->remove method or an d98 2 a99 2 the databases need upgrading, the application may be installed in the field using the following steps: d102 1 a102 1
  • Run recovery on the database environment using the DB_ENV->open method d104 1 a104 1
  • Remove any Berkeley DB environment using the DB_ENV->remove method or an @