1<!--$Id: faq.so,v 10.28 2008/01/24 00:35:23 sarette Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Access method FAQ</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<a name="2"><!--meow--></a> 12<table width="100%"><tr valign=top> 13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></b></td> 14<td align=right><a href="../am_misc/tune.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../java/conf.html"><img src="../../images/next.gif" alt="Next"></a> 15</td></tr></table> 16<p align=center><b>Access method FAQ</b></p> 17<ol> 18<p><li><b>Is a Berkeley DB database the same as a "table"?</b> 19<p>Yes; "tables" are databases, "rows" are key/data pairs, and "columns" 20are application-encapsulated fields within a data item (to which Berkeley DB 21does not directly provide access).</p> 22<p><li><b>I'm getting an error return in my application, but I can't 23figure out what the library is complaining about.</b> 24<p>See <a href="../../api_c/env_set_errcall.html">DB_ENV->set_errcall</a>, <a href="../../api_c/env_set_errfile.html">DB_ENV->set_errfile</a> and 25<a href="../../api_c/db_set_errfile.html">DB->set_errfile</a> for ways to get additional information about 26error returns from Berkeley DB.</p> 27<p><li><b>Are Berkeley DB databases portable between architectures with 28different integer sizes and different byte orders ?</b> 29<p>Yes. Specifically, databases can be moved between 32- and 64-bit 30machines, as well as between little- and big-endian machines. See 31<a href="../../ref/am_conf/byteorder.html">Selecting a byte order</a> for 32more information.</p> 33<p><li><b>I'm seeing database corruption when creating multiple databases 34in a single physical file.</b> 35<p>This problem is usually the result of <a href="../../api_c/db_class.html">DB</a> handles not sharing an 36underlying database environment. See <a href="../../ref/am/opensub.html">Opening multiple databases in a single file</a> for more information.</p> 37<p><li><b>I'm using integers as keys for a Btree database, and even 38though the key/data pairs are entered in sorted order, the page-fill 39factor is low.</b> 40<p>This is usually the result of using integer keys on little-endian 41architectures such as the x86. Berkeley DB sorts keys as byte strings, and 42little-endian integers don't sort well when viewed as byte strings. 43For example, take the numbers 254 through 257. Their byte patterns on 44a little-endian system are:</p> 45<blockquote><pre>254 fe 0 0 0 46255 ff 0 0 0 47256 0 1 0 0 48257 1 1 0 0</pre></blockquote> 49<p>If you treat them as strings, then they sort badly:</p> 50<blockquote><pre>256 51257 52254 53255</pre></blockquote> 54<p>On a big-endian system, their byte patterns are:</p> 55<blockquote><pre>254 0 0 0 fe 56255 0 0 0 ff 57256 0 0 1 0 58257 0 0 1 1</pre></blockquote> 59<p>and so, if you treat them as strings they sort nicely. Which means, if 60you use steadily increasing integers as keys on a big-endian system 61Berkeley DB behaves well and you get compact trees, but on a little-endian 62system Berkeley DB produces much less compact trees. To avoid this problem, 63you may want to convert the keys to flat text or big-endian 64representations, or provide your own 65<a href="../../ref/am_conf/bt_compare.html">Btree comparison function.</a></p> 66<a name="3"><!--meow--></a> 67<p><li><b>Is there any way to avoid double buffering in the Berkeley DB system?</b> 68<p>While you cannot avoid double buffering entirely, there are a few things 69you can do to address this issue:</p> 70<p>First, the Berkeley DB cache size can be explicitly set. Rather than allocate 71additional space in the Berkeley DB cache to cover unexpectedly heavy load or 72large table sizes, double buffering may suggest you size the cache to 73function well under normal conditions, and then depend on the file 74buffer cache to cover abnormal conditions. Obviously, this is a 75trade-off, as Berkeley DB may not then perform as well as usual under abnormal 76conditions.</p> 77<p>Second, depending on the underlying operating system you're using, you 78may be able to alter the amount of physical memory devoted to the 79system's file buffer cache. Altering this type of resource 80configuration may require appropriate privileges, or even operating 81system reboots and/or rebuilds, on some systems.</p> 82<p>Third, changing the size of the Berkeley DB environment regions can change 83the amount of space the operating system makes available for the file 84buffer cache, and it's often worth considering exactly how the operating 85system is dividing up its available memory. Further, moving the Berkeley DB 86database environment regions from filesystem backed memory into system 87memory (or heap memory), can often make additional system memory 88available for the file buffer cache, especially on systems without a 89unified buffer cache and VM system.</p> 90<p>Finally, for operating systems that allow buffering to be turned off, 91specifying the <a href="../../api_c/env_set_flags.html#DB_DIRECT_DB">DB_DIRECT_DB</a> and <a href="../../api_c/env_log_set_config.html#DB_LOG_DIRECT">DB_LOG_DIRECT</a> flags 92will attempt to do so.</p> 93<p><li><b>I'm seeing database corruption when I run out of disk space.</b> 94<p>Berkeley DB can continue to run when when out-of-disk-space errors occur, but 95it requires the application to be transaction protected. Applications 96which do not enclose update operations in transactions cannot recover 97from out-of-disk-space errors, and the result of running out of disk 98space may be database corruption.</p> 99<p><li><b>How can I associate application information with a <a href="../../api_c/db_class.html">DB</a> 100or <a href="../../api_c/env_class.html">DB_ENV</a> handle?</b> 101<p>In the C API, the <a href="../../api_c/db_class.html">DB</a> and <a href="../../api_c/env_class.html">DB_ENV</a> structures each contain 102an "app_private" field intended to be used to reference 103application-specific information. See the <a href="../../api_c/db_class.html">db_create</a> and 104<a href="../../api_c/env_class.html">db_env_create</a> documentation for more information.</p> 105<p>In the C++ or Java APIs, the easiest way to associate 106application-specific data with a handle is to subclass the <a href="../../api_cxx/db_class.html">Db</a> 107or <a href="../../api_cxx/env_class.html">DbEnv</a>, for example subclassing <a href="../../api_cxx/db_class.html">Db</a> to get MyDb. 108Objects of type MyDb will still have the Berkeley DB API methods available on 109them, and you can put any extra data or methods you want into the MyDb 110class. If you are using "callback" APIs that take <a href="../../api_cxx/db_class.html">Db</a> or 111<a href="../../api_cxx/env_class.html">DbEnv</a> arguments (for example, <a href="../../api_cxx/db_set_bt_compare.html">Db::set_bt_compare</a>) 112these will always be called with the <a href="../../api_cxx/db_class.html">Db</a> or <a href="../../api_cxx/env_class.html">DbEnv</a> 113objects you create. So if you always use MyDb objects, you will be able 114to take the first argument to the callback function and cast it to a 115MyDb (in C++, cast it to (MyDb*)). That will allow you to access your 116data members or methods.</p> 117</ol> 118<table width="100%"><tr><td><br></td><td align=right><a href="../am_misc/tune.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../java/conf.html"><img src="../../images/next.gif" alt="Next"></a> 119</td></tr></table> 120<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 121</body> 122</html> 123
