ora-27037根本原因是控制文件记录与物理归档日志脱节，必须先执行crosscheck archivelog all标记过期文件，再执行delete expired archivelog all清理控制文件幽灵记录，二者缺一不可。
ORA-27037 本身不是 RMAN 的错误，而是 Oracle 底层 I/O 层抛出的系统级错误（Linux-x86_64 Error: 2: No such file or directory），它在 RMAN 场景中高频出现，根本原因几乎总是：**控制文件里还记着某个归档日志或备份片的路径，但物理文件早已不存在了**。直接重试备份没用，必须先让控制文件“认清现实”。
为什么 crosscheck archivelog all 是第一步
控制文件是 RMAN 在 nocatalog 模式下的唯一元数据源。手工删过归档、迁移过归档目录、或从冷备恢复后没同步归档状态，都会导致控制文件记录与磁盘实际文件脱节。RMAN 执行 backup archivelog all 时，会按控制文件里列出的每一个归档日志路径去尝试打开——哪怕那个 1_250_1182528399.dbf 文件早就被 rm -f 掉了，它仍会报 ORA-27037。
crosscheck archivelog all 的作用就是挨个检查这些路径：文件存在 → 标为 available；文件不存在 → 标为 expired。这步不删任何东西，只是刷新状态标记。
- 必须在
connect target /后执行，不能连 catalog（除非你明确用了 catalog） - 耗时取决于归档数量，但不会触发 I/O 写操作，相对安全
- 如果归档分散在多个目录，确保
log_archive_dest_n配置正确，否则 crosscheck 可能漏掉部分路径
delete expired archivelog all 不能省略
只做 crosscheck 不够。RMAN 备份命令（尤其是 backup archivelog all）默认只处理 available 状态的日志。那些被标为 expired 的条目，依然躺在控制文件里，下次 backup 还会尝试访问——于是继续报 ORA-27037。
delete expired archivelog all 才真正把控制文件里这些“幽灵记录”清理掉，并同步更新控制文件内容。
- 该命令不碰磁盘（因为文件本就没了），只改控制文件
- 执行前建议先
list expired archivelog all看一眼有哪些将被清理 - 如果使用 FRA（Fast Recovery Area），且
db_recovery_file_dest_size不足，也可能触发类似报错，此时需先清理空间或调大配额
backup archivelog all 前要确认归档路径可写
即使跨检查和清理都做完，backup archivelog all 仍可能因权限或挂载问题失败。常见干扰点：
- 归档目标目录（如
/u04/backup/archive/）属主不是oracle用户，或缺少写权限 - 归档路径挂载在 NFS 或 S3FS 上，但连接中断或认证过期（尤其报错里带
S3字样时） - 归档路径磁盘满，
df -h看Use%是否 100% - RMAN 配置了
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY，但 standby 没应用完，导致主库不敢删归档，堆积后出问题
最易被忽略的是：crosscheck 和 delete 命令必须成对执行，缺一不可。很多人只跑 crosscheck 就去 backup，结果报错照旧——因为控制文件里那些 expired 条目还在，RMAN 仍会试图打开它们。
