编者按：
本文作者系流浪的金鱼（花名），甲骨文数据库工程师。个人主页：https://blog.csdn.net/rishairu1，经其本人授权发布。
【免责声明】本公众号文章仅代表个人观点，与任何公司无关。
control file sequential read等待事件：
P1: 读取的对象控制文件P2: 控制文件开始读取时候的block号P3: 读取的block数
发生的条件和场景：
由于控制文件包含最后一个事务的scn，经常被更新。通常由于该等待事件
导致i/o性能问题很少，如果发现性能问题，需要检查如下几点。
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的原因了。
后续文章更加精彩，欢迎关注本公众号或访问【阅读原文】。
——End——
专注于技术不限于技术！
用碎片化的时间，一点一滴地提高数据库技术和个人能力。
欢迎关注！
等待事件（性能分析基础）
Oracle数据库性能优化之Enq: TM – contention
【等待事件】SQL*Net more data from client
"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! "等待原理概述
