oracle data guard主备切换需基于实时状态分场景执行并闭环验证，switchover前须确认主备角色、同步延迟、日志应用及归档缺口四项核心状态，failover须严守mrp停止顺序、名称一致性与监听清理，级联架构下必须逐级切换并更新参数。
生产环境下 Oracle Data Guard 主备切换不是“按步骤点确认”就能完成的操作，而是必须基于实时状态判断、分场景执行、且每一步都带验证闭环的运维动作。能切成功不等于切得对，关键看是否保住了 RPO 和 RTO 目标。
Switchover 前必须确认的 4 个核心状态
Switchover 是计划内切换，前提是主备双方都在线、同步无延迟、角色可转换。不能只看 switchover_status 返回值，要交叉验证：
-
SELECT database_role, protection_mode, switchover_status FROM v$database;—— 主库必须是PRIMARY且switchover_status为TO STANDBY或SESSIONS ACTIVE；备库必须是PHYSICAL STANDBY且switchover_status为TO PRIMARY -
SELECT name, value, datum_time FROM v$dataguard_stats WHERE name IN ('transport lag', 'apply lag');—— 两个值都必须是+00 00:00:00；注意datum_time要在最近 30 秒内，否则说明 MRP 进程已卡住 -
SELECT sequence#, applied FROM v$archived_log WHERE dest_id = 2 ORDER BY sequence# DESC FETCH FIRST 10 ROWS ONLY;—— 最新几条的applied必须全为YES；如果出现NO，说明日志已传到但未应用，需查v$managed_standby看 MRP 是否 RUNNING -
SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;—— 在备库执行，结果必须为空；有 gap 意味着归档断档，此时 Switchover 会失败或导致数据丢失
Failover 执行时最常踩的三个坑
Failover 是主库不可用后的应急操作，但很多人把它当“快速切库命令”来用，结果切完发现数据不一致、服务连不上、甚至原主库再也起不来：
- 没先停 MRP 就直接
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;—— 这会导致部分归档日志被跳过，FINISH不等于“补齐所有日志”，它只做最后一次 gap resolve + 切换准备；正确顺序是：CANCEL→FINISH→ 验证v$archive_gap为空 → 再ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE; - 忽略
db_unique_name和 TNS 别名一致性 —— 切换后新主库的db_unique_name没改回原主库名（如从ECMSDG1改回ECMS），应用连接会因 TNS 解析不到对应实例而失败；同时tnsnames.ora中 service 名称也必须同步更新 - 没清理旧主库的监听注册残留 —— 原主库若只是宕机未彻底关机，其监听器可能仍在广播旧实例信息，导致客户端连接混乱；切换完成后应立即在原主库节点上执行
lsnrctl stop并确认ps -ef | grep tnslsnr无残留进程
级联架构（A→B→C）下切换顺序不能错
三节点级联物理备库中，B 是 A 的备库，C 是 B 的备库。一旦 A 故障，不能直接在 C 上 Failover —— 因为 C 只收 B 的日志，B 自身可能还没收全 A 的日志。必须逐级推进：
- 先确认 B 已完成 Failover 成为新主库（即 B 的
database_role为PRIMARY，且v$dataguard_stats中 transport lag 为 0） - 再在 C 上执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;→FINISH;→ACTIVATE; - 切完后立刻检查 C 的
log_archive_dest_2：它必须指向新主库 B 的 service（如service=ecmsdg1），而不是原来的 A；否则下次日志传输会失败 - 特别注意：C 切换后，B 的
fal_server参数仍指向 A，必须手动改为fal_server='ECMSDG2'（即 C 的db_unique_name），否则 B 无法向 C 请求缺失归档
真正难的不是命令怎么敲，而是切换前 5 分钟里你敢不敢根据 v$managed_standby 的 PROCESS 和 STATUS 判断 MRP 是真在跑还是假死，以及切换后第一分钟里你能不能从 v$archive_dest_status.error 里一眼看出是网络不通还是归档路径权限不对。这些细节，文档不会写，但每次演练都暴露得最彻底。
