Oracle：IO问题

但是如果系统支持AIO一般不用设置多dbwr 或者 io  slaves
      如果系统不支持AIO或者DISK_ASYNCH_IO 为 FALSE

 

多个dbwr 可以并行地搜集dirty buffer 并且并行地写数据文件

 

当系统不支持多个dbwr进程(如单CPU)且dbwr_io_slaves非零时，只有一个dbwr进程

一个 dbwr 进程搜集dirty  buffer 而 多个slaves 写数据文件

我想下面这段 oracle  document 说的再清楚不过了
Consider Multiple Database Writer (DBWR) Processes or I/O Slaves
Configuring multiple database writer processes, or using I/O slaves, is useful when the transaction rates are high or when the buffer cache size is so large that a single DBWn process cannot keep up with the load.

DB_WRITER_PROCESSES
The DB_WRITER_PROCESSES initialization parameter lets you configure multiple database writer processes (from DBW0 to DBW9 and from DBWa to DBWj). Configuring multiple DBWR processes distributes the work required to identify buffers to be written, and it also distributes the I/O load over these processes. Multiple db writer processes are highly recommended for systems with multiple CPUs (at least one db writer for every 8 CPUs) or multiple processor groups (at least as many db writers as processor groups).

Based upon the number of CPUs and the number of processor groups, Oracle either selects an appropriate default setting for DB_WRITER_PROCESSES or adjusts a user-specified setting.

DBWR_IO_SLAVES
If it is not practical to use multiple DBWR processes, then Oracle provides a facility whereby the I/O load can be distributed over multiple slave processes. The DBWR process is the only process that scans the buffer cache LRU list for blocks to be written out. However, the I/O for those blocks is performed by the I/O slaves. The number of I/O slaves is determined by the parameter DBWR_IO_SLAVES.

DBWR_IO_SLAVES is intended for scenarios where you cannot use multiple DB_WRITER_PROCESSES (for example, where you have a single CPU). I/O slaves are also useful when asynchronous I/O is not available, because the multiple I/O slaves simulate nonblocking, asynchronous requests by freeing DBWR to continue identifying blocks in the cache to be written. Asynchronous I/O at the operating system level, if you have it, is generally preferred.

DBWR I/O slaves are allocated immediately following database open when the first I/O request is made. The DBWR continues to perform all of the DBWR-related work, apart from performing I/O. I/O slaves simply perform the I/O on behalf of DBWR. The writing of the batch is parallelized between the I/O slaves.


--------------------------------------------------------------------------------
Note:
Implementing DBWR_IO_SLAVES requires that extra shared memory be allocated for I/O buffers and request queues. Multiple DBWR processes cannot be used with I/O slaves. Configuring I/O slaves forces only one DBWR process to start.

--------------------------------------------------------------------------------


Choosing Between Multiple DBWR Processes and I/O Slaves
Configuring multiple DBWR processes benefits performance when a single DBWR process is unable to keep up with the required workload. However, before configuring multiple DBWR processes, check whether asynchronous I/O is available and configured on the system. If the system supports asynchronous I/O but it is not currently used, then enable asynchronous I/O to see if this alleviates the problem. If the system does not support asynchronous I/O, or if asynchronous I/O is already configured and there is still a DBWR bottleneck, then configure multiple DBWR processes.


--------------------------------------------------------------------------------
Note:
If asynchronous I/O is not available on your platform, then asynchronous I/O can be disabled by setting the DISK_ASYNCH_IO initialization parameter to FALSE.

--------------------------------------------------------------------------------


Using multiple DBWRs parallelizes the gathering and writing of buffers. Therefore, multiple DBWn processes should deliver more throughput than one DBWR process with the same number of I/O slaves. For this reason, the use of I/O slaves has been deprecated in favor of multiple DBWR processes. I/O slaves should only be used if multiple DBWR processes cannot be configured.

 

 

 

如何鉴别系统是否使用了asynchronous I/O嘛

 

在9iR2以后oracle才支持aio的，但默认它们是不支持aio，如果要打开对aio的支持，需要重新链接一下可执行文件，9iR2与10g中打开aio选项的方式也是不同，所以需要注意，还有就是初始化参数中，对于data file使用raw devices或file system，那参数的设置也稍微有些差异。

9iR2:
1) cd to $ORACLE_HOME/rdbms/lib
a) make -f ins_rdbms.mk async_on
b) make -f ins_rdbms.mk ioracle
2) Parameter settings in init.ora for raw devices:
set 'disk_asynch_io=true' (default value is true)
2) Parameter settings in init.ora file for filesystem files:
a) set 'disk_asynch_io=true' (default value is true)
b) set 'filesystemio_options=asynch'
10gR1/10gR2:
1.1) In RHEL 2.1
Requires libaio packages.
libaio-0.3.13-3.i386.rpm
libaio-devel-0.3.13-3.i386.rpm
1.2)make option
make PL_ORALIBS=-laio -f ins_rdbms.mk async_on
1.3)In init.ora file add following option.
for raw devices
disk_asynch_io=true (this is default option)
for file system
filesystemio_options =asynch
disk_asynch_io=true (this is default option)
2.1) In RHEL 3
Requires libaio packages. (RHEL 3 Update 2)
libaio-0.3.96-3.i386.rpm
libaio-devel-0.3.96-3.i386.rpm
2.2) Make Option
make PL_ORALIBS=-laio -f ins_rdbms.mk async_on
3.3)In init.ora file add following option.
for data files on raw devices
disk_asynch_io=true (this is default option)
for data files on file system
filesystemio_options =asynch
disk_asynch_io=true (this is default option)
3.1) In RHEL 4
Requires libaio packages. (RHEL 4 Update 3)
libaio-devel-0.3.105-2.i386.rpm
libaio-0.3.105-2.i386.rpm
3.2) Make Option
make PL_ORALIBS=-laio -f ins_rdbms.mk async_on
3.3)In init.ora file add following option.
for data files on raw devices
disk_asynch_io=true (this is default option)
for data files on file system
filesystemio_options =asynch
disk_asynch_io=true (this is default option)