Berkeley DB Reference Guide: Access Methods

Access method FAQ

1. I'm seeing database corruption when creating multiple databases in a single physical file.

   This problem is usually the result of DB handles not sharing an underlying database environment. See Opening multiple databases in a single file for more information.

2. Is there any way to compact databases, or return unused database pages to the filesystem?

   When Berkeley DB database pages are emptied, they are made available for other uses, that is, new pages will not be allocated from the underlying filesystem as long as there are unused pages available. However, the pages cannot be returned to the filesystem without dumping the database, removing the physical file, and reloading the database. The one exception to this rule is Queue access method extent files. Queue extent files removed when they are emptied, and their pages returned to the underlying filesystem.

3. I'm using integers as keys for a Btree database, and even though the key/data pairs are entered in sorted order, the page-fill factor is low.

   This is usually the result of using integer keys on little-endian architectures such as the x86. Berkeley DB sorts keys as byte strings, and little-endian integers don't sort well when viewed as byte strings. You may want to convert the keys to flat text or big-endian representations, or provide your own Btree comparison function.

4. Is there any way to avoid double buffering in the Berkeley DB system?

   While you cannot avoid double buffering entirely, there are three different tuning knobs you can work with to address this issue:

   First, the Berkeley DB cache size can be explicitly set. Rather than allocate additional space in the Berkeley DB cache to cover unexpectedly heavy load or large table sizes, double buffering may suggest you size the cache to function well under normal conditions, and then depend on the file buffer cache to cover abnormal conditions. Obviously, this is a trade-off, as Berkeley DB may not then perform as well as usual under abnormal conditions.

   Second, depending on the underlying operating system you're using, you may be able to alter the amount of physical memory devoted to the file buffer cache. Running as the system super-user makes a difference for some UNIX or UNIX-like operating systems as well.

   Third, changing the size of the Berkeley DB environment regions can change the amount of space the operating system makes available for the file buffer cache, and it's often worth considering exactly how the operating system is dividing up its available memory. Further, moving the Berkeley DB database environment regions from filesystem backed memory into system memory (or heap memory), can often make additional system memory available for the file buffer cache, especially on systems without a unified buffer cache and VM system.

Copyright Sleepycat Software