rman备份还原方式重建原主库最常用，适用于未开启闪回但failover前有完整rman备份的场景，核心是还原+恢复到standby_became_primary_scn前一刻，并执行convert to physical standby后重启至mount状态。
能重建，但必须分清路径：有闪回就用闪回，没闪回就靠RMAN备份还原，没备份就只能重搭。
闪回数据库方式重建原主库（最快）
前提是原主库已开启 FLASHBACK DATABASE，且 DB_FLASHBACK_RETENTION_TARGET 足够覆盖 failover 时间点。关键不是“能不能”，而是“闪回到哪”——必须用新主库上的 STANDBY_BECAME_PRIMARY_SCN。
- 在新主库查 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 备份（含控制文件+归档）的场景。核心是「还原 + 恢复到 SCN 前一刻」，不是恢复到最后一个归档。
- 确认新主库的
STANDBY_BECAME_PRIMARY_SCN（同上） - 在原主库上用 RMAN 执行：
SET UNTIL SCN <scn>; RESTORE DATABASE; RECOVER DATABASE;</scn>—— 注意是+1，否则可能因 SCN 边界问题卡在最后一条 redo - 恢复完成后，必须先
SHUTDOWN IMMEDIATE，再STARTUP MOUNT，否则CONVERT TO PHYSICAL STANDBY会失败 - 执行：
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;后，立即SHUTDOWN IMMEDIATE; STARTUP MOUNT; - 此时可尝试只读打开验证：
ALTER DATABASE OPEN READ ONLY;，成功后再启动 MRP
容易踩的坑：RESTORE 前没 SET UNTIL，导致恢复到最新时间点而与新主库脱节；或 CONVERT 后未重启到 MOUNT 就直接启动 MRP，报 ORA-16139。
重建后必须检查的三件事
无论哪种方式，重建完成不等于同步就通了。以下检查缺一不可：
- 新主库的
LOG_ARCHIVE_DEST_2（或对应备库的 dest_n）是否指向原主库的DB_UNIQUE_NAME，且状态为ENABLE？查：SELECT DEST_ID, DESTINATION, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS; - 原主库（现备库）的
FAL_SERVER是否设为新主库的DB_UNIQUE_NAME？否则 gap 无法自动拉取 - 在原主库上执行：
RECOVER MANAGED STANDBY DATABASE DISCONNECT;后，立刻查V$MANAGED_STANDBY中PROCESS = 'MRP0'的STATUS是否为APPLYING_LOG，而非WAIT_FOR_LOG或ERROR
最关键的细节常被忽略：failover 后新主库很可能已停掉对原主库的归档传输（LOG_ARCHIVE_DEST_STATE_n = DEFER），不手动 ENABLE 就永远等不到第一份归档。
