如何在Oracle DG环境里配置透明应用程序故障转移TAF?

作者:袖梨 2026-07-11
Oracle DG 本身不提供客户端自动重连能力,TAF 必须由服务端 service + 客户端 TNS 配置协同生效;单独改 tnsnames.ora 或只建 service 都无法实现 SELECT 级别不中断的透明切换。

oracle dg 本身不提供客户端自动重连能力,taf 必须由服务端 service + 客户端 tns 配置协同生效;单独改 tnsnames.ora 或只建 service 都无法实现 select 级别不中断的透明切换。

必须在主库创建带 FAILOVER 属性的 service

这是 TAF 起效的前提。备库会通过 DG 同步该 service 元数据,但不会自动启停——必须靠触发器控制状态。

  • failover_method => 'BASIC' 是最常用且兼容性最好的选项;'PRECONNECT' 要求备库预建全部连接,DG 场景下几乎不可用
  • failover_type => 'SELECT' 表示查询类语句可被重放(事务类操作仍会回滚),若业务含大量 DML,需确认应用层能容忍中断
  • aq_ha_notifications => TRUE 必须开启,否则备库角色变更后客户端收不到通知,TAF 不会触发
  • 服务名(service_name)和网络名(network_name)建议保持一致,避免 tnsnames.ora 中 SERVICE_NAME 写错

必须配触发器+存储过程自动启停 service

主库切为备库、备库升为主库后,service 状态必须实时同步,否则客户端连到新主库时发现 service 未启动,TAF 直接失效。

  • 触发器类型必须是 AFTER STARTUP ON DATABASE,不能用 BEFORELOGON —— 启动时角色尚未确定
  • 存储过程中查 V$DATABASE.DATABASE_ROLE 是唯一可靠方式,V$INSTANCE 在备库可能不可用或返回错误值
  • 不要手动在备库执行 START_SERVICE:DG 同步的是 service 定义,不是运行状态;硬启会导致双主冲突
  • 验证是否生效:在新主库上执行 SELECT NAME, ENABLED FROM DBA_SERVICES,对应 service 的 ENABLED 应为 TRUE

客户端 tnsnames.ora 只需最小化配置

服务端已定义 FAILOVER 参数时,客户端 FAILOVER_MODE 设置会被忽略——Oracle 明确要求优先采用服务端配置。

  • 客户端 TNS 条目中只需指定 SERVICE_NAME(值等于 service 的 network_name),无需写 FAILOVER_MODE
  • 地址列表(ADDRESS_LIST)里可以只写一个地址(如主库 VIP),TAF 切换由 service 自动路由,不依赖客户端多地址轮询
  • 严禁在 listener.ora 中配置 GLOBAL_DBNAME:该静态注册项会直接禁用 TAF,且无任何报错提示
  • JDBC 连接串中若显式指定 failover=true,与服务端配置冲突时以服务端为准,但建议统一关闭客户端侧冗余参数

验证时重点看 V$SESSION.FAILED_OVER 字段

TAF 是否真正触发,不看连接是否成功,而要看会话级状态。很多测试误以为“连上了就是 OK”,其实只是 connect-time failover 在起作用。

  • 执行一次长查询(如 SELECT COUNT(*) FROM BIG_TABLE),同时人工 kill 主库实例或断网
  • 查询仍在运行时,立刻在客户端连入新主库,执行 SELECT FAILED_OVER FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV', 'SID')
  • 返回 YES 才代表 TAF 的 SELECT 模式生效;若为 NO,说明只是重新建立了新会话,原查询已丢弃
  • 注意:JDBC thin driver 默认不支持 TAF,必须用 OCI 驱动(即 oracle.jdbc.driver.OracleDriver 已淘汰,应改用 oracle.jdbc.OracleDriver 并启用 native library)

最容易被忽略的是 AQ 通知机制和 JDBC 驱动类型——两者任一缺失,TAF 就退化成普通重连,SELECT 语句不会重放。服务端配置再完美,客户端没收到通知,一切归零。

相关文章

精彩推荐