AWR不能直接诊断Data Guard传输延迟，因其不采集LGWR发送耗时、TCP重传等网络指标，也无对应等待事件；应重点关注LNS wait on SENDREQ、LGWR-LNS wait on channel等后台事件，并结合V$MANAGED_STANDBY和V$ARCHIVE_DEST_STATUS实时分析。
AWR 不能直接诊断 Data Guard 传输延迟——它压根不采集 LGWR 发送耗时、TCP 重传、ACK 延迟等网络层指标，也无对应等待事件。靠 AWR 报告里的 log file sync 或 log file parallel write 判断 DG 问题，大概率误判。
为什么 log file sync 高 ≠ DG 有问题？
当 log file sync 平均等待达几十毫秒，而 log file parallel write 仅 ~1ms，说明 lgwr 写本地磁盘很快，瓶颈不在存储；真正拖慢的是主库在等备库 ack，即 lns wait on sendreq 和 lgwr-lns wait on channel 高企。这组等待组合才是 dg sync+affirm 配置下的典型指纹。
AWR 里该盯哪几个后台等待事件？
-
LNS wait on SENDREQ：主库 LNS 进程在等备库 RFS 返回 ACK，值高说明网络延迟或备库 I/O 慢 -
LGWR-LNS wait on channel：LGWR 被 LNS 卡住，无法继续写日志，直接影响事务提交 -
ARCH wait on ATTACH或ARCH wait on ATTACH：若主库用 ARCH 模式传输，ARCH 进程卡住也会导致归档积压
注意：log file parallel write 高只反映本地写磁盘慢，和 DG 传输无关；gc cr block lost 属 RAC 私网问题，别混进来。
V$MANAGED_STANDBY 才是实时看传输状态的唯一入口
查这个视图比翻 AWR 报告快得多，且能立刻定位卡点：
-
PROCESS = 'LGWR'且STATUS = 'IDLE'→ 主库根本没触发传输（检查LOG_ARCHIVE_DEST_2是否 ENABLE、VALIDATE 状态是否 VALID） -
LGWR STATUS = 'ACTIVE'但RFS STATUS = 'IDLE'→ 主库在发，备库 RFS 没收到（网络中断、防火墙拦截、监听未启动） -
RFS STATUS = 'WRITING'但V$ARCHIVED_LOG中APPLIED_TIME滞后 >30 秒 → 问题在备库端（MRP0 应用慢、standby redo log 不足、I/O 瓶颈）
别只查一次——这个视图是动态的，建议每 5 秒执行一次，观察 SEQ# 是否持续增长。
TRANSMIT_TIME 和 APPLY_TIME 才是真延迟指标
V$ARCHIVE_DEST_STATUS 里的这两个字段比 V$DATAGUARD_STATS 更可靠：
-
TRANSMIT_TIME > 2：网络或主库 I/O 延迟（单位秒） -
APPLY_TIME显著大于TRANSMIT_TIME：问题在备库（MRP 应用慢、SRL 不足、归档目录满） -
FAILURE_COUNT持续递增：间歇性丢包或连接被防火墙重置
注意：ERROR 列内容必须细看，比如 ORA-12170: TNS:Connect timeout occurred 是 TCP 层超时，ORA-12543: TNS:destination host unreachable 是路由不通——这些 AWR 里根本不会出现。
真正卡在传输链路上的问题，从来不在 AWR 报告的“Top Events”里藏得深，而是在 V$MANAGED_STANDBY 的 STATUS 字段、V$ARCHIVE_DEST_STATUS 的 TRANSMIT_TIME 和操作系统层的 netstat -s 输出里——AWR 只是结果快照，不是诊断起点。
