Observer 在断开后不会自动重连，必须手动重新启动，并确认 Broker 状态已经完成同步。它本质上属于一次性执行命令，不会常驻后台。常见失效原因包括：未在独立主机上执行、环境变量配置错误、日志目录没有写入权限，以及主备库之间网络不可达。排查和验证时，需要重点查看 dgmon 进程、drc*.log 日志，以及 SHOW FAST_START FAILOVER 的输出结果。
Observer 断开后不会自动恢复连接，必须手动重启并确认 Broker 状态同步——这正是很多人误以为“只要启动过一次就会一直运行”的主要原因。
为什么 dgmgrl START OBSERVER 会失效或静默退出
Observer 进程本身不是守护进程，也不会自动在后台持续驻留，dgmgrl -silent "START OBSERVER" 只是一次性启动命令，执行结束后当前命令行会退出。常见导致启动失败或无提示退出的原因包括：
- 执行位置不在独立的 observer 主机上（例如通过远程 SSH 调用
dgmgrl，并不会真正拉起本地 Observer 实例） ORACLE_HOME或PATH配置不正确，导致系统无法找到或启动dgmon后台进程- Observer 日志目录（默认
$ORACLE_HOME/rdbms/log/）没有写权限，启动时会直接失败，但往往不会明显报错 - Broker 配置中的主库与备库网络不通，Observer 启动后几秒内因心跳检测失败退出，日志中通常只看到
ORA-16664: unable to receive results from database
如何确认 Observer 是否真正处于运行状态
不能只根据命令是否返回成功来判断 Observer 是否正常工作，建议同时检查以下三个方面：
- 执行
ps -ef | grep observer，确认存在dgmon进程，并且它的父进程不是 shell，而是由oracle用户维持的长期运行进程 - 检查日志文件：
tail -f $ORACLE_HOME/rdbms/log/drc*.log，正常情况下应持续输出类似Observer is monitoring configuration的信息以及心跳时间戳 - 在
dgmgrl中连接 Broker 后执行SHOW FAST_START FAILOVER，输出结果中Observer Enabled必须为YES，同时FSFO Status应显示为SYNCHRONIZED，而不是STARTED或空白
FSFO_STATUS = NOT SYNCHRONIZED 时应该先处理什么
这个状态比“Observer 进程是否还在”更重要——它表示 Broker 已经检测到主备数据未同步，即使 Observer 仍在运行，也不会触发自动切换。推荐按以下顺序处理：
- 先在主库执行
SELECT FSFO_STATUS FROM V$DATABASE，确认返回值为SYNCHRONIZED；如果不是，说明 redo 传输或应用过程存在阻塞，需要先排查并解决日志 GAP 问题 - 再检查备库的
V$ARCHIVE_DEST_STATUS，重点确认STATUS = VALID且ERROR列为空；如果出现ORA-16057或ORA-16714，则需要修复归档路径、传输配置或数据库角色设置 - 最后再重启 Observer：先停止旧进程（对查到的
dgmon执行kill -9），清理旧日志文件，然后使用完整路径重新执行$ORACLE_HOME/bin/dgmgrl -silent "START OBSERVER"
Observer 是否可靠，关键不在于“是否启动过”，而在于它能否持续读取 V$DATABASE.FSFO_STATUS 并与 Broker 保持稳定通信。无论是权限异常、网络中断、日志路径不可写，还是 SCN/数据同步异常，只要其中任一环节出现问题，Observer 都可能变成“看似运行、实际无效”的摆设。
