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）并尽量减少读的需求或增加缓冲的数量。在热点磁盘上通常也会出现这种事件，即使没有过量的访问。