补充下，CONTROLFILE位于ASM的+DATA 下，与DATA FILE共一个磁盘组，但AWR采样时间数据库都不活跃，IO很少。

• 出现该等待事件的情况

备份控制文件
RAC环境下不同实例之间控制文件的信息共享
读取控制文件的其他信息
读取控制文件的文件头信息

• 通过查询v$session_wait视图可以看到哪个文件造成此等待事件。
• 可以从以下几点来对控制文件做调整：

将控制文件的数量减少，但必须要拥有足够安全数量的控制文件，一般来说控制文件最少要两个，以保证安全。

将控制文件分开放置，并且放在比较快的设备上，以分散I/O

查看日志切换频率，检查点发生的是否频繁，和log的大小

查看执行计划是否存在问题

先不要考虑LOG FILE SEQUENTIAL READ的问题。CONTROL FILE只有一个，无冗余。刚才，我又重新采集了两节点的AWR，节点二与节点一类似，也是control file sequential read排在background wait event的第二位，第一位是Streams AQ:qmn coordinator....。比如IO统计，两节点类似情形，如下：

是不是正如你们说的，系统太闲了？才导致CONTROL FILE SEQUENTIAL READ高举TOP 2？

你可以通过v$ash看下这个control file sequential read是由哪个sql发出来的，我以前碰到一个场景是数据库表空间特别大，当查询表空间使用率的时候，就会有这个等待时间。