RMAN本身不自动删除归档日志，所谓“自动清理”实为通过cron或Windows任务计划定期调用RMAN命令（如DELETE ARCHIVELOG）实现；需先执行CROSSCHECK校验状态，再删除过期及指定时间前的日志，否则因路径、权限或状态不一致导致失效。
rman 本身不自动删除归档日志——它只在你明确执行 delete archivelog 或 backup ... delete input 时，才按策略判断能否删。所谓“自动清理”，其实是靠外部调度（如 cron 或 windows 任务计划）定期触发 rman 命令实现的。
DELETE ARCHIVELOG 不生效的常见原因
执行 DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' 却没删文件，通常不是语法错，而是状态不一致或权限/路径问题：
-
CROSSCHECK ARCHIVELOG ALL没先做：RMAN 仓库里记录的归档状态可能已过期，物理文件还在磁盘上，但 RMAN 不知道它们还存在；不校验就删，会跳过实际存在的归档 - 归档路径不在
DB_RECOVERY_FILE_DEST或 RMAN 控制文件识别范围内：比如归档被手动挪到其他目录，LIST ARCHIVELOG ALL根本查不到，自然删不了 - 使用了
DELETE ARCHIVELOG UNTIL SEQUENCE但序列号不连续：中间有缺失或已被删，RMAN 会静默跳过，不报错也不删 - 当前用户没有 OS 层面对归档目录的写权限：RMAN 能连库，但删文件时被系统拒绝，错误可能只记在日志里，终端无提示
configure archivelog deletion policy 的真实作用范围
这个配置不是“让 RMAN 定时删”，而是给 DELETE INPUT 和显式 DELETE ARCHIVELOG 加一道守门检查：
- 仅对 RMAN 内部命令生效，
rm -rf、find ... -delete完全绕过它 - 配置
TO APPLIED ON STANDBY后，DELETE ARCHIVELOG仍能成功——它只拦DELETE INPUT和跨库依赖场景，不拦时间条件删除 - 若底层隐含参数未开：
ALTER SYSTEM SET "_log_deletion_policy" = ALL SCOPE=SPFILE SID='*';，则该策略始终不生效，且不会报错，只会静默失效 - 在
MAXIMUM PROTECTION模式下配它，反而可能因 MRP 暂停导致误拦删除，没必要
真正可靠的自动清理怎么做
别依赖“配置完就自动运行”，必须用脚本+调度器组合落地：
- 脚本里固定包含三步：先
CROSSCHECK ARCHIVELOG ALL，再DELETE NOPROMPT EXPIRED ARCHIVELOG ALL，最后DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' - Linux 下用
cron，例如每天凌晨执行：0 2 * * * /home/oracle/bin/clean_arch.sh > /home/oracle/log/clean_arch_$(date +\%F).log 2>&1 - Windows 下 bat 文件要调用
rman target / cmdfile=...，不能直接写 RMAN 命令；log 路径需用绝对路径，避免计划任务上下文找不到工作目录 - 每次脚本执行后，检查日志里是否有
deleted archive log行数，以及是否出现RMAN-08137（说明备库还没应用）或RMAN-08591（说明隐含参数没生效）
最常被忽略的一点：RMAN 的“删除”动作依赖于它对归档文件位置和状态的准确认知。物理文件被手动移动、重命名或权限变更后，CROSSCHECK 就成了不可跳过的前置步骤——跳过它，等于让 RMAN 在盲区里操作。
