备库必须单独配置保留策略，否则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 就成了定时删库脚本。
