Buffer Busy Waits

Buffer Busy Waits的原因

       有很多原因导致一个会话等待buffer busy，并且随着时间的推移，该事件包含了全部的原因。

       如果一个会话希望检查一个数据块，第一步是检查它是否在内存中。最常见的事件发生顺序如下：

1.         计算哈希桶/链id；

2.         争夺相关的缓存缓冲链latch；

3.         查找哈希桶/链；

4.         如果找到了并且当前没有保持在不兼容模式，则pin缓冲头；

5.         删除latch；

6.         使用缓冲；

7.         争夺latch；

8.         Unpin缓冲头；

9.         删除latch；

为了pin一个缓冲，会话在缓冲头上创建一个缓冲处理器并将其链接到保持者队列（通

过x$bh.us_nxt和x$bh.us_prv可见）。



等待其他会话读取块（p3 = 130）

       在这种情况下，查找哈希桶指示缓冲不在内存中，因此会话得到一个空缓冲，将其附属到哈希链，设置缓冲头指向该缓冲，以排斥模式pin缓冲头，然后删除latch。此时会话可以从磁盘读取数据块。

       此时如果第二个会话想要使用相同的块，它将会计算恰当的哈希链，争夺latch，查找正确的缓冲头。但是缓冲头将在排斥模式被pin，因此第二个会话将创建一个pin结构，并且附属到在等待者队列上的缓冲头上（通过x$bh.wa_nxt和x$bh.wa_prv可见），然后删除latch，在buffer busy waits上等待。

       当一个会话在buffer busy waits上等待时，知道其意义是非常重要的—会话在一个缓冲头等待队列上有一个pin结构。

       'wait for other session to finish a read'是buffer busy等待的一个很常见的原因，在10g中以一个独立的事件出现（read by other session），但是这个事件没有在v$segstat中体现出来。

       为了看见该事件，可以在多个会话上执行磁盘扫描很大的查询：

       select source from sys.source$ where source = 'xxxx';

      

       为了解决p3 = 130的情况，关键的策略是识别出并发，I/O的对象（通过V$SEGSTAT）并尽量减少读的需求或增加缓冲的数量。在热点磁盘上通常也会出现这种事件，即使没有过量的访问。