Oracle等待事件原因和一般解决方法：control file sequential read

编者按：

本文作者系流浪的金鱼（花名），甲骨文数据库工程师。个人主页：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的原因了。