write complete waits高本质是前台进程等待dbwr释放正被独占持有的缓冲区，直接暴露写入链路阻塞；平均等待>20ms即可断定i/o子系统瓶颈，需用dd测裸设备验证，并检查多路径、队列深度及文件系统缓存配置。
write complete waits高，先看是不是存储卡在写入路径上
这个等待事件的本质是：前台进程想读/改一个缓冲区，但该缓冲区正被DBWR以独占模式持有（正在往磁盘写脏块），只能等DBWR释放——所以它直接暴露的是“写入链路阻塞”，而非Buffer Cache内存不足或SQL低效。
关键判断依据是平均等待时间：write complete waits单次平均 > 20ms 就基本可断定问题出在I/O子系统。此时必须绕过Oracle层验证裸设备吞吐：
- 用
dd if=/dev/zero of=/dev/raw_device bs=1M count=1024 oflag=direct测裸设备顺序写IOPS和延迟，结果若远低于预期（比如SSD标称写延迟15ms），说明存储配置或硬件已成瓶颈 - 检查多路径配置：是否启用了ALUA？主控器队列深度是否设得太低（常见陷阱是设为8，而实际需要64+）
- 确认文件系统缓存是否关闭：若数据文件建在ext4/xfs上且未挂
noatime,nobarrier,dioread_nolock等选项，Oracle的direct I/O可能被二次缓冲，导致落盘不可控
和free buffer waits共现时，优先查db file parallel write
当 write complete waits 和 free buffer waits 同时飙升，且前者平均等待超20ms，后者比值（free buffer inspected ÷ free buffer requested）又>5，说明DBWR写不出去，LRU扫描效率崩塌——但根因不在DBWR数量，而在写入通路本身卡死。
立刻查 v$system_event 中 db file parallel write 的平均等待时间：
- >15ms → 存储响应慢，DBWR再快也无用；加DBWR进程只会加剧latch争用
- 注意：不要只看AWR报告里“Top Events”的绝对等待次数，要盯住“Avg Wait(ms)”列，它才是真实延迟信号
DBWR写不下去，别急着调_db_writer_processes
Oracle 19c默认按CPU核心数自动配置DBWR（每8核1个），硬设为16或32反而容易引发 cache buffers lru chain 或 db writer list latch 争用。尤其当ASH中发现 write complete waits 的 p1（file#）和 p2（block#）高度集中在少数几个数据文件时，说明是局部I/O热点，不是全局吞吐问题。
更有效的动作是：
- 检查这些文件所在ASM diskgroup的条带化策略：是否误配为
UNIFORM而非FINE？是否混用不同性能的磁盘（如SATA+NVMe）？ - 运行
select * from v$asm_disk_iostat，看IO等待是否集中在某几块物理盘；若有，替换或剔除故障盘 - 确认DBWR是否被其他后台进程抢占：比如归档进程（ARCn）大量写归档日志，与DBWR竞争I/O带宽
容易被忽略的隐性瓶颈：redo log写入链路干扰
DBWR写脏块依赖检查点推进，而检查点推进又受LGWR刷重做日志速度制约。如果 log file sync 平均等待也偏高（>10ms），说明LGWR写redo慢，导致增量检查点无法及时推进，DBWR就只能反复写同一波老脏块——这会把 write complete waits 拖得更长。
验证方法：
- 查
v$sysstat中redo log space requests是否持续增长：是则说明log buffer太小或redo日志组太小、切换太频 - 看
v$log中STATUS是否频繁出现ACTIVE而非INACTIVE：表明LGWR跟不上事务提交节奏 - 不要只盯着redo日志文件大小，更要检查其所在磁盘是否与datafile共用同一LUN或阵列控制器
