oracle dg无专属超时参数，所有网络超时均由sql*net控制；sqlnet.outbound_connect_timeout需配在客户端sqlnet.ora中，仅对客户端发起连接生效，单位为秒，不可与inbound参数混淆，且rac中host须填vip而非scan。
oracle dg 里没有“dg专属超时参数”，所有网络超时都由 sql*net 控制，配错位置或混淆 inbound/outbound 就白调。
SQLNET.OUTBOUND_CONNECT_TIMEOUT 必须配在客户端 sqlnet.ora
tnsping 或 dgmgrl 连不上时卡 60 秒，报 ORA-12170，不是网络问题，是客户端没设 outbound 超时。这个参数只对客户端发起的连接生效（比如你从主库连备库、应用连 DG 服务），服务端配置无效。
-
SQLNET.OUTBOUND_CONNECT_TIMEOUT = 15放在客户端$ORACLE_HOME/network/admin/sqlnet.ora里，单位秒 - 别和
SQLNET.INBOUND_CONNECT_TIMEOUT搞混——那是限制别人连你，和 DG 切换无关 - 值太小（如设成 2）在跨机房高延迟场景下会导致误判，一次重试都来不及发出去
- RAC 环境下 HOST 必须填对方 VIP，不能用 SCAN 地址；SCAN 不保证始终解析到活动节点
FAILOVER_MODE 决定客户端连失败后是否切备库
主库挂了，应用能不能自动连备库，不靠 DG 自身，靠的是 tnsnames.ora 里的 FAILOVER_MODE。它只在客户端解析连接串时起作用，服务端完全不读这个参数。
-
TYPE = SESSION：比SELECT更稳妥，DML 事务也能故障转移 -
RETRIES = 20和DELAY = 3组合，最多等 60 秒再报错，扛得住短时抖动 - 多个
ADDRESS按顺序尝试，不是并发；备库监听器必须 running（哪怕库是 MOUNT 状态） - Java 应用用了连接池（如 HikariCP、UCP），光配 FAILOVER_MODE 不够，还得开
setFastConnectionFailoverEnabled(true)
LOG_ARCHIVE_DEST_n 的 REOPEN 才管归档传输重试
主库 LNS 发日志失败、备库 RFS 接收中断，这类问题和客户端超时无关，得看归档目标配置。DG 后台进程自己不控制超时，全靠 REOPEN 参数驱动重试。
LOG_ARCHIVE_DEST_2 = 'SERVICE=STANDBY_DG ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_stby REOPEN=60'-
REOPEN=60表示失败后 60 秒重试一次，不是每秒重试，也不是无限重试 - 别把
REOPEN设太小（如 5），频繁无效连接会压垮主库监听器 - 配合系统 TCP 参数调优：
net.core.rmem_max和net.core.wmem_max要足够大，避免缓冲区丢包
监听器静态注册 + GLOBAL_DBNAME 大小写敏感是隐形拦路虎
很多人调完超时还卡在 ORA-12170，其实根本没走到超时阶段——dgmgrl sys/password@PRIMARY_DG 连之前，tnsnames.ora 先去解析 SERVICE_NAME，再去找监听器里有没有对应服务。如果监听器压根没加载，就直接失败，不触发任何超时逻辑。
- 每个节点
listener.ora必须有SID_LIST_LISTENER段，且GLOBAL_DBNAME和 tnsnames.ora 中SERVICE_NAME字符完全一致（含大小写、下划线、数字） -
GLOBAL_DBNAME推荐设为DB_UNIQUE_NAME，避免主备同名冲突 - 改完
listener.ora必须lsnrctl reload，别stop/start—— DG 同步会断 - 验证不能只看
lsnrctl status，要实测：dgmgrl sys/password@PRIMARY_DG和sqlplus / as sysdba@PRIMARY_DG
最常被忽略的点：超时参数只管“连不连得上”，不管“连上了干不干活”。FAL 进程拉日志失败、RFS 写归档卡住、甚至 JDBC 连接池丢连接后不重试，这些都不是调 OUTBOUND_CONNECT_TIMEOUT 能解决的。得一层层确认——是解析失败？建连失败？还是建连成功后读写卡住？每层对应的参数和排查手段都不同。
