直接拷贝归档日志到db_recovery_file_dest无效，因oracle不自动扫描目录注册文件；必须执行catalog archivelog显式注册，且注册前需用strings验证文件有效性，否则控制文件无法识别，recover仍报错。
直接把归档日志文件拷贝回 db_recovery_file_dest 目录没用——oracle 不会自动发现，recover 依然报错找不到日志。
为什么 cp 归档日志到恢复区无效
Oracle 控制文件不扫描归档目录做自动识别；LIST ARCHIVELOG ALL 查不到，RECOVER DATABASE 就不会用它。哪怕你把 1_11_770379421.dbf 放进 /u01/app/oracle/fast_recovery_area/ORCL/archivelog/，它在控制文件里仍是“不存在”状态。
必须让控制文件知道这个文件存在、有效、可用，唯一方式是显式注册。
-
CATALOG ARCHIVELOG '/path/to/1_11_770379421.dbf'才是正解 - 注册前先用
strings 1_11_770379421.dbf | head -5确认含ARCHIVELOG或ORACLE字样，排除损坏或伪造文件 - 若控制文件已有同名归档记录（比如时间戳是 2026-05-03），
CATALOG会报错，需先确认是否真需要该文件
批量注册从备库或备份介质拉来的归档
你解压了 tar 包或从备库 scp 过来一堆归档，别一个个 CATALOG，效率低还易漏。
- 先确保所有归档放在一个干净临时目录，例如
/tmp/arch_restored/ - RMAN 中执行：
CATALOG START WITH '/tmp/arch_restored/';（递归扫描所有有效归档） - 验证是否注册成功：
LIST ARCHIVELOG FROM SEQUENCE 10;，确认STATUS = A且目标SEQUENCE#出现在列表中 - 如果归档分散在多个路径，可多次执行
CATALOG START WITH，RMAN 会跳过已注册项
归档确实找不回来了，怎么绕过缺失段继续恢复
不是所有归档都能找回。当确认缺失不可逆时，UNTIL 策略选错，轻则恢复失败，重则应用错误日志导致数据不一致。
-
SET UNTIL SCN最可靠：查V$ARCHIVED_LOG.FIRST_CHANGE#和V$DATABASE.CURRENT_SCN，挑一个明确落在“已有归档覆盖区间内”的 SCN -
SET UNTIL SEQUENCE 11会失败：它强制要求SEQUENCE# ≤ 11的所有归档都存在，哪怕 12、13 都在也不行 -
SET UNTIL TIME必须核对时区：SELECT DBTIMEZONE, SESSIONTIMEZONE FROM DUAL;，否则指定时间可能跨入缺失区间
异机恢复时归档路径不一致怎么办
源库归档在 /u01/app/oracle/archivelog，目标机没这个路径，RECOVER DATABASE 会直接报 ORA-00308: cannot open archived log '/u01/app/oracle/archivelog/1_12345_1234567890.arc'。
- 最稳妥做法：恢复前，在目标机建好对应目录结构，哪怕只是软链接：
mkdir -p /u01/app/oracle/archivelog - 或者改目标库参数匹配源路径：
ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/app/oracle/archivelog' SCOPE=SPFILE;，再重启 - 切勿依赖不存在的
SET ARCHIVELOG DEST命令，RMAN 根本不处理路径重定向逻辑
归档路径和注册动作是恢复链里最容易被跳过的两个环节，漏掉任何一个，RECOVER 都会卡在第一步。
