归档日志缺失时rman恢复会直接报错退出，必须用不完全恢复绕过断点；最稳妥方式是set until scn（需精准计算可用归档边界），而非until sequence；手动拷贝归档后须catalog注册才生效；recover database noredo仅适用于备库重建场景；_allow_resetlogs_corruption和bbed属高危止损手段，非标准恢复方案。
归档日志缺失时，rman 的 recover database 会直接报错退出，根本走不到“恢复完成”那步——这不是操作顺序错了，而是控制文件里没记录可用归档，或所需 scn 区间存在断点。必须用不完全恢复（incomplete recovery）绕过缺失段，且关键在于精准控制终点。
SET UNTIL SCN 是最稳妥的绕过方式
当已知缺失归档覆盖的 SCN 范围（比如查 V$ARCHIVED_LOG 发现 sequence 11 对应 FIRST_CHANGE# = 10879000000000，而你手头只有 10 和 12），就该跳过这个区间：
- 先在目标库查当前 SCN：
SELECT CURRENT_SCN FROM V$DATABASE; - 再查已有归档的边界：
SELECT MIN(FIRST_CHANGE#), MAX(NEXT_CHANGE#) FROM V$ARCHIVED_LOG WHERE SEQUENCE# IN (10,12); - 选一个明确落在已有归档 NEXT_CHANGE# 之后、缺失归档 FIRST_CHANGE# 之前的 SCN，例如
10879000000050 - RMAN 中执行：
SET UNTIL SCN 10879000000050，再RECOVER DATABASE
用 SCN 而不用 SEQUENCE，是因为后者强制要求“该序号及之前所有归档必须存在”，哪怕 12、13 都在，只要 11 缺失，SET UNTIL SEQUENCE 12 就会失败。
CATALOG ARCHIVELOG 才能让手动拷贝的归档生效
把备份里的 1_11_770379421.dbf 直接 cp 到 DB_RECOVERY_FILE_DEST 目录下，LIST ARCHIVELOG ALL 依然看不到它——Oracle 不扫描目录自动注册。
- 必须先解压/还原到临时路径，如
/tmp/arch_restored/ - RMAN 连接后执行：
CATALOG START WITH '/tmp/arch_restored/'; - 注册后检查：
LIST ARCHIVELOG FROM SEQUENCE 11;，确认状态为A（Available） - 若提示 “already cataloged”，说明控制文件中已有同名归档记录（时间戳是 2026年5月3日），需先
CHANGE ARCHIVELOG ... UNCATALOG;再重试
recover database noredo 只适用于备库重建场景
这是 DataGuard 备库修复中的关键步骤，但仅限于“控制文件已还原、数据文件来自主库增量备份”的情况：
- 执行前必须
ALTER DATABASE MOUNT，不能OPEN -
noredo表示跳过归档应用，只做块级一致性修复，依赖的是备份时刻的 SCN 与当前控制文件匹配 - 常见误用：在主库或未重建控制文件的备库上执行，会导致
ORA-00344或控制文件校验失败 - 成功后必须立刻
ALTER DATABASE OPEN RESETLOGS，否则无法启动 MRP 进程
_ALLOW_RESETLOGS_CORRUPTION 是最后手段，不是恢复方案
设 "_ALLOW_RESETLOGS_CORRUPTION"=TRUE 后 OPEN RESETLOGS，本质是跳过所有介质恢复检查，数据库能起来，但对应数据文件可能处于“逻辑损坏”状态：
- 后续任何 DML 操作都可能触发
ORA-01578坏块错误 该参数必须在 SPFILE 中动态设置并重启才生效，且打开后立即 - BBED 修改数据文件头 SCN 更危险：一旦推进值超过其他文件的 checkpoint，实例启动时就会因 SCN 不一致直接崩溃
- 真正该做的，是立刻导出还能访问的对象，然后重建库——这不是恢复，是止损
RESET，不可保留归档缺失本身不可逆，所谓“恢复”只是选择一个可接受的数据截止点；所有绕过手段都在扩大风险敞口，越晚确认缺失范围，越容易踩进跨 RESETLOGS_ID 或 THREAD# 错配的坑。
