能连，但角色可能已半切换——主库执行alter database commit to switchover to standby with session shutdown后若未完成重启，则处于mount状态、open_mode为mounted，switchover_status变为to primary或recovery needed，属中间态，需人工干预恢复服务。
Switchover中途失败后主库还能连上吗？
能连，但角色可能已半切换——比如主库执行了ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN但没完成重启，此时数据库处于MOUNT状态、OPEN_MODE为MOUNTED，且SWITCHOVER_STATUS变成TO PRIMARY或RECOVERY NEEDED。这不是“回退失败”，而是卡在中间态，必须人工干预才能恢复服务。
备库没切成功，主库已停MRP，怎么快速恢复原主库？
别急着重启或重跑switchover命令。先确认主库当前是否仍能归档、备库是否还在接收日志：
- 查主库：
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2—— 如果STATUS是ERROR或DEFERRED，说明归档传输已断，需先ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE - 查备库：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY—— 若RFS进程缺失或MRP未启动，手动启ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT - 确认备库已追平：
SELECT MAX(SEQUENCE#), APPLIED FROM V$ARCHIVED_LOG WHERE APPLIED = 'YES' GROUP BY APPLIED，结果应与主库V$ARCHIVE_DEST_STATUS.ARCHIVED_THREAD#一致
主库已shutdown immediate，但备库没升主，怎么救？
这是最典型的“半切”场景：主库关了，备库还卡在NOT ALLOWED或SESSIONS ACTIVE。关键不是强行开主库，而是让备库先具备升主条件：
- 在备库查
SELECT SWITCHOVER_STATUS FROM V$DATABASE，若返回NOT ALLOWED，大概率是还有未应用日志或MRP没运行，先补ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT - 若返回
TO PRIMARY，直接执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY—— 不要加WITH SESSION SHUTDOWN，备库此时无用户会话 - 升主成功后，原主库（现备库）必须用
ALTER DATABASE CONVERT TO PHYSICAL STANDBY重建控制文件，再STARTUP MOUNT，否则后续RECOVER会报ORA-01152
DG Broker下Switchover中断，SHOW CONFIGURATION显示FAILURE怎么办？
Broker不会自动回滚，它只记录“尝试过”。Configuration status: FAILURE意味着Broker缓存里存了不一致状态，但底层数据库未必真坏。处理顺序不能乱：
- 先在备库执行
VALIDATE DATABASE 'standby_db_name'，看具体哪项失败（常是Redo Transport Services或Apply Services） - 若提示
State: UNKNOWN，不是删配置，而是先ENABLE DATABASE 'standby_db_name'—— 这会触发Broker重新握手，多数情况下就能刷新状态 - 只有当
ENABLE持续失败（如报ORA-16778或ORA-16792），才考虑DISABLE DATABASE+REMOVE DATABASE，但必须主备库同步操作，且提前备份.dat文件
真正难处理的不是命令怎么写，而是判断“哪边已经动了、哪边还没动”。Switchover回退的本质是状态对齐，不是倒带录像。只要有一边的控制文件或归档序列号没对上，硬推就会触发ORA-1056或ORA-1152——这些错误背后都是物理一致性被破坏，得靠RECOVER DATABASE UNTIL或闪回来兜底，而不是重试COMMIT TO SWITCHOVER。
