留个心眼：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{}` 块外面，那它不会对 `run` 块里的 `backup` 命令生效。 这里放一段典型的备库专用脚本，供参考： ```php 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` 随时可能变成一个定时删库的“核武器”。