备库必须独立配置RETENTION POLICY并禁用自动归档删除策略，因其应用进度滞后于主库，直接沿用主库策略会导致误删主库恢复必需的备份；每次RMAN会话均需显式重置策略并执行CROSSCHECK后再清理归档。
RMAN 在备库上直接沿用主库的 RETENTION POLICY，会导致误删主库还依赖的备份——这不是配置漏了，而是设计如此。
为什么备库不能用主库的保留策略
主库设了 RECOVERY WINDOW OF 5 DAYS，但备库当前只应用到 8 月 20 日的归档，RMAN 却按“当前时间减 5 天”（即 8 月 22 日）去判断过期。结果所有早于 8 月 22 日的备份都被标为 OBSOLETE，一执行 DELETE OBSOLETE 就可能删掉主库恢复必需的归档或数据文件备份。
- 查备库实际应用进度：运行
SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG WHERE APPLIED = 'YES' - 备库保留窗口必须以自身应用能力为上限，建议设为
RECOVERY WINDOW OF 2 DAYS或更短 - 绝对不要在备库上运行未加
NOKEEP限制的DELETE OBSOLETE，尤其主备共用同一备份目录时
备库必须禁用归档自动删除策略
主库常配 CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY 来自动清理已应用归档，但在独立备份场景下，这会让备库 RMAN 主动删归档——而这些归档可能还没被备份脚本捕获，或主库尚未切换、仍需用于故障回切。
- 在备库 RMAN 中执行：
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE - 该配置仅对当前连接的数据库生效，重启不丢失，但需在每个备库实例上单独执行
- 若需保留“已应用且已备份”的清理逻辑，应改用脚本控制：
CROSSCHECK ARCHIVELOG ALL后再DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-2'，并校验备份完成时间戳
每次 RMAN 会话启动后必须重置保留策略
备库 RMAN 默认读取控制文件中记录的主库配置，CONFIGURE RETENTION POLICY 命令不会持久覆盖它。常见错误是把配置写在脚本中间，导致后续 BACKUP 命令仍用旧策略。
- 备份脚本开头第一件事就是重置策略，例如：
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS - 必须放在
run{}块最前面，或在rman target /连接后立即执行 - 不这么做，
REPORT OBSOLETE和DELETE OBSOLETE的判断基准仍是主库的时间窗口
归档清理要分两步走：先同步元数据，再删物理文件
备库归档路径变更、或之前手工删过文件，会导致控制文件里残留“幽灵记录”。不先 CROSSCHECK，DELETE ARCHIVELOG 会静默跳过它们，空间根本清不掉。
- 进 RMAN 后立刻执行：
CROSSCHECK ARCHIVELOG ALL - 紧接着执行：
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL - 再按时间窗口删有效归档：
DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-2' - 注意：
V$FLASH_RECOVERY_AREA_USAGE.ARCHIVELOG.PERCENT_SPACE_USED可能延迟 5–10 分钟更新；长期不降，要怀疑control_file_record_keep_time设置过小
最易被忽略的是：备库上 CONFIGURE 类命令只影响当前会话，且不会写入控制文件的“主库策略区”。哪怕你配了十次，下次新起一个 RMAN 连接，它还是默认读主库那套——所以脚本里必须显式覆盖，不能靠“配一次就一劳永逸”。
