常见的等待事件

--Buffer busy waits
  从本质上讲，这个等待事件的产生仅说明了一个会话在等待一个Buffer（数
据块），但是导致这个现象的原因却有很多种。常见的两种是：
  当一个会话视图修改一个数据块，但这个数据块正在被另一个会话修改时。
  当一个会话需要读取一个数据块，但这个数据块正在被另一个会话读取到内
存中时。
 
  Oracle 操作的最小单位是块（Block），即使你要修改一条记录，也需要对这
条记录所在的这个数据块做操作。 当你对这个数据块做修改时，其他的会话将
被阻止对这个数据块上的数据做修改（即使其他用户修改的不是当前用户修改的
数据），但是可以以一致性的方式读取这个数据块（from  undo）。当前的用户修
改完这个数据块后，将会立即释放掉加在这个数据块上的排他锁，这样另一个会
话就可以继续修改它。 修改操作是一个非常短暂的时间，这种加锁的机制我们
叫Latch。
 
当一个会话修改一个数据块时，是按照以下步骤来完成的：
  （1）以排他的方式获得这个数据块（Latch）
  （2）修改这个数据块。
  （3）释放Latch。
 
  Buffer busy waits等待事件常见于数据库中存在的热快的时候，当多个用户频
繁地读取或者修改同样的数据块时，这个等待事件就会产生。 如果等待的时间
很长，我们在AWR或者statspack 报告中就可以看到。 
 
这个等待事件有三个参数。 查看有几个参数我们可以用以下SQL:
  SQL>  select  name,  parameter1,  parameter2,  parameter3  from  v$event_name
where name='buffer busy waits';
NAME                  PARAMETER1  PARAMETER2  PARAMETER3
--------------------  ----------   ----------  ----------
buffer busy waits        file#            block#          class#
 
   在下面的示例中，查询的方法和这个一样，所以其他事件对参数的查询将不
做过多的说明。
 
File#: 等待访问数据块所在的文件id号。
Blocks： 等待访问的数据块号。
ID： 在10g之前，这个值表示一个等待时间的原因，10g之后则表示等待事件
的类别。
 
 
--Buffer    latch
  内存中数据块的存放位置是记录在一个hash列表（cache buffer chains）当中
的。 当一个会话需要访问某个数据块时，它首先要搜索这个hash 列表，从列表
中获得数据块的地址，然后通过这个地址去访问需要的数据块，这个列表Oracle
会使用一个latch来保护它的完整性。 当一个会话需要访问这个列表时，需要获
取一个Latch，只有这样，才能保证这个列表在这个会话的浏览当中不会发生变
化。
 
产生buffer latch的等待事件的主要原因是：
  （1）Buffer chains太长，导致会话搜索这个列表花费的时间太长，使其他的
会话处于等待状态。
  （2）同样的数据块被频繁访问，就是我们通常说的热快问题。
 
  产生buffer  chains太长，我们可以使用多个buffer  pool的方式来创建更多的
buffer chains，或者使用参数DB_BLOCK_LRU_LATCHES来增加latch的数量，
以便于更多的会话可以获得latch，这两种方法可以同时使用。 
 
这个等待事件有两个参数：
Latch addr： 会话申请的latch在SGA中的虚拟地址，通过以下的SQL语句可
以根据这个地址找到它对应的Latch名称：
  select * from v$latch a,v$latchname b where 
  addr=latch addr   -- 这里的latch addr  是你从等待事件中看到的值  
  and a.latch#=b.latch#;  
chain#： buffer  chains  hash 列表中的索引值，当这个参数的值等于s  0xfffffff
时，说明当前的会话正在等待一个LRU latch。
 
--Control file parallel write
  当数据库中有多个控制文件的拷贝时，Oracle 需要保证信息同步地写到各个
控制文件当中，这是一个并行的物理操作过程，因为称为控制文件并行写，当发
生这样的操作时，就会产生control file parallel write等待事件。
 
控制文件频繁写入的原因很多，比如：
  （1）日志切换太过频繁，导致控制文件信息相应地需要频繁更新。
  （2）系统I/O 出现瓶颈，导致所有I/O出现等待。
 
  当系统出现日志切换过于频繁的情形时，可以考虑适当地增大日志文件的大
小来降低日志切换频率。
  当系统出现大量的control file parallel write  等待事件时，可以通过比如降低
控制文件的拷贝数量，将控制文件的拷贝存放在不同的物理磁盘上的方式来缓解
I/O 争用。
 
这个等待事件包含三个参数：
 
  Files： Oracle 要写入的控制文件个数。
  Blocks： 写入控制文件的数据块数目。
  Requests：写入控制请求的I/O 次数。
 
--Control file sequential read
  当数据库需要读取控制文件上的信息时，会出现这个等待事件，因为控制文
件的信息是顺序写的，所以读取的时候也是顺序的，因此称为控制文件顺序读，
它经常发生在以下情况：
  （1）备份控制文件
  （2）RAC 环境下不同实例之间控制文件的信息共享
  （3）读取控制文件的文件头信息
  （4）读取控制文件其他信息
 
这个等待事件有三个参数：
  File#：要读取信息的控制文件的文件号。
  Block#： 读取控制文件信息的起始数据块号。
  Blocks：需要读取的控制文件数据块数目。
 
 
--Db file parallel read
  这是一个很容易引起误导的等待事件，实际上这个等待事件和并行操作（比
