Oracle 19c中FSFO仅允许一个Observer处于ACTIVE状态，启动第二个会触发ORA-16652错误并踢出原Observer；这是为避免脑裂而设计的强制仲裁机制，非限制而是核心安全约束。
Oracle 19c不支持多个Observer同时管理同一Data Guard配置
直接说结论：FSFO（Fast-Start Failover）机制在 Oracle 19c 中**只允许一个 Observer 进程处于 ACTIVE 状态**。尝试启动第二个 dgmgrl 连接并执行 START OBSERVER，会报错 ORA-16652: observer already running，且已有 Observer 的状态会从 ACTIVE 变为 INACTIVE —— 新启动的接管，旧的被踢出。
这不是限制，而是设计：Observer 不是“监控服务”，而是 FSFO 切换逻辑的唯一仲裁者。它需要独占持有主备库的实时状态快照、心跳信号和故障判定权。两个 Observer 同时运行会导致脑裂风险，比如主库网络抖动时，不同 Observer 可能基于局部视图做出相反决策。
为什么有人想配多个Observer？常见误解场景
用户提出“多个 Observer”需求，通常源于以下真实痛点，但解决方案不是加 Observer：
- 单点故障担忧：Observer 主机宕机 → FSFO 失效 → 只能手动切换
→ 正确做法：用操作系统级高可用（如 Pacemaker + VIP）保护 Observer 进程，或用脚本+定时任务做轻量级健康检查与自动拉起 - 跨地域延迟高：Observer 部署在主库同城机房，但备库在异地 → 心跳超时误判
→ 正确做法：调整FastStartFailoverThreshold（默认30秒），设为 ≥ 主备间最大网络 RTT × 3；同时确保 Observer 到主备的tnsnames.ora使用低延迟路由 - 维护窗口期需临时停 Observer
→ 正确做法：停之前先执行DISABLE FAST_START FAILOVER，维护完再ENABLE；切勿强行 kill 进程后留 Observer 状态不一致
Observer 主机本身可部署多实例，但必须分属不同DG配置
一台物理机或 VM 上可以运行多个 dgmgrl 实例，但每个 Observer **只能绑定一个 Data Guard Broker 配置**（即一个 broker_config_file）。你不能让两个 Observer 共享同一个 dmnn.ora。
若你有多个独立 DG 配置（例如：生产库 A ↔ 备库 A，测试库 B ↔ 备库 B），可在同一台机器上启动两个 Observer：
- 启动第一个：
dgmgrl -silent "CONNECT sys/password@primary_a" "START OBSERVER OBSERVER_CONFIG_FILE=/dg/broker/a/dmnn_a.ora" - 启动第二个：
dgmgrl -silent "CONNECT sys/password@primary_b" "START OBSERVER OBSERVER_CONFIG_FILE=/dg/broker/b/dmnn_b.ora" - 两个 Observer 日志分别落于各自
OBSERVER_CONFIG_FILE所在目录下的drc*.log
注意：OBSERVER_CONFIG_FILE 路径必须显式指定，否则默认复用 $ORACLE_HOME/dbs/dmnn.ora，必然冲突。
真正该关注的容灾点：Observer 自身状态不可见
最常被忽略的是：Observer 进程活着 ≠ FSFO 就能切。必须每天检查：
-
SELECT FSFO_STATUS FROM V$DATABASE—— 必须为SYNCHRONIZED，不是ENABLED -
SELECT VALUE FROM V$DATAGUARD_STATS WHERE NAME = 'apply lag'—— 值应稳定在 0 或极小（ -
tail -n 20 $ORACLE_HOME/rdbms/log/drc*.log—— 搜索ERROR或TIMEOUT，尤其注意连接主库或备库失败的记录
Observer 没有心跳接口、不暴露端口、不写 alert.log，它的健康完全依赖日志和视图。一旦它卡在 Waiting for primary to become unavailable，而你只盯着进程是否存在，就会错过真实故障窗口。
