不能只盯archived log file write等待事件，因其在Oracle 19c后已从Top 5移除且极少触发；归档延迟多为静默积压，需通过log file parallel write>15ms、log file sync显著高于parallel write、archived redo log writes/redo writes比值<0.8三者交叉验证。
AWR报告里没有“归档日志写入延迟”这个直接指标，但可通过 log file sync、log file parallel write 和归档相关系统统计三者交叉验证——单看任一指标都容易误判。
为什么不能只盯 archived log file write 等待事件
Oracle 19c 及以后版本中，archived log file write 等待事件已从默认 Top 5 中移除，且该事件本身极少出现（仅在归档进程 ARCH 直接写归档目标失败时触发）。实际生产中，归档延迟往往静默发生：ARCH 进程持续追不上 LGWR 的生成速度，但自身不报等待。常见现象是 archive_lag_target 频繁超时、DG 延迟上涨、或 v$archived_log 中 first_time 与 next_time 时间差拉长，而 AWR 却“一切正常”。
真正要查的三个关键信号
归档写入是否滞后，本质是“LGWR 写得快，ARCH 跟得慢”，所以必须比对两端：
-
log file parallel writeAvg Wait (ms) 持续 >15 ms → LGWR 写盘已卡，ARCH 必然积压（但需先排除 RAID 5、同盘混放等配置错误） -
log file syncAvg Wait (ms) 明显高于log file parallel write（例如前者 22 ms，后者 8 ms）→ 问题不在磁盘，而在 ARCH 未及时消费 redo；此时查v$archive_dest_status的status和error字段，重点关注STANDBY_LOGFILE或DESTINATION是否为ERROR - 系统统计中
archived redo log writes/redo writes比值持续
归档目录 I/O 必须单独验证，AWR 不覆盖
AWR 的 IO Stats 默认只统计数据文件、日志文件和控制文件，**不包含归档目录所在文件系统**。即使归档目录挂载在高延迟 NFS 或满载 SSD 上，AWR 也不会体现。必须人工确认：
- 归档路径物理位置：
SELECT destination FROM v$archive_dest WHERE status = 'VALID' AND target = 'PRIMARY'; - 对应文件系统负载（Linux）：
iostat -x 1 5查该挂载点的%util和w_await；若w_await > 20 ms且%util > 90%，归档写入必然拖慢 - 检查挂载参数：
mount | grep "your_archive_fs"，确保含noatime、barrier=0（ext4）或nobarrier（xfs），否则日志同步开销翻倍
最易被忽略的点：归档模式本身不是瓶颈，但归档策略会放大问题
比如启用了 archive_lag_target=1800（30 分钟），但业务峰值期每 2 分钟就切一次日志，ARCH 实际要每 2 分钟归档一次——这会导致它频繁唤醒、小块写、无法合并 IO。此时 log file parallel write 可能正常，但归档延迟已悄然累积。真正该调的是日志大小（让切换间隔接近 lag_target）或关闭该参数，而非升级存储。
