rman-06059 错误本质是控制文件记录的归档日志路径与磁盘实际状态不一致，需先执行 crosscheck archivelog all 将缺失文件标记为 expired，再运行 delete noprompt expired archivelog all 从控制文件中清除无效记录，否则备份持续失败；该操作仅更新元数据，不触碰磁盘文件。
RMAN-06059 错误本质是控制文件与磁盘状态不一致
RMAN-06059 不是备份脚本写错了，也不是权限问题，而是 RMAN 从控制文件里读到某条归档日志记录（比如 /u04/backup/archive/arch_1_40337_867612567.dbf），但该路径下文件实际已不存在。常见于：手工 rm 归档、迁移后没同步归档目录、磁盘空间清理、RAC 节点归档未统一挂载。控制文件没被告知“这文件没了”，所以每次 backup plus archivelog 都会尝试访问它，触发 ORA-19625 + ORA-27037。
必须执行 crosscheck archivelog all 同步状态
crosscheck archivelog all 是唯一能主动让 RMAN 去磁盘上逐个验证归档日志真实存在性的命令。它不会删除任何东西，只做两件事：对存在的归档日志标记为 AVAILABLE；对缺失的归档日志标记为 EXPIRED。注意：change archivelog all crosscheck 和 crosscheck archivelog all 功能等价，后者更常用。
- 执行前确保归档目录可读（
ls -l看一眼路径是否存在、权限是否 OK） - 如果归档分散在多个路径（如
LOG_ARCHIVE_DEST_1和LOG_ARCHIVE_DEST_2），crosscheck会自动检查所有已配置的归档目标 - 输出里出现
validation failed for archived log就说明该文件已丢失，后续会被标记为EXPIRED
delete expired archivelog all 清除过期记录
仅执行 crosscheck 不够——RMAN 仍知道那些 EXPIRED 条目存在，下次备份还会报 RMAN-06059。必须紧接着运行 delete noprompt expired archivelog all，才能从控制文件中彻底移除这些无效引用。
-
noprompt参数避免交互确认，适合脚本化处理 - 该操作不碰磁盘文件（因为文件本来就没啦），只更新控制文件中的归档日志元数据
- 如果用了恢复目录（recovery catalog），需先
connect catalog再执行，否则只更新控制文件 - 执行后可用
list expired archivelog all验证是否清空
备份前务必确认归档日志链完整
RMAN-06059 解决后能跑通备份，但不代表恢复安全。如果缺失的是中间序列号的归档（比如有 1、2、4、5，缺 3），数据库就无法完整前滚恢复到故障点之后。此时：
- 查
v$archived_log中STATUS列，X表示 expired，A表示可用，重点关注SEQUENCE#是否连续 - 用
list archivelog all查看当前控制文件里还剩哪些归档，比对ARCHIVE LOG LIST输出的当前日志序列 - 若关键归档永久丢失，
backup database plus archivelog仍能完成，但必须意识到：这部分时间点的 PITR（基于时间点的恢复）已不可行
