fsfo不自动触发的根本原因是observer未进入“可决策”状态，即v$database.fsfo_status非synchronized；常见原因包括闪回未启用、valid_for缺失、备库未实时应用、observer连通性故障、非正常宕机未触发、srl或affirm配置错误等。
FSFO 不会自动触发，根本原因不是配置漏了哪一步，而是 Observer 根本没进入“可决策”状态——V$DATABASE.FSFO_STATUS 显示 STARTED 或 NOT SYNCHRONIZED，它就只会一直卡在 Waiting for primary to become unavailable。
为什么 V$DATABASE.FSFO_STATUS 不是 SYNCHRONIZED
这个值才是 Observer 实际判断依据，不是看 SHOW CONFIGURATION 里写的是 ENABLED 就完事。常见断点：
-
FLASHBACK DATABASE没开：主库或备库任一端SELECT FLASHBACK_ON FROM V$DATABASE返回NO，FSFO 直接拒绝同步；必须两端都执行ALTER DATABASE FLASHBACK ON，且DB_RECOVERY_FILE_DEST已设、空间充足 -
LOG_ARCHIVE_DEST_n缺VALID_FOR：主库上必须有类似LOG_ARCHIVE_DEST_2='SERVICE=standby_db VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE)'，备库上对应要有VALID_FOR=(ONLINE_LOGFILES,STANDBY_ROLE)；Broker 不认模糊配置，缺一个VALID_FOR，FSFO_STATUS就卡在NOT SYNCHRONIZED - 备库没开实时应用：
OPEN_MODE必须是READ ONLY WITH APPLY，不是MOUNTED也不是READ ONLY；查SELECT OPEN_MODE FROM V$DATABASE确认，否则 Broker 认为备库“跟不上”，不许 FSFO 启动
Observer 连不上主库的典型假象
日志里反复出现 Waiting for primary to become unavailable，90% 是 Observer 根本连不通主库，而不是主库真宕机了：
- 防火墙只放行了
tnsping，但拦截了DBMS_DG.INITIATE_FS_FAILOVER的 SQL*Net 调用（它走的是 1521，但可能被状态检测规则丢弃） -
StaticConnectIdentifier配置错误：Broker 中主库和备库的该属性必须能被对方数据库进程解析，tnsnames.ora缺失、主机名无法反向解析、监听未启动都会导致 Observer ping 失败 - Observer 启动方式错误：用
ssh user@observer-host 'dgmgrl -silent "START OBSERVER"'这种远程调用无效；必须在 observer 主机本地终端执行dgmgrl -silent "START OBSERVER file=fsfo.dat"，并用nohup保活
主库“宕机”方式不对，FSFO 直接无视
FSFO 只响应非正常中断，对受控关库完全无感：
-
SHUTDOWN IMMEDIATE、SHUTDOWN NORMAL、SHUTDOWN TRANSACTIONAL—— Broker 收到的是干净退出信号，直接跳过故障判定流程 -
SHUTDOWN ABORT或kill -9pmon进程 —— 这才是唯一触发路径；测试时别用 SQL 命令模拟，直接 kill - Observer 实际等待时间是
FastStartFailoverThreshold × 3：比如阈值设 30 秒，它会连续三次尝试 ping（每次间隔约 30 秒），中间只要有一次成功，计时重置；所以网络抖动比彻底断网更易卡住
备库 SRL 不足或 AFFIRM 配置错，Observer 判定阻塞
尤其在 MAXIMUM AVAILABILITY 模式下，Observer 依赖备库确认 redo 写入成功，否则不敢发起切换：
- 备库没配 Standby Redo Log（SRL），或大小/组数不足：查
V$STANDBY_LOG，确保至少比主库 online redo log 多一组，且STATUS = UNASSIGNED -
LOG_ARCHIVE_DEST_2缺AFFIRM：必须是SYNC AFFIRM（非NOAFFIRM），否则主库写 redo 时不会等备库 SRL 写入完成，Observer 收不到“已落盘”确认 - SRL 所在磁盘满或权限异常：
SELECT * FROM V$REDO_LOG WHERE TYPE = 'STANDBY'查路径，确认磁盘空间和 Oracle 用户可写
真正麻烦的不是配置项本身，而是这些条件必须全部同时满足、持续在线、且 Observer 日志里没有 silent failure——比如 VALID_FOR 错一个字符，FSFO_STATUS 就永远卡在 NOT SYNCHRONIZED，而 SHOW CONFIGURATION 依然显示 ENABLED，这种隐性不一致最耗排查时间。
