← Back to branch summary

~ubuntu-branches/ubuntu/natty/evolution-data-server/natty

« back to all changes in this revision

Viewing changes to libdb/docs/ref/upgrade/process.html

  • Committer: Bazaar Package Importer
  • Author(s): Didier Roche
  • Date: 2010-05-17 17:02:06 UTC
  • mfrom: (1.1.79 upstream) (1.6.12 experimental)
  • Revision ID: james.westby@ubuntu.com-20100517170206-4ufr52vwrhh26yh0
Tags: 2.30.1-1ubuntu1
https://launchpad.net/bugs/42199
https://launchpad.net/bugs/229669
https://launchpad.net/bugs/173703
https://launchpad.net/bugs/360344
https://launchpad.net/bugs/508494
* Merge from debian experimental. Remaining change:
  (LP: #42199, #229669, #173703, #360344, #508494)
  + debian/control:
    - add Vcs-Bzr tag
    - don't use libgnome
    - Use Breaks instead of Conflicts against evolution 2.25 and earlier.
  + debian/evolution-data-server.install,
    debian/patches/45_libcamel_providers_version.patch:
    - use the upstream versioning, not a Debian-specific one 
  + debian/libedata-book1.2-dev.install, debian/libebackend-1.2-dev.install,
    debian/libcamel1.2-dev.install, debian/libedataserverui1.2-dev.install:
    - install html documentation
  + debian/rules:
    - don't build documentation it's shipped with the tarball

Show diffs side-by-side

added added

removed removed

Lines of Context:
libdb/docs/ref/upgrade/process.html
1
 
<!--$Id$-->
2
 
<!--Copyright 1997-2002 by Sleepycat Software, Inc.-->
3
 
<!--All rights reserved.-->
4
 
<!--See the file LICENSE for redistribution information.-->
5
 
<html>
6
 
<head>
7
 
<title>Berkeley DB Reference Guide: Upgrading Berkeley DB installations</title>
8
 
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
9
 
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
10
 
</head>
11
 
<body bgcolor=white>
12
 
<table width="100%"><tr valign=top>
13
 
<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Upgrading Berkeley DB Applications</dl></h3></td>
14
 
<td align=right><a href="../../ref/upgrade/version.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/upgrade.2.0/intro.html"><img src="../../images/next.gif" alt="Next"></a>
15
 
</td></tr></table>
16
 
<p>
17
 
<h1 align=center>Upgrading Berkeley DB installations</h1>
18
 
<p>The following information describes the general process of upgrading
19
 
Berkeley DB installations.  There are four areas to be considered when
20
 
upgrading Berkeley DB applications and database environments: the application
21
 
API, the database environment's region files, the underlying database
22
 
formats, and, in the case of transactional database environments, the
23
 
log files.  The upgrade procedures required depend on whether or not
24
 
the release is a major or minor release (in which either the major or
25
 
minor number of the version changed), or a patch release (in which only
26
 
the patch number in the version changed).  Berkeley DB major and minor
27
 
releases may optionally include changes in all four areas, that is, the
28
 
application API, region files, database formats, and log files may not
29
 
be backward-compatible with previous releases.
30
 
<p>Each Berkeley DB major or minor release has information in this chapter of
31
 
the Reference Guide, describing how to upgrade to the new release.  The
32
 
section describes any API changes made in the release.  Application
33
 
maintainers should review the API changes and update their applications
34
 
as necessary before recompiling with the new release.  In addition, each
35
 
section includes a page specifying whether the log file format or
36
 
database formats changed in non-backward-compatible ways as part of the
37
 
release.  Because there are several underlying Berkeley DB database formats,
38
 
and they do not all necessarily change in the same release, changes to
39
 
a database format in a release may not affect any particular
40
 
application.  Further, database and log file formats may have changed
41
 
but be entirely backward-compatible, in which case no upgrade will be
42
 
necessary.
43
 
<p>A Berkeley DB patch release will never modify the API, regions, log files, or
44
 
database formats in incompatible ways, and so applications need only be
45
 
relinked (or, in the case of a shared library, pointed at the new
46
 
version of the shared library) to upgrade to a new release.  Note that
47
 
internal Berkeley DB interfaces may change at any time and in any release
48
 
(including patch releases) without warning.  This means the library must
49
 
be entirely recompiled and reinstalled when upgrading to new releases
50
 
of the library because there is no guarantee that modules from one
51
 
version of the library will interact correctly with modules from another
52
 
release.
53
 
<p>If the release is a patch release, do the following:
54
 
<p><ol>
55
 
<p><li>Shut down the old version of the application.
56
 
<li>Install the new version of the application by relinking or installing
57
 
a new version of the Berkeley DB shared library.
58
 
<li>Restart the application.
59
 
</ol>
60
 
<p>Otherwise, if the application <b>does not</b> have a Berkeley DB
61
 
transactional environment, the application may be installed in the field
62
 
using the following steps:
63
 
<p><ol>
64
 
<p><li>Shut down the old version of the application.
65
 
<li>Remove any Berkeley DB environment using the <a href="../../api_c/env_remove.html">DB_ENV-&gt;remove</a> method or an
66
 
appropriate system utility.
67
 
<li>Recompile and install the new version of the application.
68
 
<li>If necessary, upgrade the application's databases.  See
69
 
<a href="../../ref/am/upgrade.html">Upgrading databases</a> for more
70
 
information.
71
 
<li>Restart the application.
72
 
</ol>
73
 
<p>Otherwise, if the application has a Berkeley DB transactional environment,
74
 
but neither the log file nor database formats need upgrading, the
75
 
application may be installed in the field using the following steps:
76
 
<p><ol>
77
 
<p><li>Shut down the old version of the application.
78
 
<li>Run recovery on the database environment using the <a href="../../api_c/env_open.html">DB_ENV-&gt;open</a> method
79
 
or the <a href="../../utility/db_recover.html">db_recover</a> utility.
80
 
<li>Remove any Berkeley DB environment using the <a href="../../api_c/env_remove.html">DB_ENV-&gt;remove</a> method or an
81
 
appropriate system utility.
82
 
<li>Recompile and install the new version of the application.
83
 
<li>Restart the application.
84
 
</ol>
85
 
<p>If the application has a Berkeley DB transactional environment, and the log
86
 
files needs upgrading but the databases do not, the application may be
87
 
installed in the field using the following steps:
88
 
<p><ol>
89
 
<p><li>Shut down the old version of the application.
90
 
<li>Run recovery on the database environment using the <a href="../../api_c/env_open.html">DB_ENV-&gt;open</a> method
91
 
or the <a href="../../utility/db_recover.html">db_recover</a> utility.
92
 
<li>Remove any Berkeley DB environment using the <a href="../../api_c/env_remove.html">DB_ENV-&gt;remove</a> method or an
93
 
appropriate system utility.
94
 
<li>Archive the database environment for catastrophic recovery.  See
95
 
<a href="../../ref/transapp/archival.html">Archival procedures</a> for more
96
 
information.
97
 
<li>Recompile and install the new version of the application.
98
 
<li>Restart the application.
99
 
</ol>
100
 
<p>Otherwise, if the application has a Berkeley DB transactional environment and
101
 
the databases need upgrading, the application may be installed in the
102
 
field using the following steps:
103
 
<p><ol>
104
 
<p><li>Shut down the old version of the application.
105
 
<li>Run recovery on the database environment using the <a href="../../api_c/env_open.html">DB_ENV-&gt;open</a> method
106
 
or the <a href="../../utility/db_recover.html">db_recover</a> utility.
107
 
<li>Remove any Berkeley DB environment using the <a href="../../api_c/env_remove.html">DB_ENV-&gt;remove</a> method or an
108
 
appropriate system utility.
109
 
<li>Archive the database environment for catastrophic recovery.  See
110
 
<a href="../../ref/transapp/archival.html">Archival procedures</a> for more
111
 
information.
112
 
<li>Recompile and install the new version of the application.
113
 
<li>Upgrade the application's databases.  See
114
 
<a href="../../ref/am/upgrade.html">Upgrading databases</a> for more
115
 
information.
116
 
<li>Archive the database for catastrophic recovery again (using different
117
 
media than before, of course).  Note: This archival is not strictly
118
 
necessary.  However, if you have to perform catastrophic recovery after
119
 
restarting the application, that recovery must be done based on the
120
 
last archive you have made.  If you make this second archive, you can
121
 
use it as the basis of that catastrophic recovery.  If you do not make
122
 
this second archive, you have to use the archive you made in step 4 as
123
 
the basis of your recovery, and you have to do a full upgrade on it
124
 
before you can apply log files created after the upgrade to it.
125
 
<li>Restart the application.
126
 
</ol>
127
 
<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/upgrade/version.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/upgrade.2.0/intro.html"><img src="../../images/next.gif" alt="Next"></a>
128
 
</td></tr></table>
129
 
<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
130
 
</body>
131
 
</html>