📄 appd_tru.htm
字号:
<li type="disc">
<p>If the interconnect device or IP address specified is incorrect or does not exist on the system, Oracle9<em>i</em> uses the default cluster interconnect device. On Tru64 UNIX V5.1, the default device is <code>mc0</code>. On Tru64 UNIX V5.1A and above, the default device is <code>ics0.</code>
</p>
<p>Oracle9<em>i</em> does not confirm which device is being used. To determine the IP address of the cluster interconnect device being used, perform the following steps:
</p>
<ol type="1" start="1">
<li>
<p>Enter the following command:
</p>
<pre>$ /usr/sbin/clu_get_info
</pre>
</li>
<li>
<p>In the output for this command, identify the cluster interconnect IP name, stored in the <code>Hostname</code> parameter, and the cluster interconnect address, stored in the <code>Cluster interconnect IP address</code> parameter. In the following example, the cluster interconnect IP name is <code>server1</code> and the address is <code>10.0.0.1</code>:
</p>
</li>
<li>
<pre>Information on each cluster member Cluster memberid = 1 Hostname = server1.employee.records Cluster interconnect IP name = server1-mc0 Cluster interconnect IP address = 10.0.0.1 Member state = UP Member base O/S version = Compaq Tru64 UNIX V5.1 (Rev. 732) Member cluster version = TruCluster Server V5.1 (Rev. 389) Member running version = INSTALLED Member name = server1 Member votes = 1 csid = 0x20002
</pre>
</li>
</ol>
</li>
</ul>
</div class="sect2">
</div class="sect1"><a id="i635555" name="i635555"></a>
<div class="sect1">
<!--
infolevel=all
infotype=general
--><a id="sthref718" name="sthref718"></a>
<h2>
<font face="arial, helvetica, sans-serif" color="#330099">Tuning Asynchronous I/O<a id="sthref719" name="sthref719"></a>
</font>
</h2>
<p>Oracle9<em>i</em><em> </em>for Tru64 systems can perform either synchronous or asynchronous I/O. To improve performance, Oracle Corporation recommends that you use asynchronous I/O. Set the DISK_ASYNCH_IO parameter to TRUE to enable asynchronous I/O.
</p>
<p>Oracle9<em>i</em> can use asynchronous I/O on any datafiles that are stored on AdvFS file systems, clustered file systems (CFS), or raw devices. You must tune some operating system parameters for optimal asynchronous I/O performance.
</p>
<div class="sect2">
<!--
infolevel=all
infotype=general
--><a id="sthref720" name="sthref720"></a>
<h3>
<font face="arial, helvetica, sans-serif" color="#330099">
aio_task_max_num Parameter
</font>
</h3>
<p>Set the aio_task_max_num operating system parameter for a single instance to the higher of the following:
</p>
<ul>
<li type="disc">
<p>Greater than the maximum of the DBWR I/O operations
</p>
</li>
<li type="disc">
<p>The value of the DB_FILE_MULTIBLOCK_READ_COUNT initialization parameter
</p>
</li>
</ul>
<p>The maximum number of DBWR I/O operations defaults to 8192.
</p>
<p>You should adjust the setting of the aio_task_max_num parameter to accommodate any other applications that use asynchronous I/O, including multiple Oracle9<em>i</em> instances on a single node. Set the value of the parameter to the maximum number of I/O requests that any application can issue. For example, if three applications are running on a system and application one can issue a maximum of 10 simultaneous asynchronous I/O requests, application two can issue 100 simultaneous asynchronous I/O requests, and application three can issue 1000 simultaneous asynchronous I/O requests, you should set the aio_task_max_num parameter to at least 1000.
</p>
<p>If you do not set the aio_task_max_num operating system parameter as described in this section, the performance of Oracle9<em>i</em> is reduced and spurious I/O errors might occur. These errors are stored in the alert log and trace files.
</p>
</div class="sect2">
</div class="sect1"><a id="CACICEDA" name="CACICEDA"></a>
<div class="sect1">
<!--
infolevel=all
infotype=general
--><a id="sthref721" name="sthref721"></a>
<h2>
<font face="arial, helvetica, sans-serif" color="#330099">Direct I/O Support and Concurrent Direct I/O Support
</font>
</h2>
<p>This section describes support for direct and concurrent I/0.
</p><a id="i631141" name="i631141"></a>
<div class="sect2">
<!--
infolevel=all
infotype=general
--><a id="sthref722" name="sthref722"></a>
<h3>
<font face="arial, helvetica, sans-serif" color="#330099">
Single Instance Requirements
</font>
</h3>
<p>Oracle9<em>i</em> has the following requirements for single instance installations:
</p>
<ul>
<li type="disc">
<p>Tru64 UNIX V5.1 or later with the appropriate patchkits.
</p>
<br /><table summary="This is a layout table to format a tip" title="This is a layout table to format a tip" dir="ltr" border="1" width="80%" frame="hsides" rules="groups" cellpadding="3" cellspacing="0"><tbody>
<tr>
<td align="left" colspan="1" rowspan="1">
<p>
<font face="arial, helvetica, sans-serif">
<strong>See Also:</strong>
</font>
</p><em>Oracle9i Installation Guide Release 2 (9.2.0.1.0) for UNIX Systems</em> for information on Tru64 patchkits.
</td>
</tr></tbody>
</table><br />
</li>
<li type="disc">
<p>Oracle datafiles stored on a Tru64 UNIX AdvFS file system.
</p>
</li>
<li type="disc">
<p>The disks that use the AdvFS file system must be physically connected to the computer running the Oracle9<em>i</em> instance. This includes disks attached by fiber channel. This specifically excludes cases where I/O must be served by another node because of a lack of physical connectivity.
</p>
</li>
</ul>
<p>On Tru64 UNIX V5.1 systems and higher in a non-clustered system environment, the AdvFS file system and direct I/O give almost all of the performance of raw devices because the file system cache is not used. In addition to this, the file system allows you to more easily manage the database files.
</p>
</div class="sect2"><a id="i631148" name="i631148"></a>
<div class="sect2">
<!--
infolevel=all
infotype=general
--><a id="sthref723" name="sthref723"></a>
<h3>
<font face="arial, helvetica, sans-serif" color="#330099">
Clustered Systems
</font>
</h3>
<p>On V5.1 systems and higher, Tru64 supports Clustered File Systems (CFS). CFS provides a single namespace file system for all nodes in a cluster. All file systems mounted in a cluster are automatically seen by all nodes in the cluster. Because it is layered on top of the AdvFS file system, the CFS file system inherits much of the characteristics of non-clustered systems.
</p>
</div class="sect2"><a id="i633873" name="i633873"></a>
<div class="sect2">
<!--
infolevel=all
infotype=general
--><a id="sthref724" name="sthref724"></a>
<h3>
<font face="arial, helvetica, sans-serif" color="#330099">
Tru64 UNIX V5.1 Clustered Systems
</font>
</h3>
<p>Oracle Corporation supports CFS only on Tru64 UNIX V5.1 or later because this file system now supports a concurrent direct I/O model. Any node that has physical connectivity to a drive can issue data I/O to its file systems without consulting with the owning node.
</p>
<p>All metadata changes to a file, for example extending, closing, changing the access or modification date, are still served by the owner node and can still cause cluster interconnect saturation. Therefore, it is possible for the CREATE TABLESPACE, ALTER TABLESPACE, ADD DATAFILE, ALTER DATABASE DATAFILE, or RESIZE commands to perform poorly on a CFS file system when compared to raw devices.
</p>
</div class="sect2">
<div class="sect2">
<!--
infolevel=all
infotype=general
--><a id="sthref725" name="sthref725"></a>
<h3>
<font face="arial, helvetica, sans-serif" color="#330099">
Multiple Instance Requirements (Oracle9<em>i</em> Real Application Clusters)
</font>
</h3>
<p>Oracle9<em>i</em> Real Application Clusters requires that you store Oracle datafiles on the Tru64 AdvFS file system. The disks that use the AdvFS file system must be physically connected to all computers running the Oracle instances. This includes disks attached by fiber channel. It excludes cases where I/O must be served by another node because of physical connectivity.
</p>
<p>If the database is running in archive mode and the archive logs are being written to disk, the destination AdvFS domain should be served by the node of the instance that is archiving the redo log. For example, if you have a three-node cluster with one instance on each node (nodea, nodeb, and nodec), you must also have three archive destination AdvFS domains (arcnodea, arcnodeb, and arcnodec). The domains should be served by nodea, nodeb, and nodec respectively and the LOG_ARCHIVE_DEST initialization parameter for each instance should specify their respective locations.
</p>
</div class="sect2"><a id="CHDBHAIA" name="CHDBHAIA"></a>
<div class="sect2"><a id="sthref726" name="sthref726"></a>
<h3>
<font face="arial, helvetica, sans-serif" color="#330099">
Disabling Direct I/O Support
</font>
</h3>
<p>An Oracle9<em>i</em> database running on an AdvFS file system with direct I/O support enabled should perform as well as an Oracle9<em>i</em> database running on raw devices. In most cases, an Oracle9<em>i</em> database that is stored on AdvFS volumes with direct I/O support enabled should perform the same as or better than the same database with direct I/O support disabled. However, the following workload attributes can reduce performance when direct I/O support is enabled:
</p>
<ul>
<li type="disc">
<p>A high read to write ratio
</p>
</li>
<li type="disc">
<p>Oracle data blocks not cached in the SGA because the query utilizes parallel query slaves
</p>
</li>
<li type="disc">
<p>A Unix Buffer Cache (UBC) several megabytes or larger
</p>
</li>
<li type="disc">
<p>Full table scan queries where the same set of tables are scanned repeatedly
</p>
</li>
<li type="disc">
<p>Tables being scanned can fit in the UBC
</p>
</li>
</ul>
<p>When direct I/O support is disabled, workloads that have most of the attributes in the preceding list rely heavily on the UBC. Because most if not all of the tables being scanned are cached in the UBC, the I/O requests issued by the parallel query are met by the UBC. As a result, the query completes much faster than if all of the data had to be read from disk, as it would with direct I/O enabled. When direct I/O support is enabled, Oracle data blocks are not cached in the UBC. They are read into process-private memory instead. This means that any query that reads a previously-scanned table must perform I/O requests to disk to retrieve the data. Disk I/O latencies are several orders of magnitude slower than memory latencies. Therefore, the query runs slower and performance suffers. If your workload has most of the attributes described in the preceding list, disabling direct I/O support will probably improve performance. However, often there are many different types of queries running on the system at the same time. Some queries only read data while others insert, modify, or delete data and the ratio of the various types of queries differ from site to site. Generally, if your site has more of an OLTP workload, disabling direct I/O support does not improve performance. Direct I/O support is enabled by default in Oracle9<em>i</em> release 2 (9.2.0.1.0). The undocumented _TRU64_DIRECTIO_DISABLED initialization parameter that is used to disable direct I/O support in Oracle9<em>i</em> release 1 (9.0.1) is removed in Oracle9<em>i</em> release 2 (9.2.0.1.0). The generic FILESYSTEMIO_OPTIONS initialization parameter is used instead. The following table describes the valid values for the FILESYSTEMIO_OPTIONS parameter as interpreted on Tru64:
</p>
<table title="FILESYSTEMIO_OPTIONS parameter options" summary="Describes the valid options for the FILESYSTEMIO_OPTIONS parameter." dir="ltr" border="1" width="100%" frame="hsides" rules="groups" cellpadding="3" cellspacing="0">
<thead>
<tr align="left" valign="top">
<th id="r1c1" align="left" colspan="1" rowspan="1" valign="bottom">
<font face="Arial, Helvetica, sans-serif">
<strong>Value
</strong></font></th>
<th id="r1c2" align="left" colspan="1" rowspan="1" valign="bottom">
<font face="Arial, Helvetica, sans-serif">
<strong>Description
</strong></font></th>
</tr>
</thead><tbody>
<tr align="left" valign="top">
<td id="r2c1" headers="r1c1" align="left" colspan="1" rowspan="1">directio
</td>
<td headers="r2c1 r1c2" align="left" colspan="1" rowspan="1">Implies that direct I/O support is enabled but asynchronous I/O support is not enabled for I/O to files on an AdvFS files system.
</td>
</tr>
<tr align="left" valign="top">
<td id="r3c1" headers="r1c1" align="left" colspan="1" rowspan="1">asynch
</td>
<td headers="r3c1 r1c2" align="left" colspan="1" rowspan="1">Equivalent to <code>none</code> because asynchronous I/O support is enabled for AdvFS files only if direct I/O support is also enabled.
</td>
</tr>
<tr align="left" valign="top">
<td id="r4c1" headers="r1c1" align="left" colspan="1" rowspan="1">setall
</td>
<td headers="r4c1 r1c2" align="left" colspan="1" rowspan="1">Implies that both direct I/O and asynchronous I/O support are enabled for AdvFS files. This is the default option.
</td>
</tr>
<tr align="left" valign="top">
<td id="r5c1" headers="r1c1" align="left" colspan="1" rowspan="1">none
</td>
<td headers="r5c1 r1c2" align="left" colspan="1" rowspan="1">Disables both direct I/O support and asynchronous I/O support on AdvFS files.
</td>
</tr></tbody>
</table>
<br /><table summary="This is a layout table to format a tip" title="This is a layout table to format a tip" dir="ltr" border="1" width="80%" frame="hsides" rules="groups" cellpadding="3" cellspacing="0"><tbody>
<tr>
<td align="left" colspan="1" rowspan="1">
<p>
<font face="arial, helvetica, sans-serif">
<strong>See Also:</strong>
</font>
</p><em>Oracle9i Reference Guide </em>for more information on the FILESYSTEMIO_OPTIONS initialization parameter.
</td>
</tr></tbody>
</table><br />
<p>The DISK_ASYNCH_IO initialization parameter controls the asynchronous I/O state for all database files, whether they are on file systems or raw devices. Therefore, if the DISK_ASYNCH_IO parameter is set to FALSE, all I/O requests to file system files are synchronous regardless of the value of the FILESYSTEMIO_OPTIONS parameter. The DISK_ASYNCH_IO parameter defaults to TRUE.
</p>
</div class="sect2"><a id="CHDDEFDA" name="CHDDEFDA"></a>
<div class="sect2"><a id="sthref727" name="sthref727"></a>
<h3>
<font face="arial, helvetica, sans-serif" color="#330099">
Preventing File Fragmentation
</font>
</h3>
<p>Because of an interaction between direct I/O and file allocation, files created with direct I/O support enabled can become severely fragmented. Severely fragmented files cause performance degradation and can lead to I/O errors, especially during backups and recovery. Oracle9<em>i</em> release 2 (9.2.0.1.0) solves this problem by temporarily disabling direct I/O support during file creation and file extension. If direct I/O support is enabled, the new file or extended file is reopened with direct I/O support enabled after the file create or resize operation is complete. On a file resize operation, direct I/O support is not temporarily disabled if the new file size is smaller than the current file size. This does not cause fragmentation because the file or extent already exists.
</p>
</div class="sect2">
</div class="sect1"><a id="i633307" name="i633307"></a>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -