awr无法定位data guard传输延迟，因其不采集lgwr网络发送耗时、tcp重传、ack延迟等指标；log file parallel write仅反映本地磁盘写入耗时，与网络传输无关，正常值不能代表dg传输快，异常值也不说明网络卡，需结合v$managed_standby、v$archived_log和tcpdump等实时工具交叉验证。
awr 报告本身无法定位或优化 data guard 传输延迟，它不采集 lgwr 网络发送耗时、tcp 重传、ack 延迟等关键指标，依赖它查“传输慢”只会漏掉真正瓶颈。
为什么不能看 AWR 里的 log file parallel write？
这个等待事件只反映 LGWR 把 redo 从 log_buffer 写入本地磁盘日志文件的耗时，和网络传输完全无关。log file parallel write 平均 2ms 不代表 DG 传输快；它飙到 15ms 也不说明网络卡——可能只是主库归档路径落在慢盘上。
常见误判场景：
- 看到
log file parallel write正常，就忽略V$ARCHIVED_LOG里APPLIED_TIME和COMPLETION_TIME差值已超 5 分钟 - 用 AWR 的 “Top 5 Timed Foreground Events” 判断瓶颈，但
LGWR网络行为压根不出现在这里 - 在 RAC 环境下只查一个实例的 AWR，其他节点的传输卡顿完全不可见
哪些 AWR 指标可以间接辅助判断？
AWR 能提供的只有「侧面线索」，必须交叉验证才有效：
-
DB Time高 +log file sync等待占比突增 → 可能是主库频繁提交，导致 LGWR 发送压力大（尤其配了SYNC模式） -
Redo Generated Per Sec（在 Report Summary 的 Instance Activity Stats）持续 >10MB/s → 对照网络带宽是否够：需 ≥Redo Generated Per Sec × 8 ÷ 0.7（单位换算+预留冗余） -
Physical Reads/Sec或db file scattered readAvg Wait >10ms 且占比高 → 备库 I/O 瓶颈，MRP 应用慢，此时V$DATAGUARD_STATS的apply lag会拉大，但transport lag接近 0
注意：V$DATAGUARD_STATS 的 transport lag 和 apply lag 是估算值，心跳间隔默认 60 秒，在跨公网链路或抖动时严重滞后，不能直接用于秒级诊断。
真正该查的三个实时视图，比 AWR 有用十倍
所有传输卡点都藏在内存视图里，必须连上主备库实时查：
-
V$MANAGED_STANDBY：唯一能看清 LGWR 和 RFS 当前状态的地方。重点看：PROCESS='LGWR'的STATUS（ACTIVE才在发）、SEQ#是否追平V$LOG_HISTORY最新序列；PROCESS='RFS'的STATUS（WRITING表示正在收） -
V$ARCHIVED_LOG：对比三组序列号：MAX(SEQUENCE#) WHERE DEST_ID=1 AND ARCHIVED='YES'（主库已归档）、MAX(SEQUENCE#) WHERE DEST_ID=2 AND ARCHIVED='YES'（备库已收到）、MAX(SEQUENCE#) WHERE APPLIED='YES'（备库已应用）——三者差值超过 30 就得干预 -
V$DATAGUARD_PROCESS：确认 MRP 进程是否存在、状态是否APPLYING_LOG；若 CPU 占用高但APPLIED_TIME不更新，大概率是备库 redo 日志路径 I/O 慢或STANDBY_FILE_MANAGEMENT=AUTO引发字典争用
网络层必须补的两步，AWR 完全覆盖不到
AWR 不碰网络栈，但 DG 传输卡在这一层最常见：
- 在主库执行：
tnsping STANDBY看监听是否通；再跑ping -s 1472 standby_ip（避开 IP 分片），观察丢包率和 RTT 波动 —— 高延迟或丢包会直接导致 LGWRNET_TIMEOUT触发重试 - 用
tcpdump -i any host standby_ip and port 1521 -w dg.pcap抓包，过滤tcp.analysis.retransmission，确认是否有重传；再看tcp.time_delta是否稳定（>100ms 就异常）
SDU 和 TCP 缓冲区这些参数调得再好，如果底层网络丢包率 >0.1%，所有优化都白搭。而 AWR 里连一个丢包数字都看不到。
复杂点在于：传输延迟从来不是单点问题。你可能调好了主库 LOG_ARCHIVE_DEST_2 的 ASYNC=256K 和 NET_TIMEOUT=30，却发现备库 DB_RECOVERY_FILE_DEST 空间只剩 5%，导致 RFS 写归档失败，日志堆积在主库 SRL 里 —— 这类跨组件依赖，AWR 根本不建模。
