AnonymousFox

//usr/share/doc/db4-devel-4.7.25/ref/transapp/filesys.html

<html>
<head>
<title>Berkeley DB Reference Guide: Recovery and filesystem operations</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
</head>
<body bgcolor=white>
<a name="2"></a>
<table width="100%"><tr valign=top>
<td><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></td>
<td align=right><a href="../transapp/hotfail.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/reclimit.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Recovery and filesystem operations
The Berkeley DB API supports creating, removing and renaming files. Creating
files is supported by the <a href="../../api_c/db_open.html">DB-&gt;open</a> method. Removing files is
supported by the <a href="../../api_c/env_dbremove.html">DB_ENV-&gt;dbremove</a> and <a href="../../api_c/db_remove.html">DB-&gt;remove</a> methods.
Renaming files is supported by the <a href="../../api_c/env_dbrename.html">DB_ENV-&gt;dbrename</a> and
<a href="../../api_c/db_rename.html">DB-&gt;rename</a> methods. (There are two methods for removing and renaming
files because one of the methods is transactionally protected and one
is not.)
Berkeley DB does not permit specifying the <a href="../../api_c/db_open.html#DB_TRUNCATE">DB_TRUNCATE</a> flag when
opening a file in a transaction-protected environment. This is an
implicit file deletion, but one that does not always require the same
operating system file permissions as deleting and creating a file do.
If you have changed the name of a file or deleted it outside of the
Berkeley DB library (for example, you explicitly removed a file using your
normal operating system utilities), then it is possible that recovery
will not be able to find a database to which the log refers. In this
case, <a href="../../utility/db_recover.html">db_recover</a> will produce a warning message, saying it was
unable to locate a file it expected to find. This message is only a
warning because the file may have been subsequently deleted as part of
normal database operations before the failure occurred, so is not
necessarily a problem.
Generally, any filesystem operations that are performed outside the
Berkeley DB interface should be performed at the same time as making a
snapshot of the database. To perform filesystem operations correctly,
do the following:
<ol>
<li>Cleanly shut down database operations.
To shut down database operations cleanly, all applications accessing
the database environment must be shut down and a transaction checkpoint
must be taken. If the applications are not implemented so they can be
shut down gracefully (that is, closing all references to the database
environment), recovery must be performed after all applications have
been killed to ensure that the underlying databases are consistent on
disk.
<li>Perform the filesystem operations; for example, remove or rename one or
more files.
<li>Make an archival snapshot of the database.
Although this step is not strictly necessary, it is strongly
recommended. If this step is not performed, recovery from catastrophic
failure will require that recovery first be performed up to the time of
the filesystem operations, the filesystem operations be redone, and then
recovery be performed from the filesystem operations forward.
<li>Restart the database applications.
</ol>
<table width="100%"><tr><td> </td><td align=right><a href="../transapp/hotfail.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/reclimit.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Copyright (c) 1996,2008 Oracle. All rights reserved.
</body>
</html>