RMAN不删除“过时”增量备份的主因是未正确配置保留策略或未先执行REPORT OBSOLETE；其判定完全依赖CONFIGURE RETENTION POLICY定义的恢复价值，而非时间或文件名，且绝不破坏增量依赖链。
直接说结论： rman 不删“过时”的增量备份，往往不是命令写错了，而是你没配对 configure retention policy，或者误用了 delete obsolete 而没先 report obsolete 看清单 —— 增量备份是否“过时”，完全由保留策略定义，不是按时间或文件名自动判断的。
CONFIGURE RETENTION POLICY 没生效，DELETE OBSOLETE 就是空转
RMAN 的 DELETE OBSOLETE 不看“7天前”或“有没有被用过”，它只查当前保留策略下哪些备份已无恢复价值。Oracle 19c 默认策略是 REDUNDANCY 1（即每个数据文件至少保留 1 份有效备份），不是时间窗口。
- 如果没显式执行过
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS，那DELETE OBSOLETE实际只清理冗余副本（比如同一数据文件有 2 份 level 0 备份，它可能删掉其中 1 份） - 如果你用的是
REDUNDANCY 2，但只做了 1 次 level 0 + 若干 level 1，DELETE OBSOLETE也不会动任何备份 —— 因为根本没达到冗余数 - 执行
SHOW RETENTION POLICY看输出，别凭印象猜策略
增量备份依赖链没断，RMAN 就不敢删
level 1 增量备份必须基于某个 level 0（或更早的 level 1）才能恢复。RMAN 删除时会检查整个恢复路径：只要某个 level 1 还被后续的 level 1 或归档日志依赖，它就被视为“必需”，DELETE OBSOLETE 绝不会碰它。
- 例如：周一做了 level 0，周二、三、四各做了 level 1。若周四的 level 1 是最新可用备份，则周一的 level 0 和周二、三的 level 1 都不能删 —— 它们共同构成完整恢复链
-
REPORT OBSOLETE会列出真正可删的备份；如果输出为空，说明当前所有备份都在恢复路径上 - 想强制清理某段旧链？得先确认它不参与任何有效恢复点，再用
DELETE FORCE BACKUPSET（慎用）
用 REDUNDANCY 策略删增量备份，容易漏掉归档日志
很多人配了 CONFIGURE RETENTION POLICY TO REDUNDANCY 2，以为能清掉旧的 level 1，结果发现 FRA 还是爆满 —— 因为 DELETE OBSOLETE 默认不处理归档日志，除非你加 BACKED UP 1 TIMES TO DEVICE TYPE DISK 这类条件。
- 归档日志是否“过时”，取决于它是否已被至少 1 份有效备份覆盖（即
BACKED UP状态），而不是冗余度 - 单独清理归档要用：
DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE DISK - 或者统一走时间窗口策略：
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS，这样DELETE OBSOLETE才会连带清理过期归档
最常被忽略的一点：RMAN 不会主动校验备份是否真能恢复。即使 DELETE OBSOLETE 显示删了 10 个 backupset，如果其中某个 level 0 文件损坏，整个增量链就废了。所以生产环境删之前，务必用 RESTORE DATABASE PREVIEW 或 VALIDATE BACKUPSET 抽样验证。否则删完才发现恢复不了，就不是空间问题了。
