Oracle数据库常见等待事件原因和一般解决方法之(control file sequential read)

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是否很慢。

- 解决方案

如果通过ASH找到导致高"control file sequential read"问题发生的session，正在执行DML，或者RMAN备份。
将这些处理分散执行可能会有效。

如果多个控制文件放入到了一个磁盘下，分散放入不同磁盘会减轻该现象。

如果控制文件数量过多，减少控制文件的数量。

如果发现log switch动作过慢，分析存放archivelog的磁盘是否有i/o问题。

如果以上问题都不存在，那么就需要考虑是否是bug的原因了。