ug_ch5a.htm

来自「db.* (pronounced dee-be star) is an adva」· HTM 代码 · 共 1,565 行 · 第 1/4 页

</td>
<td width="21%" valign="top">
<p><font size="2"><b>d_dbfpath</b></font></p>
</td>
<td width="51%" valign="top">
<p><font size="2">Set path to directory containing the database
files.</font></p>
</td>
</tr>
<tr>
<td width="28%" valign="top">
<p><font size="2">DBLOG</font></p>
</td>
<td width="21%" valign="top">
<p><font size="2"><b>d_dblog</b></font></p>
</td>
<td width="51%" valign="top">
<p><font size="2">Set path or name of database log file.</font></p>
</td>
</tr>
<tr>
<td width="28%" valign="top">
<p><font size="2">DBTAF</font></p>
</td>
<td width="21%" valign="top">
<p><font size="2"><b>d_dbtaf</b></font></p>
</td>
<td width="51%" valign="top">
<p><font size="2">Set path or name of database family transaction
activity file.</font></p>
</td>
</tr>
<tr>
<td width="28%" valign="top">
<p><font size="2">LOCKMGR</font></p>
</td>
<td width="21%" valign="top">
<p><font size="2"><b>d_lockmgr</b></font></p>
</td>
<td width="51%" valign="top">
<p><font size="2">Set the name of the lock manager to be used by
this application.</font></p>
</td>
</tr>
</table>
<h4><a name="Substituting" id="Substituting"></a>Substituting
Database Files</h4>
<p><font size="2">Alternate names for data and key files can be
specified at runtime, prior to opening a database, through use of
the <b>d_renfile</b> function. In order to use this function,
however, a file identifier must be provided in the DDL data and key
file statements for those files that are to be renamed. The DDL
file statement syntax including the specification of a file
identifier is as follows:</font></p>
<p><b>data file</b> [<i>fileid</i> =] <i>filename</i>
<b>contains</b> <i>recname</i> [,<i>recname</i>]... ;<br>
<b>key file</b> [<i>fileid</i> =] <i>filename</i> <b>contains</b>
<i>recname</i> [,<i>recname</i>]... ;</p>
<p>If provided, <i>fileid</i> must be an identifier. It will be
included in <b>dbname.h</b> as a <b>#define</b> constant that is
defined to be the file table dictionary entry number for the
specified data or key file.</p>
<p>See the example below:</p>
<pre>
<font color="#0000FF">database tims {&lt;
   data file timsdat = "tims.dat" contains ...;
   key  file timskey = "tims.key" contains ...;
   ...
</font>
</pre>
<p><font size="2">File <b>tims.h</b> would include the following
constants:</font></p>
<pre>
<font color="#0000FF">#define   TIMSDAT 0
#define   TIMSKEY 1
</font>
</pre>
<p><font size="2">Function <b>d_renfile</b> could then be used to
substitute the files as follows:</font></p>
<pre>
<font color=
"#0000FF">d_renfile("tims", TIMSDAT, "ittia.dat", task);
d_renfile("tims", TIMSKEY, "ittia.key", task);
d_open("tims","x", task);
</font>
</pre>
<p><font size="2">The calls to <b>d_renfile</b> must be issued
prior to the call to <b>d_open</b> of database <b>tims</b>. The
name of the database needs to be specified in the <b>d_renfile</b>
call, to distinguish between files contained in different databases
if more than one is opened.</font></p>
<blockquote>Note<b><i>:</i></b> When <b>d_open</b> is locating the
database files, the database file specification provided in the
<b>d_renfile</b> call overrides the environment variable (DBFPATH)
and any path prefix to the database name. The dictionary and
control file specifications are unaffected.</blockquote>
<p><font size="2">The <b>d_renfile</b> function has a companion
function, <b>d_renclean</b>. Function <b>d_renclean</b> can only be
called while all databases are closed, and will clean up all memory
and references used by <b>d_renfile</b>. This allows switching back
and forth between databases as seen in the following example. In
this example, there are two copies of the data files, one copy that
is shared by everyone on the network (drive <b>s:</b>) and the
other one on the users hard drive (drive <b>c:</b>).</font></p>
<pre>
<font color="#0000FF">d_open("tims", "s", task);

/* ... normal processing on network copy ... */

d_close(task);
d_renfile("tims", TIMSDAT, " /tims/tims.dat", task);
d_renfile("tims", TIMSKEY, " /tims/tims.key", task);
d_open("tims", "o", task);

/* ... processing on the local copy ... */

d_close(task);

/* clean up all memory from previous d_renfile functions. */
d_renclean(task);
d_open("tims", "s", task);

/* ... back to processing on the network copy ... */

d_close(task);
</font>
</pre>
<h3><a name="Dynamic" id="Dynamic"></a>5.2.3 Dynamic Database
Initialization</h3>
<p><font size="2">Dynamic database initialization functions allow a
program to initialize an entire database, or one or more files, in
a database at program execution time. These functions are useful
when a first-time initialization needs to be included as part of an
application or when a temporary database is needed.</font></p>
<blockquote>Note: These functions will destroy existing data. They
are not part of a normal database open sequence.</blockquote>
<p><font size="2">Function <b>d_initialize</b> will initialize all
database data and key files associated with the open database. In
multi-user environments, it can only be called when the database is
opened in exclusive access mode or exclusive locks have been placed
on all the files. Function <b>d_destroy</b> is called to close the
database and to delete all of the database files comprising the
open database.</font></p>
<blockquote>Note: If <b>d_renfile</b> has been called,
<b>d_destroy</b> will remove the new file names and leave the
original ones untouched.</blockquote>
<p><font size="2">Individual files that have a <i>fileid</i>
specified in the DDL file statement can be initialized using
function <b>d_initfile</b>. For example, the following DDL defines
files that keep track of a daily user login history:</font></p>
<pre>
<font color=
"#0000FF">data file day_data = "dayfile.dat" contains login_history;
key file day_key = "dayfile.key" contains login_id;
</font>
</pre>
<p><font size="2">These files are initialized by the application
when the user logs in at the beginning of the day, as
follows:</font></p>
<pre>
<font color="#0000FF">#include "db.star.h"
#include "login.h"
#include "mis.h"
DB_TASK *task;
...
/* Open Login and Mgt Info System databases */
d_opentask(&amp;task);
d_open("login;mis", "s", task);

/*   Since each user has his own login file, an 
   exclusive lock on that file will preclude the use of
   other locks and yield better performance. */
d_reclock(LOGIN_HISTORY, "x", task, CURR_DB);

/* Initialize daily login files */
d_initfile(DAY_KEY, task, CURR_DB);
d_initfile(DAY_DATA, task, CURR_DB);

...
</font>
</pre>
<h3><a name="Runtime" id="Runtime"></a>5.2.4 Runtime Control</h3>
<p><font size="2">Runtime control functions inform the
<b><i>db.*</i></b> runtime of the maximum number of files that can
be opened at a time and the size of the database cache, and are
used to turn on or off one or more of several runtime options.
These functions provide the flexibility to tune runtime performance
to meet the requirements of individual applications.</font></p>
<h4><a name="Maximum" id="Maximum"></a>Maximum Open Files</h4>
<p><font size="2">Many operating systems impose a limitation on the
number of files that an application program can have open at one
time. UNIX/Linux may have an upper limit of open files. Many
database management systems restrict the maximum number of files in
a database to this operating system limit, but <b><i>db.*</i></b>
allows up to 32,767 files to be accessed in a single database. This
is done by dynamically opening and closing files as necessary to
keep the number of open files within the operating system's
limit.</font></p>
<p>Before the database is opened, the program must inform
<b><i>db.*</i></b> of the maximum number of data and key file
handles it can have open at a time. This is accomplished with
function <b>d_setfiles</b>, which is passed an integer value
specifying this maximum. Function <b>d_setfiles</b> must be called
before the database is opened, and the value passed must be less
than or equal to the operating system limit, minus the maximum
number of additional files the application will have open at a
time. The default is a maximum of eight open files at a time.</p>
<p>For example, normally a standard C program will have (at least)
three files open upon initiation: <b>stdin</b>, <b>stdout</b>, and
<b>stderr</b>. If the operating system limit is 100, then the
following call will ensure that <b><i>db.*</i></b> will not open
too many files:</p>
<pre>
<font color=
"#0000FF">d_setfiles(90, task);        /* db.* can open 90 files */
d_open("tims", "o", task); /* Open database "tims" */
</font>
</pre>
<p><font size="2">Setting the number of open files too small may
result in some performance degradation due to unnecessary file
closings and openings.</font></p>
<p>If there are occasions when the application needs more file
handles than are available, it is possible to tell the runtime to
close all files it currently holds open. The <b>d_closeall</b>
function will close all files under <b><i>db.*</i></b> control that
are currently open. The files will be re-opened as needed. If this
function is used frequently, overall performance will decrease due
to the extra opening and closing of files.</p>
<h4><a name="Cache" id="Cache"></a>Size of Runtime Cache</h4>
<p><b><i><font size="2">db.*</font></i> performs all input and
output for the database files through a</b> <font size="2">cache
consisting of a fixed number of database page buffers. This
technique yields large performance benefits by reducing the number
of actual disk accesses required to read or write information in
the database.</font></p>
<p>The programmer can specify the number of buffers to allocate for
the cache with function <b>d_setpages</b>. In general, the more
pages specified the better the potential performance gains. The
first argument to this function specifies the number of pages in
the standard database cache. A second argument specifies the number
of pages in the transaction overflow-index cache (which should be
small because an overflow should occur infrequently).</p>
<p>If <b>d_setpages</b> is not called, <b><i>db.*</i></b> will
allocate 100 pages in the database cache and five pages in the
transaction overflow cache. The cache lookups are performed using a
hashing algorithm, as shown below:</p>
<pre>
<font color="#0000FF">d_setpages(200, 4, task);
</font>
</pre>
<p><font size="2">The initial size of the pages allocated for the
database cache will be equal to the size of the largest page in the
database. Thus, if the largest page is 4096 bytes long, then the
database cache in the above example will occupy 524K bytes (128 *
4096). The size of the pages in the overflow cache is fixed at 1024
bytes. If there is not enough memory available to accommodate the
requested number of pages, function <b>d_open</b> will return
status S_NOMEMORY.</font></p>
<h4><a name="Settings" id="Settings"></a>Option Settings</h4>
<p><font size="2">Various runtime option settings allow you to do
these activities plus others:</font></p>
<ul>
<li>Turn on or off the use of delete chain slots (for when new
records are created)</li>
<li>Turn on or off transaction logging and recovery</li>
<li>Turn on or off archive logging</li>
<li>Change between case-insensitive and case-sensitive sorting</li>
<li>Dictate how often to close files</li>
</ul>
<p>Rather than supplying separate functions to control the setting
of these runtime options, <b><i>db.*</i></b> provides two
parameter-based system option setting functions called
<b>d_on_opt</b> and <b>d_off_opt</b>. These functions are passed a
bit status word, which has a bit associated with each option. These
options have been assigned constants in <b>db.star.h</b>. See the
<b><i>db.*</i></b> <i>Reference Manual</i> for a complete list.</p>
<p>Here are some examples. To turn on delete chain usage and
archive logging:</p>
<pre>
<font color="#0000FF">d_on_opt(DBCHAINUSE | ARCLOGGING, task);
</font>
</pre>
<p><font size="2">To turn off transaction logging and archive
logging:</font></p>
<pre>
<font color="#0000FF">d_off_opt(TRLOGGING | ARCLOGGING, task);
</font>
</pre>
<p><font size="2">Transaction and archive logging are discussed in
Chapter 6, "Transaction Processing."</font></p>
<p>The ability to turn on or off the use of deleted record slots
provides some application control over the placement of related
records in the database. If all member record occurrences of a
given set are entered together, and use of the delete chain is
turned off, the records will all be physically placed in the order
in which they're entered at the end of the data file. This will
improve performance when, later, they are all accessed
together.</p>
<p>To establish case-insensitive sorting with keys:</p>
<pre>
<font color="#0000FF">d_on_opt(IGNORECASE, task);
</font>
</pre>
<p><font size="2">This option will re-define the collating sequence
of characters, and must be used for the lifetime of a database. You
cannot build a database with this option turned on, then later use
it with it turned off.</font></p>
<p>The default settings have transaction logging and delete chain
use turned <i>on</i>, and archive logging and case-insensitive
sorting turned <i>off</i>.</p>
<h2><a name="Currency" id="Currency"></a>5.3 Currency Tables</h2>
<p><font size="2">All of the data contained in a <b><i>db.*</i></b>
database is accessed through use of the currency tables. Thus, a
thorough understanding of the use of these tables is
necessary.</font></p>
<p>The retrieval of <b><i>db.*</i></b> data is always a two-step
process. First the location of the data is established, and then
the data is read. The located data is always in the form of a
specific record occurrence. The database address of a record is the
location in the database where the record is stored. The currency
tables contain database addresses as follows:</p>
<table cellspacing="0" border="0" cellpadding="7" width="542">
<tr>
<td width="22%" valign="top">
<p><i><font size="2">current record</font></i></p>
</td>
<td width="78%" valign="top">
<p><font size="2">The database address of the most recently
accessed record occurrence.</font></p>
</td>
</tr>
<tr>
<td width="22%" valign="top">
<p><i><font size="2">current owner</font></i></p>
</td>
<td width="78%" valign="top">
<p><font size="2">The database address of an owner record
occurrence for the set. There is a current owner entry for each set
in the database.</font></p>
</td>
</tr>
<tr>
<td width="22%" valign="top">
<p><i><font size="2">current member</font></i></p>
</td>
<td width="78%" valign="top">
<p><font size="2">The database address of a member record
occurrence for the set. There is a current member entry for each
set in the database.</font></p>
</td>
</tr>
</table>
<p><font size="2">A currency table value is established through the
record location functions (for example, <b>d_keyfind</b> or
<b>d_findnm</b>), and through additional functions that directly
modify currency table entries (for example, <b>d_setor</b> copies
the <i>current record</i> value to the <i>current owner</i> entry
of the specified set). Once a record has been located, its database
address is automatically stored in the currency table. Its contents
can then be read (for example, <b>d_recread</b> reads the contents
of the <i>current record</i>).</font></p>
<p>Locating record occurrences through set relationships directly
involves manipulation of the currency tables. This process is
called set navigation. The currency tables are used to keep track
of the path through the network of set relationships that was
followed to arrive at a particular record occurrence.</p>
<p>A portion of the <b>tims</b> database schema is given in Figure
5-1, with an example of a possible currency table state showing
pointers to particular record occurrences in the database.</p>
<p align="center">&nbsp;</p>
<p align="center"><img alt="Example Currency Table" border="0"
height="371" src="dbstar_5-1.gif" width="466"></p>
<p align="center">Fig. 5-1. Example Currency Table</p>
<p>Because of the importance of the currency tables, a rich set of
functions is provided to give the programmer complete control over
currency table settings. These functions are listed in Table 5-3.
The <b>d_setXY</b> functions have a naming convention in which
<b>X</b> specifies the destination currency and <b>Y</b> specifies
the source currency for the assignment operation. For example, in
<b>d_setro</b>, the <b>r</b> indicates that the current record is
to be assigned and the <b>o</b> indicates that it is to be assigned
from the current owner of the specified set. Use of the currency
tables will be explained in the sections which follow.</p>
<p align="center"><b>Table 5-3 Currency Control Functions</b></p>
<table cellspacing="0" border="0" cellpadding="7" width="542">
<tr>
<td valign="top" colspan="2">
<p><font size="2"><b>Currency Manipulation Functions</b></font></p>
</td>
</tr>
<tr>
<td width="40%" valign="top">