RMAN不自动删除归档日志的根本原因是默认CONFIGURE ARCHIVELOG DELETION POLICY TO NONE，归档生命周期由该策略而非RETENTION POLICY控制；DELETE INPUT仅作用于当前命令，需显式配置匹配存储目标的删除策略并重启数据库（如启用"_log_deletion_policy"）才能生效。
为什么 RMAN 不自动删归档日志
RMAN 默认不管理归档日志的生命周期，CONFIGURE ARCHIVELOG DELETION POLICY TO NONE 是初始状态。哪怕你反复执行 BACKUP ARCHIVELOG ALL DELETE INPUT，只要没配删除策略，新生成的归档仍会堆积——FRA 很快报 ORA-19809 溢出。
关键点在于：RETENTION POLICY 只管备份集（backupset），不管归档文件本身；归档是否可删，只由 ARCHIVELOG DELETION POLICY 决定。
-
DELETE INPUT仅作用于本次命令选中的归档，不是全局清理开关 - 归档若未被 RMAN “认作可管理对象”，就永远不会进入清理流程
- 用 FRA 存储归档却没配策略，
db_recovery_file_dest_size再大也撑不了几天
怎么配才真正生效：TO BACKED UP vs TO APPLIED ON STANDBY
策略必须匹配实际存储目标，否则 RMAN 认为“条件未满足”，拒绝删除。
常见配置：
- 归档只备份到本地磁盘一次：
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK - 归档已备份到磁带（需介质管理器）：
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO SB_TAPE - 主库+备库环境，要求归档在备库应用后才可删：
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY
注意：APPLIED ON STANDBY 并非检查“是否收到”，而是查 V$ARCHIVED_LOG.APPLIED = 'YES'。若备库 MRP 进程未运行，该字段仍为 NO，删归档就会卡住，报 RMAN-08137。
验证是否生效：SHOW ARCHIVELOG DELETION POLICY。
配了策略还删不掉？可能漏了隐含参数或重启
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY 在 Data Guard 环境下默认不生效，因为底层依赖被禁用。
必须手动放开：
- 执行：
ALTER SYSTEM SET "_log_deletion_policy" = ALL SCOPE=SPFILE SID='*'; - 修改后必须
SHUTDOWN IMMEDIATE+STARTUP，否则策略静默失效 - RAC 环境务必加
SID='*'，否则只影响当前实例 -
SCOPE=BOTH动态修改会失败，只能改 SPFILE
没重启就配策略，SHOW 看起来成功，实际 DELETE INPUT 仍绕过判断——这是最常踩的坑。
CROSSCHECK 和 DELETE 命令要配合使用
策略只是“守门员”，不是“清洁工”。RMAN 不定时扫描、不主动删文件，只在你显式执行 DELETE INPUT 或 DELETE ARCHIVELOG 时按策略放行。
典型闭环操作：
-
CROSSCHECK ARCHIVELOG ALL：刷新控制文件中归档状态，标记失效项 -
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL：清掉标记为 EXPIRED 的记录（对应已物理删除的文件） -
BACKUP ARCHIVELOG ALL DELETE INPUT：备份 + 按策略删源（前提是策略已配且生效）
单独用 NOT BACKED UP 2 TIMES 只是筛选源，不触发删除；FORCE 参数能绕过策略强制删，但 DG 环境慎用，易造成 GAP。
真正麻烦的从来不是命令写错，而是策略配了没生效、备库状态没同步、或者根本忘了重启数据库——这些点一漏，归档就停不下来地涨。
