Switchover卡住主因是前置状态未满足：主库SESSIONS ACTIVE多因RAC多实例或后台进程残留；备库NOT ALLOWED通常因LOG_ARCHIVE_DEST_STATE_2未ENABLE或归档传输异常；DGMGRL卡住则常因监听配置、LOG_ARCHIVE_CONFIG单向或MRP未启动。
Switchover卡住不是“命令没反应”，而是状态卡在某个检查点不动——最常见的是主库SWITCHOVER_STATUS长期为SESSIONS ACTIVE，或备库始终是NOT ALLOWED，本质是前置依赖没满足，不是命令写错了。
查SWITCHOVER_STATUS为什么一直不更新
这个字段卡住，90%不是SQL语法问题，而是后台进程或实例状态干扰了角色判断。
- 主库返回
SESSIONS ACTIVE但没进展：RAC环境下要确认是否只剩一个实例OPEN；用SELECT INST_ID, STATUS FROM gv$instance;查，多于一个OPEN就会卡死 - 单实例主库也卡在
SESSIONS ACTIVE：检查是否有未退出的racgimon、j000等后台会话，它们不归用户控制，但会阻塞切换校验 - 备库一直是
NOT ALLOWED：先确认LOG_ARCHIVE_DEST_STATE_2是否为ENABLE，再查v$archive_dest_status里DEST_ID = 2的STATUS是否VALID，ERROR列非空就直接失败
为什么DGMGRL执行SWITCHOVER TO后没动静
Broker不是黑盒，它卡住时通常已在后台反复重试，但被某个硬性条件拦住了。
- 连不上就别往下走：
DGMGRL> CONNECT sys/password@primary_db报ORA-12514，大概率是监听器没配GLOBAL_DBNAME = <db_unique_name>_DGMGRL</db_unique_name>，不是密码或TNS错 -
SHOW CONFIGURATION末尾不是Configuration status: SUCCESS：说明LOG_ARCHIVE_CONFIG没双向配置，比如主库写了'DG_CONFIG=(orcl,orcl_stby)'，但备库漏了orcl - 执行
SWITCHOVER TO 'orcl_stby'后卡住：立刻查v$managed_standby，如果MRP0进程不存在或状态是WAIT_FOR_LOG，说明备库根本没收到新归档，问题不在Broker而在传输链路
切到一半停住，新主库OPEN_MODE是MOUNTED且SWITCHOVER_STATUS变FAILED DESTINATION
这说明切换逻辑走完了，但归档路径配置没同步生效，新主库无法对外发日志。
- 最常踩的坑：
log_archive_dest_2还指向旧备库地址，或者log_archive_dest_state_2被设成DEFER，导致新主库启动后立刻断传 - 检查方式：在新主库上运行
SELECT DEST_ID, STATUS, ERROR FROM v$archive_dest_status WHERE DEST_ID = 2;，ERROR列出现ORA-09285（权限）或ORA-16038（日志重用）就定位到根因 - 别只改
spfile：如果用ALTER SYSTEM SET动态修改，必须加SCOPE=BOTH，否则重启后还原，下次切换还会挂
真正难排查的从来不是“哪条命令错了”，而是状态看似正常却卡在某个隐式依赖上——比如standby_file_management=MANUAL时主库新增了PDB，备库ASM磁盘组里缺对应路径，MRP0就静默停摆，v$archive_gap照样为空。这类问题不会报错，只会让一切停在“看起来该动却不动”的地方。
