编者按：
本文作者系流浪的金鱼（花名），甲骨文数据库工程师。个人主页：https://blog.csdn.net/rishairu1，经其本人授权发布。
【免责声明】本号文章仅代表个人观点，与任何公司无关。
control file sequential read等待事件：
代码语言：javascript复制 P1: 读取的对象控制文件
P2: 控制文件开始读取时候的block号
P3: 读取的block数发生的条件和场景：
由于控制文件包含最后一个事务的scn，经常被更新。通常由于该等待事件
导致i/o性能问题很少，如果发现性能问题，需要检查如下几点。
代码语言：javascript复制1. 是否有大量的DML操作。
2. 是否有rman在进行控制文件的备份。
3. 是否将多个控制文件放入了同一个磁盘。
4. 是否分配了过多的控制文件。
5. 是否频繁的发生手动commit或者日志切换。问题发生时候的调查方法
1. AWR 的 Top event中可以看到是否有高"control file sequential read"等待的发生。
2. ASH报告中找到高"control file sequential read"的session信息，通过查找BLOCKING_SESSION
列，找到导致发生问题的session，看这个session在执行什么处理。
3. 通过AWR报告的parameter,v$controlfile视图，或者警告日志中启动信息，检查控制文件数量和存放位置。
4. 通过如下的语句查看控制文件的大小。
SELECT * FROM gv$system_event WHERE event LIKE '%control%
SELECT name,block_size FROM gv$controlfile;
5. 可以设置trace来查看控制文件的使用状态。
ALTER SESSION set events 'immediate trace name controlf level 3';
6. 检查警告日志的log switch是否很慢。
解决方案
1.如果通过ASH找到导致高"control file sequential read"问题发生的session，正在执行DML，或者RMAN备份。
将这些处理分散执行可能会有效。
2.如果多个控制文件放入到了一个磁盘下，分散放入不同磁盘会减轻该现象。
3.如果控制文件数量过多，减少控制文件的数量。
4.如果发现log switch动作过慢，分析存放archivelog的磁盘是否有i/o问题。
5.如果以上问题都不存在，那么就需要考虑是否是bug的原因了。
