System IO（控制文件）+日志类等待

System I/O类型

SELECT *

FROM v$event_name d

WHERE d.WAIT_CLASS ='System I/O';

db file parallel write

SELECT *

FROM v$event_name

WHERE NAME IN ('db file parallel write');

这个等待事件有3个参数：

Requests： 操作需要执行的I/O次数(DBWR写入批量的大小-块数)。

interrupt：(中断)

timeout：等待的超时时间。

在V$SESSION_WAIT这个视图里面，这个等待事件有三个参数P1、P2、P3，其中P1代表Oracle正在写入的数据文件的数量，P2代表操作将会写入多少的BLOCK数量，P3在Oracle9i release2版本之前代表总共有多少BLOCK的I/O请求，等于P2的值；在Oracle9i release2版本之后则代表等待I/O完成的超时的时间，单位是百分之一秒。

经过高速缓冲区的所有数据是通过DBWR写入到磁盘上的。DBWR请求写入脏块的I/O后，在此工作结束期间等待db file parallel write事件。

这是一个后台等待事件，它同样和用户的并行操作没有关系，它是由后台进程DBWR产生的，当后台进程DBWR向磁盘上写入脏数据时，会发生这个等待。

DBWR会批量地将脏数据并行地写入到磁盘上相应的数据文件中，在这个批次作业完成之前，DBWR将出现这个等待事件。 如果仅仅是这一个等待事件，对用户的操作并没有太大的影响，当伴随着出现free buffer waits等待事件时，说明此时内存中可用的空间不足，这时候会影响到用户的操作，比如影响到用户将脏数据块读入到内存中。

当出现db file parallel write等待事件时，可以通过启用操作系统的异步I/O的方式来缓解这个等待。 当使用异步I/O时，DBWR不在需要一直等到所有数据块全部写入到磁盘上，它只需要等到这个数据写入到一个百分比之后，就可以继续进行后续的操作。

这个等待事件是指Oracle后台进程DBWR等待一个并行写入文件或者是BLOCK的完成，等待会一直持续到这个并行写入操作完成。这个等待事件即使在总的等待时间中占的比例比较大也不会对用户的会话有很大的影响，只有当用户的会话显示存在大量的等待时间消耗在"write complete waits" 或者是"free buffer waits"上的时候才会影响到用户的会话，较明显的影响是这个写操作的等待会影响到读取同一个磁盘上数据的用户会话的I/O。

1. 与其名称相反，该事件不与任何并行DML操作相关。
2. 该等待事件属于DBWR进程，DBWR进程负责向数据文件写入脏数据块的唯一进程，即DBWR进程执行对使用SGA的所有数据库写入。阻塞该进程的是操作系统的IO子系统。当然DBWR进程的写入操作也会对同一磁盘操作的其他会话造成影响。
3. DBWR查找脏块的时机：

>> 每隔三秒一次的查找。

>> 当前台提交需要清除缓冲区内容时。

>> 当满足_DB_LARGE_DIRTY_QUEUE/_DB_BLOCK_MAX_DIRTY_TARGET /FAST_START_MTTR_TARGET阈值。

1. 缓慢的DBWR操作可以造成前台会话在write complete waits(前台不允许修改正在传输到磁盘的块)或free buffer waits(DBWR不能满足释放缓冲区的需求)事件上。通过以下语句可以获知该事件的平均等待时间，如果平均等待时间大小10cs，则表明IO缓慢。如果不存在db file parallel write事件，很可能初始化参数disk_async_io=FALSE，这种情况一般发生在AIX和HPUX平台上。

SELECT s.event, s.time_waited, s.average_wait

FROM v$system_event s

WHERE s.event IN ('db file parallel write', 'free buffer waits',

'write complete waits')

相关查询：

SELECT *

FROM v$sysstat

WHERE NAME IN ('write clones created in background',

'write clones created in foreground')

1. 操作说明：DBWR将一组脏数据编成"写入批量组"，然后发布多个IO请求以将"写入批量组"写入数据文件，然后以此事件等待直到IO请求都完成。但是，当使用异步IO时，DBWR不等待整个批量写入完成，仅等待一定百分比的IO操作完成后，就将空闲缓冲区推到LRU链以使其可用。
2. 解决方法：

>> 如果平均等待时间长，要选择使用正确的IO操作。如果数据文件在裸设备上，并且平台支持异步IO，请应该使用异步IO。如果数据文件位于文件系统上，则应该使用同步写入和直接IO。相关的初始化参数是DISK_ASYNCH_IO和FILESYSTEMIO_OPTIONS。

>> 如果重做位于祼设备上，而数据文件位于文件系统上，则可以设置DISK_ASYNCH_IO=TRUE，FILESYSTEMIO_OPTIONS=DIRECTIO。使用这种方法可以获得对于祼设备使用异步IO，而对于文件系统使用直接IO的效果。

