Buffer Busy Waits是Oracle中非常经典的块级争用等待事件，它表示一个会话在访问某个数据块时，发现该块正被其他会话占用，只能等待对方释放。少量的Buffer Busy Waits属于正常现象，但当它在等待事件排行榜中名列前茅时，就意味着系统中存在严重的热点块竞争，必须及时定位并优化。本文将从原理、常见成因和针对性优化手段三个层面，系统地讲解如何减少Buffer Busy Waits。
一、理解Buffer Busy Waits的产生机制
Oracle读取数据的最小单位是数据块，默认块大小通常为8KB。当一个会话要读取或修改某个块时，需要先在Buffer Cache中申请该块的pin，如果此时另一个会话已经持有该块的pin且模式不兼容，当前会话就会注册一个Buffer Busy Waits等待。它与传统意义上的闩锁竞争不同：latch保护的是内存结构本身，而Buffer Busy Waits反映的是多个会话对同一个数据块内容的争抢。
在AWR或statspack报告中，可以通过Segments by Buffer Busy Waits这个板块快速定位争用最集中的段对象。如果某个表或索引在这里排在首位，基本可以确定热点对象。同时在会话级别，查询v$session_wait视图中的p1、p2、p3参数，可以进一步还原出文件号、块号和等待原因码，从而判断争用究竟发生在数据块、段头块还是undo块上。
不同块类型对应的等待原因各不相同。段头块争用多与freelist竞争有关，数据块争用常见于热点表随机写入集中，索引块争用则典型地表现为右置索引的顺序插入问题。只有先区分清楚块类型，后续的优化才有方向，盲目调参往往收效甚微。
二、热点块与freelist竞争的优化
对于采用手动段空间管理（MSSM）的表，插入数据时需要通过freelist寻找可用的空闲块，所有会话都从freelist头部取块，段头块自然成为竞争焦点。如果定位到的等待集中在段头，可以考虑增加freelist数量或者freelist group数量，让不同会话分散到不同的空闲块链表上。
更彻底的做法是将表迁移到自动段空间管理（ASSM）的表空间上。ASSM使用位图而非freelist管理空闲空间，Oracle会自动将插入操作分散到多个块上，段头争用问题基本可以消除。迁移可以通过ALTER TABLE ... MOVE实现，示例如下：
-- 查询表当前所在表空间及段空间管理方式 SELECT table_name, tablespace_name FROM user_tables WHERE table_name = 'T_ORDER'; -- 将表移动到ASSM表空间（会锁表，需在维护窗口执行） ALTER TABLE t_order MOVE TABLESPACE ts_assm; -- 重建该表上的索引（MOVE后索引会失效） ALTER INDEX idx_order_no REBUILD;
另一个关键参数是PCTFREE和PCTUSED。PCTFREE设置过小会导致行迁移增加，PCTUSED设置过大则会让块频繁在可用与不可用之间切换，加剧块头的修改频率。适当降低PCTUSED、合理设置PCTFREE，可以让每个块容纳更少的行，从而让数据分布到更多块中，降低单块的访问密度。对于并发插入非常高的表，还可以配合设置多个insert并发入口的分区设计，将写入压力物理隔离开。
三、索引块争用与右置索引问题
使用序列或者自增数值作为主键是常见的开发习惯，这类值始终递增，所有新行都会被插入到索引最右侧的叶子块，也就是所谓的右置索引问题。并发插入越多，最后几个叶子块的争用越激烈，AWR中会看到索引相关的Buffer Busy Waits居高不下。
最直接的解决方案是使用反向索引。反向索引将键值的字节顺序反转，让原本连续的值散列到索引的不同分支上，插入压力被分散到整个索引结构中：
-- 重建为反向索引 ALTER INDEX idx_order_id REBUILD REVERSE;
但反向索引的代价是不再支持索引范围扫描，等值查询依然高效，而范围查询（如BETWEEN、大于小于）无法利用它，必须全索引扫描。因此需要结合业务查询模式权衡。如果范围查询不可避免，更好的方案是改用HASH分区表并将索引建为本地分区索引，或者从应用层入手，比如采用带随机偏移的序列号、按会话取不同的序列缓存等方式打散键值的单调性。
此外，索引块的INITRANS和MAXTRANS也会影响并发。默认INITRANS为2，事务槽不足时块会动态扩展，但扩展期间其他事务必须等待。对高并发修改的索引，适当提高INITRANS（如设置为10以上），可以预留更多事务槽，减少动态扩展带来的块争用。表上的数据块同理，高并发表也可以适度提高INITRANS。
四、综合定位与预防策略
优化不能只靠猜，建立完整的定位流程非常重要。第一步通过AWR报告确认Buffer Busy Waits在DB Time中的占比和变化趋势；第二步利用Segments by Buffer Busy Waits确认热点对象；第三步结合对象类型选择对应手段，表看空间管理和参数设置，索引看键值分布和访问模式；第四步在优化后持续观察等待事件的变化，形成闭环。
除了技术手段，架构层面的预防同样关键。对于超高频写入的表，评估是否需要按业务维度做分区或分表；对于读写混合严重的热点数据，考虑引入缓存层挡住一部分读压力；对于批量作业，尽量安排在业务低峰执行，避免与在线交易争抢块资源。写入模式上，避免大量会话集中更新同一行所在的块，比如热点账户类的行级争用，可以通过逻辑拆分、异步汇总等方式改造。
最后要强调的是，Buffer Busy Waits往往与其他等待事件伴生出现，比如log file sync、gc buffer busy等。在RAC环境中，跨节点的块争用会表现为gc buffer busy acquire或gc buffer busy release，处理思路与单实例类似，但还要额外考虑应用分区，让不同节点尽量访问不同的数据子集，从源头减少跨节点块传递。综合运用参数调整、对象改造和架构优化，才能持续保持数据库在高压并发下的稳定表现。
Oracle Buffer Busy Waits等待事件优化数据库性能调优修改时间：2026-09-01 16:10:41