如何在Oracle DG环境下配置独立于主库的备份保留策略

备库必须单独配置保留策略，否则DELETE OBSOLETE会误删主库依赖的备份；RMAN在DG环境下不区分主备角色，备库沿用主库控制文件中的RETENTION POLICY，但因应用进度滞后导致过期判断失准。

备库不能直接用主库的保留策略，必须单独配置，否则 delete obsolete 会误删主库还依赖的备份。

RMAN 在 DG 环境下默认不区分主备角色

RMAN 连接到备库时，仍沿用控制文件中记录的主库配置（包括 RETENTION POLICY），但备库的归档日志应用进度、SCN 落后于主库，导致「过期判断」完全失准。例如主库设置了 RECOVERY WINDOW OF 5 DAYS，而备库当前只应用到 6 月 20 日的归档，RMAN 却按 6 月 25 日计算——结果把 6 月 20 日前所有备份都标为 OBSOLETE，一执行 DELETE OBSOLETE 就可能删掉主库恢复必需的归档或数据文件备份。

• 备库上运行 REPORT OBSOLETE 前，必须先确认其 APPLIED 归档日志最晚时间点（查 v$archived_log 中 APPLIED='YES' 的最大 FIRST_TIME）
• 备库的保留窗口应以自身应用能力为上限，建议设为 RECOVERY WINDOW OF 2 DAYS 或更短，避免跨角色误判
• 绝对不要在备库上运行未加 NOKEEP 限制的 DELETE OBSOLETE，尤其当主备共用同一备份目录时

备库必须禁用 ARCHIVELOG DELETION POLICY 的自动清理

主库常配 CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY，让 RMAN 自动删已应用归档。但在独立备份场景下，这条策略会让备库 RMAN 主动删除归档——而这些归档可能还没被备份脚本捕获，或主库尚未切换、仍需用于故障回切。

• 在备库 RMAN 中执行：CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
• 若需保留“已应用且已备份”的归档清理逻辑，应改用脚本控制：先 CROSSCHECK ARCHIVELOG ALL，再 DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-2'（配合备份完成时间戳校验）
• 注意：该配置仅对当前连接的数据库生效，重启实例不丢失，但需在每个备库实例上单独执行

备库备份脚本里必须显式覆盖 RETENTION POLICY

不能依赖全局配置，每次 RMAN 会话启动后第一件事就是重置策略。常见错误是写完 configure retention policy... 却没放在 run{} 块开头，导致后续 backup 命令仍用旧策略。

• 正确写法示例（备库专用脚本）：

run{  configure retention policy to recovery window of 2 days;  configure controlfile autobackup on;  configure controlfile autobackup format for device type disk to '/backup/standby/ctl_%F';  allocate channel c1 device type disk;  backup as compressed backupset database format '/backup/standby/db_%U';  sql 'alter system archive log current';  backup archivelog all not backed up 1 times format '/backup/standby/arch_%U';  release channel c1;}

• 关键点：configure 必须在 run{} 内，且在任何 backup 前；not backed up 1 times 比 all delete input 更安全，避免漏备就删
• 路径务必与主库物理隔离（如不同挂载点、不同 NFS 导出路径），防止主备 RMAN 同时扫描同一目录引发冲突

真正麻烦的不是配置命令本身，而是备库的“时间感知”永远滞后于主库——所有基于时间的策略都得按它实际能应用到的日志来折算，而不是看系统时钟。一旦忽略这点，DELETE OBSOLETE 就成了定时删库脚本。