必须确认备库归档全部应用且无传输GAP后才能清理，否则埋雷；先查v$archived_log中APPLIED='YES'记录是否连续，再执行三步验证：查archive_gap、dest_status及max(sequence#)；RMAN清理需先crosscheck再delete expired及completed before；手动清理需确认文件超出恢复窗口且备库已应用，用find+rm -f安全删除；最终以df -h和du -sh为准判断空间释放。
确认备库归档已全部应用且无传输 GAP
直接删归档等于埋雷，dg 备库最怕删掉还没应用的日志。必须先查 v$archived_log 里 applied = 'yes' 的记录是否连续，这是唯一可靠依据；status = 'a' 只是辅助参考，不能当真。
执行以下三步验证：
-
select thread#, low_sequence#, high_sequence# from v$archive_gap;—— 返回空结果才算无 GAP -
select dest_name, status, error from v$archive_dest_status where dest_id = 2;—— 确保主库到该备库的传输目标状态为VALID，且ERROR列为空 -
select max(sequence#) from v$archived_log where applied = 'YES';—— 记下这个值，后续清理不能低于它
用 RMAN 清理控制文件中“看得见”的归档记录
RMAN 只能操作控制文件里还存着元数据的归档日志。如果归档文件存在但控制文件没记录（比如 control_file_record_keep_time 默认 7 天已过期），RMAN 就完全看不见它们——这不是命令写错，是设计如此。
进 RMAN 后按顺序执行：
-
crosscheck archivelog all;—— 把磁盘上存在但控制文件里状态不一致的文件标为EXPIRED -
delete noprompt expired archivelog all;—— 清掉这些“僵尸记录”，否则后续空间不释放 -
delete noprompt archivelog all completed before 'SYSDATE - 3';——COMPLETED BEFORE看的是COMPLETION_TIME，比UNTIL TIME（查FIRST_TIME）更准，不易误删
手动清理 RMAN “看不见”的历史物理文件
上面步骤只清掉了控制文件里最近几天的记录，大量 7 天前的 .dbf 文件仍躺在磁盘上，df -h 不会变。这才是真正占空间的大头。
前提是：你已确认这些文件超出恢复窗口（如备份策略只要 14 天）、不在任何 RMAN 备份集中、且备库已应用完毕。
- 先进归档目录，例如：
cd /oracle/app/archivelog - 预览再删：
find . -name "*.dbf" -mtime +15 -ls | head -20—— 先看时间、路径是否合理 - 安全删除：
find . -name "*.dbf" -mtime +15 -exec rm -f {} \; - 注意：别用
-delete，rm -f更可控，避免通配符误伤
检查空间是否真正释放
删完不等于空间立刻回来。常见假象是 V$FLASH_RECOVERY_AREA_USAGE 里 ARCHIVELOG 的 PERCENT_SPACE_USED 没降——这说明控制文件统计还没刷新。
查两次：
- 第一次：
select * from V$FLASH_RECOVERY_AREA_USAGE; - 等 5–10 分钟再查一次，若仍卡在高位，可能是
control_file_record_keep_time设置过短导致元数据被覆盖太快，或有未归档的 active log 还在占用
真正的释放点永远在文件系统层面：df -h 和 du -sh /oracle/app/archivelog 才算数，别只盯着视图。
