FSFO生效必须同时满足Broker启用、Observer持续在线、安全凭证就绪、保护模式匹配四硬条件；缺一不可，否则切换将失败或产生“假主库”。
FSFO 不能只靠 dgmgrl 配置就生效，必须同时满足 Broker 启用、Observer 持续在线、安全凭证就绪、保护模式匹配这四个硬条件，缺一不可。
Broker 必须启用且配置完整
DMON 后台进程不启动，DGMGRL 所有命令都只是“纸上谈兵”。确认方式是查 v$session 中是否存在 DMON 进程，或执行 show parameter dg_broker_start 确保返回 TRUE。常见疏漏点：
- 主备库都必须设
DG_BROKER_START=TRUE，且使用SPFILE（PFILE 不支持动态写入 Broker 配置） - 主备库的
db_unique_name必须全局唯一，且在LOG_ARCHIVE_CONFIG中双向声明，例如：LOG_ARCHIVE_CONFIG='DG_CONFIG=(prim,standby)' - 手动删过归档目标后没清 Broker 缓存，会导致
ENABLE FAST_START FAILOVER报 ORA-16627 错误
Observer 必须独立部署并后台运行
Observer 不是可选组件，而是 FSFO 的“裁判”——它不在主/备库上运行，而是在第三台主机（哪怕是一台轻量级 VM）上持续监控双方心跳。启动后若提示 Fast-Start Failover is not enabled，大概率是没配 Oracle Wallet。
- Observer 启动命令必须带
-d参数后台运行：dgmgrl -d "connect_string" -logfile observer.log - Observer 连接主备库时不能用明文密码，否则无法在后台长期存活；必须通过
mkstore创建 Wallet，并在sqlnet.ora中配置WALLET_LOCATION和SQLNET.WALLET_OVERRIDE=TRUE - Observer 日志里出现
ORA-12154: TNS:could not resolve the connect identifier，说明tnsnames.ora里的连接别名没同步到 Observer 主机
保护模式与 FastStartFailoverLagLimit 必须对齐
FSFO 在 MAXAVAILABILITY 和 MAXPERFORMANCE 下都支持，但行为差异极大，直接影响 RPO 和切换触发逻辑。
- 选
MAXAVAILABILITY：要求重做同步写入备库 SRL（LOG_ARCHIVE_DEST_n必须带AFFIRM），否则ENABLE FAST_START FAILOVER会失败 - 选
MAXPERFORMANCE：允许异步传输，但必须显式设置FastStartFailoverLagLimit（单位秒），比如设为 30，表示容忍最多 30 秒未同步的事务丢失 -
FastStartFailoverThreshold是 Observer 判定“失联”的超时值，默认 30 秒；若网络抖动频繁，需调大，否则可能误切；但调太大又拖慢真实故障响应
Java 应用连不上新主库？问题几乎总出在客户端
FSFO 切换成功 ≠ 应用自动恢复。Oracle 数据库层完成切换只需几秒，但 Java 应用若没配对，会持续报 IO Error: Connection reset 或卡在旧连接上。
- 连接字符串必须含
FAILOVER_MODE子句，例如：(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=3)(DELAY=5)) - 必须用
Oracle UCP连接池，调用setFastConnectionFailoverEnabled(true)；HikariCP、Druid 等通用池不识别 DG 故障事件 - 禁用连接池的
testOnBorrow或validationQuery，它们会在 TAF 自动重建连接前主动探活，导致连接被提前标记为失效 - 新主库监听注册有延迟（尤其 RAC），建议连接池
connection-timeout设为 ≥30s，避免在STATUS=READY前反复超时
真正容易被忽略的是 Observer 的存活状态和 Wallet 凭证的时效性——它不像数据库服务那样有明确启停日志，一旦后台进程静默退出或 Wallet 密码过期，FSFO 就彻底“失明”，但所有 DGMGRL 命令仍显示正常，排查起来极难定位。
