RECOVERY WINDOW OF 7 DAYS 不是保留最近7天备份，而是确保能恢复到当前时间点前7天内任意时刻；其判断依据是备份集最老数据块的CHECKPOINT TIME（非备份开始时间），若SYSDATE减该时间≥7天且该备份仍为恢复链必要环节，则保留，否则标记为obsolete。
直接说结论：recovery window of n days 不是“保留最近 n 天的备份”，而是确保你能恢复到过去任意时间点（最多 n 天内）——它会自动保留所需的全备、增量、归档日志整条链，哪怕某些备份片生成于 n 天之前。
RECOVERY WINDOW OF 7 DAYS 实际怎么算过期？
判断依据不是备份时间戳是否超过 7 天，而是：SYSDATE - BACKUP CHECKPOINT TIME >= 7。但关键在“CHECKPOINT TIME”不是备份开始时间，而是该备份集中所有数据块的最老 SCN 对应的时间点。RMAN 用它反推：如果删掉这个备份，是否会导致某段 7 天内的恢复窗口无法覆盖？
- 比如设了
RECOVERY WINDOW OF 7 DAYS，但上次全备是 10 天前，中间归档日志完整——只要没更近的全备能替代它，这份 10 天前的全备仍被保留，因为它仍是支撑“恢复到第 8 天”的唯一基础 - 若中间归档日志被手动删过（
DELETE ARCHIVELOG），RMAN 会静默降级：那份 10 天前的全备可能立刻变成OBSOLETE，因为恢复链已断，它“事实上”已无用 -
REPORT OBSOLETE输出的列表，才是真实被策略判定为可删的备份；SHOW ALL只显示配置，不反映实际可用性
为什么设了 7 天，FRA 还是爆满报 ORA-19809？
根本原因不是策略配错，而是归档日志没同步清理。RECOVERY WINDOW 只管备份集是否过时，不管归档日志本身是否还“被需要”。默认 ARCHIVELOG DELETION POLICY 是 TO NONE，即归档日志永不自动删。
- 必须显式配置：
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK（或TO SB_TAPE），否则归档日志只增不减 - 如果用了 FRA，且没配归档删除策略，即使备份都按窗口清理了，归档日志也会把空间撑爆
- 执行
CROSSCHECK ARCHIVELOG ALL; DELETE NOPROMPT EXPIRED ARCHIVELOG;是补救手段，但不能替代策略配置
切换到 RECOVERY WINDOW 前必须确认的三件事
缺一不可，否则策略形同虚设，甚至引发误删或恢复失败：
- 数据库必须是
ARCHIVELOG模式：SELECT log_mode FROM v$database;返回ARCHIVELOG才行；否则BACKUP DATABASE PLUS ARCHIVELOG直接失败 - 开启
CONTROLFILE AUTOBACKUP ON，且 FORMAT 必须指向可写路径（尤其 RAC 环境要确认是共享存储）：CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/bak/cf_%F.bkp'; -
DB_RECOVERY_FILE_DEST（FRA 路径）或自定义备份路径，剩余空间至少是数据库大小的 1.5 倍；否则备份写入失败，控制文件元数据不同步，REPORT OBSOLETE结果不可信
容易被忽略的执行顺序陷阱
很多人以为配完就完事，其实 RMAN 的清理动作完全依赖元数据状态，而元数据不会自动刷新：
-
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS只改控制文件里的配置项，不触发任何物理操作 - 必须手动运行：
CROSSCHECK BACKUP;（同步磁盘文件与控制文件记录）→REPORT OBSOLETE;（看哪些真该删）→DELETE NOPROMPT OBSOLETE;（才真正删） - 如果长期没做
CROSSCHECK，控制文件里还记着已被人手删掉的备份片，DELETE OBSOLETE就会跳过它，导致空间无法释放 - RAC 环境下，必须确保所有节点都执行过
CROSSCHECK，否则某节点看到的“过期”和另一节点不一致
