昨天客户的一个重要应用切换到新的系统环境上，今天观察，发现部分异常等待：

从OS的CPU负载来看，定期会出现一个峰值，从ASH中可以看出，这个峰值对应的等待事件跟AWR的完全吻合。

因此，主要怀疑两个东西：

1，应用的SQL和对象的属性（比如table或者index的统计信息，并行度等等……）
2，系统的AIO设置

上面的第一条，已经提交给开发相应的SQL和其他信息；第二条，因为系统以前是11.2 RAC，使用了ASM，而现在是单机文件系统.

因此对比了这两种环境下AIO的异同，结论如下：

1，Linux下，ASM数据库和文件系统数据库的AIO设置差别：
----(1). ASM的AIO属性是不受 FILESYSTEMIO_OPTIONS 参数的影响（因为ASM会绕过文件系统buffer），只跟DISK_ASYNCH_IO有关系
----(2). 文件系统的AIO属性跟 FILESYSTEMIO_OPTIONS 和 DISK_ASYNCH_IO 都有关系

2，FILESYSTEMIO_OPTIONS=NONE ： Bug 6733627 – Unaccounted Wait Time on “Direct Path” operations with FILESYSTEM_IO_OPTIONS=NONE (Doc ID 6733627.8)

3， db file async I/O submit’相关内容：
‘db file async I/O submit’ when FILESYSTEMIO_OPTIONS=NONE (Doc ID 1274737.1) —详细讲述了 ‘db file async I/O submit’ 和 FILESYSTEMIO_OPTIONS=NONE的关系
当文件系统设置了FILESYSTEMIO_OPTIONS=NONE时，会出现“db file async I/O submit”后台等待事件，而正常应该是出现“db file parallel write”
可以通过设置 FILESYSTEMIO_OPTIONS=SETALL，启用AIO，然后在AWR中会出现db file parallel write，而不再是db file async I/O submit

4，FILESYSTEMIO_OPTIONS=DIRECTIO ： Wrong FILESYSTEMIO_OPTIONS Settings Can Cause a Corrupted Block to be Returned at the First Read (Doc ID 1918825.1)

5，一般，linux建议设置为 FILESYSTEMIO_OPTIONS=SETALL

具体测试过程如下：

先看看官方文档的描述：

此处是文件系统：filesystemio_options=none disk_asynch_io=true（缺省值），使用strace发现，没有启用AIO：

在系统上看，目前并没有启用AIO：

使用strace对后台进程DBWR进行跟踪，佐证了上述观点，当前文件系统的数据库没有启用AIO：

strace中，没有io_submit函数，因为 filesystemio_options = none
如果 filesystemio_options = setall ，那么会出现 io_submit函数。

下面的测试是使用ASM的数据库的参数：

在系统上看，虽然设置了FILESYSTEMIO_OPTIONS=NONE，但是由于DISK_ASYNCH_IO=TRUE（缺省值），因此，ASM下的数据库依然使用AIO：

可以看到，使用ASM数据库的dbw0进程，即使FILESYSTEMIO_OPTIONS设置为NONE，只要disk_asynch_io设置为true（缺省值），DBWR也可以使用到AIO：

再看ASM实例的dbw进程，也是用了AIO：

在实践学习中，跟踪工具strace是利器之一。