Penguin
Recent Changes
Blame: db_recover(1)
EditPageHistoryDiffInfoLikePages
Annotated edit history of db_recover(1) version 1, including all changes. View license author blame.
Rev Author # Line
1 perry 1 DB_RECOVER
2 !!!DB_RECOVER
3 NAME
4 SYNOPSIS
5 DESCRIPTION
6 FILESYSTEM OPERATIONS
7 RECOVERY
8 ENVIRONMENT VARIABLES
9 BUGS
10 SEE ALSO
11 ----
12 !!NAME
13
14
15 db_recover - the DB database recovery utility
16 !!SYNOPSIS
17
18
19 __db_recover__ [[__-cv__] [[__-h home__]
20 !!DESCRIPTION
21
22
23 The ''db_recover'' utility must be run after an
24 unexpected application, DB, or system failure to restore the
25 database to a consistent state. All committed transactions
26 are guaranteed to appear after ''db_recover'' has run,
27 and all uncommitted transactions will be completely
28 undone.
29
30
31 The options are as follows:
32
33
34 __-c__
35
36
37 Failure was catastrophic.
38
39
40 __-h__
41
42
43 Specify a home directory for the database.
44
45
46 __-v__
47
48
49 Run in verbose mode.
50
51
52 In the case of catastrophic failure, an archival copy, or
53 ``snapshot'' of all database files must be restored along
54 with all of the log files written since the database file
55 snapshot was made. (If disk space is a problem, log files
56 may be referenced by symbolic links). For further
57 information on creating a database snapshot, see ``DB
58 ARCHIVAL PROCEDURES'' in ''db_archive''(1).
59
60
61 If the failure was not catastrophic, the files present on
62 the system at the time of failure are sufficient to perform
63 recovery.
64
65
66 If log files are missing, ''db_recover'' will identify
67 the missing log file(s) and fail, in which case the missing
68 log files need to be restored and recovery performed
69 again.
70
71
72 The ''db_recover'' utility attaches to DB shared memory
73 regions. In order to avoid region corruption, it should
74 always be given the chance to detach and exit gracefully. To
75 cause ''db_recover'' to clean up after itself and exit,
76 send it an interrupt signal (SIGINT).
77
78
79 The ''db_recover'' utility exits 0 on success, and
80 ''
81 !!FILESYSTEM OPERATIONS
82
83
84 __Filesystem operations, e.g., moving the database
85 environment to a different machine or file creation,
86 deletion or renaming, cannot be transaction protected.__
87 For this reason, ''db_recover'' cannot re-create, delete
88 or rename files as part of recovery.
89
90
91 If ''db_recover'' cannot find a database file referenced
92 in the log, it will output a warning message that it was
93 unable to locate a file it expected to find. This message is
94 only a warning, as the file may have subsequently been
95 deleted as part of normal database operations before the
96 failure occurred. __Note that committed transactions that
97 involved these missing files are rolled forward, even though
98 the files were not found. If the files were not
99 intentionally deleted (e.g., they were created after the
100 last database snapshot, but were lost during a failure),
101 they must be manually created (using__ ''db_open(3)),''
102 and ''db_recover'' must be rerun.
103
104
105 Generally, it is simplest to perform filesystem operations
106 at the same time as making a snapshot of the database. To
107 perform filesystem operations:
108
109
110 1.
111
112
113 Cleanly shutdown database operations.
114
115
116 2.
117
118
119 Rename, create or delete files.
120
121
122 3.
123
124
125 Make a snapshot of the database.
126
127
128 4.
129
130
131 Restart database applications.
132
133
134 To cleanly shutdown database operations, all applications
135 accessing the database environment must be shutdown. If the
136 applications are not implemented such that they can be
137 shutdown gracefully (i.e., closing all references to the
138 database environment), ''db_recover'' must be run after
139 all applications have been killed to ensure that the
140 underlying database is consistent and flushed to
141 disk.
142 !!RECOVERY
143
144
145 After an application or system failure, there are two
146 possible approaches to database recovery. If there is no
147 need to retain state across the failure, and all databases
148 can be started anew, the database home directory can simply
149 be removed and recreated. If it is necessary to retain
150 persistent state across failures, then the
151 ''db_recover''(1) utility should be run for each DB
152 application environment, i.e., each database home
153 directory.
154
155
156 The ''db_recover'' utility will remove all the shared
157 regions (which may have been corrupted by the failure),
158 establish the end of the log by identifying the last record
159 written to the log, and then perform transaction recovery.
160 Database applications must not be restarted until recovery
161 completes. During transaction recovery, all changes made by
162 aborted transactions are undone and all changes made by
163 committed transactions are redone, as necessary. After
164 recovery runs, the environment is properly initialized so
165 that applications may be restarted. Any time an application
166 crashes or the system fails, ''db_recover'' should be run
167 on any exiting database environments.
168
169
170 Additionally, there are two forms of recovery: normal
171 recovery and catastrophic recovery. The DB package defines
172 catastrophic failure to be failure where either the database
173 or log files have been destroyed or corrupted from the point
174 of view of the filesystem. For example, catastrophic failure
175 includes the case where the disk drive on which either the
176 database or logs are stored has crashed, or when filesystem
177 recovery is unable to bring the database and log files to a
178 consistent state with respect to the filesystem. If the
179 failure is non-catastrophic, i.e., the database files and
180 log are accessible on a filesystem that has recovered
181 cleanly, ''db_recover'' will review the logs and database
182 files to ensure that all committed transactions appear and
183 that all uncommitted transactions are undone. If the failure
184 is catastrophic, a snapshot of the database files and the
185 archived log files must be restored onto the system. Then
186 ''db_recover'' will review the logs and database files to
187 bring the database to a consistent state as of the date of
188 the last archived log file. Only transactions committed
189 before that date will appear in the database. See
190 ''db_archive (1)'' for specific information about
191 archiving and recovering databases after catastrophic
192 failure.
193 !!ENVIRONMENT VARIABLES
194
195
196 The following environment variables affect the execution of
197 ''db_recover'':
198
199
200 DB_HOME
201
202
203 If the __-h__ option is not specified and the environment
204 variable ''DB_HOME'' is set, it is used as the path of
205 the database home, as described in
206 ''db_appinit''(3).
207 !!BUGS
208
209
210 Future versions of DB are expected to remove the restriction
211 that database files must be manually created before recovery
212 is performed.
213 !!SEE ALSO
214
215
216 The DB library is a family of groups of functions that
217 provides a modular programming interface to transactions and
218 record-oriented file access. The library includes support
219 for transactions, locking, logging and file page caching, as
220 well as various indexed access methods. Many of the
221 functional groups (e.g., the file page caching functions)
222 are useful independent of the other DB functions, although
223 some functional groups are explicitly based on other
224 functional groups (e.g., transactions and
225 logging).
226
227
228 ''db_archive''(1), ''db_checkpoint''(1),
229 ''db_deadlock''(1), ''db_dump''(1), ''db_load''(1),
230 ''db_recover''(1), ''db_stat''(1),
231 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.