Common Wait Events
Buffer busy waits
当一个session要获取buffer cache中的数据块，而该数据块正在被其他session所使用时这一event就会出现。
两种情况下会产生这一事件：
l 另一Sesssion正在buffer cache中修改该数据块，修改数据块时session会修改该数据块头的标记，以防止其他session冲突；
l 另一Session正在从datafile将此数据块读入buffer cache。这一情况在10g之前会产生buffer busy waits事件，从10g开始由read by other session事件替代。
不要混淆buffer busy waits和buffer busy， buffer busy是由于session要通过ASM使用cached metadata所产生的。
常见的可能产生buffer busy waits事件的buffer类型包括：data blocks,segment header,undo blocks和undo header。
参数：P1-file number,P2-block number,P3-10g之前是一个代表wait原因的数值，10g之后是wait class.
Timeout: 100cs or 1 second.
Control file parallel write
Session等待写控制文件的竞争。需要写控制文件主要有以下几种情况：
l CKPT每3秒向控制文件写入redo logs的checkpoint位置，用于recovery;
l NOLOGGING或者UNRECOVERABLE的DML操作时，oracle会将这些SCN写入控制文件；
l RMAN将备份和恢复信息写入控制文件。
Control file parallel write等待的是OS和IO，而并非其他session.当一个session在写控制文件时，会hold CF enqueue，这样其他Session就会等待这个enqueue。
如果这一等待时间很多，说明系统写控制文件的操作过多，或者写控制文件的性能过低。
参数：P1-number of control file; P2-total number of blocks to write to control file; P3- number of IO requests
Db file parallel read
以下两种情况会出现该事件：
l 在数据库recovery的时候出现，从Datafile并行读取恢复所需数据块；
l 用户进程从一个或者和多个数据文件读取很多非连续的single block.
参数：P1-读取的文件编号；P2-total number of blocks to read; P3-total numbe of IO requests
Db file parallel write
DBWR向数据文件写入脏数据块时产生，产生的原因是系统IO. Dbwr将一系列的脏数据块整理到”write batch”， 并向IO请求将Batch写入数据文件的资源，并一直等待到IO完成写入为止。如果使用的是异步IO,则DBWR不等待IO写入完成就直接将free buffer放回LRU chain供用户使用。
参数：P1-number of file to write to ; P2-total number of blocks to write; p3-timeout value
Db file scattered read
当session提交一个IO请求，要求读取很多数据块时会出现该事件。这些被读取的数据块被scattered into the buffer cache,他们在buffer cache中并不连续。这一事件往往出现在全表扫描和index fast full scans。参数db_file_multiblock_read_count定义了每次读取的最大block数量。
数据文件的IO等待是正常的现象，这一事件本身并不代表数据库有问题。但是如果用于等待该事件的时间明显高于其他等待事件，那就需要进一步查找原因了。
参数：P1-file number to read the blocks from; P2-starting block number to begin reading; P3-number of blocks to read
Db file sequential read
(摘自原文，理解不深刻，怕翻错了)The db file sequential read wait event occurs when the process waits for an I/O completion for a sequential read. The name is a bit misleading, suggesting a multiblock operation, but this is a single block read operation. The event gets posted when reading from an index, rollback or undo segments, table access by rowid, rebuilding control files, dumping datafile headers, or the datafile headers.
同样，这一事件本身并不代表数据库有问题。但是如果用于等待该事件的时间明显高于其他等待事件，那就需要进一步查找原因了。
参数：P1-file number to read the blocks from; P2-starting block number to begin reading; P3-number of blocks to read，绝大多数情况下是1
Db file single write
由dbwr发起，往往发生在oracle更新数据文件头时，最常见的就是checkpoint的时候。这一事件往往出现在数据文件比较混乱的情况下。
参数：P1-file number to write to,P2-starting block number,P3-number to write，往往是1
Direct path read
当session直接将数据读入PGA而不是SGA的buffer cache时会产生direct path read事件。根据硬件平台的不同和DISK_ASYNCH_IO参数的不同，direct path read有同步和异步两种方式。Direct path read一般是排序、并行查询、hash joins等需要使用到磁盘的temporary segments的操作所引起所使用到的。
这个事件的等待次数和时间在同步和异步的情况下是不同的：
l 同步的情况下session提交一个请求以后会等待IO结束，但这个等待的时间并不计入direct path read事件。 在IO完成，session获取到自己所需要的数据以后会提交direct path read事件。这样，应该是每有一个read request，就会有一个对应的等待时间，但是等待时间却是相当短的。
l 异步的情况下，session持续提交多个读取数据的请求，之后就对已经被读取到PGA的数据进行处理。只有在发现所需要的数据还没有被读入PGA,才会提交direct path read等待事件。因此，在异步的情况下，read request的数量和等待的数量是不同的。
因此，我们在v$system_event和v$session_event中看到关于这一等待事件的统计并不可靠。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/55472/viewspace-432997/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/55472/viewspace-432997/
854
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
