为何Oracle 12c RMAN备份后归档日志没有被自动删除？

RMAN从不自动删除归档日志，必须显式执行backup archivelog all delete input或delete archivelog等命令，且需配套crosscheck、清理expired及按时间删除三步操作，缺一不可。

RMAN 从不自动删归档日志，所谓“备份后自动删”是误解 —— 必须显式触发删除动作，且策略配置和执行逻辑缺一不可。

configure archivelog deletion policy 不等于自动清理

RMAN 的 configure archivelog deletion policy 只是设置一个“守门员规则”，它不主动扫描、不定时执行、不后台运行。只有当你执行 backup archivelog all delete input 或 delete archivelog 这类明确指令时，RMAN 才会按策略判断“能不能删”。 常见错觉是：配了 to backed up 1 times to disk 就万事大吉 —— 实际上，如果脚本里没写 delete input，归档就原封不动留在磁盘上，FRA 空间照涨不误。

backup archivelog all delete input 没生效的典型原因

• delete input 只删被本次 backup archivelog 命令实际覆盖的归档 —— 如果归档路径不在 RMAN 控制文件识别范围内（比如手动挪过目录、或 log_archive_dest_1 指向非 FRA 路径），list archivelog all 都查不到，自然不会被备份，更不会被 delete input 触及
• 归档已被备份过，但 RMAN 元数据陈旧：控制文件里记录的状态还是 AVAILABLE，而物理文件早已被其他进程移走或损坏；此时必须先跑 crosscheck archivelog all，否则 delete input 会跳过这些“看不见”的文件
• 在 PDB 环境下执行该命令无效：Oracle 12c+ 要求归档操作必须在 CDB$ROOT 中执行，连接到任意 PDB 后运行 backup archivelog 会直接报错 ORA-19566 或 RMAN-06004

归档堆积的真正源头常被忽略

很多 DBA 把问题归咎于 RMAN，其实根源常在两处：

• 闪回恢复区（FRA）空间不足却没设 db_recovery_file_dest_size 上限，导致归档写入失败后堆积在 log_archive_dest_1 的 OS 目录，而 RMAN 根本不管理那个路径
• control_file_record_keep_time 默认约 30 天，超过此期限的归档元数据会被覆盖；一旦发生这种情况，RMAN 永远无法通过 SQL 或 LIST 命令感知这些归档，只能靠 OS 层 find + rm 救急 —— 但这会破坏账实一致性，应仅作最后手段

最易被跳过的一步：CROSSCHECK 不是可选操作

哪怕你每天定时跑 backup archivelog all delete input，只要漏掉 crosscheck archivelog all，RMAN 就始终“看不见”那些已丢失或状态异常的归档文件。结果就是：

• delete input 表面成功，实际没删几条
• delete obsolete 对归档完全无效（它只管备份集，不管归档）
• FRA 使用率持续 >95%，v$recovery_file_dest 显示空间耗尽，但 ls -l 看目录又没多少文件 —— 因为大量 EXPIRED 记录占着配额却不释放

所以生产脚本里这三行必须成套出现、顺序不能乱：crosscheck archivelog all → delete noprompt expired archivelog all → delete noprompt archivelog all completed before 'sysdate-7'。少一行，就等于埋一颗定时炸弹。