Oracle Data Guard本身不提供独立重试策略，重试由客户端Oracle Net Services控制；FAILOVER_MODE配置在tnsnames.ora中决定连接失败后是否切备库、重试次数与间隔，而重做传输中断则依赖REOPEN参数及系统TCP调优。
oracle data guard 本身不提供“重试策略”这一独立配置项，重试行为由客户端连接层（oracle net services）控制，而非 dg 后台进程（如 lns、mrp 或 rfs）。网络临时波动影响的通常是客户端连接或服务名解析失败，不是重做传输中断——后者靠的是日志归档+gap resolution 自动恢复。
FAILOVER_MODE 配置在 TNSNAMES.ORA 中生效
客户端连接主库失败后是否尝试备库、重试几次、间隔多久，全由 FAILOVER_MODE 控制。它必须写在客户端的 TNSNAMES.ORA 文件里，服务端不读取该参数。
-
TYPE = SELECT：仅对SELECT类会话启用故障转移；若应用含 DML，建议改用TYPE = SESSION，否则事务中途断连不会切备库 -
RETRIES = 20和DELAY = 3是关键组合：20 次 × 3 秒 = 最多等待 60 秒才报错，适合应对短时网络抖动 - 地址列表中多个
ADDRESS必须按优先级排序，Oracle 按顺序逐个尝试，不并行连接 - 备库监听器必须处于运行状态（即使数据库是
MOUNT），否则客户端收不到响应，无法触发下一次重试
重做传输中断 ≠ 客户端连接失败，不能靠 FAILOVER_MODE 解决
主库 LNS 进程发重做日志到备库 RFS 失败时，Oracle 会持续重传（默认无上限），并在 V$ARCHIVE_DEST_STATUS 中显示 ERROR 状态和具体错误（如 ORA-12543: TNS:destination host unreachable）。这类问题：
- 不依赖客户端配置，与
TNSNAMES.ORA无关 - 需检查
LOG_ARCHIVE_DEST_2的REOPEN参数（例如REOPEN=60表示 60 秒后自动重试） - 若网络波动频繁，应调大
net.core.rmem_max和net.core.wmem_max（Linux 系统），避免 TCP 缓冲区溢出丢包 - 监控
ARCHIVE_LAG_TARGET是否被频繁触发，它可能强制归档并间接加剧网络压力
Java/OCI 应用中容易忽略的连接池重试陷阱
即使 TNS 配置了 FAILOVER_MODE，如果应用使用连接池（如 HikariCP、UCP），还需确认：
- 连接池未缓存失效连接：需启用
testOnBorrow或validationQuery=SELECT 1 FROM DUAL - UCP（Universal Connection Pool）需显式设置
setFastConnectionFailoverEnabled(true)，否则不响应 Oracle RAC/DG 的 FAN 事件 - JDBC URL 中若硬编码了主机名（如
jdbc:oracle:thin:@primary_host:1521:ORCL），则完全绕过 TNS 故障转移机制 - Spring Boot 的
spring.datasource.url必须指向 TNS 别名（如jdbc:oracle:thin:@DG_SERVICE_HA），且确保tnsnames.ora在$TNS_ADMIN路径下可读
真正决定“能否扛住网络波动”的，从来不是 DG 主备切换逻辑，而是客户端如何定义连接行为、操作系统如何处理 TCP 重传、以及应用层是否让连接池配合这个行为。这三个层面任何一个断掉，FAILOVER_MODE 就形同虚设。
