1DB_ARCHIVE(1)                BerkeleyDB Utilities                DB_ARCHIVE(1)
2
3
4

NAME

6       db_archive - Find unused log files for archival
7

SYNOPSIS

9       db_archive [-adlsVv] [-h home] [-P password]
10

DESCRIPTION

12       The  db_archive  utility  writes the pathnames of log files that are no
13       longer in use (for example, no longer involved in active transactions),
14       to  the standard output, one pathname per line.  These log files should
15       be written to backup media to provide for recovery in the case of cata‐
16       strophic  failure  (which  also  requires  a  snapshot  of the database
17       files), but they may then be deleted from the system  to  reclaim  disk
18       space.
19

OPTIONS

21       -a     Write  all  pathnames as absolute pathnames, instead of relative
22              to the database home directories.
23
24       -d     Remove log files that are no longer  needed;  no  filenames  are
25              written.   Automatic  log  file  removal is likely to make cata‐
26              strophic recovery impossible.
27
28       -h home
29              Specify a  home  directory  for  the  database  environment;  by
30              default, the current working directory is used.
31
32       -l     Write  out  the pathnames of all the database log files, whether
33              or not they are involved in active transactions.
34
35       -P password
36              Specify an environment password.  Although Berkeley DB utilities
37              overwrite  password  strings as soon as possible, be aware there
38              may be a window of vulnerability on systems  where  unprivileged
39              users  can see command-line arguments or where utilities are not
40              able to overwrite the memory containing the  command-line  argu‐
41              ments.
42
43       -s     Write  the  pathnames  of all the database files that need to be
44              archived in order to  recover  the  database  from  catastrophic
45              failure.   If  any  of the database files have not been accessed
46              during the lifetime of the current log  files,  db_archive  will
47              not include them in this output.
48
49              It  is  possible  that some of the files to which the log refers
50              have since been deleted from the system.  In this  case,  db_ar‐
51              chive  will  ignore  them.  When db_recover is run, any files to
52              which the log refers that are not present  during  recovery  are
53              assumed to have been deleted and will not be recovered.
54
55       -V     Write  the  library  version  number to the standard output, and
56              exit.
57
58       -v     Run in verbose mode, listing the checkpoints in the log files as
59              they are reviewed.
60
61       Log cursor handles (returned by the DB_ENV->log_cursor method) may have
62       open file descriptors for log files in the database environment.  Also,
63       the  Berkeley DB interfaces to the database environment logging subsys‐
64       tem (for example, DB_ENV->log_put and DB_TXN->abort) may  allocate  log
65       cursors and have open file descriptors for log files as well.  On oper‐
66       ating systems where  filesystem  related  system  calls  (for  example,
67       rename and unlink on Windows/NT) can fail if a process has an open file
68       descriptor for the affected file, attempting to move or remove the  log
69       files  listed  by db_archive may fail.  All Berkeley DB internal use of
70       log cursors operates on active  log  files  only  and  furthermore,  is
71       short-lived in nature.  So, an application seeing such a failure should
72       be restructured to close any open log cursors it may have,  and  other‐
73       wise to retry the operation until it succeeds.  (Although the latter is
74       not likely to be necessary; it is hard to imagine a reason to  move  or
75       rename a log file in which transactions are being logged or aborted.)
76
77       The db_archive utility uses a Berkeley DB environment (as described for
78       the -h option, the environment variable DB_HOME, or because the utility
79       was run in a directory containing a Berkeley DB environment).  In order
80       to avoid environment corruption when using a Berkeley  DB  environment,
81       db_archive  should  always be given the chance to detach from the envi‐
82       ronment and exit gracefully.  To cause db_archive to release all  envi‐
83       ronment  resources  and exit cleanly, send it an interrupt signal (SIG‐
84       INT).
85
86       The DB_ENV->log_archive method is the underlying  method  used  by  the
87       db_archive  utility.   See  the  db_archive  utility source code for an
88       example of using DB_ENV->log_archive in a IEEE/ANSI Std 1003.1  (POSIX)
89       environment.
90

EXIT STATUS

92       The db_archive utility exits 0 on success, and >0 if an error occurs.
93

ENVIRONMENT

95       DB_HOME
96              If  the  -h option is not specified and the environment variable
97              DB_HOME is set, it is used as the path of the database home,  as
98              described in DB_ENV->open.
99

NOTES

101       If  the  application(s) that use the environment make use of any of the
102       following methods:
103
104       DB_ENV->add_data_dir
105
106       DB_ENV->set_data_dir
107
108       DB_ENV->set_lg_dir
109
110       then in order for this utility to run correctly, you need  a  DB_CONFIG
111       file  which sets the proper paths using the add_data_dir, or set_lg_dir
112       configuration parameters.
113

SEE ALSO

115       db_checkpoint(1) db_deadlock(1) db_dump(1) db_hotbackup(1)  db_log_ver‐
116       ify(1)    db_load(1)   db_printlog(1)   db_recover(1)   db_replicate(1)
117       db_stat(1) db_tuner(1) db_upgrade(1) db_verify(1)
118
119
120
121BerkeleyDB 5.3.28              06 December 2016                  DB_ARCHIVE(1)
Impressum