Oracle 19c RAC+DG不支持自动选主，DG仅支持DBA显式触发或Observer监控下的switchover/failover；真正的“自动接管”需DG层failover、服务层启PRIMARY服务、网络层VIP/DNS切换三者协同完成。
Oracle 19c RAC+DG 架构里没有“自动选主”这回事
Oracle Data Guard 本身不提供跨集群的自动主库选举能力。RAC 主库内部靠 OCR 和 Voting Disk 保证单集群内实例一致性，DG 只负责主备角色切换（switchover/failover），且必须由 DBA 显式触发或 Observer 监控后执行——它不会在多个 RAC 集群之间“投票选出新主库”。所谓“自动选主”，实际是误把 Fast-Start Failover 或第三方 VIP 工具（如 Keepalived）的行为当成了 DG 原生能力。
真正能落地的“自动接管”依赖三个分层动作
要让应用在主 RAC 集群整体不可用后连上新的主库，必须串联完成以下三件事，缺一不可：
- DG 层：Observer 触发
FAILOVER，将备 RAC 集群提升为 PRIMARY - 服务层：通过
DBMS_SERVICE.START_SERVICE动态启用ROLE = 'PRIMARY'的服务名（如mydb_primary），并停掉旧的mydb_standby - 网络层：VIP 或 DNS 切换指向备 RAC 的 SCAN 地址；若用 Keepalived，需在其脚本中调用
srvctl start service并等待V$ACTIVE_SERVICES确认服务 RUNNING
漏掉任何一层，客户端连接就会失败——比如只做了 DG failover 但没启服务，tnsping mydb_primary 会超时；服务起来了但 VIP 没漂，客户端仍连向原机房地址。
为什么 V$DATABASE.FSFO_STATUS = SYNCHRONIZED 是硬门槛
Observer 不会因为配置了 ENABLE FAST_START FAILOVER 就开始监控。它只信任这个视图值。一旦退为 NOT SYNCHRONIZED，Observer 立即停止判断，日志里只写 Waiting for primary to become unavailable，看起来像卡死，其实是主动放弃。
常见诱因包括：
- 主库某 THREAD 归档中断超过
LOG_ARCHIVE_DEST_2.REOPEN设置（默认 300 秒），而该 THREAD 正在写日志 - 备库
OPEN_MODE是READ ONLY而非READ ONLY WITH APPLY，Real-Time Apply 实际未运行 - 主备
PROTECTION_MODE不一致：主库设MAXIMUM AVAILABILITY，但备库仍是MAXIMUM PERFORMANCE（Broker 修改后需SWITCHOVER或重启才生效）
Observer 启动失败的三个真实报错点
别只看 dgmgrl SHOW CONFIGURATION 显示 ENABLED。Observer 日志（$ORACLE_HOME/rdbms/log/drc*.log）里反复出现连接失败，90% 是下面这三个原因：
-
StaticConnectIdentifier配错：必须含(INSTANCE_NAME=)和(SERVER=DEDICATED)，仅写(HOST=...)(PORT=...)(SERVICE_NAME=...)不行 - 监听器没配 DGMGRL 专用服务名：
listener.ora中SID_DESC.GLOBAL_DBNAME必须是<db_unique_name>_DGMGRL（如rac_primary_DGMGRL），否则 Broker 反向注册失败 - Observer 主机没装 Oracle 软件：19c 强制要求 Observer 机器有同版本
ORACLE_HOME，且tnsnames.ora、sqlnet.ora全部就位；用 SSH 远程执行dgmgrl -silent "START OBSERVER"无效，必须本地终端运行
复杂点在于：这些检查项彼此耦合。比如 StaticConnectIdentifier 错了，Observer 连不上主库，就无法读取 V$DATABASE.FSFO_STATUS，进而永远卡在等待状态——你得先查日志定位哪一层断了，再逆向验证前置条件。
