直接拷贝归档日志到恢复区无效，因为Oracle不自动扫描目录，必须用CATALOG命令显式注册并校验文件头，使控制文件识别该归档，否则LIST ARCHIVELOG查不到、RECOVER也无法使用。
不能靠 cp 或 mv 把文件“放回去”就完事——控制文件根本看不见它，RECOVER 也不会用。
为什么直接拷贝归档日志到恢复区无效
Oracle 不扫描归档目录做自动发现。哪怕你把 1_11_770379421.dbf 手动放进 /u01/app/oracle/fast_recovery_area/ORCL/archivelog/，LIST ARCHIVELOG ALL 仍查不到，RECOVER DATABASE 也绝不会拉取它。原因很简单：控制文件里没这条记录。
- 归档日志必须被控制文件“注册”（
CATALOG）后才真正可用 - 注册前务必校验文件有效性：
strings 1_11_770379421.dbf | head -5应含ARCHIVELOG或ORACLE字样 - 若同名归档已存在（比如时间戳是 2026-05-03），
CATALOG会报错，需先确认是否真要覆盖
如何用 CATALOG 批量注册解压后的归档文件
这是最常用、最可靠的恢复路径：从备份介质（tar / 磁带 / 备库目录）解压归档 → 注册 → 验证。
- 先解压到临时路径，例如：
tar -xvf arch_bkup_20260309.tar -C /tmp/arch_restored/ - 启动 RMAN 连接目标库：
RMAN TARGET /（确保有SYSDBA权限） - 执行批量注册：
CATALOG START WITH '/tmp/arch_restored/';（递归扫描所有有效归档） - 验证是否成功：
LIST ARCHIVELOG FROM SEQUENCE 10;，确认STATUS = A且SEQUENCE# = 11在列表中
RESTORE ARCHIVELOG 的适用场景与关键限制
RESTORE ARCHIVELOG 不是“找文件复制”，而是“从备份片里抽出来写到指定位置”。它只在你明确需要把归档放到非默认路径（比如备库同步、离线分析）时才用。
- 默认写入
LOG_ARCHIVE_DEST_1或db_recovery_file_dest，跟备份片物理位置无关 - 必须显式用
SET ARCHIVELOG DESTINATION TO '/path/to/dir'指定输出路径，且该路径必须真实存在、Oracle 用户有写权限 -
SET ARCHIVELOG DESTINATION必须放在RUN块内、RESTORE命令之前；不能用$ORACLE_HOME等变量，必须写绝对路径 - 示例：
RMAN> RUN { SET ARCHIVELOG DESTINATION TO '/u01/arch_restore/'; RESTORE ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 105 THREAD 1; }
归档确实不可恢复时，如何绕过缺失段继续恢复
如果 CATALOG 后仍缺关键归档（如 SEQUENCE# = 11），又必须推进恢复，就得用 UNTIL 控制终点——但选错方式会失败或应用错误日志。
-
SET UNTIL SEQUENCE 11会失败：它强制要求 ≤11 的所有归档都存在 -
SET UNTIL SCN最可靠：查V$ARCHIVED_LOG.FIRST_CHANGE#和V$DATABASE.CURRENT_SCN，挑一个明确落在“已有归档覆盖区间内”的 SCN -
SET UNTIL TIME要核对时区：SELECT DBTIMEZONE, SESSIONTIMEZONE FROM DUAL;，否则可能跨入缺失区间
最容易被忽略的一点：注册归档前不校验文件头，可能把损坏或伪造的文件误注册进去；注册后不查 LIST ARCHIVELOG 确认 STATUS = A，就直接跑 RECOVER，结果卡在 ORA-00308 里干等。
