,I7Berkeley DB Reference Guide: Environment[P1

Berkeley DB Reference Guide: Environment



-

Creating an Environment



jThe db_appinit function is the standard function for creating"or joining a database environment.DEvery transaction-protected or multi-process application should callqdb_appinit before making any other calls to the Berkeley DB library.

nThere are several flags that you can set to customize db_appinit:

DB_CREATE
Create underlying files as necessary. This flag is normally specifiedIby applications that have the right to create the region and not by those1that simply want to join it if it already exists.–

DB_INIT_LOCK
Applications reading and writing databases opened in this environmentGwill be using locking to ensure that they do not overwrite each other'schanges.”

DB_INIT_LOG
Applications reading and writing databases opened in this environmentwill be using logging.™

DB_INIT_MPOOL
The databases opened in the environment should use a shared underlying memory pool.”

DB_INIT_TXN
Applications reading and writing databases opened in this environmentmay be using transactions.•

DB_MPOOL_PRIVATE
Create a private memory pool, not shared by other processes.K

DB_NOMMAP
IFiles that are opened read-only in the pool (and that satisfy a few otherHcriteria) are, by default, mapped into the process address space insteadFof being copied into the local cache. This can enhance performance orHdegrade it, depending on the architecture where it is done. Setting the}DB_NOMMAP flag causes Berkeley DB to never map such files into memory,Kinstead, they are read into the cache using the standard read system calls.–

DB_RECOVER
Run normal recovery on this environment before opening it for normal use.LNormal recovery is sufficient to handle most application or system failures.œ

DB_RECOVER_FATAL
Run catastrophic recovery on this environment before opening it forInormal use. Catastrophic recovery is necessary when restoring a databasefrom an archive.‘

DB_THREAD
Ensure that handles returned by the Berkeley DB subsystems are useableEby multiple threads within a single process, i.e., that the system isfree-threaded.™

DB_TXN_NOSYNC
On transaction commit, do not synchronously flush the log. This meansLthat Berkeley DB will provide atomicity, consistency, and isolation for yourKtransactions, but not durability. Upon recovery, some previously committedLtransactions may be lost, but your database will be restored to a consistentstate.†

DB_USE_ENVIRON
Use environment variables as part of file naming.ž

DB_USE_ENVIRON_ROOT
Use environment variables as part of file naming for users withappropriate privileges.


xAlmost all applications either specify only the DB_INIT_MPOOLnflag or they specify all four flags, DB_INIT_MPOOLDB_INIT_LOCK, DB_INIT_LOG and DB_INIT_TXN.HThe former configuration is for applications that simply want to use theHbasic Access Method interfaces with a shared underlying buffer pool, butAdon't care about recoverability after failure. The latter is forHapplications that need recoverability. There are situations where otherGcombinations of the initialization flags make sense, but they are quiterare.

uThe flag DB_RECOVER is specified by applications that want toIperform any necessary database recovery when they start running, i.e., ifFthere was a system or application failure the last time they ran, theyIwant the databases to be made consistent before they start running again.E(It is not an error to specify this flag when no recovery needs to be|done.) The flag DB_RECOVER_FATAL is more special-purpose. ItHperforms catastrophic database recovery, and normally requires that someFinitial arrangements be made, i.e., archived log files be brought backIinto the filesystem. Applications should not normally specify this flag.hInstead, under these rare conditions, the db_recover utilityshould be used.

MAGÿÿ