必须先查主库switchover_status为to standby或sessions active、备库为to primary或sessions active，否则90%会卡在ora-16139或失败；再验证归档传输与应用、mrp状态、log_archive_config及dest配置、fal_server、无归档断档且应用进度差≤1。
主备切换前不检查 SWITCHOVER_STATUS，90% 会卡在 ORA-16139 或直接失败。这不是流程问题，而是状态校验缺失导致的硬性阻断。
查主库和备库的 SWITCHOVER_STATUS 值是否合法
这个字段是 Oracle 内部判断“此刻能不能切”的唯一开关，不能靠经验或时间推断。
- 主库必须返回
TO STANDBY；如果返回SESSIONS ACTIVE，说明有未提交事务或活跃连接，需加WITH SESSION SHUTDOWN强制切 - 备库必须返回
TO PRIMARY或SESSIONS ACTIVE；若为NOT ALLOWED或SWITCHOVER LATENT，说明归档没收全或 MRP 没跑起来 - 执行语句就是一句：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;，别漏掉分号，也别在备库上用OPEN状态去查（物理备库应为MOUNT）
确认备库 MRP 进程是否真正在应用日志
光看进程存在没用，得看它有没有卡住、有没有跳过归档、有没有报错。
- 查进程状态：
SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';——STATUS必须是APPLYING_LOG - 查应用进度：
SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;——APPLIED_SEQ#和ARCHIVED_SEQ#差值应 ≤ 1，否则说明有积压 - 常见坑：备库启了
ARCHIVE_LAG_TARGET（比如设成 1800），会导致归档延迟写入，切换前务必临时禁用：ALTER SYSTEM SET ARCHIVE_LAG_TARGET=0;
验证 LOG_ARCHIVE_DEST_2 和 LOG_ARCHIVE_CONFIG 配置是否双向对齐
DG Broker 或 SQL 方式切换都依赖这两个参数，写错一个字母就触发 ORA-16664。
- 主库和备库都要运行：
SHOW PARAMETER LOG_ARCHIVE_CONFIG;—— 输出里必须同时包含双方的DB_UNIQUE_NAME，格式如：'DG_CONFIG=(orcl,orcl_stdy)' - 主库查：
SHOW PARAMETER LOG_ARCHIVE_DEST_2;—— 确保SERVICE指向的是备库的 TNS 名，且VALID_FOR包含(ONLINE_LOGFILES,PRIMARY_ROLE) - 备库查：
SHOW PARAMETER FAL_SERVER;—— 值必须是主库的DB_UNIQUE_NAME，不是服务名，也不是 IP
检查主库归档传输是否无积压且状态为 ENABLE
即使 MRP 在跑，如果主库根本没把归档发出去，备库再努力也是空转。
- 查传输状态：
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;——STATUS必须是VALID，ERROR列为空 - 查积压量：
SELECT * FROM V$ARCHIVE_GAP;—— 返回空集才表示没有断档 - 确认开关开着：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'log_archive_dest_state_2';—— 结果必须是ENABLE，不是DEFER或DISABLE
最容易被忽略的是：切换前没停应用写入，或者没确认 COMPATIBLE 参数一致。哪怕只差一个小版本（比如主库是 19.0.0，备库是 19.3.0），DGMGRL 就会静默拒绝命令，错误藏在 SHOW DATABASE VERBOSITY 输出里，不主动查根本看不到。
