执行 DELETE EXPIRED BACKUP 未删除任何对象，是因为RMAN仅清理控制文件中已标记为EXPIRED的记录；必须先运行CROSSCHECK BACKUP更新状态，再执行删除。
DELETE EXPIRED BACKUP 为什么没删掉任何东西
执行 delete expired backup 后显示 “0 objects deleted”，不是命令错了，而是 rman 默认只检查控制文件里标记为 expired 的记录——而这些记录往往根本没被标记上。
常见原因：备份文件物理存在但控制文件已丢失该记录；或用了 CROSSCHECK 但没跟 DELETE EXPIRED 配合；又或者备份保留策略（RETENTION POLICY）压根没生效。
- 必须先运行
CROSSCHECK BACKUP，让 RMAN 重新扫描磁盘/介质，把找不到的备份打上EXPIRED标签 - 再执行
DELETE EXPIRED BACKUP，否则它只清理“已知过期”的元数据，不碰“未知但实际缺失”的条目 - 如果用的是恢复目录（recovery catalog），确保已连接并同步：
RESYNC CATALOG，否则控制文件和目录状态不一致，EXPIRED判定会出错
RMAN 删除后控制文件还留着旧备份记录
即使 DELETE EXPIRED BACKUP 成功返回，控制文件里仍可能残留 STATUS = DELETED 或孤立的 BS_KEY 记录。这不是 bug，是 RMAN 的元数据清理机制本身不彻底——它只删备份集（backupset）和映像副本（image copy）主记录，不自动级联清理依赖项，比如 RC_BACKUP_PIECE 中的碎片条目或过时的归档日志关联。
- 用
LIST EXPIRED BACKUP确认是否真无残留；若还有，说明CROSSCHECK没扫全，或某些备份片（piece）路径权限不足导致跳过 - 手动清理需谨慎：直接更新控制文件不可行；唯一安全方式是重建控制文件（极端情况）或通过
CHANGE ... UNCATALOG显式注销特定备份（适用于已确认物理不存在且无法CROSSCHECK的场景） - 归档日志的元数据尤其顽固：哪怕归档已被
DELETE ARCHIVELOG ALL清空，其备份记录仍可能滞留，此时要配合CHANGE ARCHIVELOG ALL CROSSCHECK
DELETE EXPIRED BACKUP 在 Data Guard 环境下的风险
主库执行 DELETE EXPIRED BACKUP 不会影响备库，但反过来——在备库上执行，可能误删主库还在用的备份元数据，尤其是当主备控制文件未实时同步、或使用了独立恢复目录时。
- 永远只在主库执行元数据清理操作；备库应设为
STANDBY DATABASE模式，禁止执行任何DELETE类 RMAN 命令 - 如果用了共享恢复目录，确保主备都注册且
DB_UNIQUE_NAME区分明确，否则DELETE EXPIRED可能跨库匹配，删掉其他数据库的“过期”记录 - 备库上的
CROSSCHECK必须加FOR DB_UNIQUE_NAME <primary_name></primary_name>限定范围，否则默认只查本地角色对应的备份
替代方案：用 CONFIGURE RETENTION POLICY 更可靠
比起反复手动 DELETE EXPIRED BACKUP，靠策略驱动的自动清理更少出错。但注意：RMAN 不会主动删除“超龄但未过期”的备份，只对满足策略且状态为 EXPIRED 的才触发清理逻辑。
- 启用基于恢复窗口的策略：
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS，然后定期跑DELETE OBSOLETE（它会找“不再需要用于恢复”的备份，比EXPIRED更准） -
DELETE OBSOLETE会同时清理备份集、归档日志、甚至控制文件快照，但前提是归档日志已被应用到备库（如开启ARCHIVELOG DELETION POLICY） - 别混淆
OBSOLETE和EXPIRED：前者是“策略判定不需要”，后者是“物理找不到”。一个备份可以OBSOLETE但不EXPIRED（文件还在），也可以EXPIRED但不OBSOLETE（文件丢了但还在恢复窗口内）
真正麻烦的是跨平台迁移或控制文件重建后残留的元数据——那种情况没有银弹，得靠 LIST BACKUP SUMMARY 对比物理文件列表，再逐条 UNCATALOG。别图省事跳过 CROSSCHECK，那是所有清理动作的前提。
