rman list archivelog all显示不全，因其仅查询控制文件中已注册的归档记录，不扫描磁盘文件；需执行catalog命令（如catalog start with）将磁盘上未注册的归档日志显式纳入控制文件，否则即使文件存在rman也视为不可用。
归档不连续不是备份集缺文件，而是控制文件没“认出”它们——必须先让rman看到磁盘上的归档片，再让它告诉控制文件该用哪些。
为什么RMAN LIST ARCHIVELOG ALL 显示不全
RMAN 的 LIST ARCHIVELOG ALL 只查控制文件里已注册的归档记录，不扫描磁盘。即使你把一堆 .arc 文件拷到 /arch/ 下，只要没执行 CATALOG，RMAN 就当它们不存在。常见现象是：目录里有 1_100_123456789.arc 到 1_105_123456789.arc，但 LIST 只显示到 102，后续就断了。
- 控制文件可能来自旧备份，压根不知道新归档的存在
- 归档路径变更后没执行
CATALOG START WITH - 归档文件是
.gz压缩格式，RMAN 默认跳过（必须先gunzip）
RMAN中从备份集中提取并注册缺失归档
如果缺失的归档只存在于 RMAN 备份集中（比如 BACKUP ARCHIVELOG ALL 的备份片），不能直接 restore 到归档目录再 catalog —— 那样会破坏备份集一致性。正确做法是用 RESTORE ARCHIVELOG 直接解包还原：
- 先确认备份集中有哪些归档：
LIST BACKUP OF ARCHIVELOG ALL，找出包含序列号 103–105 的备份片（如1234567890.bak） - 指定范围还原：
RESTORE ARCHIVELOG FROM SEQUENCE 103 UNTIL SEQUENCE 105; - 还原后立即 catalog：
CATALOG START WITH '/u01/app/oracle/fast_recovery_area/...';（路径填实际还原目标） - 验证是否注册成功：
SELECT SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG WHERE SEQUENCE# BETWEEN 103 AND 105;
恢复时遇到 ORA-00329 或 ORA-00310 怎么办
这两个错误本质都是 SCN 或序列号对不上，说明控制文件期望的下一个日志，和你提供的不匹配。别急着重做整个恢复，先定位断点：
- 查当前数据文件检查点：
SELECT FILE#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME FROM V$DATAFILE_HEADER;找出最低的CHECKPOINT_CHANGE# - 查控制文件认为该应用的日志：
SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$RECOVERY_LOG ORDER BY SEQUENCE#; - 如果
FIRST_CHANGE#> 最低检查点，说明中间缺日志；如果SEQUENCE#跳号（比如 102 后直接 105），就是物理断层 - 此时必须补全缺失序列——哪怕只是空占位，也不能跳。RMAN 不接受“跳过 103–104，直接 recover 105”
最容易被忽略的 mount 状态与 fuzzy=YES
所有恢复操作前，数据库必须处于 MOUNTED 状态。如果 SELECT STATUS FROM V$INSTANCE 返回 OPEN，RECOVER 会静默失败或报奇怪错误。更隐蔽的是：V$DATAFILE_HEADER.fuzzy = 'YES' 表示文件需要恢复，但 V$RECOVER_FILE 为空——这说明控制文件里根本没记 recovery 需求，大概率是用了旧控制文件且没重建恢复信息。此时必须先 STARTUP MOUNT，再 RECOVER DATABASE USING BACKUP CONTROLFILE，否则 Oracle 连该从哪开始都不知道。
