configure archivelog deletion policy 并非自动清理机制，仅在执行 delete input 或 delete archivelog 时校验归档是否已在备库应用；需手动设置隐含参数 "_log_deletion_policy"=all 并重启数据库（rac 环境须加 sid='*'）才生效，否则策略静默失效，且备库配置无效。
CONFIGURE ARCHIVELOG DELETION POLICY 不是自动清理开关，它只在你执行 DELETE INPUT 或 DELETE ARCHIVELOG 时起守门作用——配置了也不会定时删文件，更不会影响 rm -f。
主库配 APPLIED ON STANDBY 必须重启数据库才生效
这个策略依赖底层隐含参数 "_log_deletion_policy"，Oracle 默认关闭校验能力。不手动放开并重启，配置就等于没写：
ALTER SYSTEM SET "_log_deletion_policy" = ALL SCOPE=SPFILE SID='*';- RAC 环境必须加
SID='*'，否则只改当前实例 -
SCOPE=BOTH动态修改会失败，必须用 SPFILE +SHUTDOWN IMMEDIATE+STARTUP - 重启后验证：
RMAN> SHOW ARCHIVELOG DELETION POLICY;应显示TO APPLIED ON STANDBY
常见错误：配置完没重启，BACKUP ARCHIVELOG ALL DELETE INPUT 仍报 RMAN-08137，但你以为策略“不工作”——其实是根本没加载。
备库上配 APPLIED ON STANDBY 完全无效
备库不发起归档删除动作，CONFIGURE ARCHIVELOG DELETION POLICY 对它只是元数据摆设：
- 该策略只在主库执行
DELETE INPUT或显式DELETE ARCHIVELOG时触发校验 - 备库的归档清理必须靠脚本+SQL判断：
SELECT MAX(SEQUENCE#) FROM v$archived_log WHERE applied = 'YES' AND DEST_ID = 2 - 再结合
COMPLETION_TIME 过滤，避免刚应用完就被删（MRP 有延迟） - 直接在备库运行
RMAN> CONFIGURE ...不仅无效，还可能干扰后续升级或 RAC 实例状态同步
RMAN-08591 警告说明策略未真正启用
出现 RMAN-08591: WARNING: invalid archivelog deletion policy，不是语法错，而是校验链断裂：
- 根本原因是
"_log_deletion_policy"未设为ALL或数据库没重启 - 即使
SHOW ALL显示已配置，只要没重启，策略就静默失效 - 该警告常被忽略，结果导致误删未应用归档，引发
v$archive_gap出现 gap - 检查方式：查
v$parameter中"_log_deletion_policy"值是否为ALL，且ISSES_MODIFIABLE = FALSE（说明需重启）
Maximum Protection 模式下别配 deletion policy
这个模式下 Redo 是同步写主+备，归档生成即代表备库已落盘，无需等待“应用”：
- 归档在主库可随时删，配
APPLIED ON STANDBY反而引入风险 - 若备库 MRP 进程因维护暂停，策略会误拦删，导致归档堆积
- 此时应配
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;，让主库按时间或备份次数自主清理 - 真要控制保留周期，用
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7'更直接可靠
策略生效的前提是理解它在哪起作用、在哪不起作用——它不调度、不扫描、不替代脚本，只在你动手删的那一刻，多问一句“备库真的 OK 了吗”。
