oracle 19c data guard 的 observer 不支持多实例部署，因其为单进程、无状态、无集群协调机制的独立客户端工具；多个实例会竞争配置文件、引发脑裂，官方明确限制仅允许单例运行。
oracle 19c data guard 中 observer 本身不支持多实例部署，所谓“多实例 observer”是常见误解——observer 是单进程、单配置文件、单监听端口的独立客户端工具，无法像 rac 那样横向扩展。
为什么不能起多个 observer 进程协同工作
Observer 进程设计上无状态、无集群协调机制，它只读取一个 dgbroker.ora 配置文件，并通过 SQL*Net 连接主备库做角色判断和自动故障响应。若手动启动多个 observer：
- 它们会竞争同一份
dgbroker.ora，导致参数覆盖或解析失败 - 没有心跳/选主逻辑，无法区分哪个该执行 failover，极易引发脑裂（如主库短暂网络抖动时，两个 observer 同时触发 switchover）
- Oracle 官方文档明确指出：
DGMGRL启动的 observer 仅支持单实例运行，START OBSERVER命令在已有 observer 运行时直接报错ORA-16672: observer already running
真正可用的高可用 Observer 替代方案
要提升 Observer 的可靠性，必须绕开“多实例”思路，转而强化其运行载体和监控链路：
- 把 observer 进程部署在高可用宿主机上：例如 Linux 上用
systemd配置自动拉起 + 健康检查（定期ps -ef | grep observer+ 连通性探测） - 使用外部负载感知调度器：比如 Oracle Enterprise Manager Cloud Control 或 Zabbix，当检测到 observer 进程退出或监听端口不可达时，自动在备用节点重新执行
dgmgrl / "START OBSERVER" - 禁用 observer 的自动 failover，改用人工干预流程：在
EDIT DATABASE ... SET PROPERTY AutoFailover='OFF'后，配合脚本定时调用SHOW DATABASE VERBOSITY+VALIDATE DATABASE输出日志，供值班人员快速决策
observer 启动时最容易被忽略的三个依赖项
即使只跑一个 observer，以下三点配置错误也会导致它静默失效：
-
TNSNAMES.ORA必须包含主库、备库的完整服务名定义，且每个服务名的ADDRESS指向 SCAN VIP 或单节点 VIP —— 若写成 localhost 或 127.0.0.1，observer 将无法跨网络连接远端库 - observer 所在主机的
ORACLE_HOME必须与主备库版本严格一致（特别是 19c 的 RU 补丁级别），否则DGMGRL解析 broker 配置时可能报ORA-16501: command not supported - observer 进程启动用户需对
$ORACLE_HOME/dbs有读写权限，否则无法生成临时控制文件dr1<db_name>.dat</db_name>，日志中会出现ORA-27040: file create error
Observer 的价值不在数量，而在其运行环境的确定性。与其花精力部署“第二个 observer”，不如确保第一个能稳定存活 365 天——这包括它的操作系统账户权限、网络路径稳定性、以及配套的进程看护机制。
