必须启用ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY，否则RMAN删除归档时不校验备库应用状态，易导致GAP和MRP报错；启用后仅当主备库均确认归档已应用才物理删除。
configure archivelog deletion policy to applied on standby 必须启用
不配置这项策略，RMAN 在执行 DELETE ARCHIVELOG 或 BACKUP ... DELETE INPUT 时，完全不检查备库是否已应用该归档。哪怕归档还没传过去、或刚传到但没应用，RMAN 也会照删不误，直接导致备库出现 GAP，MRP 进程报错 ORA-00308 或卡住。
启用后，RMAN 会强制读取备库的 v$archived_log.applied = 'YES' 状态——仅当主库和备库都确认该归档已被应用，DELETE INPUT 才真正物理删除。
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;- 该策略在
MAXIMUM AVAILABILITY和MAXIMUM PERFORMANCE模式下生效；MAXIMUM PROTECTION下默认已启用 - 执行前务必确认备库状态正常：
SELECT database_role, open_mode FROM v$database;应为PHYSICAL STANDBY且非MOUNTED（否则v$archived_log中applied字段可能为空）
delete input 要搭配 backup archivelog all，不能单独用 delete archivelog
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' 这类命令绕过删除策略，直接物理删文件，也不校验备库状态。它只看时间戳，不管归档是否已传、是否已应用——一旦备库延迟超过 7 天，必然丢日志。
真正安全的做法是把归档备份和清理绑定成原子操作：
BACKUP ARCHIVELOG ALL FORMAT '/backup/%U' DELETE INPUT;-
DELETE INPUT是“备份成功后才删”，不是“先删再备份” - 如果备份失败（如磁盘满、路径不可写），归档不会被删，
RMAN会报错并中止 - 注意：若主库启用了
LOG_ARCHIVE_DEST_n的SYNC或REOPEN参数，需确保网络稳定，否则DELETE INPUT可能因等待传送超时而失败
crosscheck + delete expired 不适用于 Data Guard 环境
有人误以为 OS 层手动删归档后，跑 CROSSCHECK ARCHIVELOG ALL 再 DELETE EXPIRED ARCHIVELOG ALL 就能“清理干净”。这在单机库可行，但在 DG 环境里极其危险：
-
CROSSCHECK只校验控制文件记录与物理文件是否存在，不查备库状态 -
EXPIRED状态仅表示文件丢失，DELETE EXPIRED会清除控制文件记录，但不会触发任何备库校验 - 一旦执行，
v$archived_log中对应记录消失，后续CONFIGURE ARCHIVELOG DELETION POLICY就失去作用依据 - 更糟的是：RMAN 可能因此跳过本该保留的归档，导致备库无法追平
备库归档清理必须独立处理，不能依赖主库 RMAN
主库的 APPLIED ON STANDBY 策略只管主库生成的归档是否被备库应用，不管备库自己产生的归档（比如备库切换为主库后产生的新归档）。这些归档默认不参与主库 RMAN 管理，长期堆积会占满 DB_RECOVERY_FILE_DEST。
备库归档清理只能靠脚本或 ARCHIVE_LAG_TARGET 配合自动删除：
- 推荐方案：在备库上部署定时脚本，基于
v$archived_log查询applied = 'YES'且completion_time < SYSDATE-2的归档，再用rm删除（注意路径权限） - 避免用
RMAN在备库执行DELETE ARCHIVELOG—— 备库控制文件不维护主库归档的完整元数据，易删错 - 如果备库开启
FLASHBACK DATABASE，归档还可能被闪回日志引用，删前需确认V$FLASHBACK_DATABASE_LOG中无依赖
最常被忽略的一点：删除策略生效的前提是备库始终在线且 MRP 正常运行。如果备库宕机或 MRP 被手动取消超过 24 小时，主库 RMAN 会认为“所有归档都未被应用”，拒绝执行 DELETE INPUT —— 这不是 bug，而是保护机制。此时不能强行关闭策略，而应先恢复备库同步，再让 RMAN 自动接管清理。
