最近在研究如何在IO竞争的情况下，如果存储级别已经无法优化，还有其他什么办法解决IO竞争问题。最后想到了异步IO。
我的redo写磁盘的速度已经达到了最大值，无论我如何调整redo大小和组数，无论我如何调整检查点频率都没有什么用处。调整redo大小，之后减少redo切换的频率，增加redo组数只是为了避免所有redo都已经没使用但是业务仍然需要新的日志来记录数据更改。可是如果IO不给力，会造成一堆redo都依然不够的局面。也许异步IO是你最后一招了，那就试试吧。
客户的数据库IO负载较重，检查后发现并未设置异步IO。
整个数据库的负载都集中在IO相关的等待上：
Top 5 Timed Foreground Events
当前使用的是文件系统，因此需要将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已经生效。
相关阅读：