备库无法生效归档清理策略，CONFIGURE ARCHIVELOG DELETION POLICY 仅在主库触发删除时校验，备库不执行删除；其依赖的隐含参数 _log_deletion_policy 需主库修改SPFILE并重启才生效。
备库上无法配置真正生效的归档清理策略——CONFIGURE ARCHIVELOG DELETION POLICY 在备库执行纯属无效操作，且可能干扰 Broker 状态或后续升级。
为什么备库配 CONFIGURE ARCHIVELOG DELETION POLICY 没用
该命令只在主库发起 DELETE INPUT 或显式 DELETE ARCHIVELOG 时起校验作用，备库本身不触发任何删除动作。即使你在备库 RMAN 里执行：CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
它也不会让 RMAN 自动扫描、判断、删文件。更关键的是，这个策略底层依赖隐含参数 "_log_deletion_policy"=ALL，而该参数必须在主库修改 SPFILE 并重启才生效；备库设了也白设。
常见现象：
– 执行后 RMAN 报 RMAN-08591: WARNING: invalid archivelog deletion policy
– SHOW ARCHIVELOG DELETION POLICY 显示已配置，但 DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' 仍可能误删未应用归档
– 备库 Broker 配置残留，后续重建同名 DG 配置时报 ORA-16623 或 ORA-16603
备库清理必须靠 SQL + 脚本组合判断
安全清理的核心是：只删 applied = 'YES' 且 COMPLETION_TIME ≤ SYSDATE - 7 的归档。不能只看时间戳，也不能只看 sequence# —— 因为归档可能被复制到多个 DEST_ID，或 MRP 有延迟。
实操要点：
– 先查 v$archive_dest 确认目标 DEST_ID（比如 DEST_ID = 2）
– 执行 SQL 获取已应用归档边界：SELECT MAX(SEQUENCE#) FROM v$archived_log WHERE applied = 'YES' AND DEST_ID = 2;
– 再查这些序列号对应归档的 NAME 和 COMPLETION_TIME，生成待删列表
– 必须前置校验：
• SELECT * FROM v$archive_gap 返回空
• v$managed_standby 中 MRP0 状态为 APPLYING
– 脚本开头加锁（如 touch /tmp/arch_clean.lock），避免并发冲突
物理残留归档只能用 find 清理，但有硬前提
RMAN 的 CROSSCHECK 和 DELETE 只能管理控制文件里还存有元数据的归档。而 control_file_record_keep_time 默认仅 7 天，超期后元数据消失，RMAN 就“看不见”那些文件了——它们不是过期，是失联。
这类文件必须用操作系统命令清理，但必须满足：
– 确认 v$archive_dest 中已无指向该路径的 DEST_ID（说明该路径已废弃）
– 确认当前无备份任务（如第三方工具进程）正在扫描该目录
– 使用缓冲窗口，例如：find /u01/arch -name "*.dbf" -mtime +15 -exec rm -f {} \;
其中 +15 是安全冗余（比保留窗口多留 8 天），避免刚失效就删
Maximum Protection 模式下别配 deletion policy
这个模式下 Redo 是同步写主+备，归档生成即代表备库已落盘，无需等待“应用”。主库可随时执行：DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
根本不需要 APPLIED ON STANDBY 策略。强行配置反而引入不必要的重启和参数依赖。
真正容易被忽略的是：RMAN 不会管你磁盘上还有多少 .dbf 文件，它只认控制文件里的记录；而 DBA 往往在空间告警时才发现，有大量“失联归档”躺在归档目录里，既不在 RMAN 管控中，又没被脚本覆盖到。
