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.
59
60       Log cursor handles (returned by the DB_ENV->log_cursor method) may have
61       open file descriptors for log files in the database environment.  Also,
62       the Berkeley DB interfaces to the database environment logging  subsys‐
63       tem  (for  example, DB_ENV->log_put and DB_TXN->abort) may allocate log
64       cursors and have open file descriptors for log files as well.  On oper‐
65       ating  systems  where  filesystem  related  system  calls (for example,
66       rename and unlink on Windows/NT) can fail if a process has an open file
67       descriptor  for the affected file, attempting to move or remove the log
68       files listed by db_archive may fail.  All Berkeley DB internal  use  of
69       log  cursors  operates  on  active  log  files only and furthermore, is
70       short-lived in nature.  So, an application seeing such a failure should
71       be  restructured  to close any open log cursors it may have, and other‐
72       wise to retry the operation until it succeeds.  (Although the latter is
73       not  likely  to be necessary; it is hard to imagine a reason to move or
74       rename a log file in which transactions are being logged or aborted.)
75
76       The db_archive utility uses a Berkeley DB environment (as described for
77       the -h option, the environment variable DB_HOME, or because the utility
78       was run in a directory containing a Berkeley DB environment).  In order
79       to  avoid  environment corruption when using a Berkeley DB environment,
80       db_archive should always be given the chance to detach from  the  envi‐
81       ronment  and exit gracefully.  To cause db_archive to release all envi‐
82       ronment resources and exit cleanly, send it an interrupt  signal  (SIG‐
83       INT).
84
85       The  DB_ENV->log_archive  method  is  the underlying method used by the
86       db_archive utility.  See the db_archive  utility  source  code  for  an
87       example  of using DB_ENV->log_archive in a IEEE/ANSI Std 1003.1 (POSIX)
88       environment.
89

EXIT STATUS

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

ENVIRONMENT

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

NOTES

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

SEE ALSO

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