fsfo自动切换需同时满足五项前提：启用flashback database、log_archive_dest_n含valid_for、protection_mode为maximum availability/performance、备库为physical standby且open_mode=read only with apply、v$database.fsfo_status=synchronized；缺一则observer卡在“waiting for primary to become unavailable”。
fsfo 不是“配完就自动生效”，它卡在某个环节就会静默失效——最常见的不是配置错，而是状态没到位、observer 没心跳、或主库关法不对。
FSFO_STATUS 不是 ENABLED 就代表就绪
很多人查 V$DATABASE.FSFO_STATUS 返回 ENABLED 就以为万事大吉，其实这是个误导性字段。真正决定能否触发的是它的实时值：
-
SYNCHRONIZED：唯一可触发自动切换的状态，表示 Observer 已连上主备库、日志同步正常、心跳稳定 -
STARTED：Observer 进程已启动，但尚未完成与主库的首次成功 ping（常见于防火墙拦截或DBMS_DG.INITIATE_FS_FAILOVER调用失败） -
NOT SYNCHRONIZED：主备日志延迟超限、备库未启用 Real-Time Apply、或FastStartFailoverLagLimit设置过小
必须执行：SELECT FSFO_STATUS, DATABASE_ROLE, PROTECTION_MODE FROM V$DATABASE; 确认三者同时为 SYNCHRONIZED、PRIMARY（主库）、MAXIMUM AVAILABILITY 或 MAXIMUM PERFORMANCE。
Observer 日志停在 “Waiting for primary to become unavailable”
这不是 Observer 坏了，是它收不到主库“真挂了”的信号。FSFO 依赖 Observer 每隔 FastStartFailoverThreshold 秒（默认 30）调用一次 DBMS_DG.INITIATE_FS_FAILOVER，而这个包需要主库能响应基础 SQL*Net 连接。
- 防火墙可能放行了
tnsping，但拦截了实际 SQL 包（尤其状态检测类规则） - 主库监听器虽运行，但
LOCAL_LISTENER或REMOTE_LISTENER配置错误，导致 Observer 的连接被拒绝而非超时 -
FAST_START_FAILOVER_THRESHOLD=30不代表 30 秒后就切——实际等待窗口是 threshold × 3（即 90 秒），期间只要有一次 ping 成功，计时重置
查日志路径：$ORACLE_HOME/rdbms/log/drc*.log，重点搜 Initiating Fast-Start Failover 或 Failed to ping primary。
shutdown immediate 不会触发 FSFO
这是最常被踩的坑。FSFO 只响应非正常中断，**shutdown immediate、shutdown normal、shutdown transactional 都不会触发**——因为这些命令会主动通知 Broker 主库即将退出，Broker 直接进入“受控停机”流程，跳过故障判定。
- 测试必须用
shutdown abort（模拟断电） - 但注意：
shutdown abort后若 Observer 日志报Failover cancelled: Primary instance terminated abnormally，说明 Observer 在主库崩溃前最后一刻没收到有效心跳，大概率是网络抖动或主库负载过高导致 ping 超时 - 生产环境禁用
shutdown abort测试；可用kill -9模拟更贴近断电的行为（但需确保 Observer 不在同一主机）
单 Observer 部署必然导致 FSFO 停摆
Oracle 明确要求至少两个 Observer 实例达成投票共识才能批准切换。单 Observer 是硬性单点故障：
- 一旦该 Observer 进程宕机或所在主机失联，FSFO 立即降级为不可用状态，
SHOW CONFIGURATION会显示Fast-Start Failover: DISABLED - 两个 Observer 必须部署在不同物理节点或可用区，禁止共用主机、共享存储、共用网络出口
- 它们不主从、不共享状态，各自执行
dgmgrl -silent "START OBSERVER"，靠内部 quorum 机制防脑裂
别省资源——Observer 进程本身极轻量，但缺失第二个实例，整个 FSFO 架构就失去 Oracle 认证的“高可用”资格。
