1<!--$Id: db_archive.so,v 10.30 2006/10/05 01:06:08 bostic Exp $-->
2<!--Copyright (c) 1997,2008 Oracle.  All rights reserved.-->
3<!--See the file LICENSE for redistribution information.-->
4<html>
5<head>
6<title>Berkeley DB: db_archive</title>
7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
9</head>
10<body bgcolor=white>
11<table width="100%"><tr valign=top>
12<td>
13<b>db_archive</b>
14</td>
15</tr></table>
16<hr size=1 noshade>
17<tt>
18<b><pre>db_archive [<b>-adlsVv</b>] [<b>-h home</b>] [<b>-P password</b>]</pre></b>
19<b>Description</b>
20<a name="2"><!--meow--></a>
21<p>The db_archive utility writes the pathnames of log files that
22are no longer in use (for example, no longer involved in active
23transactions), to the standard output, one pathname per line.  These
24log files should be written to backup media to provide for recovery in
25the case of catastrophic failure (which also requires a snapshot of the
26database files), but they may then be deleted from the system to reclaim
27disk space.</p>
28<p>The options are as follows:</p>
29<br>
30<b>-a</b><ul compact><li>Write all pathnames as absolute pathnames, instead of relative to the
31database home directories.</ul>
32<b>-d</b><ul compact><li>Remove log files that are no longer needed; no filenames are written.
33Automatic log file removal is likely to make catastrophic recovery
34impossible.</ul>
35<b>-h</b><ul compact><li>Specify a home directory for the database environment; by
36default, the current working directory is used.</ul>
37<b>-l</b><ul compact><li>Write out the pathnames of all the database log files, whether or not
38they are involved in active transactions.</ul>
39<b>-P</b><ul compact><li>Specify an environment password.  Although Berkeley DB utilities overwrite
40password strings as soon as possible, be aware there may be a window of
41vulnerability on systems where unprivileged users can see command-line
42arguments or where utilities are not able to overwrite the memory
43containing the command-line arguments.</ul>
44<b>-s</b><ul compact><li>Write the pathnames of all the database files that need to be archived
45in order to recover the database from catastrophic failure.  If any of
46the database files have not been accessed during the lifetime of the
47current log files, db_archive will not include them in this
48output.
49<p>It is possible that some of the files to which the log refers have since
50been deleted from the system.  In this case, db_archive will
51ignore them.  When <a href="../utility/db_recover.html">db_recover</a> is run, any files to which the
52log refers that are not present during recovery are assumed to have been
53deleted and will not be recovered.</p></ul>
54<b>-V</b><ul compact><li>Write the library version number to the standard output, and exit.</ul>
55<b>-v</b><ul compact><li>Run in verbose mode.</ul>
56<br>
57<p>Log cursor handles (returned by the <a href="../api_c/log_cursor.html">DB_ENV-&gt;log_cursor</a> method) may have open
58file descriptors for log files in the database environment.  Also, the
59Berkeley DB interfaces to the database environment logging subsystem (for
60example, <a href="../api_c/log_put.html">DB_ENV-&gt;log_put</a> and <a href="../api_c/txn_abort.html">DB_TXN-&gt;abort</a>) may allocate log cursors
61and have open file descriptors for log files as well.  On operating
62systems where filesystem related system calls (for example, rename and
63unlink on Windows/NT) can fail if a process has an open file descriptor
64for the affected file, attempting to move or remove the log files listed
65by db_archive may fail.  All Berkeley DB internal use of log cursors
66operates on active log files only and furthermore, is short-lived in
67nature.  So, an application seeing such a failure should be restructured
68to close any open log cursors it may have, and otherwise to retry the
69operation until it succeeds.  (Although the latter is not likely to be
70necessary; it is hard to imagine a reason to move or rename a log file
71in which transactions are being logged or aborted.)</p>
72<p>The db_archive utility uses a Berkeley DB environment (as described for the
73<b>-h</b> option, the environment variable <b>DB_HOME</b>, or
74because the utility was run in a directory containing a Berkeley DB
75environment).  In order to avoid environment corruption when using a
76Berkeley DB environment, db_archive should always be given the chance to
77detach from the environment and exit gracefully.  To cause db_archive
78to release all environment resources and exit cleanly, send it an
79interrupt signal (SIGINT).</p>
80<p>The <a href="../api_c/log_archive.html">DB_ENV-&gt;log_archive</a> method is the underlying method used by the db_archive utility.
81See the db_archive utility source code for an example of using <a href="../api_c/log_archive.html">DB_ENV-&gt;log_archive</a>
82in a IEEE/ANSI Std 1003.1 (POSIX) environment.</p>
83<p>The db_archive utility exits 0 on success, and &gt;0 if an error occurs.</p>
84<br><b>Environment Variables</b>
85<br>
86<b>DB_HOME</b><ul compact><li>If the <b>-h</b> option is not specified and the environment variable
87DB_HOME is set, it is used as the path of the database home, as described
88in <a href="../api_c/env_open.html">DB_ENV-&gt;open</a>.</ul>
89<br>
90</tt>
91<p><font size=1>Copyright (c) 1996,2008 Oracle.  All rights reserved.</font>
92</body>
93</html>
94