Copyright (C) 2000-2012 |
Manpages DB_ARCHIVESection: User Commands (1)Updated: May 3, 1998 Index Return to Main Contents NAMEdb_archive - the DB database archiverSYNOPSISdb_archive [-alsv] [-h home]DESCRIPTIONThe db_archive utility writes the pathnames of log files that are no longer in use (e.g., no longer involved in active transactions), to the standard output, one pathname per line. These log files should be written to backup media to provide for recovery in the case of catastrophic failure (which also requires a snapshot of the database files), but they may then be deleted from the system to reclaim disk space.The options are as follows:
The db_archive utility attaches to DB shared memory regions. In order to avoid region corruption, it should always be given the chance to detach and exit gracefully. To cause db_archive to clean up after itself and exit, send it an interrupt signal (SIGINT). The db_archive utility exits 0 on success, and >0 if an error occurs. DB ARCHIVAL PROCEDURESThere are two aspects to managing the recoverability and disk consumption of your DB databases. First, you may want to periodically create snapshots of your databases to make it possible to recover them from catastrophic failure. Second, you'll want to periodically remove log files in order to conserve on disk space. The two procedures are distinct from each other, and you cannot remove the current log files simply because you have created a database snapshot.To create a snapshot of your database that can be used to recover from catastrophic failure, the following steps should be taken:
Note that the order of these operations is important, and that the database files must be archived before the log files. The DB library supports on-line backups, and it is not necessary to stop reading or writing your databases during the time when you create this snapshot. Note however, that the snapshot of an active database will be consistent as of some unspecified time between the start of the archival and when archival is completed. To create a snapshot as of a specific time, you must stop reading and writing your databases for the entire time of the archival, force a checkpoint (see db_checkpoint(1)), and then archive the files listed by the db_archive command's -s and -l options. Once these steps are completed, your database can be recovered from catastrophic failure to its state as of the time the archival was done. To update your snapshot so that recovery from catastrophic failure is possible up to a new point in time, repeat step #2, copying all existing log files to a backup device. Each time that a complete snapshot is made, i.e. all database and log files are copied to backup media, you may discard all previous snapshots and saved log files. The time to restore from catastrophic failure is a function of the number of log records that have been written since the snapshot was originally created. Perhaps more importantly, the more separate pieces of backup media you use, the more likely that you will have a problem reading from one of them. For these reasons, it is often best to make snapshots on a regular basis. For archival safety remember to ensure that you have multiple copies of your database backups, that you verify that your archival media is error-free, and that copies of your backups are stored off-site! To restore your database after catastrophic failure, the following steps should be taken:
It is possible to recreate the database in a location different than the original, by specifying appropriate pathnames to the -h option of the db_recover utility. To remove log files, the following steps should be taken:
ENVIRONMENT VARIABLESThe following environment variables affect the execution of db_archive:
SEE ALSOThe DB library is a family of classes that provides a modular programming interface to transactions and record-oriented file access. The library includes support for transactions, locking, logging and file page caching, as well as various indexed access methods. Many of the classes (e.g., the file page caching class) are useful independent of the other DB classes, although some classes are explicitly based on other classes (e.g., transactions and logging).db_archive(1), db_checkpoint(1), db_deadlock(1), db_dump(1), db_load(1), db_recover(1), db_stat(1),
IndexThis document was created by man2html, using the manual pages. Time: 11:00:38 GMT, April 20, 2024 |