Oracle中如何解决BUFFER BUSY WAITS

和BUFFER CACHE相关的常见等待事件还有BUFFER BUSY WAITS。顾名思义，BUFFER BUSY WAITS等待事件指的是多个会话不能共享缓冲区中的数据块而引发的等待事件。
发生BUFFER BUSY WAITS事件时，P1值代表数据文件号，P2值代表数据块号，P3值代表数据块类型（Oracle 9i为发生BUFFER BUSY WAITS等待事件的原因码）。表8-2显示了P3对应的数据块类型。

为了便于理解，从Oracle 10g开始，BUFFER BUSY WAITS等待事件又细分为如下两个等待事件：
BUFFER BUSY WAITS等待事件。最常见的情况是阻塞会话（BLOCKING会话）正在修改数据块时，想以当前模式访问的会话需要等待。实践表明，手动段管理方式（MSSM，即用FREELIST管理可用数据块）管理方式的段头在并发INSERT操作时容易引起争用。
READ BY OTHER SESSION等待事件。最常见的情况是一个以上的会话欲访问高速缓冲区上不存在的数据块时，发现该数据块正在被另外一个会话从磁盘读往缓冲区。在这种情况下，正在读取数据块的会话会出现DB FILE SEQUENTIAL READ或者DB FILE SCATTERED READ等待事件，其他的会话则出现READ BY OTHER SESSION等待事件。也就是说，READ BY OTHER SESSION等待事件往往伴随着DB FILE SEQUENTIAL READ或者DB FILE SCATTERED READ等待事件出现。图8-6中的AWR报告数据来自某客户数据库。

                   图8-6 AWR报告中的部分数据

很多情况下，要短时间内快速定位引起性能故障的SQL语句往往比较困难。因为Oracle是一台巨大的同步机器，牵一发而动全身，也就是说一个普通的“热”块有可能会导致全库级的性能故障。比如当一个“热”块导致CACHE BUFFERS CHAINS LATCH争用时，会使得该LATCH保护下的所有BUCKET下的数据块访问都出现性能问题。也就是说某个业务模块中一个不重要的SQL就有可能导致所有核心业务模块都出现问题。由于生产数据库中往往运行着复杂的业务，因此各种SQL语句可能会相互影响而产生各种等待事件。图8-7中的AWR报告数据来自某客户数据库。

在这种场景下，要快速定位问题的根本原因就显得比较困难了。如何抓住“蝴蝶效应”中那只蝴蝶的翅膀就显得非常关键。很多有经验的DBA在遇到此类问题时（排除了系统执行计划导致性能问题的可能性），为了避免引起更大的损失，在收集完现场数据之后，往往首先采取的操作是KILL所有异常会话，以便快速恢复系统。至于故障原因可事后再分析。
提示 不建议通过重启数据库来解决性能故障。数据库重启之后，很多保存在V$动态视图的内容就会重置，这给故障分析带来极大的困难。所以应该优先选择KILL所有的业务会话。