必须重建原主库而非尝试恢复，当任一检查成立：v$archive_gap显示多归档缺失且主库无对应归档；standby_became_primary_scn与原主库current_scn相差数万；mount状态下recover报ora-16766/ora-01152；或控制文件checkpoint_change#远小于现主库最小归档first_change#。
原主库在 failover 后无法直接拉起为备库，必须重建——哪怕它物理上没坏，只要角色、控制文件、scn 和归档断点不匹配，就只能走 rman 恢复 + 角色转换流程。
怎么确认必须重建而不是尝试恢复？
执行以下检查，任一成立就必须重建：
-
V$ARCHIVE_GAP显示缺失连续多个归档（比如HIGH_SEQUENCE# - LOW_SEQUENCE# > 5），且主库上SELECT NAME FROM V$ARCHIVED_LOG WHERE SEQUENCE# BETWEEN ...查不到对应归档 - 备库（现主库）上执行
SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE得到 SCN（如1105672），而原主库当前CURRENT_SCN远低于该值（差几万以上） - 原主库启动到 MOUNT 后，
RECOVER DATABASE直接报ORA-16766或ORA-01152（“文件未从完备备份恢复”） - 原主库控制文件是旧的，
SELECT CHECKPOINT_CHANGE# FROM V$DATAFILE_HEADER返回值远小于现主库最小归档的FIRST_CHANGE#
RMAN 恢复时为什么必须用 STANDBY_BECAME_PRIMARY_SCN+1？
这个 SCN 是备库正式升主的精确时间点，所有在此之后产生的 redo 都属于新主库。RMAN SET UNTIL SCN 必须设为 STANDBY_BECAME_PRIMARY_SCN + 1，否则会多恢复一个日志，导致控制文件和数据文件头不一致，后续 ALTER DATABASE CONVERT TO PHYSICAL STANDBY 失败。
实操要点：
- 在新主库上查出 SCN：
SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE - 在原主库上用 RMAN 执行：
RMAN> RUN {<br> SET UNTIL SCN 1105673;<br> RESTORE DATABASE;<br> RECOVER DATABASE;<br>} - 不要加
DELETE ARCHIVELOG—— 归档日志要留给后续 MRP 进程拉取 - 恢复完成后，数据库必须保持在 MOUNT 状态，不能 OPEN
CONVERT TO PHYSICAL STANDBY 为什么容易失败？
常见失败原因不是语法错，而是环境没清理干净：
- 原主库残留的
spfile或pfile里还带着旧的LOG_ARCHIVE_DEST_n指向已失效的旧备库地址，必须先修改或重建 pfile - 密码文件（
orapw<sid></sid>）没同步到新主库——MRP 启动时会因认证失败卡住，错误日志里出现ORA-16191 - 没关闭
FORCE LOGGING：新主库必须已执行ALTER DATABASE FORCE LOGGING，否则部分 DML 不写 redo，新备库永远不同步 -
DB_UNIQUE_NAME不匹配：原主库的DB_UNIQUE_NAME必须和新主库LOG_ARCHIVE_CONFIG中列出的一致，否则 FAL 连接失败
重建后 MRP 不启动或报 ORA-00308 怎么办？
这不是配置问题，是归档路径或网络连通性问题：
- 检查新主库
V$ARCHIVE_DEST_STATUS，确认目标地址（DESTINATION）可访问，STATUS = VALID，ERROR列为空 - 从新备库服务器手动
tnsping新主库服务名，再lsnrctl status确认监听器注册了对应 service - 新主库归档路径必须对新备库可见（NFS 共享 / scp 传输 / 或统一挂载 ASM），不能只写本地路径
- 启动 MRP 前，先手工拷贝一份最新归档到备库
log_archive_dest_1路径下，再运行：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
整个过程最耗时的环节不是 RMAN 恢复，而是验证归档链路是否真正打通——哪怕只漏一个参数或少一次 tnsping，MRP 就会在后台静默失败，日志里只显示 “waiting for archive log”。
