Oracle Data Guard Switchover成功的关键在于前置三项检查：主备库SWITCHOVER_STATUS必须分别为TO STANDBY/SESSIONS ACTIVE和TO PRIMARY/SESSIONS ACTIVE；归档传输需正常（DEST_ID=2状态VALID且无ERROR，LOG_ARCHIVE_CONFIG双向配置）；日志同步须无延迟（transport lag与apply lag均为+00 00:00:00，且V$ARCHIVED_LOG中APPLIED全为YES）。
必须查清主备库角色状态、归档传输链路、日志同步进度这三项，缺一不可。跳过任一检查，SWITCHOVER 很可能卡在 ORA-16129 或直接失败。
查 SWITCHOVER_STATUS 是否允许切换
这是最常被跳过的一步，但直接决定后续命令是否 hang 住或报 ORA-16129。
- 主库执行
SELECT SWITCHOVER_STATUS FROM V$DATABASE;—— 必须返回TO STANDBY或SESSIONS ACTIVE - 备库执行同语句 —— 必须返回
TO PRIMARY或SESSIONS ACTIVE - 若主库返回
NOT ALLOWED，说明有未传输的 redo（常见于LOG_ARCHIVE_DEST_STATE_2被禁用或归档积压） - RAC 环境下，需先确认只剩一个实例在线：
SELECT INSTANCE_NAME FROM GV$INSTANCE;，否则切到一半报ORA-01105
验证归档传输是否正常（V$ARCHIVE_DEST_STATUS）
主库归档发不出去，备库永远收不到日志，SWITCHOVER 会因等待日志而超时。
- 主库查：
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;——STATUS必须是VALID，ERROR列为空 - 检查
LOG_ARCHIVE_CONFIG是否双向包含主备DB_UNIQUE_NAME，例如：'DG_CONFIG=(orcl,orcl_stby)'；漏掉任一方向，DGMGRL就无法识别角色关系 - 备库
ARCHIVE_LAG_TARGET不建议设过大（如 > 1800），否则人为延迟归档传输，导致apply lag非零
确认日志同步无延迟（v$dataguard_stats 和 v$archived_log）
即使传输正常，也不代表已应用。必须确认“传得完、收得到、用得上”三者同时成立。
- 备库执行：
SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS WHERE NAME IN ('transport lag', 'apply lag');—— 两者都应为+00 00:00:00 - 主库查最近归档是否已送达备库：
SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG WHERE DEST_ID = 2 ORDER BY SEQUENCE# DESC FETCH FIRST 5 ROWS ONLY;——APPLIED列全为YES - 若发现 gap：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;，需手工补传并注册
真正能一次成功的 SWITCHOVER，90% 的功夫花在检查上，而不是执行上。最容易被忽略的是 LOG_ARCHIVE_CONFIG 配置缺失和 RAC 多实例残留——这两处不提前清理，命令根本不会开始执行，而是静默挂起或报错退出。
