必须先 crosscheck 再 delete，因为 RMAN 的 delete 依赖控制文件元数据，若文件已被外部删除但控制文件仍标记为 AVAILABLE，直接 delete 会失败或跳过；crosscheck 将丢失文件标为 EXPIRED，后续 delete expired 才能清理脏记录。
为什么必须先 crosscheck 再 delete
rman 的 delete archivelog 不是简单删文件，它依赖控制文件里记录的归档日志元数据。如果磁盘上文件已被外部操作（如手动 rm、脚本误删、fra 自动清理）移除，但 rman 资料库仍标记为 available，直接 delete 会失败或跳过——因为 rman 找不到对应物理文件来“删除”。
所以 crosscheck archivelog all 是必走一步：它强制比对控制文件记录和实际文件存在性，把已丢失的条目标记为 expired，后续 delete expired archivelog all 才能安全清理“脏记录”。
常见错误现象：rman-06207: warning: 1 objects could not be deleted 或 rman-08137: warning: archived log not deleted，基本都是跳过了这步。
清理归档日志的三种可靠时间条件写法
生产环境推荐用基于时间的清理，避免误删未应用的归档（尤其在 Data Guard 环境）。注意 sysdate 是数据库服务器时间，需与系统时区一致：
-
delete archivelog all completed before 'sysdate-7'：删除**7天前已完成归档**的所有日志（最常用，保留最近一周恢复能力） -
delete archivelog from time 'sysdate-3'：删除**3天前到当前时刻之间生成的归档**（注意：不是“3天前之前”，容易误判） -
delete archivelog until time 'sysdate-14'：删除**所有早于14天前完成归档的日志**（等价于before，语义更明确）
关键区别：completed before 看的是 v$archived_log.completion_time；from time 和 until time 看的是 first_time 和 next_time，涉及日志序列连续性判断，慎用于主备不一致场景。
自动清理不能只靠 RMAN 脚本，还要配 FRA 空间策略
RMAN 定时任务（如 cron 调用 rman target / @clean_arch.rman）只是执行动作，真正防爆盘靠的是底层空间治理：
- 确认 FRA 已启用：
show parameter db_recovery_file_dest非空，且db_recovery_file_dest_size设了合理上限（如 50G～200G，依业务量定） - FRA 自动清理触发条件：当使用率超
80%（默认阈值），Oracle 会自动删除**过期且无备份依赖的归档日志**——但这依赖 RMAN 中已配置CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY（如有备库）或TO BACKED UP 1 TIMES TO DISK - 切勿只设大
db_recovery_file_dest_size却不配删除策略，否则 FRA 满了会卡住归档，导致ORA-19809和数据库挂起
定时任务中必须加 noprompt force，但别滥用
在无人值守的定时脚本里，delete 命令必须带 noprompt（跳过确认）和 force（强制删除即使被标记为不可删除的归档，比如正在被备用库读取但状态未同步）：
rman target / <p>但 <code>force</code> 有风险：若备库还没应用某归档，<code>force</code> 可能提前删掉，导致备库中断恢复。所以仅在单机库或确认备库延迟 delete noprompt archivelog all completed before 'sysdate-7' backed up 1 times to disk，确保至少有一份备份在磁盘上。</p><p>最容易被忽略的是：RMAN 脚本执行用户必须是 <code>oracle</code>，且 <code>ORACLE_SID</code> 和 <code>ORACLE_HOME</code> 环境变量已在 cron 中显式设置，否则 <code>rman target /</code> 会连不上实例。</p>
