AWR无法监控Data Guard网络延迟或丢包，因其不记录LGWR发送耗时、TCP重传等网络指标；需结合V$MANAGED_STANDBY、V$ARCHIVED_LOG、tcpdump及iostat交叉验证。
awr 本身不直接记录 data guard 日志传输的网络延迟或丢包，lgwr 进程的 redo 发送行为在 awr 中没有独立等待事件或统计项——你查不到「lgwr 发送耗时」或「mrp0 接收延迟」这类指标。必须绕过 awr，结合 v$ 视图、os 工具和网络抓包交叉验证。
为什么不能只看 AWR 的 log file parallel write？
log file parallel write 只反映 LGWR 把 redo 从 log buffer 写入本地日志文件（磁盘）的耗时，和网络传输完全无关。它高 ≠ 网络卡；它低 ≠ DG 传输快。常见误判是：看到 avg wait 5ms 就认为“LGWR 没问题”，结果主库早已积压数百 MB 未发送 redo，V$ARCHIVED_LOG 里 APPLIED_TIME 和 COMPLETION_TIME 差值越来越大，但 AWR 里毫无征兆。
- AWR 不采集 LGWR 的 socket send() 耗时、TCP retransmit、ACK 延迟等网络层指标
-
V$DATAGUARD_STATS中的transport lag和apply lag是估算值，依赖备库心跳，实际网络抖动时滞后严重（尤其跨公网或高延迟链路） -
V$MANAGED_STANDBY才是唯一能实时看 LGWR 当前状态的地方：关注PROCESS=‘LGWR’ 的STATUS（是否 ACTIVE）、CLIENT_PROCESS（是否 RFS）、SEQ#（当前发送日志序列号）与V$ARCHIVED_LOG最新SEQUENCE#是否一致
用 V$DATAGUARD_PROCESS 和 V$ARCHIVED_LOG 定位传输卡点
先确认是主库没发、还是备库没收。执行以下查询：
SELECT PROCESS, STATUS, CLIENT_PROCESS, SEQUENCE#, BLOCK#, BLOCKS
FROM V$MANAGED_STANDBY
WHERE PROCESS IN ('LGWR', 'RFS');
关键判断逻辑：
- 若
LGWR.STATUS = 'IDLE'且RFS.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 瓶颈）
再比对主备日志序列：
SELECT MAX(SEQUENCE#) "PRIMARY_SEQ" FROM V$LOG_HISTORY; SELECT MAX(SEQUENCE#) "STANDBY_RECV" FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND ARCHIVED='YES'; SELECT MAX(SEQUENCE#) "STANDBY_APPLY" FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND APPLIED='YES';
三者差值超过 2–3 表示已出现明显传输或应用延迟。
抓包 + iostat 定位真实瓶颈环节
当 V$MANAGED_STANDBY 显示 LGWR 在发、RFS 在收，但延迟仍高，必须下到 OS 层：
- 在主库抓 LGWR 出向流量：
tcpdump -i any port（替换为实际 RFS 监听端口）→ 查重传率（netstat -an | grep :1521 | grep ESTABLISHED | head -1 | awk '{print $5}' | cut -d: -f2-w lgwr_send.pcaptcp.analysis.retransmission）和 ACK 间隔 - 在备库抓 RFS 入向流量：
tcpdump -i any src host and port→ 对比是否丢包、是否有 out-of-order 包-w rfs_recv.pcap - 同时运行
iostat -x 1：若主库%util接近 100% 且w_await飙升，说明 LGWR 写本地日志就卡住，根本没机会发网络；若备库r_await高，说明 MRP0 读 standby redo log 慢，不是网络问题
注意：LGWR 进程的 CPU 使用率也要盯紧——高 CPU 会导致它无法及时调用 send()，表现为 V$MANAGED_STANDBY 中 LGWR STATUS 频繁在 ACTIVE/IDLE 切换，但 SEQ# 停滞。
容易被忽略的配置陷阱
很多传输延迟其实源于配置不当，而非硬件或网络：
-
LOG_ARCHIVE_DEST_2中漏配NET_TIMEOUT=30→ LGWR 默认 180 秒才超时，期间持续重试，掩盖真实网络故障 - 主库
DB_BLOCK_SIZE和备库不一致 → RFS 收到数据后无法解析，日志停留在ARCHIVED='YES' APPLY='NO'状态，V$DATAGUARD_STATS却显示transport lag=0 - 使用了
SYNC模式但未启用COMMIT WRITE WAIT→ 应用 COMMIT 返回快，但 LGWR 实际还在等 RFS ACK，log file sync等待时间会异常升高，误判为存储问题 - 备库
STANDBY_FILE_MANAGEMENT=AUTO但主库新增表空间时权限不足 → RFS 写 standby redo log 失败，错误日志藏在ALERT.log，AWR 里完全无体现
真正难定位的，是 LGWR 和 RFS 之间那几百毫秒的“黑盒”——它既不在 AWR 里，也不在 Oracle 的任何标准视图中暴露细节。必须把数据库、网络、OS 三层日志对齐时间戳，才能看清那一帧 TCP 包到底卡在哪。
