必须先执行crosscheck backup更新状态，再运行delete expired backup才能清理失效元数据；否则因控制文件无expired标记，命令返回“0 objects deleted”。
无效历史记录不清理，RMAN元数据会持续膨胀、LIST命令变慢、CROSSCHECK效率下降，甚至影响DG同步状态判断。 根本问题不是“该不该删”，而是“删不干净”或“删错范围”——控制文件里残留的EXPIRED/DELETED记录、跨库未同步的备份片、被覆盖的归档元数据，都会让RMAN行为不可预期。
为什么DELETE EXPIRED BACKUP没删掉任何东西
执行DELETE EXPIRED BACKUP返回“0 objects deleted”，不是命令写错了，是控制文件里压根没标记为EXPIRED的记录。RMAN只删已标记的，不主动扫描。
- 必须先运行
CROSSCHECK BACKUP，强制刷新磁盘上实际存在的备份集与控制文件状态的一致性 - 如果备份存放在NFS或ASM中，挂载异常或权限不足会导致CROSSCHECK跳过部分路径，对应记录永远不被标记
- 用了恢复目录（recovery catalog）但没执行
RESYNC CATALOG，主库控制文件和目录状态脱节，EXPIRED判定失效
备库上不能执行DELETE类RMAN元数据清理
在备库执行DELETE EXPIRED ARCHIVELOG ALL或DELETE OBSOLETE，可能误删主库仍在用的备份关联信息，尤其当DB_UNIQUE_NAME未严格区分时。
- 备库的
CROSSCHECK必须加限定：CROSSCHECK BACKUP FOR DB_UNIQUE_NAME <primary_db_name></primary_db_name> - 所有元数据清理操作（包括
DELETE EXPIRED、CHANGE UNCATALOG）应只在主库执行 - 备库若需清理本地归档，只允许用
DELETE ARCHIVELOG UNTIL TIME或COMPLETED BEFORE，且必须确认APPLIED = 'YES'
control_file_record_keep_time导致的“看不见”的旧备份
默认control_file_record_keep_time是7天（19c起可设为0，但不推荐），超过这个时间的归档和备份元数据会被覆盖，RMAN彻底无法识别——这些不是“无效记录”，而是“无记录”，DELETE EXPIRED完全不起作用。
- 查当前值：
SHOW PARAMETER control_file_record_keep_time - 这类文件只能手工清理：
find $ORACLE_BASE/fast_recovery_area -name "*.bkp" -mtime +30 -exec ls -lh {} \;，确认不在LIST BACKUP结果中再rm -f - 删完必须立刻回RMAN执行
CROSSCHECK ARCHIVELOG ALL和DELETE EXPIRED ARCHIVELOG ALL，否则v$archived_log里name为空但status仍为A，长期积累会干扰MRP进程
真正顽固的残留：RC_BACKUP_PIECE里的碎片条目
即使DELETE EXPIRED BACKUP成功，RC_BACKUP_PIECE视图里仍可能有STATUS='DELETED'的孤立记录，它们不占用空间但污染查询结果，且无法被常规RMAN命令清除。
- 查残留：
SELECT * FROM RC_BACKUP_PIECE WHERE STATUS = 'DELETED'; - 安全清理方式只有两种：
CHANGE BACKUPPIECE '<piece_key>' UNCATALOG;</piece_key>（需知道piece_key），或重建控制文件（仅极端情况） - 避免产生这类残留：禁用
CONFIGURE CONTROLFILE AUTOBACKUP OFF后未及时手动备份，或频繁切换归档目的地但未同步清理策略
最常被忽略的是：RMAN元数据清理不是一次性的。只要存在手工移动备份、NFS临时不可达、或control_file_record_keep_time设置过短的情况，残留就会周期性再生。定期跑CROSSCHECK+DELETE EXPIRED只是维持，不是根治。
