DB_LOG_VERIFY(1)

🦋 db_log_verify — bestie edition 💅

okay so real talk, this is the BerkeleyDB Utilities page for db_log_verify, and it's literally the vibe-checker for your log files. no cap.

---

✨ NAME ✨

db_log_verify — verify log files of a database environment 🎀

---

🌸 SYNOPSIS 🌸

db_log_verify [-cNvV] [-h home-to-verify] [-H temporary-home] [-P
password] [-C cache-size] [-b start-lsn] [-e end-lsn] [-s start-time]
[-z end-time] [-d database-filename] [-D database-name]

---

💖 DESCRIPTION 💖

So the db_log_verify utility verifies the log files of a specific database environment. that's the whole job, and she does it well 🫶

she can verify a specific range of log records, or just the changed log records of a specific database. pick your lane, bestie.

---

✨ OPTIONS ✨

• -C cache-size — sets the cache size, in megabytes, of the temporary database environment that gets used internally while the log verification is happening. bigger logs = bigger cache, iykyk.
• -b start-lsn — tells her the starting log record (by lsn) to verify. where the story begins ✨
• -c — do you want her to keep going after an error? yes? pass this. if you don't specify it, verification stops the second the first error shows up. no second chances, periodt.
• -D database-name — names a database. only log records related to this database get verified. everyone else can go home 💅
• -d database-filename — names a database file. only log records related to this database file get verified.
• -e end-lsn — the ending log record, by lsn. the finale 🌈
• -h home-to-verify — the home directory of the database environment whose log is getting verified. this is the main character location 📍
• -H temporary-home — a home directory for this utility to create a temporary database environment so it can store runtime data during the verification.

it is an error to specify the same directory as the -h option. not cute. don't do it.

if you don't specify this directory at all, every temporary database created during the verification will be in-memory — which is genuinely not a problem as long as the log files you're verifying aren't huge. small logs? in-memory slays. 🌸

• -N — do not acquire shared region mutexes while running. other problems, like potentially fatal errors in Berkeley DB, are ignored as well. this option is intended only for debugging errors, and should not be used under any other circumstances. fr fr, this is a debugging-only situation, not a lifestyle.
• -P password — specify an environment password. even though Berkeley DB utilities overwrite password strings as soon as possible, there may be a window of vulnerability on systems where unprivileged users can see command-line arguments, or where the utilities aren't able to overwrite the memory holding those command-line arguments. so like… be aware 👀
• -s start-time — the starting log record by time. heads up tho: the time range specified is not precise, because the lsn of the most recent time point is what gets used as the starting lsn. it's giving "close enough" 🕐
• -V — write the library version number to standard output and exit. quick little flex then bye 👋
• -v — enable verbose mode, which displays verbose output during the verification process. she'll narrate everything, and honestly? iconic.
• -z end-time — the ending log record by time. same deal as -s: the time range is not precise, because the lsn of the most recent time point is used as the ending lsn.

---

okay so about ranges 📏 — to specify a range of log records, you must provide either an lsn range or a time range. you can neither specify both, nor specify an lsn and a time as a range. pick one combo, bestie, that's the rule.

and if the log footprint is over several megabytes, specify a home directory and a big cache size for the log verification's internal use. otherwise the process' private memory may be exhausted before the verification completes. that's the plot twist nobody wants 😭

the db_log_verify utility does not perform the locking function, even in Berkeley DB environments that are configured with a locking subsystem. noted. 💀

all errors get written to stderr, and all normal and verbose messages get written to stdout. clean separation, we love to see it.

the db_log_verify utility uses a Berkeley DB environment (as described for the -h option, the environment variable DB_HOME, or because the utility was run in a directory containing a Berkeley DB environment). in order to avoid environment corruption when using a Berkeley DB environment, db_log_verify should always be given the chance to detach from the environment and exit gracefully. to cause db_log_verify to release all environment resources and exit cleanly, send it an interrupt signal (SIGINT). be nice to her and she'll clean up after herself 🫶

---

🌈 EXIT STATUS 🌈

The db_log_verify utility exits 0 on success, and >0 if an error occurs. simple math, no notes.

---

🧚 ENVIRONMENT 🧚

• DB_HOME — if the -h option is not specified and the environment variable DB_HOME is set, it is used as the path of the database home, as described in DB_ENV->open. she'll find your home if you don't tell her 💜

---

⭐ NOTES ⭐

If the application(s) that use the environment make use of the DB_ENV->set_lg_dir method, then in order for this utility to run correctly, you need a DB_CONFIG file which sets the proper paths using the set_lg_dir configuration parameter. don't skip this step, it's the difference between slay and 😭

---

👑 SEE ALSO 👑

db_archive(1) db_checkpoint(1) db_deadlock(1) db_dump(1) db_hotbackup(1) db_load(1) db_printlog(1) db_recover(1) db_replicate(1) db_stat(1) db_tuner(1) db_upgrade(1) db_verify(1)

---

and that's the whole page, bestie 💖 this one's from BerkeleyDB 5.3.28, dated 06 December 2016 — yeah she's vintage, but she still ate. go verify some logs, you got this ✨🎀🦋