V$ARCHIVE_DEST_STATUS的ERROR字段若显示ORA-12170，表明主备间TCP连接已超时或被重置，本质是网络丢包或防火墙拦截；此时链路不可靠，需立即检查MTU匹配、抓包验证及LNS进程WAIT状态。
查V$ARCHIVE_DEST_STATUS的ERROR字段是否报ORA-12170
ORA-12170是Oracle对网络连接超时或被重置的统一包装，本质就是TCP层断开，90%以上对应真实丢包或防火墙拦截。主库执行SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;，只要ERROR列含ORA-12170，就不用再猜——链路已不可靠。
常见错误现象：
- ERROR为空但STATUS为
ERROR：不是没报错，是Oracle在重试中尚未写入错误信息，需配合V$MANAGED_STANDBY看LNS状态 - ERROR显示
ORA-12543或ORA-12154：那是TNS解析失败，和丢包无关，先检查tnsnames.ora和监听
用ping -s 1472测MTU级连通性，别只用普通ping
普通ping默认发64字节包，绕过IP分片，根本测不出丢包。真实归档日志走TCP，包长常超1500字节，一旦中间设备MTU不一致（比如主库网卡MTU=1500、防火墙MTU=1400），就会触发分片+丢弃，而标准ping完全感知不到。
实操建议：
- 从主库执行
ping -s 1472 备库IP（Linux）或ping -l 1472 备库IP（Windows），连续100次，丢包率＞1%即危险 - 若
1472丢包但ping 备库IP正常，基本锁定MTU不匹配；下一步用tcpdump -i any host 备库IP and port 1521抓包确认SYN是否被丢 - 别信“网络监控说丢包率0%”——很多监控只采样ICMP，而LNS走的是TCP流，必须实测
查LNS进程在V$PROCESS里是否卡在SENDREQ等待
LNS卡在SENDREQ不是性能问题，是它发了日志包后，死等备库RFS返回ACK，但ACK永远不来。这和丢包直接相关：包发出去了，响应丢了，LNS只能超时重发。
验证步骤：
- 主库查
SELECT SPID, PROGRAM, BACKGROUND, STATUS FROM V$PROCESS WHERE PROGRAM LIKE '%LNS%';，确认进程存在且BACKGROUND = 'YES' - 再查
SELECT EVENT, STATE, SECONDS_IN_WAIT FROM V$SESSION WHERE PADDR IN (SELECT ADDR FROM V$PROCESS WHERE PROGRAM LIKE '%LNS%');，若EVENT = 'SENDREQ'且SECONDS_IN_WAIT > 30，大概率丢包已发生 - 此时
V$ARCHIVE_DEST_STATUS.ERROR可能还没刷出ORA-12170，因为Oracle默认NET_TIMEOUT=180秒才判定失败
备库netstat看是否有ESTABLISHED连接但无数据流动
主库LNS连上了，备库RFS也接受了，但日志就是不进来——这种“假连接”常因中间设备（如负载均衡器、状态防火墙）维持TCP会话但静默丢包导致。
操作要点：
- 备库执行
netstat -an | grep :[3-6][0-9]{4} | grep ESTABLISHED（注意端口范围30000–65535），确认有来自主库IP的连接 - 接着用
ss -i或cat /proc/net/nf_conntrack | grep查该连接的重传次数（retrans）、丢包数（drops） - 若连接存在但
Recv-Q长期为0、Send-Q持续增长，说明RFS收不到完整包，十有八九是路径上某处丢包
真实丢包不会总在错误日志里留痕迹，它更喜欢藏在TCP重传统计、连接队列和MTU边界里。盯住SENDREQ状态和netstat里的ESTABLISHED连接，比反复刷V$DATAGUARD_STATS有用得多。