如并行查询，并行DML）没有关系。 这个事件发生在数据库恢复的时候，当有
一些数据块需要恢复的时候，Oracle会以并行的方式把他们从数据文件中读入到
内存中进行恢复操作。
 
这个等待事件包含三个参数：
  Files： 操作需要读取的文件个数。
  Blocks： 操作需要读取的数据块个数。
  Requests：操作需要执行的I/O次数。
 
--Db file parallel write
  这是一个后台等待事件，它同样和用户的并行操作没有关系，它是由后台进
程DBWR产生的，当后台进程DBWR想磁盘上写入脏数据时，会发生这个等待。
 
  DBWR会批量地将脏数据并行地写入到磁盘上相应的数据文件中，在这个批
次作业完成之前，DBWR将出现这个等待事件。 如果仅仅是这一个等待事件，
对用户的操作并没有太大的影响，当伴随着出现free buffer waits等待事件时，说
明此时内存中可用的空间不足，这时候会影响到用户的操作，比如影响到用户将
脏数据块读入到内存中。
  
  当出现db  file  parallel  write等待事件时，可以通过启用操作系统的异步I/O
的方式来缓解这个等待。 当使用异步I/O 时，DBWR不在需要一直等到所有数
 
据块全部写入到磁盘上，它只需要等到这个数据写入到一个百分比之后，就可以
继续进行后续的操作。
 
这个等待事件有两个参数：
    Requests： 操作需要执行的I/O次数。
    Timeouts：等待的超时时间。
 
--Db file scattered read
  这个等待事件在实际生产库中经常可以看到，这是一个用户操作引起的等待
事件，当用户发出每次I/O 需要读取多个数据块这样的SQL 操作时，会产生这
个等待事件，最常见的两种情况是全表扫描（FTS： Full Table Scan）和索引快
速扫描（IFFS： index fast full scan）。
 
  这个名称中的scattered( 发散)，可能会导致很多人认为它是以scattered 的方
式来读取数据块的，其实恰恰相反，当发生这种等待事件时，SQL的操作都是
顺序地读取数据块的，比如FTS或者IFFS方式（如果忽略需要读取的数据块已
经存在内存中的情况）。
 
  这里的scattered指的是读取的数据块在内存中的存放方式，他们被读取到内
存中后，是以分散的方式存在在内存中，而不是连续的。
 
这个等待事件有三个参数：
File#： 要读取的数据块所在数据文件的文件号。
Block#： 要读取的起始数据块号。
Blocks：需要读取的数据块数目。
 
--Db file sequential read
  这个等待事件在实际生产库也很常见，当Oracle 需要每次I/O只读取单个数
据块这样的操作时，会产生这个等待事件。 最常见的情况有索引的访问（除IFFS
外的方式），回滚操作，以ROWID的方式访问表中的数据，重建控制文件，对
文件头做DUMP等。
 
  这里的sequential也并非指的是Oracle 按顺序的方式来访问数据，和db file
scattered read一样，它指的是读取的数据块在内存中是以连续的方式存放的。
 
这个等待事件有三个参数：
File#： 要读取的数据块锁在数据文件的文件号。
Block#： 要读取的起始数据块号。
Blocks：要读取的数据块数目（这里应该等于1）。
 
--Db file single write
  这个等待事件通常只发生在一种情况下，就是Oracle 更新数据文件头信息
 
时（比如发生Checkpoint）。
 
  当这个等待事件很明显时，需要考虑是不是数据库中的数据文件数量太大，
导致Oracle 需要花较长的时间来做所有文件头的更新操作（checkpoint）。
 
这个等待事件有三个参数：
File#: 需要更新的数据块所在的数据文件的文件号。
Block#：需要更新的数据块号。
Blocks：需要更新的数据块数目（通常来说应该等于1）。
 
--Direct path read
  这个等待事件发生在会话将数据块直接读取到PGA当中而不是SGA中的情
况，这些被读取的数据通常是这个会话私有的数据，所以不需要放到SGA作为
共享数据，因为这样做没有意义。 这些数据通常是来自与临时段上的数据，比
如一个会话中SQL的排序数据，并行执行过程中间产生的数据，以及Hash Join，
merge join产生的排序数据，因为这些数据只对当前的会话的SQL操作有意义，
所以不需要放到SGA当中。
 
  当发生direct path read等待事件时，意味着磁盘上有大量的临时数据产生，
比如排序，并行执行等操作。 或者意味着PGA中空闲空间不足。
 
这个等待事件有三个参数：
Descriptor address:  一个指针，指向当前会话正在等待的一个direct read I/O。
First dba: descriptor address 中最旧的一个I/O 数据块地址。
Block cnt: descriptor address上下文中涉及的有效的buffer 数量。
 
--Direct path write
  这个等待事件和direct  path  read 正好相反，是会话将一些数据从PGA中直
接写入到磁盘文件上，而不经过SGA。
 
这种情况通常发生在：
  （1）使用临时表空间排序（内存不足）
  （2）数据的直接加载（使用append方式加载数据）
  （3）并行DML操作。
 
这个等待事件有三个参数：
  Descriptor address: 一个指针，指向当前会话正在等待的一个direct I/O.
  First dba: descriptor address 中最旧的一个I/O 数据块地址。
  Block cnt: descriptor address 上下文中涉及的有效地 buffer 数量。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28278387/viewspace-746612/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28278387/viewspace-746612/