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

在Oracle DG（Data Guard）环境下，备份保留策略的配置存在一个常见误区：备库不能直接沿用主库的备份保留策略。许多DBA认为主备配置一致即可，但若在备库执行 `delete obsolete`，可能导致主库数据恢复所需的备份被误删。原因在于RMAN在DG环境下不区分主备角色，备库执行RMAN时会读取主库的控制文件配置，而备库的归档日志应用进度滞后于主库，导致基于时间窗口的保留策略计算错误。

RMAN默认不区分主备角色

当连接到备库执行RMAN时，它读取的是控制文件中的主库配置，包括 `RETENTION POLICY`。问题在于备库的归档日志应用进度和SCN总是比主库慢。例如，主库设置 `RECOVERY WINDOW OF 5 DAYS`，但备库可能仅应用到6月20日的归档。RMAN会按6月25日计算哪些备份过期，从而将6月20日之前的所有备份标记为 `OBSOLETE`。一旦执行 `delete obsolete`，主库恢复所需的归档或数据文件备份便会被删除。 关键注意点： - 在备库执行 `REPORT OBSOLETE` 前，需先查询 `v$archived_log` 中 `APPLIED='YES'` 的最晚 `FIRST_TIME`，确认备库实际追到的应用时间点。 - 备库的保留窗口应以自身应用能力为上限，建议设置 `RECOVERY WINDOW OF 2 DAYS` 或更短，避免替主库做出决策。 - 高危警告：在主备共用备份目录的场景下，切勿在备库直接运行不带 `NOKEEP` 限制的 `DELETE OBSOLETE`。

备库的归档清理策略必须单独配置

主库通常会设置 `CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY`，让RMAN自动删除已在所有备库上应用过的归档。但在备库独立备份场景下，若备库的RMAN也执行此策略，可能导致备库主动删除尚未被备份脚本捕获的归档，或主库保留用于回切的归档。因此，需在备库执行以下命令： `CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;` 若仍希望保留“已应用且已备份”的清理逻辑，不建议依赖全局配置，改用脚本控制。例如，先执行 `CROSSCHECK ARCHIVELOG ALL`，再执行 `DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-2'`，并配合备份完成的时间戳确保安全。注意，该配置针对当前连接的数据库实例生效，每个备库实例需单独执行。

脚本中必须显式声明策略

最稳妥的做法是不依赖全局配置，每次启动RMAN会话后，在 `run{}` 块内重新声明策略。注意，`configure retention policy` 等命令必须写在 `run{}` 块内，且位于所有 `backup` 命令之前，否则不会对 `run` 块内的备份生效。 以下为备库专用脚本示例：

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`，可防止备份失败时归档被误删。 - 备份路径务必与主库物理隔离，避免共用挂载点导致RMAN扫描目录时发生冲突。 总之，核心难点不在于配置命令本身，而在于理解：备库的“时间感知”永远慢半拍。所有基于时间的策略都必须以备库实际应用到的日志时间点为基准，而非系统时钟。忽略这一点，`delete obsolete` 随时可能成为破坏数据恢复的隐患。