mu_ch3.htm

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

managers for any practical number of users is not typically
significant.</font></p>
<p>The TCP and UNIX domain socket lock managers consume file
descriptors on a one per user basis plus a fixed overhead. For
safety and simplicity, a reasonable estimation for the number of
file descriptors needed is ten plus the number of users. Most
UNIX/Linux platforms have a per process open file descriptor limit
configured into and enforced by the kernel. On many of these
systems, there is both a soft limit that is set lower by default
than the hard limit enforced by the kernel. Where an API is
available, these lock managers attempt to set the soft limit to the
hard limit to avoid problems. Increasing the hard limit involves
reconfiguring the kernel. Some systems (mostly SVR4) have a kernel
configuration file that is read at boot time to set soft and hard
limit parameters. On other systems such as BSD UNIX variants, the
normal procedure involves editing a configuration file and
rebuilding the kernel. In any case, the procedures are highly
system dependent and have potential to cause serious harm to the
system (for example, the system will no longer boot) if carried out
incorrectly. Carefully read your relevant system administration
documentation before attempting any such procedure.</p>
<p>On systems that implement the System V IPC primitives in the
kernel, modifying these parameters involves reconfiguring the
kernel as discussed above. On systems in which the System V IPC
system does not involve the kernel, there will be a different means
of setting these parameters unless they happen to only be
constrained by other resource limits. Again, consult your relevant
system administration documentation carefully before attempting to
make any changes.</p>
<h3><a name="Naming" id="Naming"></a>3.3.7 Lock Manager Naming</h3>
<h4>Setting Lock Manager Names</h4>
<p><font size="2">When not using the default lock manager name (see
below for specific cases), the name of a lock manager is most
typically specified using the <b>-a</b> command line switch when
starting the lock manager. However it can also be set via the
LOCKMGR environment variable. The name of the lock manager being
used by an application can be set using the <b>d_lockmgr</b> API
call, the LOCKMGR environment variable, or the <b>db.star.ini</b>
file.</font></p>
<h4>Local Lock Managers</h4>
<p><font size="2">Naming local lock managers is quite simple. The
UNIX domain socket lock manager has the default name of "lockmgr".
When using only one lock manager of given type on a system, no
complications arise from using the default and you avoid the
necessity of setting the lock manager name for both the lock
manager and lock manager clients. When using multiple lock managers
on the same system, it is necessary to set the appropriate names as
described above (although one lock manager can continue to use the
default name if desired).</font></p>
<h4>TCP Lock Manager</h4>
<p><font size="2">Naming for the TCP lock manager is more
complicated than for any of the others, partly because of its
inclusion of the UNIX domain lock manager functionality. As with
the other UNIX lock managers the default name is "lockmgr". This
works perfectly provided only local connections are used. This
limited case is equivalent to using the UNIX domain socket lock
manager, and the same naming considerations apply.</font></p>
<p>However, to obtain a network (TCP) connection to the lock
manager it is necessary to identify the lock manager's host and
(either implicitly or explicitly) the port on which it is
listening. You can implicitly specify the port by putting a
"db.star tcp" port specification in each system's
<b>/etc/services</b> file, or in a network NIS services map, or by
allowing it to default to 1523.</p>
<p>A complete explicit TCP lock manager name for a TCP connection
is of the form <b><i>hostname:port</i></b> where
<b><i>hostname</i></b> is either a host's primary name, an alias
registered in <b>/etc/hosts</b>, in NIS host maps, or with DNS
(some of which will not be available on many systems), or an IP
address. See the following list for an example:</p>
<table border="1" cellspacing="1" cellpadding="7" width="542">
<tr>
<td width="56%" valign="top">
<p><font size="2">IP address:port</font></p>
</td>
<td width="44%" valign="top">
<p><font face="Courier" size="2">192.0.1.205:1523</font></p>
</td>
</tr>
<tr>
<td width="56%" valign="top">
<p><font size="2">hostname:port</font></p>
</td>
<td width="44%" valign="top">
<p><font face="Courier" size="2">db.star:1611</font></p>
</td>
</tr>
<tr>
<td width="56%" valign="top">
<p><font size="2">hostname:port</font></p>
</td>
<td width="44%" valign="top">
<p><font face="Courier" size="2">db.star.domain.com:1611</font></p>
</td>
</tr>
<tr>
<td width="56%" valign="top">
<p><font size="2">IP address (implicit port)</font></p>
</td>
<td width="44%" valign="top">
<p><font face="Courier" size="2">192.0.1.204</font></p>
</td>
</tr>
<tr>
<td width="56%" valign="top">
<p><font size="2">hostname (implicit port)</font></p>
</td>
<td width="44%" valign="top">
<p><font face="Courier" size="2">db.star</font></p>
</td>
</tr>
<tr>
<td width="56%" valign="top">
<p><font size="2">hostname (implicit port)</font></p>
</td>
<td width="44%" valign="top">
<p><font face="Courier" size="2">db.star.domain.com</font></p>
</td>
</tr>
<tr>
<td width="56%" valign="top">
<p><font size="2">local name (for UNIX domain sockets
only)</font></p>
</td>
<td width="44%" valign="top">
<p><font face="Courier" size="2">lockmgr2</font></p>
</td>
</tr>
</table>
<p><font size="2">As a result of these considerations, the default
name "lockmgr" can only work for TCP connections if the lock
manager port is specified implicitly, and the host it is on has a
primary name or alias of "lockmgr". However, note that it is still
possible to mix TCP and UNIX domain socket connections in the same
lock manager. Simply choose your name by taking TCP considerations
into account and then using the <i>hostname</i> part of the name as
the lock manager name for local clients. See the following as an
example:</font></p>
<pre>
<font color="#0000FF">lm -mt -a wlw:1550
setenv LOCKMGR wlw
ida -mt</font>
</pre>
<p><font size="2">If you specify a name in <b>hostname:port</b>
format, even if the lock manager is local, a TCP connection will be
established. Finally, keep in mind that the UNIX domain lock
manager and the UNIX domain socket part of the TCP lock managers
share the same name space on the local system.</font></p>
<p>While any of the formats described above will work, you cannot
mix them. If you do, you will get a S_TAFSYNC TAF synchronization
error, because lock manager names written to the TAF files will not
match. Choose one representation for the lock manager name and
stick with it.</p>
<p>More than one TCP lock manager can be run from the same host
provided that both the name <i>and</i> the port are unique. For
example, two lock managers named <b>lockmgr:1523</b> and
<b>lockmgr2:1523</b> cannot be run on the same host, nor can
<b>wlw:1523</b> and <b>wlw:1524</b>. You must set up one or more
host aliases to obtain the distinct <i>hostname</i> components of
the lock manager names.</p>
<h3><a name="Filesystems" id="Filesystems"></a>3.3.8 NFS
Filesystems</h3>
<p><font size="2">The TCP lock manager relies on file identifiers
generated by the runtime of the form <i>fsname@hostname</i> plus
the <b>i-node</b>. The <b>fsname</b> is the absolute path of a
mount point and <i>hostname</i> is the server name or alias for
that mount point as extracted from the local mounted filesystem
table. The <b>i-node</b> parameter is the <b>i-node</b>. Creating
alternate paths to the mount point or individual files using
symbolic links can also confuse the TCP lock manager and lead to
data corruption. For example, an NFS host named <b>ufs2</b> may
have a database stored in a directory named
<b>/Centura/shared/db/tims</b>, with one of the files named
<b>tims.d01</b> at an i-node of 34453. An NFS client may have that
directory mounted as <b>/db/tims</b>. The runtime library will
construct the following canonical identifier for the
file:</font></p>
<pre>
<font color="#0000FF">/Centura/shared/db/tims@ufs2:34453 </font>
</pre>
<p><font size="2">This identifier will be the same from other
workstations that may have the database drive mounted on a
different local path.</font></p>
<p>Databases accessed by <b><i>db.*</i></b> that are kept on NFS
file systems are more susceptible to data loss and corruption than
files kept on a local disk because of the extra levels of caching
involved. If an NFS client system crashes (on most UNIX systems
this happens rarely if ever) or suffers a power loss, data updates
in its local cache that were not written back to the file server
will be lost. <b><i>db.*</i></b> provides the SYNCFILE option to
help address this problem. The SYNCFILES option causes a cache
synchronization operation to be carried out after every write
operation (usually by the <b>fsync()</b> function call). On a few
older NFS file systems, this operation may not work reliably. This
option has an impact on database performance, and should be used
only when there is a possibility of losing important data.</p>
<h2><a name="FileIssues" id="FileIssues"></a>3.4 TAF File Issues on
UNIX/Linux</h2>
<p><font size="2">As discussed elsewhere in this manual, lock
managers are not involved in the locking of the TAF file. Instead
this task is handled strictly by the runtime library
code.</font></p>
<p><font size="2">On UNIX, the default method for locking the TAF
file is the UNIX OS <b>lockf()</b> function. On Linux,
<b>flock()</b> is used. Its functionality is primarily provided by
a daemon <b>rpc.lockd</b>, which runs on the file server. Thus,
this function is capable of handling lock requests from
applications on multiple machines for the same file shared via a
network file system. As such, it is fully capable of working with
applications using the <b><i>db.*</i></b> network locking approach
as implemented by the TCP lock manager. Historically, there have
been significant correctness and reliability problems with
<b>lockf()</b> and specifically <b>rpc.lockd</b>. In recent years
these problems have largely been corrected. However, source
customers still have the option of compiling the runtime to use the
predecessor to <b>lockf()</b>, the <b>flock()</b> function<b>.</b>
The locks for <b>flock()</b> are only visible on the local machine,
but it has the advantage of being faster than <b>lockf()</b>
(usually ) and not having the correctness problems seen in older
versions of <b>lockf()</b>. Be aware, however, that UNIX is phasing
out <b>flock()</b> and the function is already not available on
some platforms.</font></p>
<p><font size="2">An alternate method of locking the TAF file that
is not dependent on OS functions (that may have bugs or are not
available) is the "portable locking" option. This option is
implemented using a "guard file" strategy, and the code is enabled
by calling the function <b>d_on_opt</b> with the PORTABLE constant.
To lock the TAF file, a process will attempt to delete a file named
<b>db.star.lfg</b>, which serves as the guard file. If the
<b>unlink</b> succeeds, then the TAF file is considered locked by
that process. If the <b>unlink</b> fails, the lock is not granted
and the process will sleep for one second and try again. The
process that does succeed will re-create <b>db.star.lfg</b> after
accessing the TAF file. When using this portable locking method it
may be necessary to create <b>db.star.lfg</b> before any processes
begin execution. If <b>db.star.taf</b> does not exist,
<b><i>db.*</i></b> automatically creates both it and
<b>db.star.lfg</b>.</font></p>
<p><a href="MU_Ch4.htm">Next Page</a></p>
</body>
</html>