根本原因是控制文件元数据与磁盘实际状态不一致：RMAN严格依据v$archived_log执行操作，若归档路径未注册、文件被OS直接删除未crosscheck、或control_file_record_keep_time超期导致元数据丢失，RMAN便无法识别目标日志，致使DELETE ARCHIVELOG ALL COMPLETED BEFORE等命令静默跳过。
根本原因不是rman“删不了”，而是控制文件里记录的状态和磁盘实际状态不一致——rman按控制文件行事，你看到的“过期”在它眼里可能根本不存在或已被标记为不可删。
为什么DELETE ARCHIVELOG ALL COMPLETED BEFORE经常静默跳过文件
这不是命令失效，是RMAN压根没“看见”那些文件。常见三种情况：
- 归档路径不在
db_recovery_file_dest或RMAN已知范围内（比如手动挪到/backup/arch，但没在RMAN里catalog start with） - 之前用
rm直接删过文件，控制文件还留着记录，RMAN查v$archived_log时发现物理文件缺失，但没走CROSSCHECK，就当“不存在”跳过 -
control_file_record_keep_time默认约30天，超期后元数据被覆盖，RMAN彻底丢失该归档的任何线索，只能OS层手工清理
CROSSCHECK ARCHIVELOG ALL必须放在第一步
这步不是可选，是强制同步动作：它让RMAN逐个扫描磁盘上所有归档文件，把控制文件里有记录但磁盘上没文件的标为EXPIRED，把磁盘上有但控制文件没记录的补录进来。
漏掉这步的后果：
-
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL清不掉“僵尸记录”，FRA配额不释放 -
DELETE ARCHIVELOG ALL COMPLETED BEFORE查不到目标文件，返回“no archived log found”却误以为已清空 - 后续
LIST ARCHIVELOG ALL结果和ls -l目录内容对不上
备库删归档前必须验证APPLIED = 'YES'而非STATUS = 'A'
STATUS = 'A'只表示归档日志已接收，不代表已应用；真正安全删除的唯一依据是v$archived_log.APPLIED = 'YES'。
验证不能只看单条记录，要跑三组检查：
-
SELECT MIN(sequence#), MAX(sequence#) FROM v$archived_log WHERE applied = 'YES' AND standby_dest = 'YES';—— 确认连续应用范围 -
SELECT * FROM v$archive_gap;—— 必须返回空集，否则存在传输断点 - 主库查
v$archive_dest_status中对应DG目标的STATUS = 'VALID'且ERROR为空
跳过任一检查，DELETE ARCHIVELOG UNTIL TIME就可能删掉还没apply的日志，备库同步直接中断。
删完空间不释放？先盯住V$FLASH_RECOVERY_AREA_USAGE里的PERCENT_SPACE_USED
这不是bug，是控制文件统计刷新延迟。关键点：
- 删完立刻查
V$FLASH_RECOVERY_AREA_USAGE，ARCHIVELOG行的百分比可能不变——等5–10分钟再查 - 如果长期不降，不是RMAN没删，而是
control_file_record_keep_time设太小（比如调成7天），导致旧归档元数据被快速覆盖，控制文件无法准确统计已释放空间 - 此时
df -h显示空间已释放，但Oracle内部仍计为占用，需调大该参数并重启实例才能修正统计
真正卡住的从来不是删除动作本身，而是元数据和物理状态之间的那层映射关系——RMAN只信控制文件，而控制文件只信你让它校验过的东西。
