DELETION POLICY TO APPLIED ON STANDBY 不起作用的主因是该策略仅在备库生效且需配合 ON STANDBY 子句的删除命令，主库RMAN不感知备库应用状态，且依赖备库控制文件中归档记录的APPLIED标记完整。
DELETION POLICY TO APPLIED ON STANDBY 为什么不起作用
最常见的现象是：主库归档日志被 rman 删除了，但备库还没应用完，导致 archive log list 显示 applied = no，甚至出现 gap 或 mrp 进程卡住。根本原因不是策略写错了，而是 oracle 不会自动“跨库检查应用状态”——deletion policy to applied on standby 只在备库执行删除时生效，而主库的 rman crosscheck 和 delete 默认只看本地控制文件和归档目录，完全不感知备库是否应用。
必须在备库配置并启用 CONFIGURE ARCHIVELOG DELETION POLICY
这个策略必须在物理备库（不是主库）上配置，且数据库需处于 MOUNT 或 OPEN 状态（OPEN READ ONLY + APPLY 也行）。主库配了没用，RMAN 不会去读备库的配置。
-
CONNECT / AS SYSDBA登录到备库实例（不是主库） - 运行：
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; - 确认生效：
SHOW ARCHIVELOG DELETION POLICY;输出应为TO APPLIED ON STANDBY - 如果备库是 READ ONLY，确保
RECOVER MANAGED STANDBY DATABASE DISCONNECT正在运行，否则“APPLIED”状态不会更新
RMAN 删除命令必须显式指定 ON STANDBY 才触发策略
即使策略已配好，日常 DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' 这类命令仍只清理本地“已完成”的归档，不会查备库应用进度。真正触发 TO APPLIED ON STANDBY 的，是带 ON STANDBY 子句的删除：
- 在备库执行：
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-3' ON STANDBY; - 该命令会扫描控制文件中所有归档记录，过滤出已在本机标记为
APPLIED=TRUE的，并只删这些；未应用的跳过 - 注意：
ON STANDBY是备库专属语法，主库执行会报错ORA-19588 - 不要依赖
AUTODELETE或BACKUP ... DELETE INPUT自动触发该策略——它们默认不走ON STANDBY路径
容易被忽略的依赖项：备库控制文件必须包含归档历史
如果备库曾用 RESETLOGS 或重建过控制文件，旧归档记录可能丢失，导致 RMAN 查不到某归档是否已应用，从而拒绝删除（安全起见宁可不删）。验证方法：
- 查备库归档历史：
SELECT NAME, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG WHERE FIRST_TIME > SYSDATE-5 ORDER BY FIRST_TIME; - 如果
APPLIED列大量为NO或为空，说明 MRP 进程异常或归档元数据不全 - 确保备库未开启
STANDBY_FILE_MANAGEMENT=AUTO外的其他干扰设置，避免归档路径与主库不一致导致控制文件漏记 - 归档路径最好统一用
USE_DB_RECOVERY_FILE_DEST，避免 RMAN 因路径差异找不到归档文件
最麻烦的点在于：策略生效与否，取决于备库控制文件里有没有那条归档记录，以及它是否被标记为 APPLIED。这两件事都和 MRP 进程健康度、控制文件同步完整性强相关，而不是单纯配个命令就能一劳永逸。
