必须显式执行set archivelog destination指定绝对路径并置于run块内restore前，且恢复后须用catalog注册到控制文件，否则归档虽拷贝成功却无法被recover识别。
不能直接“找回”已删的归档日志，RESTORE ARCHIVELOG 只是从备份片里解压拷贝，路径和注册全靠你手动控制；不设目标路径、不注册进控制文件，恢复后文件就“消失”了。
RESTORE ARCHIVELOG 默认写到哪？为什么恢复后找不到文件
RMAN 不会按备份片存放路径来写归档，它只认当前会话的归档目标规则：
- 没执行
SET ARCHIVELOG DESTINATION TO，就写进LOG_ARCHIVE_DEST_1指向的目录 - 如果
LOG_ARCHIVE_DEST_1指向快速恢复区（db_recovery_file_dest），而该路径权限不对、空间满或根本不存在，就会报ORA-19505: failed to identify file - 即使
LIST BACKUP OF ARCHIVELOG显示备份存在，RESTORE后查不到文件，大概率是它悄悄落到了/u01/app/oracle/fast_recovery_area/ORCL/archivelog/这类默认路径下
必须用 SET ARCHIVELOG DESTINATION TO 指定输出路径
这是唯一可控方式，且有硬性约束：
- 必须放在
RUN块内，且在RESTORE ARCHIVELOG命令之前执行 - 路径必须是绝对路径，不能含
$ORACLE_HOME或其他环境变量 - 目录必须真实存在，Oracle 用户（非 root）要有读写权限
- Windows 下建议统一用正斜杠
/，避免反斜杠转义问题 - 单个
RUN块中可多次SET ARCHIVELOG DESTINATION，实现分段恢复到不同目录
示例：
RMAN> RUN {
SET ARCHIVELOG DESTINATION TO '/u01/arch_restore/';
RESTORE ARCHIVELOG FROM SEQUENCE 100 UNTIL SEQUENCE 105 THREAD 1;
}
恢复后归档还不能被 RECOVER 自动识别
手动恢复出来的归档文件，RMAN 和数据库都“看不见”，必须注册进控制文件：
- 执行
CATALOG ARCHIVELOG '/u01/arch_restore/1_100_770379421.dbf'（单个） - 或批量
CATALOG START WITH '/u01/arch_restore/' - 注册前务必检查文件有效性：用
strings 1_100_*.dbf | head -5，应含ARCHIVELOG或ORACLE字样 - 若注册失败，常见原因是控制文件里已有同名记录，需先
CHANGE ARCHIVELOG 1_100_770379421.dbf UNCATALOG再重试 - RAC 环境下特别注意：注册的归档
THREAD#和RESETLOGS_ID必须与当前库完全一致，否则LIST ARCHIVELOG显示STATUS = D（Deleted），RECOVER不会拉取
绕过还原，直接让 RECOVER 走得通
如果归档确实没了又没备份，硬要恢复到某个时间点，关库做不完全恢复是最后手段；但只要还有归档备份，就别跳过 SET ARCHIVELOG DESTINATION 和 CATALOG 这两步——它们不是可选项，是路径控制和元数据同步的强制环节。漏掉任意一个，RECOVER DATABASE 都会停在 ORA-00279 或静默跳过关键归档。
