尤其是在Oracle STATSPACK报告的前五个忙等待的读(顺序/分散)系统中，如前5个定时事件：
% 总和事件 等待 时间(s) 消逝时间
----------------------- ------------ ----------- -----------
db文件顺序读 2,598 7,146 48.54
db文件分散读 25,519 3,246 22.04
库缓冲区载入死锁 673 1,363 9.26
CPU时间 2,154 934 7.83
日志文件平行写 19,157 837 5.68
减轻缓冲区忙等待的主要方式是减少系统中的I/O，这可以通过SQL使用更少的块读(block reads，比如添加索引)的方式得以实现。即使对于一个比较大的db_cache_size，我们也可以减少缓冲区忙等待的时间。
为了能够查看整个系统的等待事件，我们可以查阅v$system_event性能视图。这一性能视图提供了等待事件的名称，等待事件与时间的总和，以及每一事件的平均等待时间。
可以通过v$waitstat视图来查询导致等待的缓冲区的类型。这一视图列出了每一缓冲区类型的等待，COUNT是类所有的等待总和，TIME是这一类所有等待的时间总和，如下所示：
select * from v$waitstat;
类 COUNT TIME
------------------ ---------- ----------
data block 1961113 1870278
segment header 34535 159082
undo header 233632 86239
undo block 1886 1706
当一个session访问缓冲区的块时，就有可能产生缓冲忙等待。这一缓冲区忙等待的产生可能由以下的原因造成的：
块可能被其它的session读到缓冲区，所以session必须等待块的读入结束。
session可能有与等待的session查询不协调的缓冲块。
由于缓冲区忙等待是由不同特定的块之间的竞争而造成的，所以只能通过识别哪些块发生冲突和冲突产生的原因，你才有可能做出判断，相应的调整包括识别和消除块竞争的原因。
v$session_wait性能视图，提供了识别等待产生原因的方法。
v$session_wait视图的列代表的缓冲区忙等待事件如下：
P1―与等待相关的数据文件的全部文件数量。
P2―P1中的数据文件的块数量。
P3―描述等待产生原因的代码。
这里是一个这些值的Oracle数据词典查询:
select
p1 "File #".
p2 "Block #",
p3 "Reason Code"
from
v$session_wait
where
event = 'buffer busy waits';
如果以上查询的结果显示一个块在忙等待，以下的查询将显示这一块的名称和类型：
select
owner,
segment_name,
segment_type
from
dba_extents
where
file_id = &P1
and
&P2 between block_id and block_id + blocks -1;
一旦这一块被识别，v$segment_statistics性能视图促使块水平统计的实时监控。这一过程使得DBA识别与独立列表与索引有关的问题。
我们也可以查询dba_data_files以确定卷入等待的文件的file_name，方法是使用v$session_wait中的P1。
从v$session_wait中查询P3(原因编码)的值可以知道session等待的原因。原因编码的范围从0到300，并可以解码。
在一个SCUR或XCUR缓冲区产生且没有结束的改变。
0 块被读入缓冲区。
100 我们想要NEW(创建)一个块，但这一块当前被另一session读入。
110 我们想将当前块设为共享，但这一块被另一session读入，所以我们必须等待read()结束。
120 我们想获得当前的块，但其他人已经将这一块读入缓冲区，所以我们只能等待他人的读入结束。
130 块被另一session读入，而且没有找到其它协调的块，所以我们必须等待读的结束。缓冲区死锁后这种情况也有可能产生。所以必须读入块的CR。
200 我们想新创建一个block，但其他人在使用，所以我们只好等待他人使用结束。
210 Session想读入SCUR或XCUR中的块，如果块交换或者session处于非连续的TX模式，所以等待可能需要很长的时间。
220 在缓冲区查询一个块的当前版本，但有人以不合法的模式使用这一块，所以我们只能等待。
230 以CR/CRX方式获得一个块，但块中的更改开始并且没有结束。
231 CR/CRX扫描找到当前块，但块中的更改开始并且没有结束。
原因编码
正如我在开始时所说的那样，缓冲区忙等待是I/O bound系统中最常见的现象。数据块等待导致的I/O竞争通常是由当扫描相同的索引时，多个session重复读入相同的块。在这样的情况下，session 1快速扫描缓冲区的块，然后块从磁盘被读入。当session 1等待磁盘读完成过程中，其它块扫描相同的索引，并很快捕捉session 1，并想从磁盘上读入相同的块。由此产生了缓冲区忙等待。
以下规则有助于解决提及的当处于竞争时的情况：
数据块竞争―通过改变PCTFREE或者PCTUSED值来识别和消除程序中的HOT块，以减少数据块的数量。
Freelist块竞争―增加FREELISTS值，当使用Parellel服务器时，一定确保每一事例有自己的FREELIST GROUPs。
Segment header竞争―增加FREELISTS值，并使用FREELIST GROUPs。
Undo header块―增加回滚段(rollback segments)的数量。
好处
缓冲区忙等待的识别和解决是比较复杂和棘手。Oracle提供了v$segment_statistics视图有助于监视缓冲区忙等待。当能够正确地识别和修正缓冲区忙等待的原因时，你所努力的付出一定会得到回报的。
% 总和事件 等待 时间(s) 消逝时间
----------------------- ------------ ----------- -----------
db文件顺序读 2,598 7,146 48.54
db文件分散读 25,519 3,246 22.04
库缓冲区载入死锁 673 1,363 9.26
CPU时间 2,154 934 7.83
日志文件平行写 19,157 837 5.68
减轻缓冲区忙等待的主要方式是减少系统中的I/O，这可以通过SQL使用更少的块读(block reads，比如添加索引)的方式得以实现。即使对于一个比较大的db_cache_size，我们也可以减少缓冲区忙等待的时间。
为了能够查看整个系统的等待事件，我们可以查阅v$system_event性能视图。这一性能视图提供了等待事件的名称，等待事件与时间的总和，以及每一事件的平均等待时间。
可以通过v$waitstat视图来查询导致等待的缓冲区的类型。这一视图列出了每一缓冲区类型的等待，COUNT是类所有的等待总和，TIME是这一类所有等待的时间总和，如下所示：
select * from v$waitstat;
类 COUNT TIME
------------------ ---------- ----------
data block 1961113 1870278
segment header 34535 159082
undo header 233632 86239
undo block 1886 1706
当一个session访问缓冲区的块时，就有可能产生缓冲忙等待。这一缓冲区忙等待的产生可能由以下的原因造成的：
块可能被其它的session读到缓冲区，所以session必须等待块的读入结束。
session可能有与等待的session查询不协调的缓冲块。
由于缓冲区忙等待是由不同特定的块之间的竞争而造成的，所以只能通过识别哪些块发生冲突和冲突产生的原因，你才有可能做出判断，相应的调整包括识别和消除块竞争的原因。
v$session_wait性能视图，提供了识别等待产生原因的方法。
v$session_wait视图的列代表的缓冲区忙等待事件如下：
P1―与等待相关的数据文件的全部文件数量。
P2―P1中的数据文件的块数量。
P3―描述等待产生原因的代码。
这里是一个这些值的Oracle数据词典查询:
select
p1 "File #".
p2 "Block #",
p3 "Reason Code"
from
v$session_wait
where
event = 'buffer busy waits';
如果以上查询的结果显示一个块在忙等待，以下的查询将显示这一块的名称和类型：
select
owner,
segment_name,
segment_type
from
dba_extents
where
file_id = &P1
and
&P2 between block_id and block_id + blocks -1;
一旦这一块被识别，v$segment_statistics性能视图促使块水平统计的实时监控。这一过程使得DBA识别与独立列表与索引有关的问题。
我们也可以查询dba_data_files以确定卷入等待的文件的file_name，方法是使用v$session_wait中的P1。
从v$session_wait中查询P3(原因编码)的值可以知道session等待的原因。原因编码的范围从0到300，并可以解码。
在一个SCUR或XCUR缓冲区产生且没有结束的改变。
0 块被读入缓冲区。
100 我们想要NEW(创建)一个块，但这一块当前被另一session读入。
110 我们想将当前块设为共享，但这一块被另一session读入，所以我们必须等待read()结束。
120 我们想获得当前的块，但其他人已经将这一块读入缓冲区，所以我们只能等待他人的读入结束。
130 块被另一session读入，而且没有找到其它协调的块，所以我们必须等待读的结束。缓冲区死锁后这种情况也有可能产生。所以必须读入块的CR。
200 我们想新创建一个block，但其他人在使用，所以我们只好等待他人使用结束。
210 Session想读入SCUR或XCUR中的块，如果块交换或者session处于非连续的TX模式，所以等待可能需要很长的时间。
220 在缓冲区查询一个块的当前版本，但有人以不合法的模式使用这一块，所以我们只能等待。
230 以CR/CRX方式获得一个块，但块中的更改开始并且没有结束。
231 CR/CRX扫描找到当前块，但块中的更改开始并且没有结束。
原因编码
正如我在开始时所说的那样，缓冲区忙等待是I/O bound系统中最常见的现象。数据块等待导致的I/O竞争通常是由当扫描相同的索引时，多个session重复读入相同的块。在这样的情况下，session 1快速扫描缓冲区的块，然后块从磁盘被读入。当session 1等待磁盘读完成过程中，其它块扫描相同的索引，并很快捕捉session 1，并想从磁盘上读入相同的块。由此产生了缓冲区忙等待。
以下规则有助于解决提及的当处于竞争时的情况：
数据块竞争―通过改变PCTFREE或者PCTUSED值来识别和消除程序中的HOT块，以减少数据块的数量。
Freelist块竞争―增加FREELISTS值，当使用Parellel服务器时，一定确保每一事例有自己的FREELIST GROUPs。
Segment header竞争―增加FREELISTS值，并使用FREELIST GROUPs。
Undo header块―增加回滚段(rollback segments)的数量。
好处
缓冲区忙等待的识别和解决是比较复杂和棘手。Oracle提供了v$segment_statistics视图有助于监视缓冲区忙等待。当能够正确地识别和修正缓冲区忙等待的原因时，你所努力的付出一定会得到回报的。
闽公网安备 35060202000074号