必须在业务低峰期执行且不可跳过任何状态校验；主备库switchover_status须为to standby或sessions active，rac环境需全节点一致；主库切换后必须startup mount并验证database_role为physical standby；备库切主后须手动启mrp并确认transport lag与apply lag均为+00 00:00:00。
必须在业务低峰期执行，且全程不能跳过任何状态校验——switchover_status不是“看看就行”，而是切换能否启动的硬闸。
查主备库switchover_status前先清空干扰会话
主库返回 SESSIONS ACTIVE 很常见，但别急着加 WITH SESSION SHUTDOWN。先确认这些会话是否真影响切换：
-
V$SESSION中USERNAME为空或为SYS、SYSTEM的后台进程（如CKPT、LGWR）不构成阻塞，可忽略 - 真正要杀的是应用连接：查
SELECT sid, serial#, username, program FROM v$session WHERE type='USER'，对非 DBA 用户会话执行ALTER SYSTEM KILL SESSION 'sid,serial#' - RAC 环境下，
switchover_status可能因节点间元数据未同步而显示不一致，需在所有节点运行SELECT inst_id, switchover_status FROM gv$database，确保全部返回TO STANDBY或SESSIONS ACTIVE
主库执行COMMIT TO SWITCHOVER TO PHYSICAL STANDBY后必须STARTUP MOUNT
这条命令触发 End of Redo 标记写入，并强制归档当前日志。执行后主库实例自动关闭，但控制文件已标记为 PHYSICAL STANDBY 角色——此时不能直接 STARTUP，否则报 ORA-01507（11.2.0.4 及更早版本）或卡在 MOUNT 阶段（12c+）。
- 11g 环境统一用：
SHUTDOWN ABORT→STARTUP MOUNT，跳过SHUTDOWN IMMEDIATE（它可能因等待归档完成而挂住） - 执行完立刻验证：
SELECT database_role FROM v$database必须返回PHYSICAL STANDBY；若只返回STANDBY，说明控制文件未更新，DG 配置有缺陷 - 别等备库切完再查——主库
STARTUP MOUNT后，立刻在备库上查v$archive_dest_status的STATUS是否为VALID，ERROR字段是否为空，否则备库收不到后续日志
备库切主后必须手动启MRP并验证apply lag
备库执行 ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY 后，数据库角色变为 PRIMARY，但不会自动打开——必须显式执行 ALTER DATABASE OPEN。此时原主库（现备库）尚未启动日志应用进程，同步链路实际中断。
- 新主库
OPEN后，立即在原主库（新备库）上执行：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT - 检查
v$managed_standby：必须看到PROCESS = 'MRP0'且STATUS = 'APPLYING_LOG'；若只有ARCH或RFS进程，说明 MRP 没起来 - 验证同步延迟：
SELECT name, value FROM v$dataguard_stats WHERE name IN ('transport lag', 'apply lag')，两个值都必须是+00 00:00:00；哪怕apply lag是+00 00:00:01，也意味着最新日志还没应用完，此时做二次切换仍可能丢数据
最易被忽略的是 RAC 环境中 MRP 进程的绑定节点——它只在一个实例上运行，切换命令必须在该实例执行，否则 switchover_status 始终卡在 NOT ALLOWED，而你可能还在其他节点反复重试。
