1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
<! "@(#)env.so 10.15 (Sleepycat) 11/2/98">
<!Copyright 1997, 1998 by Sleepycat Software, Inc. All rights reserved.>
<html>
<body bgcolor=white>
<head>
<title>Berkeley DB Reference Guide: Architecture</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btr
ee,hash,hashing,transaction,transactions,locking,logging,access method,access me
thods,java,C,C++">
</head>
<h3>Berkeley DB Reference Guide: Architecture</h3>
<p>
<h1 align=center>Environment</h1>
<p>
The Berkeley DB environment is the encapsulation of the five Berkeley DB
subsystems, a collection of related applications, and the databases
accessed by those applications.
The applications we will be describing here are
similar to the Access Method applications
previously described in the Reference Guide, but they are also fully
recoverable
in the face of application or system failure. The Berkeley DB application
environment is created and described by the <a href="../../api_c/DbEnv/appinit.html">db_appinit</a> interface.
This interface creates a consistent naming scheme for all of the
subsystems sharing the environment.
<p>
It is important to realize that all applications sharing a single home
directory implicitly trust each other. They have access to each other's
data as it resides in the shared memory buffer pool and will share
resources such as buffer space and locks. At the same time, any
applications that access the same files <b>must</b> share an environment
if consistency is to be maintained across the different applications.
<p>
The simplest way to administer a Berkeley DB application environment is to
create a single <b>home</b> directory that stores the files for the
applications that will share the environment. The environment can then be
identified by the name of that directory. The environment may be shared
by any number of applications as well as by any number of threads within
the applications.
<p>
Note that it is possible for an environment to include resources from
other directories on the system, and applications often choose to
distribute resources to other directories or disks for performance or
other reasons. However, by default, the shared memory regions (i.e., the
locking, logging, memory pool, and transaction regions) and log files will
be stored in the specified directory hierarchy. In situations where
further customization is desired, such as placing the log files on a
separate device, it is recommended that the application installation
process create a configuration file named <b>DB_CONFIG</b> in the
database home directory, specifying the customization. See
<a href="../../api_c/DbEnv/appinit.html">db_appinit</a> for details on this procedure.
<p>
Once an environment has been created, database files specified using
relative pathnames will be named relative to the home directory. When
recovery needs to be run (e.g., after system or application failure), this
directory is specified as the home directory to <a href="../../utility/db_recover.html">db_recover</a> and
the system is restored to a consistent state, ready for the applications
to be restarted. Note that the use of pathnames relative to the home directory
is encouraged, so that the entire environment can be moved to facilitate
restoring and recovering a database in a different directory or even on
a different system.
<p>
When transactions have been configured for the environment, the
checkpoint daemon, <a href="../../utility/db_checkpoint.html">db_checkpoint</a>, must be run as long as there
are applications present. When locking is being used, the deadlock
detection daemon, <a href="../../utility/db_deadlock.html">db_deadlock</a>, must be run as long as there are
applications present. The <a href="../../utility/db_archive.html">db_archive</a> utility provides information
to facilitate log reclamation and creation of database snapshots. After
application or system failure, the <a href="../../utility/db_recover.html">db_recover</a>, utility must be
run before any applications are restarted to return the database to a
consistent state.
<p>
Finally, Berkeley DB applications that run with additional privileges should
<b>always</b> call the <a href="../../api_c/DbEnv/appinit.html">db_appinit</a> function to initialize naming
for their application. This ensures that the environment variables
<a href="../../ref/env/naming.html#DB_HOME">DB_HOME</a> and <a href="../../ref/env/naming.html#TMPDIR">TMPDIR</a> will be used only if the application
explicitly specifies that they are safe.
<p>
<a href="../../ref/arch/bigpic.html"><img src="../../images/prev.gif"></a>
<a href="../../ref/toc.html"><img src="../../images/toc.gif"></a>
<a href="../../ref/arch/subsystem.html"><img src="../../images/next.gif"></a>
</tt>
</body>
</html>
|
