NNAAMMEE db_recover - the DB database recovery utility SSYYNNOOPPSSIISS ddbb__rreeccoovveerr [--ccvv] [--hh hhoommee] DDEESSCCRRIIPPTTIIOONN The _d_b___r_e_c_o_v_e_r utility must be run after an unexpected application, DB, or system failure to restore the database to a consistent state. All committed transactions are guaranteed to appear after _d_b___r_e_c_o_v_e_r has run, and all uncommitted transactions will be completely undone. The options are as follows: --cc Failure was catastrophic. --hh Specify a home directory for the database. --vv Run in verbose mode. In the case of catastrophic failure, an archival copy, or ``snapshot'' of all database files must be restored along with all of the log files written since the database file snapshot was made. (If disk space is a problem, log files may be referenced by symbolic links). For further infor- mation on creating a database snapshot, see ``DB ARCHIVAL PROCEDURES'' in _d_b___a_r_c_h_i_v_e(1). If the failure was not catastrophic, the files present on the system at the time of failure are sufficient to per- form recovery. If log files are missing, _d_b___r_e_c_o_v_e_r will identify the missing log file(s) and fail, in which case the missing log files need to be restored and recovery performed again. The _d_b___r_e_c_o_v_e_r 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 _d_b___r_e_c_o_v_e_r to clean up after itself and exit, send it an interrupt signal (SIGINT). The _d_b___r_e_c_o_v_e_r utility exits 0 on success, and >0 if an error occurs. FFIILLEESSYYSSTTEEMM OOPPEERRAATTIIOONNSS FFiilleessyysstteemm ooppeerraattiioonnss,, ee..gg..,, mmoovviinngg tthhee ddaattaabbaassee eennvviirroonn-- mmeenntt ttoo aa ddiiffffeerreenntt mmaacchhiinnee oorr ffiillee ccrreeaattiioonn,, ddeelleettiioonn oorr rreennaammiinngg,, ccaannnnoott bbee ttrraannssaaccttiioonn pprrootteecctteedd.. For this rea- son, _d_b___r_e_c_o_v_e_r cannot re-create, delete or rename files as part of recovery. If _d_b___r_e_c_o_v_e_r cannot find a database file referenced in the log, it will output a warning message that it was unable to locate a file it expected to find. This message is only a warning, as the file may have subsequently been deleted as part of normal database operations before the failure occurred. NNoottee tthhaatt ccoommmmiitttteedd ttrraannssaaccttiioonnss tthhaatt iinnvvoollvveedd tthheessee mmiissssiinngg ffiilleess aarree rroolllleedd ffoorrwwaarrdd,, eevveenn tthhoouugghh tthhee ffiilleess wweerree nnoott ffoouunndd.. IIff tthhee ffiilleess wweerree nnoott iinntteennttiioonnaallllyy ddeelleetteedd ((ee..gg..,, tthheeyy wweerree ccrreeaatteedd aafftteerr tthhee llaasstt ddaattaabbaassee ssnnaappsshhoott,, bbuutt wweerree lloosstt dduurriinngg aa ffaaiilluurree)),, tthheeyy mmuusstt bbee mmaannuuaallllyy ccrreeaatteedd ((uussiinngg _d_b___o_p_e_n(3)), and _d_b___r_e_c_o_v_e_r must be rerun. Generally, it is simplest to perform filesystem operations at the same time as making a snapshot of the database. To perform filesystem operations: 1. Cleanly shutdown database operations. 2. Rename, create or delete files. 3. Make a snapshot of the database. 4. Restart database applications. To cleanly shutdown database operations, all applications accessing the database environment must be shutdown. If the applications are not implemented such that they can be shutdown gracefully (i.e., closing all references to the database environment), _d_b___r_e_c_o_v_e_r must be run after all applications have been killed to ensure that the underly- ing database is consistent and flushed to disk. RREECCOOVVEERRYY After an application or system failure, there are two pos- sible approaches to database recovery. If there is no need to retain state across the failure, and all databases can be started anew, the database home directory can sim- ply be removed and recreated. If it is necessary to retain persistent state across failures, then the _d_b___r_e_c_o_v_e_r(1) utility should be run for each DB applica- tion environment, i.e., each database home directory. The _d_b___r_e_c_o_v_e_r utility will remove all the shared regions (which may have been corrupted by the failure), establish the end of the log by identifying the last record written to the log, and then perform transaction recovery. Database applications must not be restarted until recovery completes. During transaction recovery, all changes made by aborted transactions are undone and all changes made by committed transactions are redone, as necessary. After recovery runs, the environment is properly initialized so that applications may be restarted. Any time an applica- tion crashes or the system fails, _d_b___r_e_c_o_v_e_r should be run on any exiting database environments. Additionally, there are two forms of recovery: normal recovery and catastrophic recovery. The DB package defines catastrophic failure to be failure where either the database or log files have been destroyed or corrupted from the point of view of the filesystem. For example, catastrophic failure includes the case where the disk drive on which either the database or logs are stored has crashed, or when filesystem recovery is unable to bring the database and log files to a consistent state with respect to the filesystem. If the failure is non-catas- trophic, i.e., the database files and log are accessible on a filesystem that has recovered cleanly, _d_b___r_e_c_o_v_e_r will review the logs and database files to ensure that all committed transactions appear and that all uncommitted transactions are undone. If the failure is catastrophic, a snapshot of the database files and the archived log files must be restored onto the system. Then _d_b___r_e_c_o_v_e_r will review the logs and database files to bring the database to a consistent state as of the date of the last archived log file. Only transactions committed before that date will appear in the database. See _d_b___a_r_c_h_i_v_e _(_1_) for specific information about archiving and recovering databases after catastrophic failure. EENNVVIIRROONNMMEENNTT VVAARRIIAABBLLEESS The following environment variables affect the execution of _d_b___r_e_c_o_v_e_r: DB_HOME If the --hh option is not specified and the environment variable _D_B___H_O_M_E is set, it is used as the path of the database home, as described in _d_b___a_p_p_i_n_i_t(3). BBUUGGSS Future versions of DB are expected to remove the restric- tion that database files must be manually created before recovery is performed. SSEEEE AALLSSOO The DB library is a family of groups of functions 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 functional groups (e.g., the file page caching functions) are useful independent of the other DB func- tions, although some functional groups are explicitly based on other functional groups (e.g., transactions and logging). For a general description of the DB package, see _d_b___i_n_t_r_o(3). _d_b___a_r_c_h_i_v_e(1), _d_b___c_h_e_c_k_p_o_i_n_t(1), _d_b___d_e_a_d_l_o_c_k(1), _d_b___d_u_m_p(1), _d_b___l_o_a_d(1), _d_b___r_e_c_o_v_e_r(1), _d_b___s_t_a_t(1), _d_b___i_n_t_r_o(3), _d_b___a_p_p_i_n_i_t(3), _d_b___c_u_r_s_o_r(3), _d_b___d_b_m(3), _d_b___i_n_t_e_r_n_a_l(3), _d_b___l_o_c_k(3), _d_b___l_o_g(3), _d_b___m_p_o_o_l(3), _d_b___o_p_e_n(3), _d_b___t_h_r_e_a_d(3), _d_b___t_x_n(3)