主库宕机后备库接管需手动执行FINISH+SWITCHOVER，且Failover前必须确认无归档缺口、MRP0已停、备库处于OPEN或MOUNTED状态；操作顺序不可颠倒，否则引发ORA-16139或ORA-19909错误，切后须及时更新归档路径。
主库宕机后，备库必须手动执行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH + ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY 才能接管，Broker 的 FSFO（Fast-Start Failover）不是默认开启的，不配就不起作用。
Failover 前必须确认的三件事
Failover 是破坏性操作，一旦执行，原主库就无法直接加入现有 DG 链路，必须重建或闪回。所以动手前务必确认：
-
v$archive_gap查询结果为空 —— 说明没有归档日志缺失，否则FINISH会报错或丢数据 - 备库
MRP0进程状态是APPLYING_LOG或刚停掉（用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL停） - 备库已
OPEN（Active Data Guard 模式下可读），但角色仍是PHYSICAL STANDBY；若为MOUNTED，需先STARTUP MOUNT
标准 Failover 操作顺序（不能颠倒）
顺序错了轻则报 ORA-16139: media recovery required，重则触发 ORA-19909（orphan incarnation）错误，导致后续无法闪回恢复 DG 环境。
- 停 MRP 应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL - 完成最后一批归档应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH（注意：不是FINISH FORCE，除非明确接受数据丢失） - 切换角色：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY - 打开数据库：
ALTER DATABASE OPEN（此时OPEN_MODE变为READ WRITE）
执行完后立刻查：SELECT database_role, open_mode FROM v$database，确认返回 PRIMARY 和 READ WRITE。
常见失败原因和对应处理
报错不是卡在语法，而是底层状态没对齐。最常踩的坑集中在以下几点：
-
ORA-16139：说明FINISH没成功，可能因为还有未应用的归档 —— 先查v$managed_standby中PROCESS = 'RFS'和'MRP0'的STATUS，再跑一遍FINISH -
ORA-19909：备库之前做过 Failover 但没闪回清理，当前 incarnation 已 orphan —— 必须用FLASHBACK DATABASE TO SCN xxx回到上次 Failover 前的 SCN，再重试 - 切完仍是
MOUNTED：漏了ALTER DATABASE OPEN，或者数据库启用了RESTRICTED SESSION，需加ALTER SYSTEM DISABLE RESTRICTED SESSION
Failover 后原主库怎么处理
原主库不是“修好就能连上”，它当前的 control file 和 datafile SCN 已落后于新主库，强行启动会报 ORA-01122 / ORA-01207。可行路径只有两条：
- 如果备库提前开了闪回且保留时间足够：把原主库
FLASHBACK DATABASE TO SCN yyy，再执行ALTER DATABASE CONVERT TO PHYSICAL STANDBY，最后STARTUP MOUNT+ 启动 MRP - 否则只能用 RMAN 从新主库做增量备份重建 —— 注意：不是全量备份，
BACKUP INCREMENTAL FROM SCN zzz DATABASE能大幅缩短时间
真正容易被忽略的是：Failover 后新主库的 log_archive_dest_n 配置不会自动更新，所有归档仍往旧主库地址发，必须手工改掉，否则后续归档失败，新备库收不到日志。
