Broker是RAC环境下Switchover的强制依赖，必须启用DMON进程、配置已加载且状态为ENABLED，切换必须通过DGMGRL执行，严禁使用裸SQL；RAC各节点DMON均需运行，DB_UNIQUE_NAME大小写敏感，线程残留需手动禁用。
确认 Broker 是否启用并处于健康状态
没开 Data Guard Broker 的 RAC 环境做 Switchover，等于裸奔——所有校验、时序、角色同步都得人工盯，稍有延迟就可能卡在 TO STANDBY 或 SESSIONS ACTIVE 状态里出不来。Broker 的 DMON 进程才是整个切换流程的“裁判+计时员”。
- 检查 Broker 是否运行：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'DMON';，主备库都必须返回一行且STATUS = CONNECTED - 确认配置已加载：
DGMGRL> SHOW CONFIGURATION;，输出不能是Configuration status: DISABLED，否则先执行ENABLE CONFIGURATION; - RAC 环境下特别注意：每个节点的
DMON都要起，不能只在实例 1 上启；V$DATAGUARD_CONFIG中的DB_UNIQUE_NAME必须和 Broker 配置完全一致（大小写敏感）
Switchover 命令必须走 DGMGRL，别碰裸 SQL
RAC 主库用 ALTER DATABASE COMMIT TO SWITCHOVER 是高危操作：它不感知集群内其他实例是否还有活跃会话，也不等所有线程的 Redo 传完，容易导致新主库启动后报 ORA-01152: file 1 was not restored from a backup 或 MRP 卡在 WAIT_FOR_GAP。
- 正确姿势：在任意节点的
DGMGRL中执行SWITCHOVER TO <code>db_unique_name;，Broker 会自动在所有 RAC 实例上广播关闭指令，并等待所有线程的 End-of-Redo 到达备库 - 如果提示
ORA-16664: unable to receive the result from a database，大概率是某节点的DMON没起来，或监听器未注册到 SCAN VIP - 切勿在 RAC 备库上手动执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT—— Broker 已接管 MRP 启停，手动干预会导致 Broker 状态错乱
RAC 切换后 Open 新主库和重启原主库的操作顺序不能颠倒
19c+ RAC 环境下，Switchover 完成后，新主库默认处于 MOUNT 状态，但原主库（即将变新备库）不会自动重启。这两步谁先谁后、怎么启，直接决定能否快速恢复服务。
- 先在新主库（原备库）上执行：
ALTER DATABASE OPEN;—— 注意不是STARTUP，因为 Broker 已将其置于MOUNT，只需打开 - 再在原主库（现备库）节点上用
srvctl启动整个数据库：srvctl start database -d <code>db_unique_name，而不是单实例startup，否则 RAC 资源无法注册进 Clusterware - 验证新备库是否开始应用日志：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS IN ('MRP0', 'RFS');，应看到MRP0状态为APPLYING_LOG
最容易被忽略的 RAC 特有陷阱：THREAD 和 GAP_STATUS 误判
RAC 主库若曾增减过节点，V$THREAD 中可能残留 CLOSED 状态但未禁用的线程。Broker 会把它当成“未同步线程”，持续报告 GAP_STATUS = YES，导致 SWITCHOVER_STATUS 卡在 NOT ALLOWED，而实际归档日志并无缺失。
- 查异常线程：
SELECT THREAD#, STATUS, ENABLED FROM V$THREAD;，找出STATUS = CLOSED但ENABLED = YES的记录 - 禁用它：
ALTER DATABASE DISABLE THREAD <code>n;（n是线程号），然后重启数据库使变更生效 - 该问题在 19c/21c RAC + ADG 组合中高频出现，尤其在做过节点滚动升级的生产环境，不处理就永远切不过去
