备库归档空间满时严禁直接rm -f，必须先确认v$archive_gap为空、mrp0状态为applying_log、主库dest_id状态valid且error为空，再执行crosscheck后delete expired，最后用find清理控制文件不可见的失联归档。
备库归档空间满不能直接 rm -f，否则会触发 gap
直接删文件是最高频的误操作。备库上 v$archived_log 里 applied = 'yes' 才代表这条归档已被 mrp 进程应用完毕；只看文件名或时间戳（比如按 sequence# 或 name 末尾数字）极易误删未应用归档，导致 v$archive_gap 出现非空结果，同步中断甚至需重建备库。
- 必须先查
SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;—— 返回空集才算无 GAP - 再确认 MRP 进程状态：
SELECT process, status, sequence# FROM v$managed_standby WHERE process = 'MRP0';，status必须为APPLYING_LOG - 检查主库
v$archive_dest_status中对应DEST_ID的STATUS是VALID，且ERROR列为空
RMAN delete archivelog 在备库基本无效，别信 configure archivelog deletion policy
configure archivelog deletion policy to applied on standby 在备库上纯属摆设：该策略只在主库执行 DELETE INPUT 或显式 DELETE ARCHIVELOG 时触发校验，且依赖隐含参数 "_log_deletion_policy" = ALL 和实例重启。备库本身不发起删除动作，配了也白配，还可能干扰 RAC 或升级。
- 备库清理只能靠手动
DELETE NOPROMPT ARCHIVELOG ...，且必须加COMPLETED BEFORE 'SYSDATE - N'时间条件 - 时间表达式务必带单引号：
'SYSDATE - 3'合法，SYSDATE-72（小时）易解析失败 - 若有多个归档目标（如本地文件系统 + ASM），用
FROM DEST_ID 2显式限定，避免跨DEST_ID误删
先 CROSSCHECK 再 DELETE EXPIRED，否则空间不释放
如果之前手动 rm -f 过归档文件，或备份工具未正常退出，控制文件里会残留“幽灵记录”。不先做 CROSSCHECK ARCHIVELOG ALL，后续 DELETE 命令会跳过这些失效条目，v$flash_recovery_area_usage 中 ARCHIVELOG 的 PERCENT_SPACE_USED 依然居高不下。
- 进 RMAN 后顺序执行：
CROSSCHECK ARCHIVELOG ALL;→DELETE NOPROMPT EXPIRED ARCHIVELOG ALL; - 这一步必须在
DELETE ARCHIVELOG UNTIL TIME之前完成，否则可能报RMAN-08137或静默失败 - 删完后等 5–10 分钟再查
V$FLASH_RECOVERY_AREA_USAGE，控制文件统计刷新有延迟
控制文件管不到的“失联归档”只能用 find -mtime 清理
control_file_record_keep_time 默认 7 天，超期归档的元数据被覆盖，RMAN 完全看不见它们——哪怕物理文件还在磁盘上。这类文件不是“过期”，是“失联”，只能靠操作系统命令清理，但有两个硬前提：
- 数据库已连续运行超 7 天，且期间未执行全库恢复（否则旧归档可能参与 PITR）
- 确认无第三方备份工具正在读取这些旧文件（如
ps -ef | grep backup） - 推荐命令：
find /u02/archivelog -name "*.dbf" -mtime +15 -exec rm -f {} \;，+15比+7更安全，留出 MRP 应用延迟余量
真正卡点不在命令怎么写，而在“是否敢删”——得同时满足 v$archive_gap 为空、MRP0 正在 APPLYING、且数据库没刚做完恢复这三个条件，才能动 find。缺一不可。
