Observer 进程不直接监控FSFO切换状态，仅在主库不可用时触发自动切换；真实切换状态需通过Broker视图（如v$dataguard_status、v$database）及dgmgrl命令查看。
oracle 19c 中的 observer 进程本身不直接“监控”fsfo（fast-start failover）切换状态，它只负责在检测到主库不可用时触发自动切换。真正反映切换状态的是 data guard broker 的内部状态和视图，observer 只是执行器之一。
Observer 进程是否在运行？怎么看
Observer 是一个独立的后台进程（DMON 实例外的单独 ora_observer 进程），启动后会持续连接主库、备库和 Broker 配置库。确认它是否存活，不能只看进程名，要结合 Broker 状态：
- 在任意节点执行
dgmgrl连接 Broker：dgmgrl /，然后运行show configuration - 若输出中出现
Observer present字样（例如：Observer: myobserver.example.com），说明 Observer 已注册并活跃 - 仅靠
ps -ef | grep observer不可靠——进程可能挂起但 Broker 仍显示 “present”，此时实际已失联 - Observer 日志默认在 $ORACLE_BASE/diag/rdbms/
observer_name/trace/observer.log，关键线索是Connected to database和Starting heartbeat记录
FSFO 切换是否发生？查哪些视图和命令
Observer 触发切换后，状态变化体现在 Broker 元数据和动态性能视图中，而非 Observer 自身日志：
- 在新主库上查
v$dataguard_status：重点关注MESSAGE列含switchover或failover的最近几条记录 - 运行
SELECT FS_FAILOVER_STATUS, FS_FAILOVER_CURRENT_TARGET FROM v$database;—— 若FS_FAILOVER_STATUS为SYNCHRONIZED或REINSTATEMENT IN PROGRESS，说明切换已完成且 Broker 正在同步状态 -
dgmgrl中执行show database verbose "standby_db_name"，观察Role（应为PHYSICAL STANDBY）、Intended State和Transport Lag是否回归正常 - 注意：
v$archive_dest_status中STATUS为VALID且ERROR为空，才是切换后归档传输恢复的可靠信号
Observer 没触发切换？常见卡点在哪
FSFO 未按预期触发，多数问题出在 Observer 与 Broker 的协作前提被破坏，而非 Observer 本身故障：
- 主库必须处于
ENABLED状态且FS_FAILOVER_THRESHOLD设置合理（默认 30 秒，太短易误切，太长影响 RTO） - Observer 必须能同时连通主库和备库的
sys用户（非sysdba权限不行），且网络延迟 - Broker 配置中
FastStartFailoverTarget必须明确指向合法的物理备库名（大小写敏感），且该备库的LogXptMode为SYNC或ASYNC（但 FSFO 要求至少ASYNC） - 主库实例必须处于 OPEN 状态（不是 MOUNT）；若主库崩溃后仅剩实例进程，但数据库未 open，Observer 无法确认其“不可用”，不会强制切换
Observer 进程本身无状态持久化能力，它的全部行为都依赖 Broker 配置和实时网络可达性。最容易被忽略的是：Observer 启动后并不主动刷新 Broker 内部状态缓存，一旦 Broker 配置变更（如修改 FastStartFailoverTarget），必须重启 Observer 才生效。
