Penguin
Recent Changes
Blame: db_archive(1)
EditPageHistoryDiffInfoLikePages
Annotated edit history of db_archive(1) version 1, including all changes. View license author blame.
Rev Author # Line
1 perry 1 DB_ARCHIVE
2 !!!DB_ARCHIVE
3 NAME
4 SYNOPSIS
5 DESCRIPTION
6 DB ARCHIVAL PROCEDURES
7 ENVIRONMENT VARIABLES
8 SEE ALSO
9 ----
10 !!NAME
11
12
13 db_archive - the DB database archiver
14 !!SYNOPSIS
15
16
17 __db_archive__ [[__-alsv__] [[__-h
18 home__]
19 !!DESCRIPTION
20
21
22 The ''db_archive'' utility writes the pathnames of log
23 files that are no longer in use (e.g., no longer involved in
24 active transactions), to the standard output, one pathname
25 per line. These log files should be written to backup media
26 to provide for recovery in the case of catastrophic failure
27 (which also requires a snapshot of the database files), but
28 they may then be deleted from the system to reclaim disk
29 space.
30
31
32 The options are as follows:
33
34
35 __-a__
36
37
38 Write all pathnames as absolute pathnames, instead of
39 relative to the database home directories.
40
41
42 __-h__
43
44
45 Specify a home directory for the database.
46
47
48 __-l__
49
50
51 Write out the pathnames of all of the database log files,
52 whether or not they are involved in active
53 transactions.
54
55
56 __-s__
57
58
59 Write the pathnames of all of the database files that need
60 to be archived in order to recover the database from
61 catastrophic failure. If any of the database files have not
62 been accessed during the lifetime of the current log files,
63 ''db_archive'' will not include them in this
64 output.
65
66
67 It is possible that some of the files referenced in the log
68 have since been deleted from the system. In this case,
69 ''db_archive'' will ignore them. When
70 ''db_recover''(1) is run, any files referenced in the log
71 that are not present during recovery are assumed to have
72 been deleted and will not be recovered.
73
74
75 __-v__
76
77
78 Run in verbose mode, listing the checkpoints in the log
79 files as they are reviewed.
80
81
82 The ''db_archive'' utility attaches to DB shared memory
83 regions. In order to avoid region corruption, it should
84 always be given the chance to detach and exit gracefully. To
85 cause ''db_archive'' to clean up after itself and exit,
86 send it an interrupt signal (SIGINT).
87
88
89 The ''db_archive'' utility exits 0 on success, and
90 ''
91 !!DB ARCHIVAL PROCEDURES
92
93
94 There are two aspects to managing the recoverability and
95 disk consumption of your DB databases. First, you may want
96 to periodically create snapshots of your databases to make
97 it possible to recover them from catastrophic failure.
98 Second, you'll want to periodically remove log files in
99 order to conserve on disk space. The two procedures are
100 distinct from each other, and you cannot remove the current
101 log files simply because you have created a database
102 snapshot.
103
104
105 To create a snapshot of your database that can be used to
106 recover from catastrophic failure, the following steps
107 should be taken:
108
109
110 1.
111
112
113 Run ''db_archive'' -s to identify all of the database
114 data files that must be saved, and copy them to a backup
115 device, (e.g., tape). If the database files are stored in a
116 separate directory from the other database files, it may be
117 simpler to archive the directory itself instead of the
118 individual files.
119
120
121 __More importantly, if any of the database files have not
122 been accessed during the lifetime of the current log files,
123 db_archive will not list them in its output!__ For this
124 reason, it may be important to use a separate database file
125 directory, archiving it instead of the files listed by
126 ''db_archive''.
127
128
129 2.
130
131
132 If your database is currently active, i.e., you are reading
133 and writing to the database files while the snapshot is
134 being taken, run ''db_archive'' -l to identify the
135 database log files, and copy them to a backup device, (e.g.,
136 tape). If the database log files are stored in a separate
137 directory from the other database files, it may be simpler
138 to archive the directory itself instead of the individual
139 files.
140
141
142 Note that the order of these operations is important, and
143 that the database files __must__ be archived before the
144 log files.
145
146
147 The DB library supports on-line backups, and it is not
148 necessary to stop reading or writing your databases during
149 the time when you create this snapshot. Note however, that
150 the snapshot of an active database will be consistent as of
151 some unspecified time between the start of the archival and
152 when archival is completed. To create a snapshot as of a
153 specific time, you must stop reading and writing your
154 databases for the entire time of the archival, force a
155 checkpoint (see ''db_checkpoint''(1)), and then archive
156 the files listed by the ''db_archive'' command's
157 __-s__ and __-l__ options.
158
159
160 Once these steps are completed, your database can be
161 recovered from catastrophic failure to its state as of the
162 time the archival was done. To update your snapshot so that
163 recovery from catastrophic failure is possible up to a new
164 point in time, repeat step #2, copying all existing log
165 files to a backup device.
166
167
168 Each time that a complete snapshot is made, i.e. all
169 database and log files are copied to backup media, you may
170 discard all previous snapshots and saved log
171 files.
172
173
174 The time to restore from catastrophic failure is a function
175 of the number of log records that have been written since
176 the snapshot was originally created. Perhaps more
177 importantly, the more separate pieces of backup media you
178 use, the more likely that you will have a problem reading
179 from one of them. For these reasons, it is often best to
180 make snapshots on a regular basis.
181
182
183 __For archival safety remember to ensure that you have
184 multiple copies of your database backups, that you verify
185 that your archival media is error-free, and that copies of
186 your backups are stored off-site!__
187
188
189 To restore your database after catastrophic failure, the
190 following steps should be taken:
191
192
193 1.
194
195
196 Restore the copies of the database files from the backup
197 media.
198
199
200 2.
201
202
203 Restore the copies of the log files from the backup media,
204 __in the order in which they were written__. (It's
205 possible that the same log file appears on multiple backups,
206 and you only want the most recent version of that log
207 file!)
208
209
210 3.
211
212
213 Run ''db_recover'' -c to recover the
214 database.
215
216
217 It is possible to recreate the database in a location
218 different than the original, by specifying appropriate
219 pathnames to the -h option of the ''db_recover''
220 utility.
221
222
223 To remove log files, the following steps should be
224 taken:
225
226
227 1.
228
229
230 If you are concerned with catastrophic failure, first copy
231 them to backup media (e.g., tape), as described above. This
232 is because log files are necessary for recovery from
233 catastrophic failure.
234
235
236 2.
237
238
239 Run ''db_archive'', without options, to identify all of
240 the log files that are no longer in use (e.g., involved in
241 an active transaction).
242
243
244 3.
245
246
247 Remove those log files from the system.
248 !!ENVIRONMENT VARIABLES
249
250
251 The following environment variables affect the execution of
252 ''db_archive'':
253
254
255 DB_HOME
256
257
258 If the __-h__ option is not specified and the environment
259 variable ''DB_HOME'' is set, it is used as the path of
260 the database home, as described in
261 ''db_appinit''(3).
262 !!SEE ALSO
263
264
265 The DB library is a family of groups of functions that
266 provides a modular programming interface to transactions and
267 record-oriented file access. The library includes support
268 for transactions, locking, logging and file page caching, as
269 well as various indexed access methods. Many of the
270 functional groups (e.g., the file page caching functions)
271 are useful independent of the other DB functions, although
272 some functional groups are explicitly based on other
273 functional groups (e.g., transactions and
274 logging).
275
276
277 ''db_archive''(1), ''db_checkpoint''(1),
278 ''db_deadlock''(1), ''db_dump''(1), ''db_load''(1),
279 ''db_recover''(1), ''db_stat''(1),
280 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.