ash查不到dbwr等待因其多数时间睡眠不被采样，应通过前台会话的free buffer waits、db file parallel write及enq: fb - contention等连锁事件间接定位dbwr瓶颈。
ASH里查不到DBWR的等待？先确认采样逻辑
ASH（v$active_session_history）默认每秒采样一次活动会话，但**DBWR进程大部分时间处于“非活动”状态**——它在写完一批脏块后会主动睡眠（通常3秒），期间不被采样；只有在发起I/O并等待完成的那几十毫秒内才可能被捕获。所以直接SELECT * FROM v$active_session_history WHERE program = 'ora_dbw0_...'大概率查不到记录，这不是DBWR没压力，而是ASH根本“看不见”它睡觉前后的空档。
真正能反映DBWR是否滞后的是前台进程的反应：如果大量会话卡在free buffer waits或反复扫描LRU链，ASH里会密集出现free buffer inspected高、free buffer requested也高的组合，这才是DBWR跟不上节奏的间接证据。
用ASH定位DBWR瓶颈的正确路径
别盯着DBWR本身，盯它引发的连锁反应。关键动作是查那些因缺buffer而卡住的前台会话堆栈：
- 执行
SELECT sql_id, event, p1text, p1, p2text, p2, session_state FROM v$active_session_history WHERE event = 'free buffer waits' AND sample_time > SYSDATE - INTERVAL '5' MINUTE ORDER BY sample_time DESC;——若p1（即buffer pool set id）集中在少数几个值（如1、2、3），说明buffer pool局部热点，DBWR线程在特定set上争用严重 - 同时查
SELECT sql_id, event, wait_class FROM v$active_session_history WHERE event IN ('db file parallel write', 'write complete waits') AND sample_time > SYSDATE - INTERVAL '5' MINUTE;——如果这两类事件和free buffer waits在相同时间窗口高频共现，且db file parallel write的p1（file#）集中在同一组数据文件（比如users表空间），基本锁定是存储写入能力不足，不是DBWR配置问题 - 注意
session_state：若大量free buffer waits会话的session_state是WAITING而非ON CPU，说明瓶颈确实在I/O路径，而非CPU或Latch
为什么db file parallel write平均等待时间比ASH更可靠
db file parallel write的平均等待时间（Avg Wait ms）来自v$system_event或AWR报告，是DBWR真实I/O耗时的聚合统计，不受采样丢失影响。而ASH里即使捕获到一次db file parallel write，也只能看到单次等待，无法反映趋势。
当db file parallel write Avg Wait > 15ms，且与free buffer waits共现时，优先排查存储层：裸设备dd if=/dev/zero of=/dev/raw_device bs=1M count=1024 oflag=direct测出的IOPS是否达标；多路径是否均衡；控制器队列深度是否设得太低。硬调db_writer_processes参数反而可能加剧latch争用——Oracle 11g+已按CPU数自动配比，手动设为8或16常适得其反。
容易被忽略的隐性信号：ASH里的enq: FB - contention
这个事件极少进Top 5，但它代表多个进程在争抢file bitmap块（位图块用于跟踪空闲空间）。一旦批量INSERT或UPDATE触发大量空间分配，DBWR写完脏块后要更新对应数据文件的位图，此时若位图块未缓存或被锁住，就会卡在这里。ASH中若发现enq: FB - contention与free buffer waits在相同时间段集中出现，且p1（file#）一致，说明问题不在DBWR写速，而在文件空间管理机制被拖慢——该查v$segment_statistics里对应表空间的space used增长速率，以及是否启用了ASSM自动段管理。
