1<!--$Id: ram.so,v 10.11 2008/01/24 00:36:26 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: Memory-only or Flash configurations</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>Programmer Notes</dl></b></td> 14<td align=right><a href="../program/namespace.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../program/cache.html"><img src="../../images/next.gif" alt="Next"></a> 15</td></tr></table> 16<p align=center><b>Memory-only or Flash configurations</b></p> 17<p>Berkeley DB supports a variety of memory-based configurations for systems 18where filesystem space is either limited in availability or entirely 19replaced by some combination of memory and Flash. In addition, Berkeley DB 20can be configured to minimize writes to the filesystem when the 21filesystem is backed by Flash memory.</p> 22<p>There are three parts of the Berkeley DB database environment normally written 23to the filesystem: the database environment region files, the database 24files and the database environment log files. Each of these items can 25be configured to live in memory rather than in the filesystem:</p> 26<br> 27<b>The database environment region files:</b><ul compact><li>Each of the Berkeley DB subsystems in a database environment is described by 28one or more regions, or chunks of memory. The regions contain all of the 29per-process and per-thread shared information (including mutexes), that 30comprise a Berkeley DB environment. By default, these regions are backed by 31the filesystem. In situations where filesystem backed regions aren't 32optimal, applications can create memory-only database environments in 33two different types of memory: either in the application's heap memory 34or in system shared memory. 35<p>To create the database environment in heap memory, specify the 36<a href="../../api_c/env_open.html#DB_PRIVATE">DB_PRIVATE</a> flag to the <a href="../../api_c/env_open.html">DB_ENV->open</a> method. Note that database 37environments created in heap memory are only accessible to the threads 38of a single process, however.</p> 39<p>To create the database environment in system shared memory, specify the 40<a href="../../api_c/env_open.html#DB_SYSTEM_MEM">DB_SYSTEM_MEM</a> flag to the <a href="../../api_c/env_open.html">DB_ENV->open</a> method. Database 41environments created in system memory are accessible to multiple 42processes, but note that database environments created in system shared 43memory do create a small (roughly 8 byte) file in the filesystem, read 44by the processes to identify which system shared memory segments to 45use.</p> 46<p>For more information, see <a href="../../ref/env/region.html">Shared 47memory regions</a>.</p></ul> 48<b>The database files:</b><ul compact><li>By default, databases are periodically flushed from the Berkeley DB memory 49cache to backing physical files in the filesystem. To keep databases 50from being written to backing physical files, pass the 51<a href="../../api_c/memp_set_flags.html#DB_MPOOL_NOFILE">DB_MPOOL_NOFILE</a> flag to the <a href="../../api_c/memp_set_flags.html">DB_MPOOLFILE->set_flags</a> method. This flag 52implies the application's databases must fit entirely in the Berkeley DB 53cache, of course. To avoid a database file growing to consume the 54entire cache, applications can limit the size of individual databases 55in the cache by calling the <a href="../../api_c/memp_set_maxsize.html">DB_MPOOLFILE->set_maxsize</a> method.</ul> 56<b>The database environment log files:</b><ul compact><li>If a database environment is not intended to be transactionally 57recoverable after application or system failure (that is, if it will not 58exhibit the transactional attribute of "durability"), applications 59should not configure the database environment for logging or 60transactions, in which case no log files will be created. If the 61database environment is intended to be durable, log files must either 62be written to stable storage and recovered after application or system 63failure, or they must be replicated to other systems. 64<p>In applications running on systems without any form of stable storage, 65durability must be accomplished through replication. In this case, 66database environments should be configured to maintain database logs in 67memory, rather than in the filesystem, by specifying the 68<a href="../../api_c/env_log_set_config.html#DB_LOG_IN_MEMORY">DB_LOG_IN_MEMORY</a> flag to the <a href="../../api_c/env_set_flags.html">DB_ENV->set_flags</a> method.</p></ul> 69<br> 70<p>In systems where the filesystem is backed by Flash memory, the number 71of times the Flash memory is written may be a concern. Each of the 72three parts of the Berkeley DB database environment normally written to the 73filesystem can be configured to minimize the number of times the 74filesystem is written:</p> 75<br> 76<b>The database environment region files:</b><ul compact><li>On a Flash-based filesystem, the database environment should be placed 77in heap or system memory, as described previously.</ul> 78<b>The database files:</b><ul compact><li>The Berkeley DB library maintains a cache of database pages. The database 79pages are only written to backing physical files when the application 80checkpoints the database environment with the <a href="../../api_c/txn_checkpoint.html">DB_ENV->txn_checkpoint</a> method, 81when database handles are closed with the <a href="../../api_c/db_close.html">DB->close</a> method, or when 82the application explicitly flushes the cache with the <a href="../../api_c/db_sync.html">DB->sync</a> 83or <a href="../../api_c/memp_sync.html">DB_ENV->memp_sync</a> methods. 84<p>To avoid unnecessary writes of Flash memory due to checkpoints, 85applications should decrease the frequency of their checkpoints. This 86is especially important in applications which repeatedly modify a 87specific database page, as repeatedly writing a database page to the 88backing physical file will repeatedly update the same blocks of the 89filesystem.</p> 90<p>To avoid unnecessary writes of the filesystem due to closing a database 91handle, applications should specify the <a href="../../api_c/db_close.html#DB_NOSYNC">DB_NOSYNC</a> flag to the 92<a href="../../api_c/db_close.html">DB->close</a> method.</p> 93<p>To avoid unnecessary writes of the filesystem due to flushing the cache, 94applications should not explicitly flush the cache under normal 95conditions -- flushing the cache is rarely if ever needed in a 96normally-running application.</p></ul> 97<b>The database environment log files:</b><ul compact><li>The Berkeley DB log files do not repeatedly overwrite the same blocks of the 98filesystem as the Berkeley DB log files are not implemented as a circular 99buffer and log files are not re-used. For this reason, the Berkeley DB log 100files should not cause any difficulties for Flash memory configurations. 101<p>However, as Berkeley DB does not write log records in filesystem block sized 102pieces, it is probable that sequential transaction commits (each of 103which flush the log file to the backing filesystem), will write a block 104of Flash memory twice, as the last log record from the first commit will 105write the same block of Flash memory as the first log record from the 106second commit. Applications not requiring absolute durability should 107specify the <a href="../../api_c/env_set_flags.html#DB_TXN_WRITE_NOSYNC">DB_TXN_WRITE_NOSYNC</a> or <a href="../../api_c/env_set_flags.html#DB_TXN_NOSYNC">DB_TXN_NOSYNC</a> flags 108to the <a href="../../api_c/env_set_flags.html">DB_ENV->set_flags</a> method to avoid this overwrite of a block of 109Flash memory.</p></ul> 110<br> 111<table width="100%"><tr><td><br></td><td align=right><a href="../program/namespace.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../program/cache.html"><img src="../../images/next.gif" alt="Next"></a> 112</td></tr></table> 113<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 114</body> 115</html> 116
