RAC主库多实例并存导致SWITCHOVER_STATUS卡在SESSIONS ACTIVE是正常现象，因racgimon等后台进程被计入活跃会话；需停一个实例并执行ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN。
主库多实例并存导致 SWITCHOVER_STATUS 卡在 SESSIONS ACTIVE
这不是配置错误，而是 RAC 环境下必然出现的现象。只要主库还有多个实例在线，v$database.switchover_status 就大概率返回 SESSIONS ACTIVE，哪怕你查 v$session 看不到用户会话——后台进程如 racgimon、j000 仍被计入“活跃会话”。
实操建议：
- 先查残留进程：
SELECT SID, SERIAL#, PROGRAM FROM v$session WHERE PROGRAM LIKE '%racgimon%' OR PROGRAM LIKE '%J00%' - 停掉一个实例：
srvctl stop instance -d <db_unique_name> -n <node_name>（别只 shutdown，要确保 CRS 资源 offline） - 再执行：
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN——这条命令跳过会话检查，直接降级 - 切忌用
ALTER SYSTEM KILL SESSION杀racgimon：它属于集群健康监控关键进程，杀错可能触发 OCR 异常
ORA-01105 或 ORA-1093 报错源于多实例挂载冲突
这两个错误本质一样：RAC 主库或备库存在多个实例同时处于 MOUNT 状态，Broker 或 SQL 切换命令检测到跨实例 mount 冲突，直接拒绝执行。
验证方式必须用全局视图：SELECT INST_ID, STATUS, DATABASE_ROLE FROM gv$instance
- 主库应仅有一行显示
OPEN，其余为NOT MOUNTED（不是DOWN或空白） - 备库必须全部为
MOUNTED，且不能有任何OPEN实例 - 停实例后务必确认 CRS 状态：
crsctl stat res -t | grep <db_unique_name>，看到对应实例资源是OFFLINE才算真正释放 - 如果备库是单实例对接 RAC 主库，更要检查备库本地是否有未清理的后台连接（比如
ora_q000_*进程），它们也会触发ORA-1093
MRP 进程起不来或卡在 WAIT_FOR_LOG
切换后新备库无法启动 MRP，或者 v$managed_standby 中 MRP0 状态停滞，根本原因不是 Broker 配置问题，而是日志应用链底层断裂。
必须逐项确认：
-
SELECT OPEN_MODE, DATABASE_ROLE FROM v$database—— 结果必须是MOUNTED+PHYSICAL STANDBY；若为READ ONLY，说明没走对切换路径 -
SELECT GROUP#, THREAD#, BYTES/1024/1024 MB, STATUS FROM v$standby_log—— 缺失 SRL、状态为UNASSIGNED或线程不匹配都会让 MRP 拒绝启动 - 检查 ASM 磁盘组是否已正确挂载：
SELECT NAME, STATE FROM v$asm_diskgroup；常见坑是备库用了和主库同名但未 mount 的磁盘组（比如+DATA在备库没 mount） - 如果备库是 19c 而主库是 12c，还要确认是否已完成滚动升级：19c 的 MRP 无法解析 12c 原始 redo 格式，必须先用 12.2 实例中转同步，再升级
密码文件不同步或缺失 SYSBACKUP 权限
切换过程中报 ORA-01017（用户名密码错误）或 ORA-16664（无法联系主库），90% 是因为 RAC 各节点密码文件不一致，或没包含 SYSBACKUP 权限。
这个权限不是可选的——DG Broker 和远程归档传输都依赖它认证。
- 所有 RAC 节点必须使用同一份密码文件（通过
scp同步，不能各建各的） - 创建时加
SYSBACKUP：orapwd file=$ORACLE_HOME/dbs/orapw<sid> password=<pwd> format=12.2 sysbackup=y - 验证权限：
SELECT * FROM V$PWFILE_USERS WHERE USERNAME = 'SYS' AND SYSBACKUP = 'TRUE' - 切记：即使主库已启用了
FORCE LOGGING，如果密码文件没同步，备库连归档接收都建立不了连接
最易被忽略的是：切换完成后，19c 新主库上 LOG_ARCHIVE_DEST_1 如果还指向旧 ASM diskgroup（如 +FRA12），归档会静默失败；而 srvctl modify database -d xxx -o $ORACLE_HOME 必须显式执行，否则集群资源仍绑定旧 Oracle Home。