>> 使用DB_WRITER_PROCESSES选项产生多个DBWR进程。

1、I/O系统的性能缓慢时

db file parallel write等待的发生原因和解决方法如下：

如果DBWR进程上db file parallel write等待时间表现得过长，就可以判断为I/O系统上有问题。如果DBWR上的db file parallel write等待时间延长，服务器进程就会接连经历free buffer waits事件或write complete waits事件的等待。这个问题可以通过改善I/O系统解决，改善I/O性能的方法如下：

（1）组合使用裸设备和异步I/O是目前为止的最好方法。

（2）OS级上使用Direct I/O。若CPU数量充足，可以调整db_writer_processes参数值，将DBWR数量增加。多个DBWR具有模拟异步的效果。oracle推荐的DBWR进程是CPU_COUNT/8。

2、I/O工作过多时

频繁发生检查点时，DBWR的活动量过多，可能导致DBWR的性能降低。DBWR的性能与整个系统的性能有直接的联系。将fast_start_mttr_target(MTTR指平均恢复时间,数据库进行崩溃恢复需要的秒数。)参数值设定过小时，将频繁发生增量检查点工作。日志文件过小时，将频繁发生日志文件的转换，因此检查点工作将增加。因Parallel Query发生direct path read时，在truncate、drop、hot backup时也发生检查点。如果I/O系统上不存在性能问题，但还是广泛出现db file parallel write等待，就应该检查是否存在给DBWR带来不必要的负荷的因素。

3、不能有效使用高速缓存区时

间接改善DBWR性能的另一种方法是合理使用多重缓冲池。与其说这个方法能改善I/O系统的性能，不如说是因为不必要的写入工作减少，进而减少了DBWR的负担。

控制文件I/O等待事件

SELECT A.* FROM V$EVENT_NAME A WHERE NAME LIKE 'control file%';

这一类等待事件通常发生在更新控制文件时，例如日志切换、检查点等发生时，需要更新控制文件内的System Change Number(SCN)所引起的相关等待事件，以下将为这些控制文件所引起的等待事件做详尽的介绍。

control file parallel write-控制文件并行写

SELECT A.*

FROM V$EVENT_NAME A

WHERE NAME IN ('control file parallel write');

这个等待事件包含三个参数：

files：Oracle要写入的控制文件个数。

block#：写入控制文件的数据块数目。

requests：写入控制文件请求的I/O次数。

在V$SESSION_WAIT这个视图里面，这个等待事件有三个参数P1、P2、P3，这三个参数都设置为同样的值，代表控制文件对I/O的请求数量。当Oracle更新控制文件的时候是同时更新所有控制文件并写入同样的信息。

这个等待事件表明服务器进程(Server Process)在更新所有的控制文件的时候等待I/O的完成。因为控制文件所在的磁盘的I/O过高引起无法完成对所有控制文件的物理写入，写入控制文件的这个会话会拥有CF队列，因此其他的会话都会在这个队列中等待。

一般环境下，因为更新控制文件的次数不多，因此不怎么发生control file parallel write等待现象。但如下情况下可能发生与控制文件相关的争用。

1. 日志文件切换经常发生时：

日志文件过小时，将经常发生日志文件的切换。每当发生日志文件切换时，需要对控制文件进行更新，所以LGWR进程等待control file parallel write事件的时间将延长。

1. 检查点经常发生时：

MTTR设定得过短或频繁发生人为的检查点时，CKPT进程等待control file parallel write事件的时间将延长。

1. nologging引起频繁的数据文件修改时：

对数据文件在nologging选项下执行修改工作时，为了修改unrecoverable SCN需要更新控制文件。这时，服务器进程将等待control file parallel write事件。

1. I/O系统的性能缓慢时：

最好是将控制文件位于独立的磁盘空间上，使用裸设备或direct I/O。

control file parallel write等待，通常与control file sequential read等待或enq: CF - contention等待一同出现的情况较多。enq: CF - contention等待是在多个会话为了同时更新控制文件获得CF锁的过程中发生的。control file parallel write、control file sequential read、CF - contention等待，全是因为过多的控制文件更新或I/O系统的性能问题引发的。

当server 进程更新所有控制文件时，这个事件可能出现。如果等待很短，可以不用考虑。如果等待时间较长，检查存放控制文件的物理磁盘I/O 是否存在瓶颈。

多个控制文件是完全相同的拷贝，用于镜像以提高安全性。对于业务系统，多个控制文件应该存放在不同的磁盘上，一般来说三个是足够的，如果只有两个物理硬盘，那么两个控制文件也是可以接受的。在同一个磁盘上保存多个控制文件是不具备实际意义的。

当数据库中有多个控制文件的拷贝时，Oracle 需要保证信息同步地写到各个控制文件当中，这是一个并行的物理操作过程，因为称为控制文件并行写，当发生这样的操作时，就会产生control file parallel write等待事件。

