зеркало из https://github.com/mozilla/gecko-dev.git
191 строка
9.6 KiB
HTML
191 строка
9.6 KiB
HTML
|
<HTML>
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>db_recover</TITLE>
|
||
|
|
</HEAD>
|
||
|
|
<BODY BGCOLOR=white>
|
||
|
|
<H1>db_recover</H1>
|
||
|
|
<HR SIZE=1 NOSHADE>
|
||
|
|
<PRE>
|
||
|
|
<!-- Manpage converted by man2html 3.0.1 -->
|
||
|
|
<B>db</B>_<B>recover</B> [<B>-cv</B>] [<B>-h</B> <B>home</B>]
|
||
|
|
|
||
|
|
|
||
|
|
</PRE>
|
||
|
|
<H2>DESCRIPTION</H2><PRE>
|
||
|
|
The db_recover utility must be run after an unexpected
|
||
|
|
application, DB, or system failure to restore the database
|
||
|
|
to a consistent state. All committed transactions are
|
||
|
|
guaranteed to appear after db_recover has run, and all
|
||
|
|
uncommitted transactions will be completely undone.
|
||
|
|
|
||
|
|
The options are as follows:
|
||
|
|
|
||
|
|
<B>-c</B> Failure was catastrophic.
|
||
|
|
|
||
|
|
<B>-h</B> Specify a home directory for the database.
|
||
|
|
|
||
|
|
<B>-v</B> Run in verbose mode.
|
||
|
|
|
||
|
|
In the case of catastrophic failure, an archival copy, or
|
||
|
|
``snapshot'' of all database files must be restored along
|
||
|
|
with all of the log files written since the database file
|
||
|
|
snapshot was made. (If disk space is a problem, log files
|
||
|
|
may be referenced by symbolic links). For further
|
||
|
|
information on creating a database snapshot, see ``DB
|
||
|
|
ARCHIVAL PROCEDURES'' in <B><A HREF="db_archive.html">db_archive(1)</A></B>.
|
||
|
|
|
||
|
|
If the failure was not catastrophic, the files present on
|
||
|
|
the system at the time of failure are sufficient to
|
||
|
|
perform recovery.
|
||
|
|
|
||
|
|
If log files are missing, db_recover will identify the
|
||
|
|
missing log file(s) and fail, in which case the missing
|
||
|
|
log files need to be restored and recovery performed
|
||
|
|
again.
|
||
|
|
|
||
|
|
The db_recover utility attaches to DB shared memory
|
||
|
|
regions. In order to avoid region corruption, it should
|
||
|
|
always be given the chance to detach and exit gracefully.
|
||
|
|
To cause db_recover to clean up after itself and exit,
|
||
|
|
send it an interrupt signal (SIGINT).
|
||
|
|
|
||
|
|
The db_recover utility exits 0 on success, and >0 if an
|
||
|
|
error occurs.
|
||
|
|
|
||
|
|
|
||
|
|
</PRE>
|
||
|
|
<H2>FILESYSTEM OPERATIONS</H2><PRE>
|
||
|
|
<B>Filesystem</B> <B>operations,</B> <B>e.g.,</B> <B>moving</B> <B>the</B> <B>database</B>
|
||
|
|
<B>environment</B> <B>to</B> <B>a</B> <B>different</B> <B>machine</B> <B>or</B> <B>file</B> <B>creation,</B>
|
||
|
|
<B>deletion</B> <B>or</B> <B>renaming,</B> <B>cannot</B> <B>be</B> <B>transaction</B> <B>protected.</B>
|
||
|
|
For this reason, db_recover cannot re-create, delete or
|
||
|
|
rename files as part of recovery.
|
||
|
|
|
||
|
|
If db_recover cannot find a database file referenced in
|
||
|
|
the log, it will output a warning message that it was
|
||
|
|
unable to locate a file it expected to find. This message
|
||
|
|
is only a warning, as the file may have subsequently been
|
||
|
|
deleted as part of normal database operations before the
|
||
|
|
failure occurred. <B>Note</B> <B>that</B> <B>committed</B> <B>transactions</B> <B>that</B>
|
||
|
|
<B>involved</B> <B>these</B> <B>missing</B> <B>files</B> <B>are</B> <B>rolled</B> <B>forward,</B> <B>even</B>
|
||
|
|
<B>though</B> <B>the</B> <B>files</B> <B>were</B> <B>not</B> <B>found.</B> <B>If</B> <B>the</B> <B>files</B> <B>were</B> <B>not</B>
|
||
|
|
<B>intentionally</B> <B>deleted</B> <B>(e.g.,</B> <B>they</B> <B>were</B> <B>created</B> <B>after</B> <B>the</B>
|
||
|
|
<B>last</B> <B>database</B> <B>snapshot,</B> <B>but</B> <B>were</B> <B>lost</B> <B>during</B> <B>a</B> <B>failure),</B>
|
||
|
|
<B>they</B> <B>must</B> <B>be</B> <B>manually</B> <B>created</B> <B>(using</B> <B><A HREF="db_open.html">db_open(3)</A></B>), and
|
||
|
|
db_recover must be rerun.
|
||
|
|
|
||
|
|
Generally, it is simplest to perform filesystem operations
|
||
|
|
at the same time as making a snapshot of the database. To
|
||
|
|
perform filesystem operations:
|
||
|
|
|
||
|
|
1. Cleanly shutdown database operations.
|
||
|
|
2. Rename, create or delete files.
|
||
|
|
3. Make a snapshot of the database.
|
||
|
|
4. Restart database applications.
|
||
|
|
|
||
|
|
To cleanly shutdown database operations, all applications
|
||
|
|
accessing the database environment must be shutdown. If
|
||
|
|
the applications are not implemented such that they can be
|
||
|
|
shutdown gracefully (i.e., closing all references to the
|
||
|
|
database environment), db_recover must be run after all
|
||
|
|
applications have been killed to ensure that the
|
||
|
|
underlying database is consistent and flushed to disk.
|
||
|
|
|
||
|
|
|
||
|
|
</PRE>
|
||
|
|
<H2>RECOVERY</H2><PRE>
|
||
|
|
After an application or system failure, there are two
|
||
|
|
possible approaches to database recovery. If there is no
|
||
|
|
need to retain state across the failure, and all databases
|
||
|
|
can be started anew, the database home directory can
|
||
|
|
simply be removed and recreated. If it is necessary to
|
||
|
|
retain persistent state across failures, then the
|
||
|
|
<B><A HREF="db_recover.html">db_recover(1)</A></B> utility should be run for each DB
|
||
|
|
application environment, i.e., each database home
|
||
|
|
directory.
|
||
|
|
|
||
|
|
The db_recover utility will remove all the shared regions
|
||
|
|
(which may have been corrupted by the failure), establish
|
||
|
|
the end of the log by identifying the last record written
|
||
|
|
to the log, and then perform transaction recovery.
|
||
|
|
Database applications must not be restarted until recovery
|
||
|
|
completes. During transaction recovery, all changes made
|
||
|
|
by aborted transactions are undone and all changes made by
|
||
|
|
committed transactions are redone, as necessary. After
|
||
|
|
recovery runs, the environment is properly initialized so
|
||
|
|
that applications may be restarted. Any time an
|
||
|
|
application crashes or the system fails, db_recover should
|
||
|
|
be run on any exiting database environments.
|
||
|
|
|
||
|
|
Additionally, there are two forms of recovery: normal
|
||
|
|
recovery and catastrophic recovery. The DB package
|
||
|
|
defines catastrophic failure to be failure where either
|
||
|
|
the database or log files have been destroyed or corrupted
|
||
|
|
from the point of view of the filesystem. For example,
|
||
|
|
catastrophic failure includes the case where the disk
|
||
|
|
drive on which either the database or logs are stored has
|
||
|
|
crashed, or when filesystem recovery is unable to bring
|
||
|
|
the database and log files to a consistent state with
|
||
|
|
respect to the filesystem. If the failure is non-
|
||
|
|
catastrophic, i.e., the database files and log are
|
||
|
|
accessible on a filesystem that has recovered cleanly,
|
||
|
|
db_recover will review the logs and database files to
|
||
|
|
ensure that all committed transactions appear and that all
|
||
|
|
uncommitted transactions are undone. If the failure is
|
||
|
|
catastrophic, a snapshot of the database files and the
|
||
|
|
archived log files must be restored onto the system. Then
|
||
|
|
db_recover will review the logs and database files to
|
||
|
|
bring the database to a consistent state as of the date of
|
||
|
|
the last archived log file. Only transactions committed
|
||
|
|
before that date will appear in the database. See
|
||
|
|
db_archive (1) for specific information about archiving
|
||
|
|
and recovering databases after catastrophic failure.
|
||
|
|
|
||
|
|
|
||
|
|
</PRE>
|
||
|
|
<H2>ENVIRONMENT VARIABLES</H2><PRE>
|
||
|
|
The following environment variables affect the execution
|
||
|
|
of db_recover:
|
||
|
|
|
||
|
|
DB_HOME
|
||
|
|
If the <B>-h</B> option is not specified and the environment
|
||
|
|
variable DB_HOME is set, it is used as the path of
|
||
|
|
the database home, as described in <B><A HREF="db_appinit.html">db_appinit(3)</A></B>.
|
||
|
|
|
||
|
|
|
||
|
|
</PRE>
|
||
|
|
<H2>BUGS</H2><PRE>
|
||
|
|
Future versions of DB are expected to remove the
|
||
|
|
restriction that database files must be manually created
|
||
|
|
before recovery is performed.
|
||
|
|
|
||
|
|
|
||
|
|
</PRE>
|
||
|
|
<H2>SEE ALSO</H2><PRE>
|
||
|
|
The DB library is a family of groups of functions that
|
||
|
|
provides a modular programming interface to transactions
|
||
|
|
and record-oriented file access. The library includes
|
||
|
|
support for transactions, locking, logging and file page
|
||
|
|
caching, as well as various indexed access methods. Many
|
||
|
|
of the functional groups (e.g., the file page caching
|
||
|
|
functions) are useful independent of the other DB
|
||
|
|
functions, although some functional groups are explicitly
|
||
|
|
based on other functional groups (e.g., transactions and
|
||
|
|
logging). For a general description of the DB package,
|
||
|
|
see <B><A HREF="db_intro.html">db_intro(3)</A></B>.
|
||
|
|
|
||
|
|
<B><A HREF="db_archive.html">db_archive(1)</A></B>, <B><A HREF="db_checkpoint.html">db_checkpoint(1)</A></B>, <B><A HREF="db_deadlock.html">db_deadlock(1)</A></B>, <B><A HREF="db_dump.html">db_dump(1)</A></B>,
|
||
|
|
<B><A HREF="db_load.html">db_load(1)</A></B>, <B><A HREF="db_recover.html">db_recover(1)</A></B>, <B><A HREF="db_stat.html">db_stat(1)</A></B>, <B><A HREF="db_intro.html">db_intro(3)</A></B>,
|
||
|
|
<B><A HREF="db_appinit.html">db_appinit(3)</A></B>, <B><A HREF="db_cursor.html">db_cursor(3)</A></B>, <B><A HREF="db_dbm.html">db_dbm(3)</A></B>, <B><A HREF="db_internal.html">db_internal(3)</A></B>,
|
||
|
|
<B><A HREF="db_lock.html">db_lock(3)</A></B>, <B><A HREF="db_log.html">db_log(3)</A></B>, <B><A HREF="db_mpool.html">db_mpool(3)</A></B>, <B><A HREF="db_open.html">db_open(3)</A></B>, <B><A HREF="db_thread.html">db_thread(3)</A></B>,
|
||
|
|
<B><A HREF="db_txn.html">db_txn(3)</A></B>
|
||
|
|
|
||
|
|
</PRE>
|
||
|
|
<HR SIZE=1 NOSHADE>
|
||
|
|
<ADDRESS>
|
||
|
|
Man(1) output converted with
|
||
|
|
<a href="http://www.oac.uci.edu/indiv/ehood/man2html.html">man2html</a>
|
||
|
|
</ADDRESS>
|
||
|
|
</BODY>
|
||
|
|
</HTML>
|