|
DB->verify
|
|
#include <db.h>
int
DB->verify(DB *db, const char *file,
const char *database, FILE *outfile, u_int32_t flags);
Description
The DB->verify function verifies the integrity of all databases in the
file specified by the file argument, and optionally outputs the
databases' key/data pairs to the file stream specified by the
outfile argument.
The flags value must be set to 0 or
the following value:
- DB_SALVAGE
- Write the key/data pairs from all databases in the file to the file stream
named in
the outfile argument. The output format is the same as that
specified for the db_dump utility, and can be used as input for
the db_load utility.
Because the key/data pairs are output in page order as opposed to the sort
order used by db_dump, using DB->verify to dump key/data
pairs normally produces less than optimal loads for Btree databases.
In addition, the following flags may be set by bitwise inclusively OR'ing them into the
flags parameter:
- DB_AGGRESSIVE
- Output all the key/data pairs in the file that can be found.
By default, DB->verify does not assume corruption. For example,
if a key/data pair on a page is marked as deleted, it is not then written
to the output file. When DB_AGGRESSIVE is specified, corruption
is assumed, and any key/data pair that can be found is written. In this
case, key/data pairs that are corrupted or have been deleted may appear
in the output (even if the file being salvaged is in no way corrupt), and
the output will almost certainly require editing before being loaded into
a database.
- DB_NOORDERCHK
- Skip the database checks for btree and duplicate sort order and for
hashing.
The DB->verify function normally verifies that btree keys and duplicate
items are correctly sorted, and hash keys are correctly hashed. If the
file being verified contains multiple databases using differing sorting
or hashing algorithms, some of them must necessarily fail database
verification because only one sort order or hash function can be
specified before DB->verify is called. To verify files with
multiple databases having differing sorting orders or hashing functions,
first perform verification of the file as a whole by using the
DB_NOORDERCHK flag, and then individually verify the sort order
and hashing function for each database in the file using the
DB_ORDERCHKONLY flag.
- DB_ORDERCHKONLY
- Perform the database checks for btree and duplicate sort order and for
hashing, skipped by DB_NOORDERCHK.
When this flag is specified, a database argument should also be
specified, indicating the database in the physical file which is to be
checked. This flag is only safe to use on databases that have already
successfully been verified using DB->verify with the
DB_NOORDERCHK flag set.
The DB->verify function does not perform any locking, even in
Berkeley DB environments that are configured with a locking subsystem. As such, it
should only be used on files that are not being modified by another thread of
control.
The database argument must be set to NULL except when the
DB_ORDERCHKONLY flag is set.
The DB->verify function returns a non-zero error value on failure, 0 on success, and DB_VERIFY_BAD if a database is corrupted. When the
DB_SALVAGE flag is specified, the DB_VERIFY_BAD return
means that all key/data pairs in the file may not have been successfully
output.
The DB->verify function is the underlying function used by the db_verify utility.
See the db_verify utility source code for an example of using DB->verify
in a IEEE/ANSI Std 1003.1 (POSIX) environment.
Environment Variables
- DB_HOME
- If the dbenv argument to db_create was initialized using
DB_ENV->open, the environment variable DB_HOME may be used
as the path of the database environment home. Specifically, DB->verify
is affected by the configuration value DB_DATA_DIR.
Errors
The DB->verify function may fail and return a non-zero error for the following conditions:
- EINVAL
- An invalid flag value or parameter was specified.
The DB->verify function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions.
If a catastrophic error has occurred, the DB->verify function may fail and return
DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail
in the same way.
See Also
db_create,
DB->associate,
DB->close,
DB->cursor,
DB->del,
DB->err, DB->errx
DB->fd,
DB->get,
DB->pget,
DB->get_byteswapped,
DB->get_type,
DB->join,
DB->key_range,
DB->open,
DB->put,
DB->remove,
DB->rename,
DB->set_alloc,
DB->set_append_recno,
DB->set_bt_compare,
DB->set_bt_minkey,
DB->set_bt_prefix,
DB->set_cachesize,
DB->set_dup_compare,
DB->set_errcall,
DB->set_errfile,
DB->set_errpfx,
DB->set_feedback,
DB->set_flags,
DB->set_h_ffactor,
DB->set_h_hash,
DB->set_h_nelem,
DB->set_lorder,
DB->set_pagesize,
DB->set_paniccall,
DB->set_q_extentsize,
DB->set_re_delim,
DB->set_re_len,
DB->set_re_pad,
DB->set_re_source,
DB->stat,
DB->sync,
DB->truncate,
DB->upgrade,
and
DB->verify.
Copyright Sleepycat Software
|