必须在新主库上查询STANDBY_BECAME_PRIMARY_SCN值作为锚点，RMAN中SET UNTIL SCN需加+1且仅能在原主库执行；CONVERT TO PHYSICAL STANDBY前须MOUNT并关闭闪回；OPEN READ ONLY后须按告警日志建议配置SRL。
确认新主库的STANDBY_BECAME_PRIMARY_SCN值
故障转移（failover）完成后，原备库已升为主库，原主库处于“失效待恢复”状态。此时不能直接用旧备份全量还原——必须对齐SCN，否则RMAN恢复会报ORA-01152或ORA-01547。关键动作是在**新主库**上查出切换发生的精确SCN：
SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
这个值是整个重建流程的锚点。注意：不是用CURRENT_SCN，也不是用DBA_LOGSTDBY_PROGRESS，更不能靠猜测归档日志序列号来估算。如果该字段返回NULL，说明failover未真正完成（比如只执行了ALTER DATABASE ACTIVATE STANDBY DATABASE但没清理角色），需先在新主库执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN再重查。
RMAN中SET UNTIL SCN必须加+1且不能跨库执行
很多重建失败源于RMAN脚本里SET UNTIL SCN写错。正确写法是：SET UNTIL SCN <standby_became_primary_scn> + 1。不加+1会导致恢复停在切换前最后一个归档日志的结尾，漏掉切换瞬间生成的那部分在线日志（即“激活时的final redo”），导致控制文件与数据文件SCN不一致。
这个RMAN命令**必须在原主库（待重建库）上执行**，不能连到新主库去跑。因为RMAN需要读取本地控制文件和备份集元数据，而原主库控制文件里仍保留着旧角色信息，这是后续CONVERT TO PHYSICAL STANDBY能成功的基础。若误在新主库上执行，RMAN会找不到对应备份集或报ORA-19571。
ALTER DATABASE CONVERT TO PHYSICAL STANDBY前必须MOUNT且禁用闪回
执行ALTER DATABASE CONVERT TO PHYSICAL STANDBY前，数据库必须处于MOUNT状态，且不能启用闪回（Flashback Database）。否则会报ORA-38760：“This database has not been enabled for flashback database”。这不是警告，是硬性阻止。
检查并关闭闪回的步骤是：
-
SELECT FLASHBACK_ON FROM V$DATABASE;—— 若返回YES，需先ALTER DATABASE FLASHBACK OFF; SHUTDOWN IMMEDIATE;STARTUP MOUNT;- 再执行
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
这个顺序不能颠倒。有些文档说“可跳过闪回检查”，实际在19c及以后版本中，只要闪回区（DB_RECOVERY_FILE_DEST）非空且闪回开启，CONVERT就必然失败。
OPEN READ ONLY后必须检查告警日志里的SRL建议
执行ALTER DATABASE OPEN READ ONLY后，Oracle会校验控制文件与数据字典的一致性，并在告警日志（alert.log）末尾输出类似这样的提示：
WARNING: Standby Redo Logs not configured. Consider adding them.
这不是可忽略的日志，而是强制要求项。没有Standby Redo Logs（SRL），MRP进程无法应用实时日志，后续RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE会立即报ORA-01274：“cannot add file that was originally created as…”。必须按告警日志建议的路径、大小、组数，用ALTER DATABASE ADD STANDBY LOGFILE补全SRL——哪怕只是临时建一组最小配置（如3组×200MB），也比留空强。
容易被忽略的是：SRL路径必须与新主库的LOG_ARCHIVE_DEST_n中定义的VALID_FOR匹配，否则即使建了SRL，MRP也会拒绝使用。