控制文件频繁写入的原因很多，比如：

• 日志切换太过频繁，导致控制文件信息相应地需要频繁更新。当系统出现日志切换过于频繁的情形时，可以考虑适当地增大日志文件的大小来降低日志切换频率。
• 系统I/O 出现瓶颈，导致所有I/O出现等待。

如果在等待时间中这个等待事件占的比重比较大，可以从如下几个方面来调整：

• 在确保控制文件不会同时都丢失的前提下，将控制文件的数量减小到最少，降低控制文件的拷贝数量(在确保安全的前提下)。
• 如果系统支持异步I/O，则推荐尽量使用异步I/O，这样可以实现真正并行的写入控制文件。
• 将控制文件移动到负载比较低，速度比较快的磁盘上去。
• 将控制文件的拷贝存放在不同的物理磁盘上的方式来缓解I/O 争用。

control file sequential read

SELECT A.*

FROM V$EVENT_NAME A

WHERE NAME IN ('control file sequential read');

这个等待事件有三个参数：

File#：要读取信息的控制文件的文件号。

Block#：读取控制文件信息的起始数据块号。

Blocks：需要读取的控制文件数据块数目。

在V$SESSION_WAIT这个视图里面，这个等待事件有三个参数P1、P2、P3，其中P1代表正在读取的控制文件号，通过下面的SQL语句可以知道究竟是具体是哪个控制文件被读取：

SELECT * FROM X$KCCCF WHERE INDX = \<file#>；

P2代表开始读取的控制文件BLOCK号，它的BLOCK大小和操作系统的BLOCK大小一样，通常来说是512K，也有些UNIX的是1M或者2M，P3代表会话要读取BLOCK的数量。一般来说使用参数P1、P2来查询BLOCK,当然也可以包括参数P3，但是那样最终就变成了一个多BLOCK读取，因此我们一般都忽略参数P3。

Wait Time: The wait time is the elapsed time of the read

控制文件连续读/控制文件单个写对单个控制文件I/O 存在问题时，这两个事件会出现。如果等待比较明显，检查单个控制文件，看存放位置是否存在I/O 瓶颈。

当数据库需要读取控制文件上的信息时，会出现这个等待事件，因为控制文件的信息是顺序写的，所以读取的时候也是顺序的，因此称为控制文件顺序读，它经常发生在以下情况：

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

Reading from the control file. This happens in many cases. For example, while:

1、Making a backup of the control files

2、Sharing information (between instances) from the control file

3、Reading other blocks from the control files

4、Reading the header block

读取控制文件的时候遇到I/O等待就会出现这个等待事件，例如备份控制文件的时候、读取BLOCK头部都会引起这个等待事件，等待的时间就是消耗在读取控制文件上的时间。

如果这个等待事件等待的时间比较长，则需要检查控制文件所在的磁盘是否很繁忙，如果是，将控制文件移动到负载比较低，速度比较快的磁盘上去。如果系统支持异步I/O，则启用异步I/O。对于并行服务器来说，如果这种等待比较多，会造成整个数据库性能下降，因为并行服务器之间的一些同步是通过控制文件来实现的。

解决方式与control file parallel write的解决方式一样。

首先，该等待事件并不表明数据库有问题。一个健康的系统，物理读事件应是除空闲等待事件外的最大等待事件。而该事件在RAC中尤其明显，依照经验来看，在一个正常的RAC集群中，该事件应该排在top10中，因为实例间共享同一份控制文件，对控制文件读取是很频繁的，如果被其他等待事件挤出前10了，那就得看看是哪些等待事件了。其次，可以查看AWR报告该事件的等待次数，平均等待时间，最大等待时间等信息进行进一步确认。看看这些信息比起日常AWR报告信息是否有明显的异常。

control file single write

SELECT A.*

FROM V$EVENT_NAME A

WHERE NAME IN ('control file single write');

P2代表开始读取的控制文件BLOCK号，它的BLOCK大小和操作系统的BLOCK大小一样，通常来说是512K，也有些UNIX的是1K或者2K，P3代表会话要读取BLOCK的数量。一般来说使用参数P1、P2来查询BLOCK,当然也可以包括参数P3，但是那样最终就变成了一个多BLOCK读取，因此我们一般都忽略参数P3。

在V$SESSION_WAIT这个视图里面，这个等待事件有三个参数P1、P2、P3，其中P1代表正在读取的控制文件号，通过下面的SQL语句可以知道究竟是具体是哪个控制文被读取：

SELECT * FROM X$KCCCF WHERE INDX = \<file#>；

这个等待事件出现在写控制文件的共享信息到磁盘的时候，这是个自动操作，并且通过一个实例来保护的，如果是并行的数据库服务器，那么对于并行服务器来说也只能有一个实例能够执行这个操作。这个事件的等待事件就是写操作所消耗的时间。

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章！

验证码：

请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。