ora-12535 是网络层tcp连接被静默拦截的典型信号，非dg逻辑错误；根本原因是arc/fal进程发起的底层连接受防火墙、监听host配置（如localhost）、端口不匹配或出向规则缺失等影响，导致syn发不出或ack收不到，超时后统一报此错。
ORA-12535 不是 DG 自身逻辑错误，而是底层 TCP 连接被网络层静默拦截的典型信号 —— 日志传输进程（ARC/LNS）根本发不出 SYN 包，或收不到 ACK，超时后统一甩出这个错误。
tnsping 能通但 ARC 进程持续报 ORA-12535
这是 DG 环境里最误导人的现象：你在主库上 tnsping 备库别名能返回 OK，但 ARC 进程日志里反复刷 ORA-12535，甚至夹杂 ORA-07286: sksagdi: cannot obtain device information 这类“设备故障”假象。
根本原因不是存储或权限，而是：ARC 进程使用的连接上下文和你手动 tnsping 不同 —— 它走的是 LOG_ARCHIVE_DEST_n 配置里的完整连接描述符，且以 Oracle 用户身份、在监听器启动用户权限下发起连接，对防火墙规则更敏感。
- Windows 环境下，
tnslsnr.exe监听 1521，但ARC进程 outbound 连接目标端口未必是 1521（比如备库监听端口被改过），需确认LOG_ARCHIVE_DEST_2中(PORT = ...)值是否匹配备库实际监听端口 - Linux 上若启用了
iptables或firewalld，必须放行主库 IP → 备库监听端口的 **出向规则**（很多只加了入向，忘了出向） -
tnsping用的是客户端本地解析，而ARC使用的是数据库实例内部解析，受sqlnet.ora中NAMES.DIRECTORY_PATH和SQLNET.EXPIRE_TIME影响，后者设得太小会导致连接被中间设备断连
listener.ora 的 HOST 写 localhost 导致 DG 连接静默失败
DG 日志传输不报错、不重试、不写 trace，只卡在 “waiting for archive log” 状态，背后大概率是监听配置把 HOST 写成了 localhost 或 127.0.0.1。
主库 ARC 进程尝试连接备库时，DNS 解析出 127.0.0.1，结果连接打到了自己本机 —— 本机没开监听，或监听只绑了回环，TCP 连接直接被拒绝，Oracle 层面就表现为超时。
- 检查备库
$ORACLE_HOME/network/admin/listener.ora，确认LISTENER段中(HOST = ...)是真实 IP（如192.168.10.25）或可被主库解析的主机名，**绝不能是localhost或127.0.0.1** - 同时核对主库
LOG_ARCHIVE_DEST_2里(ADDRESS=(HOST=...))是否与之一致；不一致就会 DNS 解析错位 - 改完必须执行
lsnrctl stop && lsnrctl start，reload不会重载HOST绑定
ADG 环境下 FAL 进程因连接中断反复报 ORA-12535
当备库已启用实时应用（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT），FAL（Fetch Archive Log）进程会主动向主库拉取缺失日志。一旦网络抖动或策略变更，它比 ARC 更早暴露连接问题。
典型表现是备库 alert.log 里高频出现：
FAL[client]: Failed to request gap sequence GAP-thread1 sequence38218-38218 FAL[client]: All defined FAL servers have been attempted.
这不是备库自身故障，而是它连不上主库的 FAL server 地址 —— 该地址由主库 LOG_ARCHIVE_DEST_1 的 SERVICE 参数决定，背后仍走 TNS 解析 + TCP 连接。
- 确认主库
LOG_ARCHIVE_DEST_1的SERVICE值，在主库tnsnames.ora中存在且指向正确地址 - FAL 连接默认复用主库监听端口（通常 1521），但若主库监听配置了
SECURE_REGISTER_LISTENER=ON，而备库未配对应 wallet，则连接会被拒绝，现象也是超时 - 临时验证可用
sqlplus从备库机器直连主库 service：如果sqlplus sys@primary_svc as sysdba都卡住，那问题一定在基础连通性，不是 DG 配置
真正棘手的地方在于：ORA-12535 是个“哑错误”，它不告诉你丢包发生在哪一跳，也不区分是源端发不出、中间被拦、还是目的端不响应。必须逐段验证 —— 从主库 tnsping 备库别名，到主库 telnet 备库IP 备库端口，再到备库本机 lsnrctl status 看监听是否真在运行并接受远程连接。漏掉任何一层，排查就会绕远。
