Observer 不能只配一个，因为单点故障会导致Fast-Start Failover必然停摆；Oracle要求至少两个Observer达成共识才能批准切换，二者须部署在不同节点、独立运行并靠投票防脑裂。
Observer 为什么不能只配一个
单 observer 是故障单点，一旦宕机，data guard 就失去自动故障判断能力，fast-start failover 会直接挂起，主库出问题时无法触发自动切换。这不是“可能失效”，而是“必然停摆”——因为 oracle 要求至少两个 observer 实例达成共识（quorum）才能批准 failover。
- Observer 不参与数据同步，只监听角色状态和心跳；但它必须能连上主库、备库、以及另一个 Observer
- 两个 Observer 必须部署在不同物理节点或可用区，禁止共用同一台主机或同一套网络出口
- 它们不共享状态，也不主从分工，靠
DGMGRL的START OBSERVER命令各自独立运行，靠内部投票机制避免脑裂
启动双 Observer 的实操要点
启动顺序和参数稍有偏差，就容易出现“一个在跑，一个报错退出”或者“两个都连不上备库”。关键不在命令多复杂，而在环境准备是否闭环。
- 确保两个 Observer 主机的
tnsnames.ora都正确定义了主库（PRIMARY_DB）、备库（STANDBY_DB）和服务名，且SQL*Net连通性双向验证过（tnsping+sqlplus /@PRIMARY_DB） - 启动命令必须带完整路径和显式服务名：
DGMGRL> START OBSERVER observer1.ora，其中observer1.ora是配置文件，内容只需一行：CONNECT IDENTIFIER IS PRIMARY_DB（另一台用STANDBY_DB或保持一致，Oracle 12c+ 允许两者都连主库） - 不要后台运行
nohup dgmgrl ... &，改用系统服务管理（如 systemd），否则进程意外退出后无日志、无告警
Fast-Start Failover 启用前必须核对的三项配置
很多“启用了但切不动”的问题，根源是这三项中某一项没生效，而不是 Observer 本身坏了。
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
-
FastStartFailoverThreshold：默认 30 秒，但若网络延迟波动大（比如跨城专线），设成 60 更稳；设太小会导致误触发 -
FastStartFailoverLagLimit：控制最大允许延迟（单位秒），如果设为 0，意味着备库必须完全实时，稍有归档积压就拒绝 failover；生产建议设为 90～180 -
FastStartFailoverAutoReinstate：务必设为TRUE，否则 failover 后原主库恢复上线时不会自动转为新备库，需要手动干预
Observer 日志里最该盯住的三类错误
Observer 日志（默认在 $ORACLE_BASE/diag/rdbms/observer_name/trace/）不是用来查性能的，是用来确认“它到底信不信得过当前集群状态”的。
-
ORA-16664: unable to receive the result from a database：说明 Observer 连不上某个数据库，不是 DB 问题，先查本地tnsping和防火墙 -
FSFO: Observer state is INACTIVE：常见于 Observer 启动后未执行ENABLE FAST_START FAILOVER，或主备库的LogXptMode不是SYNC -
FSFO: Quorum lost, only 1 observer alive：另一个 Observer 已失联超 2 分钟，此时 failover 处于“半锁定”状态——可手动触发，但自动触发被禁用
Observer 本身没有“高可用组件”，它的高可用全靠部署逻辑和外部监控兜底。最容易被忽略的是：没人定期检查两个 Observer 进程是否都在，也没人验证它们写的 trace 文件里有没有新增错误行——这比配错参数更常导致故障时措手不及。
