configure archivelog deletion policy 不是自动清理机制，仅在主库执行 delete input 或显式 delete archivelog 时校验归档是否已在备库应用；必须设置隐含参数 "_log_deletion_policy"=all 并重启数据库（rac 环境需加 sid='*'）才生效，否则静默失效且备库配置完全无效。
CONFIGURE ARCHIVELOG DELETION POLICY 不是自动清理开关
它只在主库执行 DELETE INPUT 或显式 DELETE ARCHIVELOG 时起校验作用，不会定时删文件，也不影响 rm -f。配置了但没重启数据库，策略就静默失效——RMAN-08591 警告不是语法错误，而是底层校验链断裂。
必须手动启用隐含参数并重启：
-
ALTER SYSTEM SET "_log_deletion_policy" = ALL SCOPE=SPFILE SID='*';（RAC 环境必须加SID='*'） -
SHUTDOWN IMMEDIATE+STARTUP，动态修改SCOPE=BOTH会失败 - 验证：运行
RMAN> SHOW ARCHIVELOG DELETION POLICY;，应显示TO APPLIED ON STANDBY - 检查
v$parameter中"_log_deletion_policy"值是否为ALL，且ISSES_MODIFIABLE = FALSE（说明需重启）
备库上配 deletion policy 完全无效
备库不发起归档删除动作，CONFIGURE ARCHIVELOG DELETION POLICY 对它只是元数据摆设。你在备库执行 CONFIGURE 不仅无效，还可能干扰 RAC 实例状态同步或后续升级。
备库清理必须靠脚本+SQL判断：
- 先查已应用边界：
SELECT MAX(SEQUENCE#) FROM v$archived_log WHERE applied = 'YES' AND DEST_ID = 2;（DEST_ID需从v$archive_dest确认） - 再查这些序列号对应归档的
COMPLETION_TIME，只删COMPLETION_TIME明确早于该时间点的文件 - 必须前置检查：
SELECT * FROM v$archive_gap为空，且v$managed_standby中MRP0状态为APPLYING - 绝对不要在备库直接跑
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'——它只看时间戳，不管是否已应用
Maximum Protection 模式下别配 APPLIED ON STANDBY
这个模式下 Redo 是同步写主+备，归档生成即代表备库已落盘，无需等待“应用”。配 APPLIED ON STANDBY 反而引入风险：
- 若备库 MRP 进程因维护暂停，策略会误拦删，导致归档堆积
- 主库可随时删归档，应配
TO SHIPPED TO ALL STANDBY或干脆不配 - 确认当前模式：
SELECT protection_mode, protection_level FROM v$database;
RMAN 管不到的归档必须用 find 清理
RMAN 的 CROSSCHECK 和 DELETE 只能管理控制文件里还留有元数据的归档。而 control_file_record_keep_time 默认仅 7 天，超期后物理文件仍在磁盘上，但 RMAN “看不见”——它们不是过期，是失联。
这类文件只能用操作系统命令清理，但有两个硬前提：
- 确认无备份任务正在读取（如第三方备份工具进程仍在运行）
- 用
find /path/to/arch -mtime +15 -name "*.dbf" -exec rm -f {} \;，其中+15是缓冲值（比保留窗口多 8 天），避免刚过期就被删 - 路径必须准确指向归档目录，不能笼统用
FRA路径——FRA 下可能混有控制文件快照、闪回日志等
真正容易被忽略的是：策略生效与否和数据库是否重启强绑定，而不是 RMAN 配置是否“看起来正确”。很多 DBA 在主库改完 policy 就去跑 BACKUP ARCHIVELOG ALL DELETE INPUT，结果报 RMAN-08137，第一反应是策略写错了——其实只是忘了重启。
