Oracle Data Guard中如何详细排查网络通信报错并测试连通性？

本文共计1174个文字，预计阅读时间需要5分钟。

相关专题

tnsping 成功但 Data Guard 传输失败，说明什么

tnsping 成功只代表 tns 名称能解析、监听器端口（默认 1521）tcp 可达，它不走 sql*net 协议栈，也不模拟 lgwr 或 arch 进程的真实连接行为。所以即使 tnsping 返回 ok，ora-12514（服务名未注册）、ora-12170（连接超时）或 ora-00154（协议错误）仍会频繁出现。

关键区别在于：tnsping 发的是 ICMP 风格探测包，而 Data Guard 日志传输依赖的是 Oracle Net 的完整握手与数据帧协商。防火墙可能放行 ICMP 但拦截了大包分片、重传或特定 TCP 标志位。

• 若 tnsping 成功但 sqlplus /@standby_db 报 ORA-12514，重点查备库监听器是否静态注册了 GLOBAL_DBNAME = <db_unique_name>
• 若 sqlplus 偶发超时或报 ORA-12170，大概率是网络抖动或中间设备（如状态防火墙）重置长连接
• 若日志中反复出现 ORA-00154，需排查主备 Oracle 版本/补丁是否一致、字符集是否匹配、是否存在 MTU 不匹配导致的 TCP 分片丢弃

用 sqlplus 模拟真实连接并测 RTT 抖动

比 tnsping 更贴近 LGWR 行为的方式，是在主库执行带超时的轻量级连接测试：

sqlplus -L -S /@standby_db "SET TIMING ON; SELECT SYSDATE FROM DUAL;"

其中 -L 表示登录失败时不重试，-S 是静默模式。建议连续执行 10–20 次，观察输出中的“Elapsed”时间：

• 平均耗时 > 500ms 或标准差 > 300ms，提示网络路径存在明显延迟或抖动
• 出现 ORA-12170 且非偶发（比如 5 次里有 2 次以上），说明底层连接被中断，不是 DNS 或 TNS 解析问题
• 若首次连接慢、后续变快，可能是监听器未启用 INBOUND_CONNECT_TIMEOUT 导致初始连接排队

注意：测试账号必须有 CREATE SESSION 权限，且不能使用受限会话（RESTRICTED SESSION）。

抓包定位丢包发生在主库 LGWR 还是备库 MRP0

Data Guard 日志传输是单向 TCP 流：主库 LGWR → 备库 RFS（Remote File Server），再由 MRP0 应用。丢包位置不同，对策完全不同。

在主库执行：

tcpdump -i eth0 'host <standby_ip> and port 1521' -w dg_out.pcap -c 1000

在备库执行：

tcpdump -i eth0 'host <primary_ip> and port 1521' -w dg_in.pcap -c 1000

用 Wireshark 打开后重点关注：

• dg_out.pcap 中大量 [TCP Retransmission] 或重复 ACK → 主库发不出去，查主库网卡、路由、QoS 策略
• dg_in.pcap 中有数据包但 MRP0 进程没写入 standby redo log → 问题在备库内核接收缓冲区、Oracle 内存参数（如 _log_write_parallelism）或磁盘 I/O
• 两端都有重传但无数据交互 → 中间网络设备（如负载均衡器、防火墙）干扰 TCP 序列号或窗口大小

查 V$ARCHIVE_DEST_STATUS 快速判断传输卡点

这个视图是 Data Guard 网络诊断的第一站，不用猜，直接看字段含义：

• TRANSMIT_TIME > 2：归档从主库发出到被备库 RFS 接收耗时过长 → 网络或主库 I/O 延迟
• APPLY_TIME 显著大于 TRANSMIT_TIME（比如差 30 秒以上）→ 备库应用慢，查 MRP0 状态、standby redo log 是否齐全、磁盘写入能力
• STATUS = ERROR 且 ERROR 列含 ORA-12543 或 ORA-12170 → TCP 连接已断，不是配置问题，是网络或监听器宕了
• FAILURE_COUNT 持续递增 → 间歇性丢包或连接被重置，和抓包结果互验

执行语句就是这一条，别加多余条件：

SELECT DEST_ID, STATUS, ERROR, TRANSMIT_TIME, APPLY_TIME, FAILURE_COUNT FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;

真正容易被忽略的是：这个视图反映的是最近一次归档尝试的结果，如果传输已停摆超过 5 分钟，TRANSMIT_TIME 和 APPLY_TIME 可能还是旧值——得配合告警日志里最新一条 ORA 错误时间戳一起看。