RMAN-06059错误主因是控制文件记录了已丢失的归档日志路径，需先crosscheck archivelog all再delete noprompt expired archivelog all清理过期记录，而非权限或磁盘空间问题。
rman 备份 plus archivelog 失败，大概率不是备份逻辑错了，而是控制文件里还记着已丢失的归档日志路径 —— 物理文件早被删了，但 oracle 还以为它们存在。
为什么 backup plus archivelog 突然报 RMAN-06059？
错误典型表现为：RMAN-06059: expected archived log not found + ORA-19625 + OSD-04002（“系统找不到指定的文件”）。这不是权限或磁盘满的问题，而是控制文件（control file）和实际归档目录状态不一致。
常见诱因包括：
- 手动用
rm或 Windows 资源管理器清空过log_archive_dest指向的归档目录 - 第三方备份软件（如 NBU、AnyBackup）异常中断后残留过期记录
- RAC 节点重建、单机化迁移后未清理旧归档元数据
- ASM 磁盘组空间不足导致归档写入失败，但控制文件仍登记了未完成的序列号
crosscheck archivelog all 之后必须跟 delete expired archivelog all
crosscheck 只是“核对”，不会自动清理；它把物理不存在的归档标记为 EXPIRED，但这些记录仍留在控制文件中。若只执行 crosscheck 就跑 backup plus archivelog，RMAN 依然会尝试读取那些 EXPIRED 条目，然后再次报错。
正确顺序是：
- 先运行
crosscheck archivelog all（耗时取决于归档数量，建议在低峰期执行） - 再运行
delete noprompt expired archivelog all（加noprompt避免交互确认） - 验证：
list expired archivelog all应返回空结果
注意：delete expired archivelog 不删磁盘上还存在的归档，只清理控制文件里的“幽灵记录”。它安全，但不可逆 —— 如果你误删了真实归档又没做冷备，这一步会永久降低可恢复性。
手动备份归档日志前，先确保当前归档可读且完整
即使清除了过期记录，也要防一手：检查最新归档是否真能被 RMAN 识别。
- 查最近归档：
select name, first_time, next_time from v$archived_log order by first_time desc fetch first 5 rows only; - 确认
log_archive_dest_1路径下对应文件存在（比如ARC00148_0684537946.001） - 如果发现最新几个归档在
v$archived_log里有记录，但磁盘上缺失，说明归档进程曾中断 —— 此时应先alter system archive log current强制切换，再重试crosscheck
手动备份单个归档段可用：backup archivelog from sequence 148 until sequence 150 format '/backup/arch_%d_%s_%p';，但生产环境不推荐零散操作，优先走 plus archivelog delete input 流程。
备份脚本里加 delete input 的风险与替代方案
backup archivelog all delete input 很方便，但隐患明显：一旦备份中途失败（网络断、磁带满、权限丢），归档就彻底没了，无法重试。
更稳妥的做法分两步：
- 先备份：
backup archivelog all format '/backup/arch_%d_%T_%s_%p'; - 再删（确认备份无误后）：
delete noprompt archivelog all completed before 'sysdate - 1/24';（删 1 小时前已完成的）
尤其在归档量大（每小时 GB 级）、存储不稳定或使用 NFS 共享目录时，跳过 delete input 是防止“备份即删库”的关键缓冲。
真正麻烦的不是命令记不住，而是误判“归档丢失” —— 有时文件明明在，只是权限不对、挂载点失效、或 ASM 别名指向错误路径。执行 crosscheck 前，先用 ls -l 或 asmcmd ls 看一眼目标目录，比直接敲命令省半小时排障时间。
