RMAN-06059报错本质是控制文件与物理归档日志状态不一致，需用CROSSCHECK校验并标记缺失文件为EXPIRED，再执行DELETE EXPIRED清理无效记录，而非直接使用DELETE FORCE或跳过校验。
RMAN-06059报错本质是控制文件和物理文件状态不一致
这不是归档日志“真丢了”，而是 RMAN 控制文件里还记着某个 archivelog 的路径和序列号，但对应文件在磁盘或 ASM 中早已被删掉。RMAN 备份时照着控制文件去读，自然报 ORA-19625 + ORA-27037 —— “找不到文件”。常见诱因包括：手工 rm 归档、DELETE FORCE ARCHIVELOG 脚本执行、ASM 文件被清理、RAC 节点间归档路径未同步、Veeam 插件调用 RMAN 时未及时刷新元数据。
必须用 CROSSCHECK 同步状态，不能只 LIST 或查 v$archived_log
LIST ARCHIVELOG ALL 或 SELECT * FROM v$archived_log 只反映控制文件当前记录，不校验物理存在。真正起作用的是 CROSSCHECK，它会逐个访问归档路径（含 ASM alias），把实际缺失的条目标记为 EXPIRED。
- 执行
CROSSCHECK ARCHIVELOG ALL后，RMAN 会输出类似validation failed for archived log file name=+ARCH/orcl/archivelog/2026_05_16/thread_1_seq_90376 - 若使用恢复目录（catalog），需先
CONNECT CATALOG再执行，否则只校验控制文件 - 在 RAC 环境中，确保所有节点都运行过该命令，尤其注意
+ARCH路径是否跨实例可见 - 不要跳过这步直接
DELETE EXPIRED，否则可能误删仍存在的归档
DELETE EXPIRED 是清理动作，不是备份补救措施
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL 的作用是把控制文件中那些已被标记为 EXPIRED 的记录彻底清除。它不恢复任何数据，也不修复备份链，只是让 RMAN 下次备份时不再尝试读取这些已失效的条目。
- 执行前确认：这些归档确实不需要用于 PITR（时间点恢复）或 DG 日志应用
- 如果归档被误删且无副本，
DELETE EXPIRED后数据库将失去从缺失点之后的完整恢复能力 - Veeam 等第三方工具依赖 RMAN 元数据，必须等
DELETE EXPIRED完成后才可重试备份任务 - 避免使用
DELETE FORCE，它会跳过校验直接删记录，风险更高
归档删除脚本和 RMAN 备份之间必须有协调机制
你看到的 DELETE FORCE ARCHIVELOG UNTIL TIME 'SYSDATE-3' 这类脚本，如果独立于 RMAN 备份调度运行，就是典型冲突源头。RMAN 不知道你删了什么，控制文件仍保留引用。
- 推荐改用 RMAN 内置策略：
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY（如有 DG）或TO BACKED UP 1 TIMES TO DEVICE TYPE DISK - 若必须用外部脚本，应在 RMAN 备份完成后、且
CROSSCHECK+DELETE EXPIRED执行完毕再触发 - 检查
V$ARCHIVED_LOG.DELETED字段，确认归档状态为YES后再清理物理文件 - 对 ASM 存储，注意
asmcmd ls和 RMANLIST结果可能不一致，优先以CROSSCHECK为准
实际出问题时，最易被忽略的是 RAC 多实例下 CROSSCHECK 未在全部节点执行，或 Veeam 调用 RMAN 时未指定正确 target 数据库连接串，导致元数据刷新只发生在单个实例上。
