先说说一个高频误区：很多DBA以为配了RMAN的归档删除策略，备份完成后归档日志就会自动清理。实际上，RMAN从来不会主动帮你打扫卫生——它只负责执行你明确下达的命令。必须显式地执行backup archivelog all delete input或delete archivelog这类指令，归档才会被触及。而且，光有命令还不够，配套的crosscheck、清理expired以及按时间删除这三步，缺一不可。
configure archivelog deletion policy 不等于自动清理
很多人把configure archivelog deletion policy理解成“自动清理开关”，其实它更像一个“守门员规则”——只告诉RMAN什么条件下可以删，但不会主动扫描、定时执行或后台运行。只有当你执行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元数据陈旧。控制文件里记录的状态还是
A VAILABLE，而物理文件早已被其他进程移走或损坏。此时必须先跑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'。少一行，就等于埋一颗定时冲击波。
