Gecko [ 122.154.134.11 ]

Name	Size	Permission
admin.html	3.28 KB	-rw-r--r--
app.html	16.29 KB	-rw-r--r--
archival.html	9.52 KB	-rw-r--r--
atomicity.html	4.19 KB	-rw-r--r--
checkpoint.html	4.7 KB	-rw-r--r--
cursor.html	4.99 KB	-rw-r--r--
data_open.html	5.89 KB	-rw-r--r--
deadlock.html	5.78 KB	-rw-r--r--
env_open.html	6.53 KB	-rw-r--r--
fail.html	4.98 KB	-rw-r--r--
faq.html	7.8 KB	-rw-r--r--
filesys.html	4.22 KB	-rw-r--r--
hotfail.html	5.51 KB	-rw-r--r--
inc.html	6.1 KB	-rw-r--r--
intro.html	2.72 KB	-rw-r--r--
logfile.html	3.57 KB	-rw-r--r--
nested.html	4.19 KB	-rw-r--r--
put.html	10.51 KB	-rw-r--r--
read.html	7.93 KB	-rw-r--r--
reclimit.html	9.7 KB	-rw-r--r--
recovery.html	6.42 KB	-rw-r--r--
term.html	4.09 KB	-rw-r--r--
throughput.html	7.14 KB	-rw-r--r--
transapp.cs	10.34 KB	-rw-r--r--
tune.html	10.76 KB	-rw-r--r--
why.html	2.49 KB	-rw-r--r--
writetest.cs	2.32 KB	-rw-r--r--

Code Editor : recovery.html

<html>
<head>
<title>Berkeley DB Reference Guide: Recovery procedures</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/logfile.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/hotfail.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Recovery procedures
The fifth component of the infrastructure, recovery procedures, concerns
the recoverability of the database. After any application or system
failure, there are two possible approaches to database recovery:
<ol>
<li>There is no need for recoverability, and all databases can be re-created
from scratch. Although these applications may still need transaction
protection for other reasons, recovery usually consists of removing the
Berkeley DB environment home directory and all files it contains, and then
restarting the application.
Such an application may use the <a href="../../api_c/db_set_flags.html#DB_TXN_NOT_DURABLE">DB_TXN_NOT_DURABLE</a> flag to avoid
writing log records.
<li>It is necessary to recover information after system or application
failure. In this case, recovery processing must be performed on any
database environments that were active at the time of the failure.
Recovery processing involves running the <a href="../../utility/db_recover.html">db_recover</a> utility or
calling the <a href="../../api_c/env_open.html">DB_ENV-&gt;open</a> method with the <a href="../../api_c/env_open.html#DB_RECOVER">DB_RECOVER</a> or
<a href="../../api_c/env_open.html#DB_RECOVER_FATAL">DB_RECOVER_FATAL</a> flags.
During recovery processing, all database changes made by aborted or
unfinished transactions are undone, and all database changes made by
committed transactions are redone, as necessary. Database applications
must not be restarted until recovery completes. After recovery
finishes, the environment is properly initialized so that applications
may be restarted.
</ol>
If performing recovery, there are two types of recovery processing:
normal and catastrophic. Which you choose depends
on the source for the database and log files you are using to recover.
If up-to-the-minute database and log files are accessible on a stable
filesystem, normal recovery is sufficient. Run the <a href="../../utility/db_recover.html">db_recover</a>
utility or call the <a href="../../api_c/env_open.html">DB_ENV-&gt;open</a> method specifying the
<a href="../../api_c/env_open.html#DB_RECOVER">DB_RECOVER</a> flag. However, the normal recovery case
never includes recovery using hot backups of the database
environment. For example, you cannot perform a hot backup of databases
and log files, restore the backup and then run normal recovery -- you
must always run catastrophic recovery when using hot backups.
If the database or log files have been destroyed or corrupted, or normal
recovery fails, catastrophic recovery is required. For example,
catastrophic failure includes the case where the disk drive on which
the database or log files are stored has been physically destroyed, or
when the underlying filesystem is corrupted and the operating system's
normal filesystem checking procedures cannot bring that filesystem to
a consistent state. This is often difficult to detect, and a common
sign of the need for catastrophic recovery is when normal Berkeley DB recovery
procedures fail, or when checksum errors are displayed during normal
database procedures. When catastrophic recovery is necessary, take the
following steps:
<ol>
<li>Restore the most recent snapshots of the database and log files from
the backup media into the directory where recovery will be performed.
<li>If any log files were archived since the last snapshot was made, they
should be restored into the directory where recovery will be performed.
If any log files are available from the database environment that failed
(for example, the disk holding the database files crashed, but the disk
holding the log files is fine), those log files should be copied into
the directory where recovery will be performed.
Be sure to restore all log files in the order they were written. The
order is important because it's possible the same log file appears on
multiple backups, and you want to run recovery using the most recent
version of each log file.
<li>Run the <a href="../../utility/db_recover.html">db_recover</a> utility, specifying its -c option;
or call the <a href="../../api_c/env_open.html">DB_ENV-&gt;open</a> method, specifying the <a href="../../api_c/env_open.html#DB_RECOVER_FATAL">DB_RECOVER_FATAL</a>
flag. The catastrophic recovery process will review the logs and
database files to bring the environment databases to a consistent state
as of the time of the last uncorrupted log file that is found. It is
important to realize that only transactions committed before that date
will appear in the databases.
It is possible to re-create the database in a location different from
the original by specifying appropriate pathnames to the -h
option of the <a href="../../utility/db_recover.html">db_recover</a> utility. In order for this to work
properly, it is important that your application refer to files by names
relative to the database home directory or the pathname(s) specified in
calls to <a href="../../api_c/env_set_data_dir.html">DB_ENV-&gt;set_data_dir</a>, instead of using full
pathnames.
</ol>
<table width="100%"><tr><td> </td><td align=right><a href="../transapp/logfile.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../transapp/hotfail.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Copyright (c) 1996,2008 Oracle. All rights reserved.
</body>
</html>

${this.title}

Code Editor : recovery.html