failover后原主库必须重建为物理备库；能否成功取决于其是否可启动、是否启用闪回或是否有可用rman备份：①启用闪回则用standby_became_primary_scn闪回后执行convert to physical standby；②未启用闪回则用rman不完全恢复至该scn前再转换；③无法启动则需重搭备库；所有路径均须执行convert步骤，否则控制文件仍标识为primary导致日志应用失败。
Failover 后原主库已脱离 DG 架构，不能“切回来”，必须重建为物理备库；能否成功取决于它是否还能启动、有无闪回启用、有无可用 RMAN 备份。
原主库还能启动且开了闪回？用 STANDBY_BECAME_PRIMARY_SCN 闪回
闪回是最快路径，但前提是原主库 FLASHBACK DATABASE 已启用，且 DB_FLASHBACK_RETENTION_TARGET 覆盖了 Failover 时间点。
- 在新主库查关键 SCN：
SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;（例如返回1622177） - 原主库启动到
MOUNT状态后执行：FLASHBACK DATABASE TO SCN 1622177; - 闪回完成后**立刻**执行：
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;——漏掉这步，控制文件仍认为是主库，后续全报错 - 然后：
SHUTDOWN IMMEDIATE; STARTUP MOUNT;，再启用日志应用：RECOVER MANAGED STANDBY DATABASE DISCONNECT;
常见错误：闪回后直接 OPEN，报 ORA-01275；或忘记 CONVERT TO PHYSICAL STANDBY，导致 V$DATABASE.DATABASE_ROLE 仍是 PRIMARY，归档无法传输。
原主库能启动但没开闪回？用 RMAN 不完全恢复
这是最常用路径，但要求 Failover 前有完整 RMAN 备份（含控制文件 + 归档），且备份时间点早于 STANDBY_BECAME_PRIMARY_SCN。
- 在新主库查 SCN：
SELECT STANDBY_BECAME_PRIMARY_SCN FROM V$DATABASE; - 在原主库用 RMAN 执行基于 SCN 的不完全恢复：
RUN {<br> SET UNTIL SCN <standby_became_primary_scn>;<br> RESTORE DATABASE;<br> RECOVER DATABASE;<br>}</standby_became_primary_scn>注意：不是+1，是严格小于该 SCN - 恢复完成后，必须执行：
ALTER DATABASE CONVERT TO PHYSICAL STANDBY; - 再
SHUTDOWN IMMEDIATE; STARTUP MOUNT;，然后启用 MRP：RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
容易踩的坑：SET UNTIL TIME 容易因时区/精度出错，SCN 更可靠；恢复后若跳过 CONVERT 步骤，数据库会拒绝应用日志，报 ORA-16139: media recovery required。
原主库根本起不来？只能重搭物理备库
没有闪回、没有可用 RMAN 备份、或者备份损坏/过期，就只剩一条路：从头搭建物理备库。
- 用
RMAN RESTORE FROM SERVICE是 Oracle MAA 推荐方式，无需拷贝备份集到本地 - 需确保网络连通、TNS 配置正确、
LOG_ARCHIVE_DEST_n参数已重配指向新主库 - 重建后务必验证：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';返回APPLYING_LOG
最关键的遗漏点：所有路径都必须执行 ALTER DATABASE CONVERT TO PHYSICAL STANDBY。只要控制文件里 DATABASE_ROLE 还是 PRIMARY，它就永远无法成为真正的备库——这点在故障排查中常被跳过。
