free buffer waits高但dbwr cpu低说明i/o路径阻塞，非dbwr不干活而是被卡在写入链路；需检查异步i/o是否启用、db file parallel write平均等待是否超15ms、free buffer inspected/requested比值是否＞5，并排查存储配置、sql物理读及buffer cache大小。
free buffer waits高但DBWR CPU低，说明I/O路径卡住了
这不是DBWR没干活，而是它被堵在写入链路上。典型表现是AWR里free buffer waits每秒持续超100ms，但v$process查ora_dbw*线程CPU占用很低，同时db file parallel write平均等待远超15ms（比如报告里出现11207ms这种量级）。这时候别急着加db_writer_processes，先确认异步I/O开了没。
-
show parameter disk_asynch_io必须返回TRUE -
lsmod | grep aio得看到内核AIO模块已加载 - 文件系统挂载选项要含
async（XFS默认支持；ext4需显式加barrier=1,commit=30） - 若用ASM，
asm_diskstring指向的设备udev规则里得带OPTIONS="aio"
free buffer inspected / free buffer requested比值＞5，DBWR确实跟不上了
执行SELECT name, value FROM v$sysstat WHERE name IN ('free buffer requested','free buffer inspected');，算出比值。大于3～5就说明前台进程反复扫LRU链却找不到可重用buffer——脏块堆在cache里没被及时拉走。这时重点不是加DBWR数量，而是看I/O吞吐是否撑得住。
- 查AWR“I/O Profile”部分：
Physical writes÷Write requests若接近1:1，说明写请求太碎，优先调大db_block_size或改应用批量逻辑 - 比值接近1时，问题在buffer cache过小或SQL物理读爆炸，加DBWR毫无意义
-
db_writer_processes设太高（如硬配8或16）反而引发cache buffers lru chain争用
free buffer waits和write complete waits共现，八成是存储配置翻车
两个事件同时飙高，且write complete waits平均等待超20ms，基本锁定存储层。Exadata上常见真凶是“自动磁盘擦洗”开着，征期高峰IO被吃光；FlashCache配成WriteThrough模式，脏块必须刷到机械盘才返回，绕过了闪存加速。
- 用
dd if=/dev/zero of=/dev/raw_device bs=1M count=1024 oflag=direct测裸设备IOPS，确认是不是Oracle层之外的问题 - 多路径配置不当或存储控制器队列深度设得太低，也会导致同样现象
- 文件系统缓存未关闭，Oracle写请求被二次缓冲，实际落盘延迟不可控
_db_block_max_scan_pct调高只是把压力往后推
这个隐含参数控制前台进程扫描LRU链的上限百分比（11g默认40%）。设成60%看似能多扫一段再唤DBWR，但实际只是把争用推迟爆发——脏块总量没变，单次查找时间变长，还可能把冷数据块也卷进扫描范围。
更危险的是，它不解决根本吞吐，只转移争用位置：ASH里若发现free buffer wa后面跟着大量latch: cache buffers lru chain，就是这个参数在捣鬼。真正该动的，是I/O子系统能力、SQL效率或buffer cache sizing，而不是这个饮鸩止渴的开关。
