File: transapp_recovery.html

package info (click to toggle)
db5.3 5.3.28%2Bdfsg1-0.5
  • links: PTS, VCS
  • area: main
  • in suites: buster
  • size: 158,360 kB
  • sloc: ansic: 448,411; java: 111,824; tcl: 80,544; sh: 44,326; cs: 33,697; cpp: 21,604; perl: 14,557; xml: 10,799; makefile: 4,077; yacc: 1,003; awk: 965; sql: 801; erlang: 342; python: 216; php: 24; asm: 14
file content (166 lines) | stat: -rw-r--r-- 8,954 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Recovery procedures</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="transapp.html" title="Chapter 11.  Berkeley DB Transactional Data Store Applications" />
    <link rel="prev" href="transapp_logfile.html" title="Log file removal" />
    <link rel="next" href="transapp_hotfail.html" title="Hot failover" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 11.2.5.3</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Recovery procedures</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="transapp_logfile.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 11. 
		Berkeley DB Transactional Data Store Applications
        </th>
          <td width="20%" align="right"> <a accesskey="n" href="transapp_hotfail.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="transapp_recovery"></a>Recovery procedures</h2>
          </div>
        </div>
      </div>
      <p>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:</p>
      <div class="orderedlist">
        <ol type="1">
          <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_reference/C/dbset_flags.html#dbset_flags_DB_TXN_NOT_DURABLE" class="olink">DB_TXN_NOT_DURABLE</a> flag to avoid
writing log records.</li>
          <li>
            <p>
        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="../api_reference/C/db_recover.html" class="olink">db_recover</a> utility or
        calling the <a href="../api_reference/C/envopen.html" class="olink">DB_ENV-&gt;open()</a> method with the <a href="../api_reference/C/envopen.html#envopen_DB_RECOVER" class="olink">DB_RECOVER</a> or
        <a href="../api_reference/C/envopen.html#envopen_DB_RECOVER_FATAL" class="olink">DB_RECOVER_FATAL</a> flags.
    </p>
            <p>
        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.
    </p>
          </li>
        </ol>
      </div>
      <p>If performing recovery, there are two types of recovery processing:
<span class="emphasis"><em>normal</em></span> and <span class="emphasis"><em>catastrophic</em></span>.  
Which you choose depends on the source for the database and log files you are 
using to recover.</p>
      <p>
    If up-to-the-minute database and log files are accessible on a stable
    filesystem, normal recovery is sufficient.  Run the <a href="../api_reference/C/db_recover.html" class="olink">db_recover</a> utility or
    call the <a href="../api_reference/C/envopen.html" class="olink">DB_ENV-&gt;open()</a> method specifying the <a href="../api_reference/C/envopen.html#envopen_DB_RECOVER" class="olink">DB_RECOVER</a> flag.  However, the
    normal recovery case <span class="bold"><strong>never</strong></span> 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.
</p>
      <p>
    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:
</p>
      <div class="orderedlist">
        <ol type="1">
          <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>
          <li>
            <p>
        If any log files were archived since the last snapshot was made,
        they should be restored into the directory where recovery will be
        performed.
    </p>
            <p>
        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.
    </p>
            <p>
        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.
    </p>
          </li>
          <li>
            <p>
        Run the <a href="../api_reference/C/db_recover.html" class="olink">db_recover</a> utility, specifying its <span class="bold"><strong>-c</strong></span> option; or call the <a href="../api_reference/C/envopen.html" class="olink">DB_ENV-&gt;open()</a> method,
        specifying the <a href="../api_reference/C/envopen.html#envopen_DB_RECOVER_FATAL" class="olink">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.
    </p>
            <p>
        It is possible to re-create the database in a location different
        from the original by specifying appropriate pathnames to the
        <span class="bold"><strong>-h</strong></span> option of the <a href="../api_reference/C/db_recover.html" class="olink">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_reference/C/envset_data_dir.html" class="olink">DB_ENV-&gt;set_data_dir()</a>, instead of using full pathnames.
    </p>
          </li>
        </ol>
      </div>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="transapp_logfile.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="transapp.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="transapp_hotfail.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Log file removal </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Hot failover</td>
        </tr>
      </table>
    </div>
  </body>
</html>