- Berkeley DB Reference Guide:
- Access Methods
|
|
Yes; "tables" are databases, "rows" are key/data pairs, and "columns" are application-encapsulated fields within a data item (to which Berkeley DB does not directly provide access).
See DB_ENV->set_errcall, DB_ENV->set_errfile and DB->set_errfile for ways to get additional information about error returns from Berkeley DB.
Yes. See Selecting a byte order for more information.
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.
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 are removed when they are emptied, and their pages returned to the underlying filesystem.
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. For example, take the numbers 254 through 257. Their byte patterns on a little-endian system are:
254 fe 0 0 0 255 ff 0 0 0 256 0 1 0 0 257 1 1 0 0
If you treat them as strings, then they sort badly:
256 257 254 255
On a big-endian system, their byte patterns are:
254 0 0 0 fe 255 0 0 0 ff 256 0 0 1 1 257 0 0 1 1
and so, if you treat them as strings they sort nicely. Which means, if you use steadily increasing integers as keys on a big-endian system Berkeley DB behaves well and you get compact trees, but on a little-endian system Berkeley DB produces much less compact trees. To avoid this problem, you may want to convert the keys to flat text or big-endian representations, or provide your own Btree comparison function.
While you cannot avoid double buffering entirely, there are a few things you can do 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.
Finally, for operating systems that allow buffering to be turned off, specifying the DB_DIRECT_DB and DB_DIRECT_LOG flags will attempt to do so.
Berkeley DB can continue to run when when out-of-disk-space errors occur, but it requires the application to be transaction protected. Applications which do not enclose update operations in transactions cannot recover from out-of-disk-space errors, and the result of running out of disk space may be database corruption.
In the C API, the DB and DB_ENV structures each contain an "app_private" field intended to be used to reference application-specific information. See the db_create and db_env_create documentation for more information.
In the C++ or Java APIs, the easiest way to associate application-specific data with a handle is to subclass the Db or DbEnv, for example subclassing Db to get MyDb. Objects of type MyDb will still have the Berkeley DB API methods available on them, and you can put any extra data or methods you want into the MyDb class. If you are using "callback" APIs that take Db or DbEnv arguments (for example, Db::set_bt_compare) these will always be called with the Db or DbEnv objects you create. So if you always use MyDb objects, you will be able to take the first argument to the callback function and cast it to a MyDb (in C++, cast it to (MyDb*)). That will allow you to access your data members or methods.
|
|
Copyright (c) 1996-2004 Sleepycat Software, Inc. - All rights reserved.