FSFO Observer心跳超时不会触发切换，真正执行切换的是Data Guard Broker；Observer失联仅导致状态变为NOT RUNNING或UNKNOWN，Broker仍可依据主库不可达及阈值条件发起failover。
FSFO Observer 进程是否在心跳超时后触发切换？
fsfo（fast-start failover）observer 不是“自动切换”的决策者，它只负责监控和报告；真正执行切换的是 data guard broker 的 dgmgrl 后台进程。observer 自身断连或心跳超时，只会导致 observer status 变为 not running 或 unknown，不会直接触发 failover —— 这是很多人误以为“observer 挂了就会切”的根本误区。
验证这一点，关键不是看 Observer 日志，而是查 Broker 控制文件状态和 SHOW CONFIGURATION VERBOSE 输出中的 Fast-Start Failover 状态字段。
-
Fast-Start Failover显示ENABLED且Observer显示NOT RUNNING：说明 Observer 失联，但 Broker 仍保有切换能力（只要主库不可达且满足阈值） - 若显示
DISABLED或REQUIRES REINSTATEMENT：说明 FSFO 已被 Broker 主动停用，需人工干预 - Observer 心跳默认每 10 秒发一次，超时判定窗口是
FastStartFailoverThreshold（默认 30 秒），即连续 3 次未收到响应才标记为失联
如何安全模拟主库断网（不杀进程、不关实例）
直接 ifconfig eth0 down 或拔网线风险高：可能触发主机级网络重置、ARP 刷新延迟、甚至引发 RAC 节点驱逐。更可控的方式是用 iptables 在主库本地拦截到备库/Observer 的流量。
假设 Observer IP 是 192.168.5.100，备库监听端口是 1521，主库执行：
iptables -A OUTPUT -d 192.168.5.100 -j DROP iptables -A OUTPUT -d <standby_ip> -p tcp --dport 1521 -j DROP</standby_ip>
这样主库仍能响应本地连接、不影响 DB 实例运行，但 Observer 和备库完全收不到其心跳与 redo 传输。
- 务必先
service iptables save或记录规则，避免重启后残留 - 不要用
INPUT链屏蔽，否则会干扰 Broker 代理进程（DGBROKER）自身通信 - 断网后立刻查
DGMGRL：运行SHOW DATABASE VERBOSExxx看Transport Lag和Apply Lag是否持续增长
怎么确认 Observer 真的“心跳超时”并影响 FSFO 决策？
仅看 lsnrctl status observer 或进程是否存在没用。Observer 是否“生效”，取决于它是否向 Broker 注册了有效会话，并被 Broker 记录在控制文件中。
最直接证据是查 Broker 日志（$ORACLE_HOME/rdbms/log/drc<db_name>.log</db_name>）里是否有类似：
FSFO: Observer heartbeat timeout for database xxx, status UNKNOWN
同时检查 DGMGRL 中的状态变化：
- 执行
SHOW FAST_START FAILOVER：若输出含Observer: NOT RUNNING，说明已超时失联 - 再执行
SHOW DATABASE 'primary_db' VERBOSExxx：观察Fast-Start Failover Target是否仍指向备库，以及Protection Mode是否降级为MAXIMUM PERFORMANCE - 注意：即使 Observer 失联，只要主库实际宕机（非仅断网），Broker 仍会在
FastStartFailoverThreshold+FastStartFailoverLagLimit组合判断后触发切换
为什么断网后没切换？常见卡点在哪
FSFO 不触发切换，90% 情况不是 Observer 问题，而是 Broker 的保护性约束没被突破。重点盯这几个配置项：
-
FastStartFailoverLagLimit（默认 30 秒）：要求备库应用日志滞后 ≤ 该值。断网后主库仍在写，备库 lag 快速突破阈值，Broker 就拒绝切换 —— 查Apply Lag是否 >30 -
FastStartFailoverPseudoStandbyDelay（默认 0）：若设为非零，会强制延迟切换，用于容错瞬时抖动 - 主库虽断网，但 DB 实例仍在运行，Broker 默认认为它“活着”，必须等
PrimaryLostWriteTimeout（默认 0）或依赖 OS-level heartbeat（如 Oracle Clusterware）来宣告死亡 - Observer 本身未用
START OBSERVER启动，或启动时未指定-D参数后台运行，导致 shell 退出后进程消失
真正可靠的模拟，得让 Broker 认定主库“不可达+不可恢复”，而不是仅仅“连不上”。这往往需要配合 srvctl stop instance 或 kill -9 PMON 进程（仅测试环境），才能绕过网络层假象。
