Oracle Data Guard 不支持多 Observer 配置，因 FSFO 架构采用单点仲裁模型，仅允许一个 Observer 持有 observer_sid 并维持心跳；多 Observer 会互相踢出、引发状态抖动或误触发，且 Broker 无共享状态与选举机制。
Oracle Data Guard 不支持多 Observer 配置，FSFO（Fast-Start Failover）只允许一个活跃 Observer 实例运行。 尝试启动第二个 dgmgrl 连接并执行 START OBSERVER 会失败，且 Broker 本身不提供主备 Observer 切换或集群化 Observer 的机制。
为什么不能配多个 Observer？
Observer 是 FSFO 架构中唯一具备“决策权”的外部组件，它持续监控主库和备库的存活与同步状态，并在满足条件时触发自动 failover。Broker 的设计模型是单点仲裁：同一 FSFO 配置下，仅允许一个 Observer 持有当前配置的 observer_sid 并维持心跳连接。若强行启动第二个 Observer：
- 第二个
dgmgrl进程会报错ORA-16675: observer already running for this configuration - 即使绕过校验（如改用不同 OS 用户、不同 $ORACLE_HOME），两个 Observer 会互相踢出对方，导致状态抖动、failover 被抑制或误触发
- Broker 内部没有共享状态存储，也不支持 Observer 间协商或选举，不存在“Observer HA”协议层
Observer 单点失效了怎么办？
真实生产中 Observer 宕机不可怕，可怕的是没人知道它挂了。关键不是“多起几个”，而是让 Observer 本身具备可恢复性：
- Observer 必须部署在独立主机（不能和主/备库共机），推荐使用轻量级 VM 或容器，资源占用极低（
- 用系统级守护进程管理，例如 Linux systemd service，配置
Restart=always和RestartSec=10，确保崩溃后秒级拉起 - Observer 启动命令必须带完整连接信息和日志重定向，例如：
dgmgrl / "START OBSERVER FILE=/u01/app/oracle/admin/fsfo/observer.ora" > /u01/app/oracle/admin/fsfo/observer.log 2>&1 &
- 配合监控脚本定期检查
ps -ef | grep observer+tail -n 20 observer.log | grep "Connected to"，异常时告警而非依赖人工巡检
替代方案：用脚本+定时任务模拟 Observer 行为？
不推荐。手动脚本无法可靠实现 FSFO 的核心能力：
- 无法精确判断“主库不可达但备库已同步到最新 SCN”这一关键条件（需要 Broker 内部的
FSFO_THRESHOLD和心跳序列号比对） - 无法安全协调 failover 过程中的角色冻结、重做传输暂停、MRP 停止等原子操作，极易引发脑裂或数据丢失
- 脚本触发的
FAILOVER TO是 manual failover，不满足“零干预”要求，且 Broker 会拒绝在 FSFO 启用时执行该命令 - Oracle 官方明确将非 Broker 方式列为 unsupported 场景，出问题不提供技术支持
Observer 的可靠性取决于部署方式和运维闭环，而不是数量。真正容易被忽略的是：Observer 日志文件路径权限错误导致启动静默失败、$TNS_ADMIN 环境变量未继承导致连接主库时报 ORA-12154、以及忘记在防火墙放行 Observer 主机到主备库的 1521 端口——这些比“能不能加第二个”更常导致故障。
