ASH中db file parallel write高但I/O瓶颈仅出现在部分节点，根本原因是RAC环境存储路径不一致，如多路径配置未对齐、ASM failgroup分布不均或某节点挂载低性能LUN；需按instance_number分拆gv$active_session_history定位热点节点，再结合v$asm_disk_iostat和iostat下钻至failgroup与物理路径层验证。
为什么ASH里看到db file parallel write高，但I/O瓶颈却只在部分节点？
RAC环境下db file parallel write等待时间飙升，但v$system_event显示各节点差异极大（比如Node1平均42ms，Node3仅8ms），说明I/O路径不一致。根本原因常是存储多路径配置未对齐、ASM磁盘组failgroup分布不均，或某节点挂载了性能较差的LUN。ASH本身不记录存储层细节，所以必须用gv$active_session_history按instance_number分拆查，否则会把Node1的42ms和Node3的8ms取平均，掩盖真实热点。
怎么从ASH定位非对称写入的SQL源头？
不能直接查v$active_session_history里event = 'db file parallel write'——这个事件由DBWn触发，ASH采样时前台会话已不在该等待上。正确路径是：先锁定高db file parallel write等待的节点，再查该节点上wait_class = 'System I/O'且session_type = 'FOREGROUND'的会话，它们正因脏块刷出慢而反复触发free buffer waits，进而拖慢自身执行。关键过滤条件：
-
sample_time > SYSDATE - 1/48（聚焦最近30分钟） -
instance_number = 1（替换成实际高负载节点号） -
wait_class = 'System I/O'（排除User I/O干扰） -
event NOT IN ('log file parallel write', 'control file sequential read')（聚焦数据文件写）
查出的sql_id大概率是频繁修改小表、或批量UPDATE大表但未分批提交的语句。
db file parallel write等待时间高，但WRITE COMPLETE WAITS没起来，说明什么？
这表示DBWn进程发出了I/O请求，但操作系统或存储层响应延迟，而非Oracle内部调度问题。典型表现是：db file parallel write平均等待>15ms，而WRITE COMPLETE WAITS几乎为0。此时要立刻检查：
- 对应节点的
iostat -x 1 5输出中%util是否持续>95%，await是否>20ms - ASM磁盘组中各failgroup的
disk_read_time/disk_write_time是否严重不均（查gv$asm_disk_iostat） - 存储侧是否有LUN队列深度打满、控制器CPU过载、或FC链路误码率升高
注意：加SSD或调高db_writer_processes对此类问题无效，甚至可能加剧争用。
如何验证是不是ASM failgroup分布导致的非对称？
执行以下查询，对比各节点上同一ASM磁盘组内不同failgroup的I/O响应：
SELECT inst_id, failgroup,
ROUND(AVG(disk_write_time)/1000, 2) avg_ms,
COUNT(*) samples
FROM gv$asm_disk_iostat
WHERE group_number = (SELECT group_number FROM v$asm_diskgroup WHERE name = 'DATA')
GROUP BY inst_id, failgroup
ORDER BY inst_id, avg_ms DESC;如果发现Node1上FAILGROUP_A的avg_ms是Node2同failgroup的3倍以上，基本可断定该failgroup下的物理磁盘或路径在Node1侧存在单点瓶颈——比如Node1走的是旧HBA卡+老交换机，而Node2已升级NVMe直连。
非对称I/O最麻烦的地方在于：它让AWR报告里的“Average Wait Time”失去诊断价值，因为平均值被低负载节点拉低；必须坚持按实例、按failgroup、按采样窗口三层下钻，否则永远在修错误的问题。
