1<!--$Id: db_verify.so,v 10.30 2005/03/08 16:29:34 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB: DB->verify</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<table width="100%"><tr valign=top> 12<td> 13<b>DB->verify</b> 14</td> 15<td align=right> 16<a href="/api_c/api_core.html"><img src="/images/api.gif" alt="API"></a> 17<a href="/ref/toc.html"><img src="/images/ref.gif" alt="Ref"></a></td> 18</tr></table> 19<hr size=1 noshade> 20<tt> 21<b><pre> 22#include <db.h> 23<p> 24int 25DB->verify(DB *db, const char *file, 26 const char *database, FILE *outfile, u_int32_t flags); 27</pre></b> 28<hr size=1 noshade> 29<b>Description: DB->verify</b> 30<p>The DB->verify method verifies the integrity of all databases in the 31file specified by the <b>file</b> parameter, and optionally outputs the 32databases' key/data pairs to the file stream specified by the 33<b>outfile</b> parameter.</p> 34<p><b>The DB->verify method does not perform any locking, even in Berkeley DB 35environments that are configured with a locking subsystem. As such, it 36should only be used on files that are not being modified by another 37thread of control.</b></p> 38<p>The DB->verify method may not be called after the <a href="/api_c/db_open.html">DB->open</a> method is called. 39</p> 40<p>The <a href="/api_c/db_class.html">DB</a> handle may not be accessed again after DB->verify is 41called, regardless of its return.</p> 42<p>The DB->verify method is the underlying method used by the <a href="/utility/db_verify.html">db_verify</a> utility. 43See the <a href="/utility/db_verify.html">db_verify</a> utility source code for an example of using DB->verify 44in a IEEE/ANSI Std 1003.1 (POSIX) environment.</p> 45<a name="2"><!--meow--></a> 46<p>The DB->verify method will return DB_VERIFY_BAD if a database is 47corrupted. When the DB_SALVAGE flag is specified, the 48DB_VERIFY_BAD return means that all key/data pairs in the file 49may not have been successfully output. 50Unless otherwise specified, the DB->verify method 51returns a non-zero error value on failure 52and 0 on success. 53</p> 54<b>Parameters</b> <br> 55 <b>database</b><ul compact><li>The <b>database</b> parameter is the database in <b>file</b> on which 56the database checks for btree and duplicate sort order and for hashing 57are to be performed. See the DB_ORDERCHKONLY flag for more 58information. 59<p>The database parameter must be set to NULL except when the 60DB_ORDERCHKONLY flag is set.</p></ul> 61 <b>file</b><ul compact><li>The <b>file</b> parameter is the physical file in which the databases 62to be verified are found.</ul> 63 <b>flags</b><ul compact><li>The <b>flags</b> parameter must be set to 0 or 64the following value: 65<br> 66<b><a name="DB_SALVAGE">DB_SALVAGE</a></b><ul compact><li>Write the key/data pairs from all databases in the file to the file 67stream named in the <b>outfile</b> parameter. Key values are written 68for Btree, Hash and Queue databases, but not for Recno databases. 69<p>The output format is the same as that specified for the <a href="/utility/db_dump.html">db_dump</a> 70utility, and can be used as input for the <a href="/utility/db_load.html">db_load</a> utility.</p> 71<p>Because the key/data pairs are output in page order as opposed to the sort 72order used by <a href="/utility/db_dump.html">db_dump</a>, using DB->verify to dump key/data 73pairs normally produces less than optimal loads for Btree databases.</p></ul> 74<br> 75<p>In addition, the following flags may be set by bitwise inclusively <b>OR</b>'ing them into the 76<b>flags</b> parameter:</p> 77<br> 78<b><a name="DB_AGGRESSIVE">DB_AGGRESSIVE</a></b><ul compact><li>Output <b>all</b> the key/data pairs in the file that can be found. 79By default, DB->verify does not assume corruption. For example, 80if a key/data pair on a page is marked as deleted, it is not then written 81to the output file. When DB_AGGRESSIVE is specified, corruption 82is assumed, and any key/data pair that can be found is written. In this 83case, key/data pairs that are corrupted or have been deleted may appear 84in the output (even if the file being salvaged is in no way corrupt), and 85the output will almost certainly require editing before being loaded into 86a database.</ul> 87<b><a name="DB_PRINTABLE">DB_PRINTABLE</a></b><ul compact><li>When using the DB_SALVAGE flag, if characters in either the key 88or data items are printing characters (as defined by <b>isprint</b>(3)), use printing characters to represent them. This flag permits users 89to use standard text editors and tools to modify the contents of 90databases or selectively remove data from salvager output. 91<p>Note: different systems may have different notions about what characters 92are considered <i>printing characters</i>, and databases dumped in 93this manner may be less portable to external systems.</p></ul> 94<b><a name="DB_NOORDERCHK">DB_NOORDERCHK</a></b><ul compact><li>Skip the database checks for btree and duplicate sort order and for 95hashing. 96<p>The DB->verify method normally verifies that btree keys and duplicate 97items are correctly sorted, and hash keys are correctly hashed. If the 98file being verified contains multiple databases using differing sorting 99or hashing algorithms, some of them must necessarily fail database 100verification because only one sort order or hash function can be 101specified before DB->verify is called. To verify files with 102multiple databases having differing sorting orders or hashing functions, 103first perform verification of the file as a whole by using the 104DB_NOORDERCHK flag, and then individually verify the sort order 105and hashing function for each database in the file using the 106DB_ORDERCHKONLY flag.</p></ul> 107<b><a name="DB_ORDERCHKONLY">DB_ORDERCHKONLY</a></b><ul compact><li>Perform the database checks for btree and duplicate sort order and for 108hashing, skipped by DB_NOORDERCHK. 109<p>When this flag is specified, a <b>database</b> parameter should also be 110specified, indicating the database in the physical file which is to be 111checked. This flag is only safe to use on databases that have already 112successfully been verified using DB->verify with the 113DB_NOORDERCHK flag set.</p></ul> 114<br></ul> 115 <b>outfile</b><ul compact><li>The <b>outfile</b> parameter is an optional file stream to which the 116databases' key/data pairs are written.</ul> 117<br> 118<br><b>Environment Variables</b> 119<p>If the database was opened within a database environment, the 120environment variable <b>DB_HOME</b> may be used as the path of the 121database environment home.</p> 122<p>DB->verify is affected by any database directory specified using 123the <a href="/api_c/env_set_data_dir.html">DB_ENV->set_data_dir</a> method, or by setting the "set_data_dir" string 124in the environment's <a href="/ref/env/db_config.html#DB_CONFIG">DB_CONFIG</a> file.</p> 125<br><b>Errors</b> 126<br> 127<b>ENOENT</b><ul compact><li>The file or directory does not exist.</ul> 128<br> 129<p>The DB->verify method 130may fail and return one of the following non-zero errors:</p> 131<br> 132<b>EINVAL</b><ul compact><li>If DB->verify was called after <a href="/api_c/db_open.html">DB->open</a>; or if an 133invalid flag value or parameter was specified.</ul> 134<br> 135<hr size=1 noshade> 136<br><b>Class</b> 137<a href="/api_c/db_class.html">DB</a> 138<br><b>See Also</b> 139<a href="/api_c/db_list.html">Databases and Related Methods</a> 140</tt> 141<table width="100%"><tr><td><br></td><td align=right> 142<a href="/api_c/api_core.html"><img src="/images/api.gif" alt="API"></a><a href="/ref/toc.html"><img src="/images/ref.gif" alt="Ref"></a> 143</td></tr></table> 144<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 145</body> 146</html> 147
