备库上 configure archivelog deletion policy 无效，因该策略仅在主库执行 DELETE INPUT 或显式删除时校验，且依赖重启生效的隐含参数 "_log_deletion_policy"=ALL；备库不可直接运行 delete archivelog all completed before 'SYSDATE-7'，否则可能误删未应用归档。
configure archivelog deletion policy 在备库上根本不起作用
在备库上执行 configure archivelog deletion policy to applied on standby 是无效操作。这个策略只在主库发起 DELETE INPUT 或显式 DELETE ARCHIVELOG 时触发校验，而备库本身不执行归档删除动作——它只是接收和应用日志。RMAN 不会在备库自动扫描、判断、删文件。
更关键的是，该策略依赖隐含参数 "_log_deletion_policy" = ALL，且必须修改 SPFILE 并重启数据库才生效。没重启，配置就等于没写；在非 DG 环境配了，纯属干扰后续升级。
- 备库执行该命令后，
RMAN-08591警告大概率出现，不是配置错了，而是参数未启用 - 即使配成功，也不会让 RMAN 自动清理——它只是“守门员”，不是“清洁工”
- Maximum Protection 模式下完全不需要配，因为日志是同步落盘，主库可随时删
delete archivelog all completed before 'SYSDATE-7' 不能直接在备库跑
在备库直接运行 DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' 极其危险：它只按时间戳删，不管归档是否已应用。如果 MRP 进程有延迟（比如刚应用完但还没更新 v$archived_log.applied），或者归档被手动复制到多个 DEST_ID，这条命令可能误删未应用归档，导致 GAP。
正确做法是先查已应用归档的边界，再加时间兜底：
- 用 SQL 查最大已应用序列号：
SELECT MAX(SEQUENCE#) FROM v$archived_log WHERE applied = 'YES' AND DEST_ID = 2（DEST_ID需先查v$archive_dest确认） - 再查这些序列号对应归档的
NAME和COMPLETION_TIME，只删COMPLETION_TIME 的 - 必须前置检查：
SELECT * FROM v$archive_gap为空，且v$managed_standby中 MRP0 状态为APPLYING
物理文件残留必须靠 find + mtime，RMAN 管不到
RMAN 的 CROSSCHECK 和 DELETE 只能管理控制文件里还留有元数据的归档。而 control_file_record_keep_time 默认仅 7 天，超过这个时间的归档，即使物理文件还在磁盘上，RMAN 也“看不见”——它们不是过期，是失联。
这类文件只能用操作系统命令清理，但有两个硬前提：
- 确认无备份任务正在读取（如第三方备份工具进程仍在运行）
- 用
find /path/to/arch -mtime +15 -name "*.dbf" -exec rm -f {} \;，+15 是缓冲值（比保留窗口多 8 天），避免刚过期就被删 - 老版本
find不支持原子性，脚本中断可能导致部分删、部分留，建议加锁或用rsync --remove-source-files替代
安全清理脚本必须包含四重校验
一个可用的备库归档清理脚本，不能只拼几个 RMAN 命令。它必须在开头做四件事：
- 检查
v$archive_gap，非空则直接退出并报错 - 检查
v$managed_standby中 MRP0 进程状态，不是APPLYING就停 - 检查
v$recovery_file_dest空间使用率，超 85% 才触发清理 - 导出当前环境变量（如
$ORACLE_SID、$ORACLE_HOME），避免 crontab 下执行时路径错乱
复杂点不在语法，而在判断链：删一个文件，要跨数据库视图、操作系统时间、外部进程状态三道关。漏掉任何一环，都可能把备库推到 GAP 甚至重建边缘。
