RMAN无法删除控制文件中无记录的归档日志，因其仅管理元数据可见的文件；需先用CROSSCHECK和DELETE清理可见部分，再手动删除超期物理文件。
RMAN 本身不能直接“清空”归档目录，它只能删掉控制文件里还“记得”的那些归档日志。如果目录里堆着好几年前的 *.dbf 文件，RMAN 命令大概率根本看不见它们——这不是操作错了，是设计如此。
为什么 DELETE ARCHIVELOG ALL 没用？
常见错误现象：RMAN 执行完 DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'，df -h 显示归档目录空间没变化；或者 list archivelog all 根本不显示那些旧文件。
原因很直接：Oracle 控制文件默认只保留约 7–30 天的归档元数据（由 control_file_record_keep_time 参数决定，通常为 7）。超过这个时间窗口的归档记录已被覆盖，RMAN 的元数据视图里没有它们，自然无法通过 SQL 或 RMAN 命令定位、删除。
这些文件是物理残留，不是恢复所需，但 RMAN 不管它们——你得自己动手。
-
CROSSCHECK ARCHIVELOG ALL只能发现当前磁盘上存在、但控制文件里状态不一致的文件（比如被mv走又没同步的） -
DELETE EXPIRED ARCHIVELOG ALL只清理标记为EXPIRED的记录，不碰“不存在于控制文件”的文件 -
DELETE OBSOLETE依赖 RMAN 保留策略，对无记录文件完全无效
先让 RMAN 清掉它“看得见”的部分
这步必须做，否则后续手工清理可能引发 v$archived_log 状态混乱，尤其在 DG 备库上容易中断日志应用。
以 oracle 用户执行：
rman target / RMAN> CROSSCHECK ARCHIVELOG ALL; RMAN> DELETE NOPROMPT EXPIRED ARCHIVELOG ALL; RMAN> DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-15'; RMAN> DELETE NOPROMPT OBSOLETE;
注意：
-
COMPLETED BEFORE看的是COMPLETION_TIME，即归档写入完成时间，最常用也最稳妥 - 别用
UNTIL TIME，它查的是FIRST_TIME（LOW SCN 时间戳），在日志切换频繁时可能误删 - 备库必须先确认
APPLIED = 'YES'，否则删了未应用的归档会导致同步断裂
手动清理 RMAN “看不见”的历史残留
这才是释放大量空间的关键动作。前提是：你已确认这些文件远超业务恢复窗口（如备份策略只要保留 14 天），且不在任何 RMAN 备份集中。
进入归档目录（例如 /oracle/app/archivelog）后：
cd /oracle/app/archivelog # 先预览：列出 15 天前所有 .dbf 文件（确认路径和时间是否合理） find . -name "*.dbf" -mtime +15 -ls确认无误后执行删除（立刻释放磁盘空间）find . -name "*.dbf" -mtime +15 -delete
要点：
-
-mtime +15表示修改时间大于 15 天（即 16 天及以上），不是“15 天前”，注意边界 - 生产环境建议加
-maxdepth 3防止递归过深误删子目录下非归档文件 - 若目录结构含日期子目录（如
2024_01_01），可用find . -path "./202[0-3]_*" -name "*.dbf" -delete更精准
DG 备库清理要多一道验证
备库不能照搬主库流程。删错一个未应用的归档，轻则报 ORA-01152，重则需重建备库。
必须按顺序确认：
- 查
v$archive_dest_status，确保STATUS = 'VALID'且ERROR为空 - 查
v$archived_log，过滤APPLIED = 'YES'且DELETED = 'NO' - 再执行
CROSSCHECK和DELETE EXPIRED - 最后用
DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE-3'（注意是UNTIL TIME，因备库COMPLETION_TIME可能不准）
如果之前有人手动 rm 过文件，control_file_record_keep_time 又设得太小（比如 3 天），控制文件可能反复覆盖旧记录失败，导致大量“幽灵归档”堆积——这时调大该参数并重启实例，再做一次 CROSSCHECK，才能让 RMAN 重新识别出哪些该标为 EXPIRED。
