比值＞3～5表明DBWR跟不上，≈1则buffer cache小或SQL物理读过多；需查AWR快照中free buffer requested与inspected值，结合write complete waits和db file parallel write等待分析I/O瓶颈，并定位高disk_reads低buffer_gets的SQL。
看AWR里free buffer requested和free buffer inspected比值
这个比值直接决定问题方向：比值 > 3～5，说明前台进程反复扫描LRU链却找不到空闲buffer，DBWR确实跟不上；比值 ≈ 1，则大概率是buffer cache太小或SQL物理读爆炸，加DBWR毫无意义。
执行以下查询获取关键指标：
SELECT name, value FROM v$sysstat WHERE name IN ('free buffer requested', 'free buffer inspected');注意：该查询需在问题时段的AWR快照中执行（比如用DBA_HIST_SYSSTAT关联SNAP_ID），不能只查当前v$sysstat——实时值可能已被后续负载冲刷失真。
核对write complete waits和db file parallel write是否共现
free buffer waits和write complete waits同时高发，且后者平均等待超20ms，基本锁定I/O子系统卡住，不是Oracle配置问题。
检查路径：
- 在AWR报告“Top 5 Timed Events”里确认
write complete waits是否排进前3，Avg wait是否>20ms - 下拉到“Wait Event Histogram”或“System I/O”部分，找
db file parallel write的Avg Wait(ms) —— 超过15ms即异常，超过100ms（如Exadata案例中11207ms）说明存储写入已瘫痪 - 若两者共现，跳过所有DBWR参数调整，直奔存储层：多路径配置、控制器队列深度、裸设备缓存开关
查SQL Statistics里disk_reads高但buffer_gets低的语句
这类SQL是free buffer waits的隐形推手：一次全表扫描可能耗尽几百个free buffer，而DBWR还没来得及刷，下一个物理读就又卡住。
重点关注AWR报告中“SQL ordered by Physical Reads”模块，筛选条件：
-
disk_reads/executions> 10000（单次执行读盘上万块） -
buffer_gets/disk_reads - 执行计划含
FULL但对应表NUM_ROWS为空或LAST_ANALYZED超30天
典型例子：SELECT /*+ FULL(t) */ * FROM config_table t WHERE status = 'A'，但config_table没统计信息，优化器误判走全扫——这种语句比慢SQL更危险，它不占CPU，但疯狂吃buffer。
别被_db_block_max_scan_pct误导
这个隐含参数调高（比如从默认40%设成60%）看似能让前台多扫一段LRU再唤DBWR，实则是把压力往后拖，还可能把冷数据块卷进扫描范围。
真正要观察的是ASH采样里的p3（set-id#）分布：
- 如果
free buffer waits事件的p3值高度集中在某几个buffer pool set（比如set 3、set 7），说明已出现局部热点，此时调参会让争用从全局蔓延成局部雪崩 - 验证方法：查
SELECT p3, COUNT(*) FROM v$active_session_history WHERE event = 'free buffer waits' GROUP BY p3 ORDER BY 2 DESC
生产环境动这个参数前，必须确认ASH里p3是离散分布的——否则你不是在调优，是在埋雷。
