RMAN不自动清理归档日志的根本原因是默认CONFIGURE ARCHIVELOG DELETION POLICY TO NONE，必须显式配置匹配存储目标的删除策略（如TO BACKED UP 1 TIMES TO DISK），并配合CROSSCHECK与DELETE命令才能实现闭环清理。
为什么归档日志备份总失败或不清理
根本原因不是备份命令写错，而是归档日志本身没被 RMAN “认作可管理对象”——默认情况下，RMAN 对归档日志完全放任不管，CONFIGURE ARCHIVELOG DELETION POLICY TO NONE 是初始状态，意味着哪怕你执行了 BACKUP ARCHIVELOG ALL DELETE INPUT，只要没配删除策略，后续归档仍会持续堆积，FRA 很快爆满报 ORA-19809。
- 归档日志是否被备份，取决于
ARCHIVELOG DELETION POLICY，而不是RETENTION POLICY；后者只管备份集（backupset），不管归档文件本身 -
DELETE INPUT只在当前备份命令中生效，不能替代持久策略；一旦脚本漏跑或中断，归档就滞留 - 若用 FRA 存储归档，又没配删除策略，
db_recovery_file_dest_size再大也迟早撑爆
如何让 RMAN 自动清理已备份的归档日志
必须显式配置归档日志删除策略，且要匹配实际存储目标。常见错误是只写 TO DISK 却没确认备份目的地是否真有对应设备类型。
- 归档已备份到本地磁盘一次：
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK - 归档已备份到磁带一次（需介质管理器）：
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO SB_TAPE - 若同时备份到磁盘+磁带，策略需明确指向主存储目标，否则 RMAN 不触发清理
- 执行后可用
SHOW ARCHIVELOG DELETION POLICY验证是否生效
BACKUP ARCHIVELOG 命令里 delete input 和 not backed up 的区别
DELETE INPUT 和 NOT BACKED UP 控制的是“本次命令作用范围”，不是全局策略。它们影响立即行为，但不改变归档日志的长期生命周期管理。
-
BACKUP ARCHIVELOG ALL DELETE INPUT：备份所有归档，并删掉**本次备份列表里的那些文件**；若某归档已被删过或不在当前归档列表中，不报错也不处理 -
BACKUP ARCHIVELOG FROM TIME 'SYSDATE-1' DELETE INPUT：只备份过去 24 小时生成的归档，再删它们 -
BACKUP ARCHIVELOG ALL NOT BACKED UP 2 TIMES：只备份**从未备份过、或只备份过 1 次**的归档；配合DELETION POLICY才能形成闭环 - 单独用
NOT BACKED UP而不配策略，RMAN 不会删任何东西，只是筛选源
归档日志连续性被破坏后怎么办
RMAN 不校验归档序列完整性，它只按控制文件记录的归档存在状态做判断。一旦出现 GAP（比如手动 DELETE ARCHIVELOG 或传输失败），REPORT OBSOLETE 可能误判，甚至导致关键归档被标记为 obsolete 并删掉。
- 先检查是否有 GAP：
LIST ARCHIVELOG ALL看序列号是否跳变；再执行CROSSCHECK ARCHIVELOG ALL同步控制文件状态 - 发现 GAP 后，
RECOVER DATABASE会直接失败，此时必须从最近全备 + 完整归档链恢复，不能依赖窗口策略 - 禁用所有外部定时清理脚本（如基于时间的
find /arch -mtime +7 -delete），这类操作 RMAN 完全不可见，等于悄悄剪断恢复链 - 审计要求下，每次
DELETE OBSOLETE前必须人工核对REPORT OBSOLETE输出的时间戳，确认最早可恢复时间点 ≥ 合规窗口
RETENTION POLICY、CONTROLFILE AUTOBACKUP、归档模式三者绑定运行；漏掉任意一环，备份体系就只剩表面动作，没有实际恢复能力。 
