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'。少一行，就等于埋一颗定时炸弹。
