Failover是主库彻底不可用时唯一快速恢复业务的手段，操作不可逆且有数据丢失风险；须先确认主库无法mount、存在ORA-00205等致命错误，再在备库执行CANCEL和FINISH终止日志应用，最后通过COMMIT TO SWITCHOVER TO PRIMARY并OPEN完成切换，之后必须更新归档配置、连接串并重建DG关系。
主库彻底不可用时，Failover 是唯一能快速恢复业务的手段，但操作不可逆、有数据丢失风险，必须严格按顺序执行。
确认主库已完全不可访问，不能 mount
Failover 前必须排除“主库还能抢救”的可能。常见误判包括：
- 仅 SQL*Plus 连不上 —— 可能只是监听或实例未注册，
ps -ef | grep pmon仍能看到进程 - 主库能
startup nomount—— 这说明控制文件完好，应优先尝试startup mount+ALTER SYSTEM FLUSH REDO TO 'standby_db_unique_name' - 主库挂载后报 ORA-01157/ORA-01110 —— 很可能是数据文件损坏，此时仍可尝试从归档恢复，不建议直接 Failover
真正满足 Failover 前提的典型现象是：startup mount 报 ORA-00205（无法识别控制文件）、lgwr 进程被 kill -9 后无法重启、或服务器宕机且无备份控制文件可用。
备库上停止 Redo Apply 并强制完成已接收日志应用
这一步决定数据丢失量。顺序不能颠倒：
- 先执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;—— 否则FINISH会卡住 - 再执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;—— 它会自动应用所有已接收但未应用的归档和 standby redo 日志 - 如果
FINISH报错（如 ORA-16037：日志未按顺序），说明存在 GAP，必须先查V$ARCHIVE_GAP并手工注册缺失日志，否则无法继续
注意：FINISH 成功后，V$DATABASE.SWITCHOVER_STATUS 会变为 TO PRIMARY，这是执行下一步的安全信号。
执行激活并打开新主库
两步必须连续执行，中间不能 shutdown：
-
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;—— 这不是普通 switchover，而是 Failover 的关键语句；它会重写控制文件，清除 DG 配置痕迹 -
ALTER DATABASE OPEN;—— 不能用startup，否则会报 ORA-01589（必须使用 RESETLOGS 或 NORESETLOGS）
执行后立即检查：SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE; 应返回 PRIMARY 和 READ WRITE。此时原主库若恢复，将无法自动加入 DG 配置，必须重建为新主库的物理备库。
Failover 后最易忽略的三个点
很多团队在数据库跑起来后就认为结束了，但以下问题会在几小时内暴露：
- 新主库的
LOG_ARCHIVE_DEST_2仍指向原主库地址 —— 必须立刻ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='' SCOPE=BOTH;，否则归档会持续失败并填满DB_RECOVERY_FILE_DEST - 应用连接串未切换到新主库 VIP —— 尤其 RAC 环境下，旧连接池可能还在往原主库节点发请求，导致大量 ORA-03113
- 未检查
V$DATAGUARD_STATS中的transport lag和apply lag—— 它们此时已失效，但监控脚本若未适配，会持续报警“同步延迟”
Failover 不是终点，而是重建 DG 关系的起点；原主库上线后，必须用闪回或 RMAN 从新主库重建，不能直接启动加入。
