report obsolete 不显示备份的主因是归档日志不完整、control_file_record_keep_time 过小或元数据未同步；需依次验证恢复链连续性、控制文件保留参数及执行 crosscheck 清理过期记录。
REPORT OBSOLETE 不显示备份，通常不是策略没配，而是备份根本没进 RMAN 的判定范围。
RETENTION POLICY 实际生效状态被覆盖或清空
执行 SHOW RETENTION POLICY 看到的输出才是真实生效值。19c 升级后常见情况是策略退回到默认的 TO NONE，尤其执行过 CONFIGURE RETENTION POLICY CLEAR 后——此时 REPORT OBSOLETE 永远返回 “no obsolete backups”。
- 若输出为
RETENTION POLICY TO NONE，必须重配，例如：CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS -
TO NONE在使用 FRA 时极危险：RMAN 不标记任何备份为 obsolete，FRA 空间满会触发ORA-19809，数据库可能 hang 住 -
SHOW ALL不反映当前策略是否有效，只展示配置历史；唯一可信的是SHOW RETENTION POLICY
归档日志不完整导致恢复链断裂
RMAN 判定 backup 是否 obsolete，依赖整个恢复链（全备 + 增量 + 归档）是否能支撑策略要求的时间点。哪怕备份物理存在，只要中间归档缺失，RMAN 就可能降级处理、跳过标记，REPORT OBSOLETE 结果就比预期少，且不报错。
- 检查归档连续性：
SELECT thread#, MIN(sequence#), MAX(sequence#) FROM v$archived_log GROUP BY thread# - 确认归档未被其他脚本误删，特别是
DELETE ARCHIVELOG UNTIL TIME类命令 - 若用
RECOVERY WINDOW，但归档只保留了 3 天，那即使策略设为 7 天，RMAN 也只会按实际归档跨度评估可恢复性
控制文件元数据已丢失或过期
CONTROL_FILE_RECORD_KEEP_TIME 设置过小（如仍为默认 7 天），而保留策略是 14 天，会导致控制文件里老备份记录被循环覆盖——这些备份在物理上还存在，但 RMAN 已“看不见”它们，自然不会出现在 REPORT OBSOLETE 中。
- 查当前值：
SHOW PARAMETER control_file_record_keep_time - 建议值应 > 保留策略天数，例如策略为 7 天，该参数至少设为 10；若策略为 30 天，建议设为 35+
- 该参数只影响控制文件中可复用段（如归档记录、备份记录），不影响 datafile 或 tablespace 记录
CROSSCHECK 缺失导致元数据与磁盘脱节
如果归档目录曾被手动 rm、NFS 挂载异常、或备份片被移动过，控制文件里仍存着旧记录，但文件已不存在。REPORT OBSOLETE 只扫描“状态为 AVAILABLE”的备份，EXPIRED 或缺失的不会参与判断。
- 必须先运行：
CROSSCHECK BACKUP和CROSSCHECK ARCHIVELOG ALL - 再清理过期元数据：
DELETE NOPROMPT EXPIRED BACKUP、DELETE NOPROMPT EXPIRED ARCHIVELOG ALL - 做完这步再跑
REPORT OBSOLETE，结果才可信
真正麻烦的点不在配置本身，而在“策略看似生效，实则被归档完整性、控制文件寿命、元数据一致性三重静默屏蔽”。不验证这三项，REPORT OBSOLETE 的空输出就永远只是个假象。
