最近在研究如何在IO竞争的情况下，如果存储级别已经无法优化，还有其他什么办法解决IO竞争问题。最后想到了异步IO。

我的redo写磁盘的速度已经达到了最大值，无论我如何调整redo大小和组数，无论我如何调整检查点频率都没有什么用处。调整redo大小，之后减少redo切换的频率，增加redo组数只是为了避免所有redo都已经没使用但是业务仍然需要新的日志来记录数据更改。可是如果IO不给力，会造成一堆redo都依然不够的局面。也许异步IO是你最后一招了，那就试试吧。

网上有很多类似的文章，收藏一篇，以后不用google了，直接翻博客，方便。  

转载自著名的杨大师：地址为  http://yangtingkun.itpub.net/post/468/526904

客户的数据库IO负载较重，检查后发现并未设置异步IO。

整个数据库的负载都集中在IO相关的等待上：

Top 5 Timed Foreground Events

检查后发现，当前系统并未使用异步io：

[oracle@localhost ~]$ cat /proc/slabinfo | grep kio
kioctx 37 140 384 10 1 : tunables 54 27 8 : slabdata 14 14 0
kiocb 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0

返回结果中kiocp对应的前两项为0，说明系统中没有使用异步io。

检查显示oracle已经链接了aio的包：

[oracle@localhost ~]$ /usr/bin/ldd $ORACLE_HOME/bin/oracle | grep libaio
libaio.so.1 => /lib64/libaio.so.1 (0x0000003e13000000)

而数据库中检查发现filesystemio_options设置有误：

SQL> show parameter disk_asynch_io

NAME TYPE VALUE
------------------------------------ -------------------------------- --------------------
disk_asynch_io boolean TRUE

SQL> show parameter filesystemio_options

NAME TYPE VALUE
------------------------------------ -------------------------------- -------------------
filesystemio_options string none

当前使用的是文件系统，因此需要将filesystemio_options设置为asynch，才能开启异步io：

SQL> ALTER SYSTEM SET FILESYSTEMIO_OPTIONS = ASYNCH SCOPE = SPFILE;

System altered.

SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> STARTUP
ORACLE instance started.

Total System Global Area 6.0264E+10 bytes
Fixed Size 2242912 bytes
Variable Size 2147485344 bytes
Database Buffers 5.7982E+10 bytes
Redo Buffers 131960832 bytes
Database mounted.
Database opened.
SQL>

再次检查系统上异步io的设置，发现异步io已经启动：

[oracle@localhost ~]$ more /proc/slabinfo |grep kio
kioctx 130 160 384 10 1 : tunables 54 27 8 : slabdata 16 16 0
kiocb 16 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 1

可以看到，目前异步IO已经生效。