DB_DUMP(1)

💾 DB_DUMP(1) — BerkeleyDB Utilities 💾

okay bestie, pull up a chair, we're talking about db_dump from the BerkeleyDB Utilities suite and honestly? it's giving "quietly essential." let's get into it 🫶

---

✨ NAME ✨

db_dump — write database file using flat-text format. yes, that's the whole name section, she's brief but she's iconic 💅

---

🌸 SYNOPSIS 🌸

db_dump [-klNpRrV] [-b blob-dir] [-d ahr] [-f output] [-h home] [-P
password] [-s database] [-D bytes] file

db_dump [-kNpV] [-d ahr] [-f output] [-h home] -m database

db_dump185 [-p] [-f output] file

three whole moods, three whole invocations. we love a versatile queen 👑

---

🦋 DESCRIPTION 🦋

so the tea is: the db_dump utility reads the database file and writes it out to standard output using a portable flat-text format that the db_load utility understands. cute little relay race, love that for them 🏃♀️

the file argument has to be a file produced using the Berkeley DB library functions. no random files, bestie, it has to be one of ours. periodt.

and then there's db_dump185, which is basically db_dump's vintage older sister — she's similar to db_dump, except she reads databases in the format used by Berkeley DB versions 1.85 and 1.86. throwback vibes fr fr 🎀

---

💅 OPTIONS 💅

• -b blob-dir — tells you where the BLOB data lives for the database you're dumping. that's the directory, specifically. give her the address and she'll find the blobs 📍
• -d — dumps the specified database in a format that's helpful for debugging the Berkeley DB library routines. and it takes one of these lil letters:
  • a — display all information. everything. the whole gossip 🗣️
  • h — display only page headers.
  • r — do not display the free-list or pages on the free list. this mode is used by the recovery tests.

heads up bestie: the output format of the -d option is not standard and may change, without notice, between releases of the Berkeley DB library. so don't go building your whole personality on it, okay? 😭

• -D bytes — specifies the maximum number of bytes to dump for each key/data item found in the specified database. only valid when -da is also specified. and it overrides the value set for the "set_data_len" parameter in your DB_CONFIG file, if any. she overrules, respectfully 💅
• -f output — write to the specified output file instead of to standard output. redirect her, she doesn't mind 🎀
• -h home — specify a home directory for the database environment. by default, the current working directory is used. she'll just chill where she is unless you tell her otherwise 🏠
• -k — dump record numbers from Queue and Recno databases as keys. numbering, but make it keys 🔢
• -l — list the databases stored in the file. just a lil inventory, a lil show-and-tell 📋
• -N — do not acquire shared region mutexes while running. other problems, such as potentially fatal errors in Berkeley DB, will be ignored as well.

okay serious voice for one sec: this option is intended only for debugging errors, and should not be used under any other circumstances. do not make this your default. i'm begging 🙈

• -P password — specify an environment password. and yes, Berkeley DB utilities overwrite password strings as soon as possible, BUT be aware there may be a window of vulnerability on systems where unprivileged users can see command-line arguments, or where utilities aren't able to overwrite the memory containing the command-line arguments. so like... be careful with her, she's exposed for a second 😭🔐
• -p — if characters in either the key or data items are printing characters (as defined by isprint(3)), use printing characters in file to represent them. this option lets users use standard text editors and tools to modify the contents of databases. so you can just... open it up and edit. slay 🦋

note: different systems may have different notions about what characters are considered printing characters, and databases dumped in this manner may be less portable to external systems. she travels, but she doesn't travel everywhere the same way ✈️

• -R — aggressively salvage data from a possibly corrupt file. the -R flag differs from the -r option in that it will return all possible data from the file at the risk of also returning already deleted or otherwise nonsensical items. data dumped in this fashion will almost certainly have to be edited by hand or other means before the data is ready for reload into another database. she's feral, she's thorough, she's bringing home trash too 💀
• -r — salvage data from a possibly corrupt file. when used on an uncorrupted database, this option should return equivalent data to a normal dump, but most likely in a different order. chill salvage, same content, shuffled playlist 🔀
• -s database — specify a single database to dump. if no database is specified, all databases in the database file are dumped. one or all, her choice, your call 👑
• -V — write the library version number to the standard output, and exit. version check, then bye 👋

---

🚨 the important warnings section (no heading in the original, but these are real ones) 🚨

dumping and reloading Hash databases that use user-defined hash functions will result in new databases that use the default hash function. although using the default hash function may not be optimal for the new database, it will continue to work correctly. so like... not ideal, but fine. she's fine 💜

dumping and reloading Btree databases that use user-defined prefix or comparison functions will result in new databases that use the default prefix and comparison functions. in this case, it is quite likely that the database will be damaged beyond repair, permitting neither record storage or retrieval. yeah. that one's bad. that's a real one. 😭

the only available workaround for either case is to modify the sources for the db_load utility to load the database using the correct hash, prefix, and comparison functions. that's it. that's the workaround. go edit some sources bestie 🫶

---

the db_dump utility output format is documented in the Dump Output Formats section of the Berkeley DB Reference Guide. go read her, she's thorough 📖

the db_dump utility may be used with 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_dump should always be given the chance to detach from the environment and exit gracefully. to cause db_dump to release all environment resources and exit cleanly, send it an interrupt signal (SIGINT). let her leave the party politely, don't drag her out mid-sentence 💅

even when using a Berkeley DB database environment, the db_dump utility does not use any kind of database locking if it is invoked with the -d, -R, or -r arguments. if used with one of these arguments, the db_dump utility may only be safely run on databases that are not being modified by any other process; otherwise, the output may be corrupt. so if you're using -d, -R, or -r, make sure nobody else is touching that database. nobody. at all. 😤

---

⭐ EXIT STATUS ⭐

the db_dump utility exits 0 on success, and >0 if an error occurs. zero is the vibe, anything above zero means something went sideways 🌈

---

🧚 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 her way home through the env var if you don't hand her a map 🏡

---

🔥 SEE ALSO 🔥

db_archive(1) db_checkpoint(1) db_deadlock(1) db_hotbackup(1) db_log_verify(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)

the whole friend group, go say hi to all of them 🫶✨

---

BerkeleyDB 5.3.28 💖 06 December 2016 — that's the version and the date this page was written, and honestly? still serving. k bye bestie, go dump responsibly 💅🎀