怎样利用Oracle 12c AWR报告优化Data Guard传输延迟

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 read Avg 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 波动 —— 高延迟或丢包会直接导致 LGWR NET_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 根本不建模。