mu_ch3.htm
来自「db.* (pronounced dee-be star) is an adva」· HTM 代码 · 共 484 行 · 第 1/2 页
HTM
484 行
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta name="generator" content="HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org"><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><meta name="Generator" content="Microsoft Word 97"><title>db.* Multi-User Guide Chapter 3</title></head><body><h1><a name="Issues" id="Issues"></a>Chapter 3<br>Platform Issues</h1><h2><a name="Introduction" id="Introduction"></a>3.1Introduction</h2><p><font size="2">The <b><i>db.*</i></b> product currently runs onthe following variations of the Linux platform: Red Hat 6.1, RedHat eCos, Caldera, and Suse 6.3. The beginning of this chapterdiscusses the Linux operating system. The final section of thischapter describes the various lock managers, their characteristics,and the effect each may have on your application.</font></p><h2><a name="Notes" id="Notes"></a>3.2 Operating System Notes</h2><h4>SYNCFILES</h4><p><font size="2">When a transaction is completed,<b><i>db.*</i></b> must ensure that all the database changes havebeen physically written to disk before returning back to theapplication. Provided that the <b><i>db.*</i></b> runtime optionSYNCFILES is enabled (the default), files will be committed to diskat the proper time using the <b>fsync</b> function<b>.</b> Thisensures that, by the time <b><i>db.*</i></b> begins updating thedata and key files in a transaction, the log file is committed todisk. Likewise, when <b><i>db.*</i></b> has finished writing to thedata and key files, it will commit these to disk.</font></p><h4>PORTABLE</h4><p><font size="2">A <b><i>db.*</i></b> application accesses the TAFfile frequently. Therefore, in a multi-user environment, severalapplications may potentially be accessing the TAF filesimultaneously. To prevent corruption of the TAF file,<b><i>db.*</i></b> uses a form of file locking to serialize access(not the same mechanism as used by data and key file locks). Thelock manager is not used. <b><i>db.*</i></b>, by default, usesoperating system file locks instead.</font></p><p>Some systems fail to provide any form of file locking.<b><i>db.*</i></b> therefore provides an alternative, portablelocking mechanism for the TAF file, which uses a "guard file" toindicate whether the TAF file is locked. As long as the guard fileexists, the TAF file is not locked. If the guard file does notexist, then the TAF file is locked. This mechanism can be switchedon by calling <b>d_on_opt(PORTABLE)</b> or by adding "portable=1"to the [db.star] section of <b>db.star.ini</b>. The <b>PORTABLE</b>option also applies to the DBL file, if you are using the Generallock manager.</p><blockquote>Note: db.* applications using the same TAF file mustall use the same mechanism to lock the TAF file.</blockquote><h4>Lock Manager Network Timeout</h4><p><font size="2">Communications between the <b><i>db.*</i></b>runtime and the lock manager always take the form of a request sentby the runtime, followed by a reply sent by the lock manager. Everytime the runtime sends a message to the lock manager the runtimeblocks until a reply is received. However, in the event of acommunication failure at the transport level, a reply from the lockmanager may never be received.</font></p><p>The number of seconds <b><i>db.*</i></b> waits before returninga timeout error can be controlled by adding an entry to the<b>db.star.ini</b> file in the lock manager section. See below.</p><pre><font color="#0000FF">[LOCKMGR]net_timeout=45</font></pre><p><font size="2">The default value is 30 seconds. Once a networktimeout error has occurred, the <b><i>db.*</i></b> runtime assumesthe connection to the lock manager is lost, so you will have toclose the database. Thus you should choose a timeout value longenough to ensure that timeouts do not occur during routineoperation.</font></p><p>Do not confuse the network timeout with the lock timeout,described in Chapter 7 of the <b><i>db.*</i> User's Guide</b>,which determines the number of seconds the lock manager waitsbefore denying a lock request for files that are already locked byanother user. The network timeout should always be set to a valuelonger than the lock timeout; if the network timeout is not longer,<b><i>db.*</i></b> will automatically increase it.</p><p>Note that you can set both network and lock timeout values inthe <b>db.star.ini</b> file. See below.</p><pre><font color="#0000FF">[LOCKMGR]timeout=<seconds>;lock timeout, default 10 seconds<br>net_timeout=<seconds>;network timeout, default 30 seconds</font></pre><h2><a name="Managers" id="Managers"></a>3.3 UNIX and Linux LockManagers</h2><h3><a name="Manager" id="Manager"></a>3.3.1 Choosing a LockManager</h3><p><font size="2">The first consideration for choosing a lockmanager is whether it is available on your OS and OS configuration.The UNIX domain socket lock manager is only available on UNIX/Linuxplatforms that support this socket type (including most UNIXvariants with the exception of a few older versions). The TCP lockmanager is available on all UNIX/Linux variants.</font></p><p>The next consideration is whether you require a local or networklock manager. A local lock manager can only service clients on thesame system as the lock manager and will almost always havesignificantly better performance than network lock managers.Network lock managers are necessary when a database is shared overa network file system and the client applications may be ondifferent machines. Note that in the case of network lock managersnone, some, or all clients may be on the same machine as the lockmanager. However, if all clients are on the same machine, a locallock manager is normally preferable.</p><p>The UNIX domain socket lock manager is local and the TCP lockmanager is network. The local/network distinction is blurred by theTCP lock manager, which can (and by default does) use UNIX domainsockets for local connections to provide local communication speedwhere possible while still supporting network connections.Additional configuration, performance, and reliability issues arisewhen using a network lock manager with client applications on aremote machine.</p><p>If the above considerations do not conclusively determine whichlock manager to use, you may wish to discriminate based onperformance. However, aside from the network vs. local performancedifference, the differences tend to be primarily platformdependent.</p><h3><a name="TempFiles" id="TempFiles"></a>3.3.2 TemporaryFiles</h3><p><font size="2">The UNIX domain socket and TCP lock managersplace files used during communication with <b><i>db.*</i></b>applications in the <b>/tmp</b>directory (the default<b><i>db.*</i></b> temporary directory). If your UNIX/Linux systemhas background processes that arbitrarily delete files from<b>/tmp</b>, communication problems will arise when critical filesare deleted (for example, you may receive the error message<b>S_NOLOCKMGR)</b>. The default temporary directory can be changedfor a lock manager either by using the command line option <b>-zdir_name</b> or by setting the DBTMP environment variable to thedirectory you want to use. The environment variable DBTMP, the<b>db.star.ini</b> file, and the functions <b>d_dbtmp</b> and<b>d_dbtmp</b> can all be used to change the default<b><i>db.*</i></b> temporary directory for an <b><i>db.*</i></b>application. Note that it is critical for a lock manager and allthe <b><i>db.*</i></b> applications that will be using it to havethe same temporary directory.</font></p><h3><a name="Starting" id="Starting"></a>3.3.3 Starting a LockManager</h3><p><font size="2">All of the lock managers discussed in thissection can be started from the command line. On UNIX/Linux, thelock manager will by default use <b>fork()</b> to spawn a copy ofitself to run in the background, and then the command lineinvocation will return. This behavior can be suppressed by the<b>-n</b> switch.</font></p><p>A lock manager can also be started as part of the system startupprocess by editing or creating the appropriate systeminitialization file. In the case of BSD UNIX platforms, the mostlikely file to modify is <b>/etc/rc.local</b>. In the case ofSystem V UNIX, you probably need to create a file in the<b>/etc/init.d</b> or <b>/etc/rc2.d</b> directories. For thecorrect approach, consult the system administration documentationfor your system. In all cases, it is normally sensible to start thelock manager near or at the end of the system startup process.</p><h3><a name="Terminating" id="Terminating"></a>3.3.4 Terminating aLock Manager</h3><p><font size="2">All lock managers discussed in this section canbe terminated cleanly from the CONSOLE utility using the SHUTDOWNcommand, or doing one of the following:</font></p><p>Use the CONSOLE utility shutdown command line switch:</p><pre><font color="#0000FF">console -m<i>type</i> -a lockmgr_name -s</font></pre><p><font size="2">Use the <b>lmclear</b> utility:</font></p><pre><font color="#0000FF">lmclear -l -a lockmgr_name -m<i>type</i></font></pre><p><font size="2">Or send the process the SIGINT signal using the<b>kill</b> command:</font></p><pre><font color="#0000FF">kill -2 process_id</font></pre><p><font size="2">(where <b>process_id</b> is determined using the<b>ps</b> command)</font></p><p>In the above examples, <i>type</i> can be ‘t’ forTCP/IP or ‘p’ for UNIX domain sockets.</p><p>On most systems a control key (for example, <Ctrl+C>)generates SIGINT, and this can be used when a lock manager is notrunning in the background. Note that the use of SIGKILL toterminate a lock manager (<b>kill -9 process_id</b>), or anapplication using a lock manager, should happen only as a lastresort. This signal cannot be caught or handled and, thus, nocleanup can occur.</p><p>This type of termination, certain types of crashes, and, in thecase of lock manager clients, failure to use the API to exitcleanly (for example, calling <b>exit()</b> with databases stillopen) constitutes "abnormal termination." Note that all lockmanagers attempt to detect clients that have terminated abnormallyand then perform the necessary cleanup. However, due to limitationsof the type of communication being used, OS limitations, or thespecific nature of the abnormal termination, it may not be possiblefor the lock manager to detect the termination and carry out thecleanup.</p><p>In the event of an abnormal termination of the UNIX domainsocket lock manager, the TCP lock manager, or an application usingone of them, it may be necessary to remove UNIX domain socket filesfrom DBTMP manually.</p><h3><a name="TerminatingClient" id="TerminatingClient"></a>3.3.5Terminating a Lock Manager Client</h3><p><font size="2">A <b><i>db.*</i></b> application that uses a lockmanager should take special care to always close any database itopens before it terminates, regardless of how the application isterminated. Writing a program that simply closes any open databasesbefore the application exits normally is generally <i>not</i>adequate on UNIX/Linux. The reason is that programs are oftenterminated abnormally from signals generated either by users or thesystem itself.</font></p><p>For many applications it is a viable option to simply block mostor all user-generated signals such as SIGINT or SIGQUIT. For 1)those user-generated signals that cannot simply be blocked, and 2)system-generated signals (such as SIGSEGV, segmentation fault, orSIGBUS, bus error), which indicate the program is no longer in arunnable state, the alternative is to write and install a signalhandler that is called in when the signal occurs. The signalhandler can attempt to close any open databases and perform anyother necessary cleanup before the application terminates.</p><p>In some cases a system-generated signal is received, but theapplication has reached a state where it can no longer run all thecode necessary to close the open databases. In addition, somesignals such as SIGKILL cannot be caught or blocked. The onlydefense against such terminations is to educate users regarding theconsequences of initiating one (in such cases as SIGKILL) and howto clean up after a termination (for example, using <b>lmclear</b>)if it cannot be avoided.</p><p>For more information on writing programs that can optimally dealwith signals, refer to your OS documentation. On UNIX/Linuxsystems, the <b>signal()</b> man pages are a likely place to beginyour search for information.</p><h3><a name="Resource" id="Resource"></a>3.3.6 Resource Issues</h3><p><font size="2">All the lock managers discussed in this sectionconsume system or per process resources largely as a function ofthe number of client applications (users) they have. It is usuallynecessary to increase system defined limits for these resources tosupport large numbers of users. The memory used by the lock⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?