Free Buffer Waits是Oracle数据库中一个与缓冲区缓存空间管理紧密相关的等待事件。当服务器进程需要在缓存中读取或构造一个新块，却发现LRU链表中没有足够的空闲缓冲区可用时，就会进入该等待。此时进程通常需要先将脏缓冲区写出到磁盘，以释放空间，但这一过程会受到DBWR进程的工作效率、存储系统的响应速度以及检查点行为等多重影响。在AWR报告中，如果Free Buffer Waits占据较高的Top等待事件占比，往往意味着数据库的写I/O链路或缓存配置存在需要关注的短板。
Free Buffer Waits的触发机制
理解Free Buffer Waits首先要从Oracle缓冲区缓存的LRU机制说起。服务器进程在需要读取数据块时，会向缓冲区缓存申请空闲缓冲区；如果LRU辅助链表上可用的缓冲区数量不足，进程会触发LRU写查找，扫描主LRU链表中已经修改的脏块，并请求DBWR进程将其写出。前台进程并不能直接写出脏块，而是需要等待DBWR完成写操作后回收空间。如果DBWR进程繁忙或存储写入效率过低，前台进程就会在free buffer waits事件上累积等待。
这一机制与buffer busy waits不同，后者是多个会话争用同一个缓冲区的并发冲突，而Free Buffer Waits关注的是缓存整体空闲空间不足的问题。在RAC环境下，一个实例的Free Buffer Waits还可能与跨实例的Cache Fusion交互有关，但多数场景下单实例的存储I/O和DBWR配置是更常见的诱因。数据库如果频繁出现检查点，例如由重做日志切换或FAST_START_MTTR_TARGET设置过小引起，会要求DBWR集中写出大量脏块，从而加剧空闲缓冲区的短缺。
定位Free Buffer Waits的常用方法
要定位Free Buffer Waits的根源，可以先从系统级等待统计入手。通过查询V$SYSTEM_EVENT视图，可以看到该事件的累计等待次数和平均等待时间。如果平均等待时间明显高于正常值，说明单次等待的时长已经影响到用户体验。进一步查询V$SESSION_EVENT或V$SESSION视图，可以定位到当前正在等待的前台会话及其对应的SQL语句，便于判断是否由某类特定的读写操作引发。
下面的SQL可以列出系统中Free Buffer Waits事件的总体指标：
SELECT event, total_waits, time_waited_micro,
ROUND(time_waited_micro / DECODE(total_waits, 0, 1, total_waits), 2) AS avg_wait_us
FROM v$system_event
WHERE event = 'free buffer waits';
对于会话级别的定位，可以使用以下语句观察当前正在经历该等待的会话及其执行的SQL_ID：
SELECT s.sid, s.serial#, s.username, s.event, s.seconds_in_wait,
s.sql_id, s.machine, s.program
FROM v$session s
WHERE s.event = 'free buffer waits'
ORDER BY s.seconds_in_wait DESC;
除了会话和系统视图，AWR报告中的Top 5 Timed Events、Wait Classes和Instance Activity统计也能提供关键线索。重点观察DBWR相关统计值，例如physical writes、DBWR checkpoints、background checkpoints等是否异常偏高。同时需要检查存储层的I/O响应时间，因为DBWR写出慢通常直接反映为存储延迟升高。
从实例参数与存储角度进行优化
针对Free Buffer Waits的优化措施需要建立在准确定位的基础上。如果DBWR进程数量不足，无法并行处理多个数据文件的写请求，可以适当增加DB_WRITER_PROCESSES参数。不过需要注意的是，在Oracle 12c及之后的版本中，数据库默认会根据CPU数量自动派生多个DBW进程，此时手动调整该参数可能不再适用。可以通过V$BGPROCESS视图查看当前实际运行的DBW进程数量以及它们各自的状态。
存储层面的优化往往比单纯增加DBWR更有效。如果存储设备的写带宽或IOPS有限，即便增加更多DBWR进程，它们也只是在队列中等待，并不能从根本上减少等待时间。此时应当考虑使用更高性能的存储介质、增加磁盘数量、优化RAID配置或调整文件系统挂载选项。对于使用ASM的环境，检查磁盘组的冗余级别和条带化设置也很有必要。此外，操作系统级别的异步I/O是否启用，对DBWR的写效率也有显著影响，可以通过数据库参数FILESYSTEMIO_OPTIONS或DISK_ASYNCH_IO进行确认。
另一个常见优化点是降低脏块生成的速率。高并发的大量更新操作会快速耗尽缓冲区，即使DBWR高效工作也可能无法及时跟上。此时通过SQL调优减少不必要的物理写，例如合并批量更新、增加合适的索引以减少全表扫描产生的脏块，或者将部分大事务拆分，都能有效缓解缓存压力。对于可接受数据延迟的场景，还可以考虑使用ALTER TABLE ... CACHE或调整表的存储参数，但需谨慎评估缓存命中率的变化。
常见误判与验证思路
不少DBA在遇到Free Buffer Waits时，第一反应是加大缓冲区缓存，认为空间扩大了自然就不会等待。这种思路并不完全正确。如果写入瓶颈在于DBWR进程本身或存储吞吐能力，单纯扩大缓冲区缓存反而可能导致DBWR需要管理的脏块数量增多，写出压力更大，甚至使等待时间进一步恶化。正确做法是先收集AWR和操作系统层面的I/O数据，判断瓶颈到底在CPU、内存还是存储。
还有的团队会盲目增加DBWR进程，但忽略了数据库写进程的等待事件。可以通过查询V$SESSION中属于DBW后台进程的等待事件来验证它们是否也卡在I/O等待上。下面语句可以辅助判断DBWR进程自身的等待分布：
SELECT p.name, s.event, s.total_waits, s.time_waited_micro FROM v$session s, v$bgprocess p WHERE p.paddr = s.paddr AND p.name LIKE 'DBW%' ORDER BY p.name;
如果DBWR进程的主要等待事件集中在db file parallel write或direct path write等I/O相关事件，说明存储响应才是核心问题。反之，如果DBWR进程的等待很少但前台进程仍然等待Free Buffer Waits，可能需要检查LRU链表的扫描效率或是否存在大量的脏块散射写。此时启用多个缓冲池或将热点对象分离到KEEP池，也可能带来改善。
在实际生产环境中，Free Buffer Waits经常与日志切换、检查点、存储抖动等同时出现。建立一套包含AWR快照、操作系统sar/iostat和存储监控的基线数据，能够帮助DBA在问题复现时快速对比差异，找到真正的性能拐点。通过持续观察DBWR写速率、平均等待时间和等待次数变化趋势，可以评估优化措施是否真正有效。
Oracle Free Buffer Waits等待事件性能优化修改时间：2026-09-25 22:26:01