oracle data guard无自动清理机制，rman的archivelog删除策略仅为守门员而非定时服务；主库需配置“to applied on standby”并启用隐含参数\_log\_deletion\_policy=all且重启才生效，备库该策略完全无效，安全清理须满足已应用且超保留窗口。
Oracle Data Guard 没有真正意义上的“自动清理”机制——RMAN 的 configure archivelog deletion policy 不是定时服务，而是删除动作的守门员；真要自动删，必须靠外部调度（如 cron + 脚本），且主库和备库策略完全不同、不能混用。
主库配 configure archivelog deletion policy to applied on standby 为什么常不生效
这个策略只在主库执行 BACKUP ARCHIVELOG ALL DELETE INPUT 或显式 DELETE ARCHIVELOG 时触发校验，不是后台常驻进程。常见失效原因：
- 没启用隐含参数：
ALTER SYSTEM SET "_log_deletion_policy" = ALL SCOPE=SPFILE SID='*';，且未重启数据库（SHUTDOWN IMMEDIATE+STARTUP） - 在非 Data Guard 环境（单机库）或 Maximum Protection 模式下配置，既无意义又可能引发误拦删
- 误以为配置后 RMAN 就会“自动扫盘删”，实际它完全不主动扫描文件系统
- 用
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7'可绕过该策略，说明策略只守特定命令，不守所有删法
备库不能靠 RMAN 策略清理，必须写脚本
备库本身不发起 DELETE INPUT，configure archivelog deletion policy 在备库上纯属无效配置。安全清理必须满足两个硬条件：已应用（applied = 'YES'）+ 超过保留窗口（如 COMPLETION_TIME ）。脚本关键逻辑：
- 先查
v$archive_gap和v$managed_standby，确认 MRP0 进程正在 APPLY 且无 GAP，否则直接退出 - 用 SQL 获取已应用归档的最大
SEQUENCE#：SELECT MAX(SEQUENCE#) FROM v$archived_log WHERE applied = 'YES' AND DEST_ID = 2（DEST_ID需根据v$archive_dest确认） - 再结合
COMPLETION_TIME二次过滤，避免刚应用完就删（MRP 延迟风险） - 生成
rm -f命令前，务必校验NAME字段路径是否真实存在且可读
物理残留归档必须用 find -mtime +15 清理
RMAN 的 CROSSCHECK 和 DELETE 只能管住控制文件里还“记得”的归档（受 control_file_record_keep_time 控制，默认仅 7 天）。超过这个时间的物理文件，RMAN 完全看不见，但磁盘上还占着空间。这类“失联归档”只能靠操作系统命令清理，但要注意：
- 必须加锁（如
lockfile或flock），防止多个清理任务并发冲突 - 不能只按
mtime，得配合find /path/to/arch -name "*.dbf" -mtime +15 -exec rm -f {} \;，+15 是缓冲值（比保留窗口多 8 天） - 老版本
find不支持原子性，中断可能导致部分删、部分留，建议加-print0 | xargs -0 rm -f提升健壮性 - 执行前确认无第三方备份工具（如 Veritas、Commvault）正在扫描该目录
最易被忽略的点是：主库策略和备库脚本必须分开设计、独立部署；任何试图在备库上配 RMAN deletion policy 的操作，都是徒劳且可能埋下升级隐患的。清理动作永远要以“MRP 是否在跑”和“有没有 GAP”为第一判断依据，而不是时间或文件名。
