RMAN清理Oracle归档日志：从堆积原理到自动化脚本实战

生产库的归档日志又又又满了——这大概是每个DBA都经历过的午夜惊魂。告警短信在凌晨三点疯狂震动，登录一看，归档目录利用率99%，数据库连一个checkpoint都完不成，所有事务全部挂起。你手忙脚乱地查v$recovery_file_dest，发现几百GB的归档日志躺在快速恢复区里，哪一次备份的成功记录都找不着。这时候脑子里只有一件事：怎么把这堆日志干净利落地清掉，还别把库搞崩。

如果你也被这个问题折腾过，或者正在为“归档日志堆积”而焦虑，那这篇东西就是写给你的。

这篇文章要聊的就是Oracle数据库里归档日志的清理，核心工具是RMAN（Recovery Manager，Oracle的恢复管理器）。我会从原理层面讲清楚归档日志为什么会堆积、堆积了会造成什么后果，再重点讲RMAN清理归档日志的正确姿势：单条命令怎么用、批量清理怎么设计、备份与清理怎么配合，最后会把实盘里踩过的坑和排查思路一并整理出来。内容适用于Oracle 11g、12c、19c乃至21c的传统架构，以及开了归档模式的环境。新手能把“RMAN删除归档日志”这条命令用明白，老手可以看看脚本化自动化的设计思路有没有借鉴价值。

1. 归档日志为什么堆成山：先搞懂它从哪来、有什么用

1.1 归档日志的本质：数据库所有变更的原始账单

数据库一旦开启归档模式（ARCHIVELOG MODE），每次重做日志切换（Log Switch）时，LGWR后台进程写完在线重做日志（Online Redo Log），ARCn归档进程就会把已写满的在线日志文件完整复制一份，存到指定的归档目录或快速恢复区（Fast Recovery Area，FRA）中。这份拷贝就是“归档日志”。

你可以把在线重做日志想象成店里的流水账本，翻完一页就必须存档，归档日志就是那一页账本的影印件。它的用途只有一个：恢复。无论是实例崩溃后的完全恢复、介质损坏后的不完全恢复，还是用Data Guard搭建备库做容灾，离线备份加归档日志都是最底层的恢复底座。没有归档日志，数据库恢复到故障点那一刻就是一句空话。

理解了这层逻辑，你会发现一个关键事实：归档日志是恢复的硬需求，不能随手删。网上有些教程说“直接rm -f归档目录下的文件”，那是在赌你的备份体系永远不需要追溯旧日志，赌输了就是数据永久丢失，教训比加班还惨痛。

1.2 堆积的元凶：备份策略缺位与恢复区阈值设置失衡

归档日志堆积，表面看是“没清理”，本质上是“备份策略与日志清理没有配合起来”。常见的直接原因有几个：

其一，RMAN备份策略里没有配置删除归档日志的规则，或者配置了但对应的备份长期失败。归档日志只有在其对应的数据文件备份已经存在之后，才允许被安全删除——这是物理上的安全前提。如果全备一直失败，RMAN按策略去算“哪些归档可以删”时，会发现一条都不够格，日志自然越积越多。

其二，快速恢复区（DB_RECOVERY_FILE_DEST_SIZE）的空间配额设置得太小，或者干脆没设。Oracle在快速恢复区里存放归档日志、控制文件自动备份、闪回日志等，空间耗尽之后，数据库会直接卡死。这个“卡死”不是慢，是彻底Hang住，连只读查询都进不去。

其三，备库断档。用Data Guard时，主库的归档日志要源源不断地送到备库去应用，如果备库宕了、网络断了，主库的归档日志就无法安全删除——RMAN删除时会检查日志是否已在备库应用，保护机制会拒绝删除。

其四，纯人肉的“手工删除大法”埋下的隐患。直接在操作系统层面删掉归档文件，数据库控制文件里却还留着记录，导致RMAN后来做任何操作都可能报告控制文件与磁盘文件不一致，最后不得不手动crosscheck。这类问题我在第五部分整理过。

2. 清理之前的必修课：先做体检再动手

2.1 盘点现状：确认归档日志总量与磁盘空间压力

我再强调一遍：生产库上删归档日志，没有“看一眼磁盘就敲命令”这种说法。清理前至少要拿到几组数据，心里有数了才敢动手。

最常用的一条SQL，查看归档日志的总体占用情况：

SELECT ROUND(SUM(BLOCKS * BLOCK_SIZE) / 1024 / 1024 / 1024, 2) AS ARCH_SIZE_GB FROM V$ARCHIVED_LOG WHERE DEST_ID = 1 AND ARCHIVED = 'YES' AND DELETED = 'NO';

这条SQL统计的是还没被标记为删除的归档日志（DELETED='NO'）。这里有个容易误解的地方：即使你在RMAN里执行了DELETE命令，控制文件里那些日志记录也不会彻底消失，只会被标记为“已删除”，直到保留策略把它们真正清除。所以在统计占用时，不能用SELECT COUNT(*) FROM V$ARCHIVED_LOG这种简单粗暴的方式，要把DELETED字段过滤掉。

磁盘压力的检查我习惯用两层视角：一层是快速恢复区的使用率，一层是归档目录所在文件系统的使用率。

SELECT NAME, SPACE_LIMIT / 1024 / 1024 / 1024 AS LIMIT_GB, SPACE_USED / 1024 / 1024 / 1024 AS USED_GB, SPACE_RECLAIMABLE / 1024 / 1024 / 1024 AS RECLAIMABLE_GB FROM V$RECOVERY_FILE_DEST;

如果SPACE_USED接近SPACE_LIMIT，说明快速恢复区快爆了，数据库随时可能进入Hang死状态。文件系统层面直接看df -h即可。我见过一个环境，快速恢复区配额20GB，归档日志实际已经写到25GB，日志还在往快速恢复区里挤，数据库那头已经彻底没反应了——就是因为SPACE_LIMIT被当成摆设，没有建告警。

2.2 确认备份基线：没有备份就没有删除权

归档日志的删除逻辑建立在一条铁律上：先有备份，后有删除。

Oracle允许你删掉某一份归档日志的前提是，这份日志对应的数据文件已经存在一份可用的备份。实操中，这意味着在制定清理策略前，必须确认最近的增量备份、全量备份都是成功的。你可以用RMAN命令查看：

RMAN> LIST BACKUP SUMMARY;

重点看最后一列“Status”，正常的备份应该都是A（Available，可用）。如果有D（Expired，失效），说明备份文件可能已经被手工挪走或者被系统删掉了，这种环境下一定不要继续清理归档日志，先把备份链条修补完整再说。

我接手过一个环境：备份脚本每天凌晨跑一次，但某一天备份存储空间不够，全备失败，连续失败三天之后，第四天凌晨数据库直接卡住。原因就是归档日志一直在增长，但RMAN找不到可用的备份基线，拒绝删除任何归档日志。这个案例后来成了我做“归档报警”最常引用的例子——备份不与归档清理联动，迟早出大事。

2.3 为什么不能直接rm删文件：控制文件会记仇

有的同行在生产环境里图省事，直接在Linux命令行里rm -f归档目录下的文件。我要认真拦住这种操作，因为它不只是风险高，几乎必然给后续运维留下后患。

数据库控制文件里维护着所有归档日志的元数据，包括文件名、线程号、序列号、创建时间、大小等。你在操作系统层面rm掉文件，控制文件不知道。之后再跑RMAN时，它会对控制文件里记录的归档日志做存在性检查，发现“你记录的文件找不到了”，就会把这些日志标记为Expired。这种情况下RMAN不会自动清理这些过期记录，你还得手动执行CROSSCHECK和DELETE EXPIRED，否则控制文件里的归档记录会一直“占着茅坑不拉屎”。

而直接用RMAN的DELETE命令，Oracle会同时做三件事：删除物理文件、在控制文件里把对应记录标记为已删除、并同步到备份集元数据中，保证恢复目录信息一致。三件事一步到位，这才是受控的清理。控制文件虽是“记仇”，但RMAN给足了台阶，我们没必要绕开它走野路子。

3. RMAN清理归档日志的命令细节：从入门到实战

3.1 基础命令：DELETE ARCHIVELOG的三种玩法

RMAN清理归档日志的核心命令是DELETE ARCHIVELOG，最常见的有三种用法。

最基础的一种，删除所有已备份过的归档日志：

RMAN> DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE DISK;

这条命令的含义非常直白：把“已经在磁盘上备份过至少一次”的归档日志全部删掉。注意“BACKED UP 1 TIMES”不是指归档日志本身被备份过，而是指包含这些归档日志、或与这些日志关联的备份已经完成，安全基线已建立。

第二种，按时间范围删除：

RMAN> DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';

删除7天前的所有归档日志。实际操作中我更建议把它和“已备份”条件叠加，否则这条命令会强制删除满足时间的日志，即使备份不存在。正确姿势是：

RMAN> DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7' BACKED UP 1 TIMES TO DEVICE TYPE DISK;

第三种，按序列号范围删除。这套在备库断档恢复后特别有用：

RMAN> DELETE ARCHIVELOG FROM SEQUENCE 100 THREAD 1 UNTIL SEQUENCE 200 THREAD 1;

这条适合在你知道主库某个序列范围已经成功应用到备库后，精确清理那一段日志。

注意：别在生产环境随手执行不带任何条件的DELETE ARCHIVELOG ALL。这条命令连备份都没确认的日志也会一起删，一旦数据库需要恢复到这些日志覆盖的时间点，你连后悔药都没得吃。

3.2 实战组合：归档备份与删除一条龙

真正的生产环境清理，我很少单独执行DELETE ARCHIVELOG，而是把“备份+清理”做成一整条链路的RMAN脚本。核心思路：先备份需要保留的归档日志，然后顺手把已经备份过的日志删掉。

基础版是这样：

RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT;

这条命令把所有归档日志备份到磁盘或磁带，备份完成后立刻删除源文件。它兼顾了“留底”和“释放空间”，在存储充裕、带宽足够的环境里最省事。我们生产环境的备份任务长这样：

RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;

PLUS ARCHIVELOG是个非常聪明的设计：它在备份数据文件之前，先备份当前所有归档日志并清空它们，然后在数据文件备份结束后，再备份这段时间新产生的归档并清除。这样数据文件备份期间产生的日志也能被覆盖到，备份链路不会断。

如果是19c以上环境，还可以：

RMAN> BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES DELETE INPUT;

NOT BACKED UP条件会把“没备份过”的日志备份，然后删掉这些已备份的，未备份的永远有备份保护，不会误删。

3.3 清理后的确认与验证：别删完就忘

删完日志不是终点，必须做一次确认。最常见的确认方式：

RMAN> CROSSCHECK ARCHIVELOG ALL; RMAN> DELETE EXPIRED ARCHIVELOG ALL;

CROSSCHECK的作用是拿控制文件里记录的归档日志去和物理文件比对，把丢失或缺失的标记为Expired。DELETE EXPIRED则把这些失效记录清理掉。这两条命令是解决“控制文件元数据残留”问题的标准组合拳。

确认清理是否生效，可以用视图再查一次：

SELECT ROUND(SUM(BLOCKS * BLOCK_SIZE) / 1024 / 1024 / 1024, 2) AS ARCH_SIZE_GB FROM V$ARCHIVED_LOG WHERE DEST_ID = 1 AND ARCHIVED = 'YES' AND DELETED = 'NO';

数值回落正常，说明清理到位。如果数值没有明显变化，我建议检查你是不是把归档日志写在了多个DEST_ID上，有些环境配置了多路归档，光看DEST_ID=1会漏掉。

4. 自动化清理：让脚本替你守住安全线

4.1 一个稳妥的RMAN清理脚本设计

生产环境不可能天天凌晨爬起来敲命令，自动化是必须的。但自动化不等于“定时删除”，而是“定时按条件清理”。我维护过的一个典型脚本结构是：

#!/bin/bash export ORACLE_SID=orcl export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH LOG_DIR=/home/oracle/scripts/log DT=`date +%Y%m%d_%H%M%S` LOG_FILE=${LOG_DIR}/arch_clean_${DT}.log rman target / nocatalog log=${LOG_FILE} << EOF CONFIGURE RETENTION POLICY TO REDUNDANCY 1; CROSSCHECK ARCHIVELOG ALL; DELETE NOPROMPT EXPIRED ARCHIVELOG ALL; DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE DISK; EXIT; EOF

脚本里有四处细节值得说清楚：

第一，CONFIGURE RETENTION POLICY TO REDUNDANCY 1，把保留策略设为“仅保留一份备份”。冗余超过1份的旧备份会被标记为Obsolete，并通过DELETE OBSOLETE命令清理。这样数据文件备份数量受控，归档日志的清理基线也更清晰。

第二，CROSSCHECK放在清理之前，先把不一致的记录修复，后面DELETE时不会因为找不到文件而报错。

第三，DELETE NOPROMPT是为了在脚本环境中免交互执行。交互模式下RMAN会停下来问“Are you sure?”，脚本里你没法人工回车，必须加NOPROMPT。

第四，日志落盘。归档清理这种高危操作，任何一步出错都必须能回溯。LOG_FILE把完整输出留下来，出问题后翻日志，比从告警里猜原因靠谱得多。

然后放到crontab里：

0 1 * * * /home/oracle/scripts/arch_clean.sh > /dev/null 2>&1

凌晨一点执行，避开业务高峰，也给前一天晚上的备份任务留出足够完赛时间。

4.2 备份保留策略如何与归档清理协同

不少环境里，归档清理失败的原因不是命令写错了，而是备份保留策略与清理策略互相打架。

举个例子：你的RMAN全备保留策略是REDUNDANCY 2，也就是磁盘上保留了最近两份完整备份，更早的会标成Obsolete。如果上次全备失败，磁盘上只剩一份全备，此时删除归档日志时，RMAN会发现满足“备份1次”条件的日志仍然存在且安全。但如果备份频繁失败，旧备份被清掉，新备份又没出来，保留的备份数少于2，而归档日志还在无脑增长，问题就会集中爆发。

我的设计思路是：备份策略决定“保留几份可恢复的备份”，归档清理策略决定“每个备份点之前的日志可以删”。两者合起来就是完整的恢复能力。实际执行顺序应该是：先做备份（数据文件+归档），再清Obsolete备份，最后删已备份过的归档日志。

RMAN里可以一次性编排：

RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT; RMAN> DELETE NOPROMPT OBSOLETE; RMAN> DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE DISK;

这套顺序保证：所有日志先备份后删除、备份不会被旧日志挤爆、归档空间不会无限膨胀。运维值班的人只需要看备份日志有没有报错，不需要每天追着空间告警跑。

4.3 磁盘快满时的紧急清理方案

自动化正常运行时一切岁月静好，但它也会失灵——最常见的原因是备份存储满了，备份任务连续失败多日，日志堆积到只剩几百MB的可用空间。此时常规的DELETE ARCHIVELOG可能因为备份记录不满足“BACKED UP”条件而删不掉任何文件。

这种紧急状态下，我有一个分层处理的办法，危险性逐级升高，请谨慎评估使用：

第一层：如果磁盘上还有可用空间，先尝试备份最近几天的归档日志，让清理条件先满足起来。空间不够，就找一个暂时不用的目录，先备份最新的两个日志，让RMAN认为“备份基线”存在。

第二层：如果空间确实已经撑不住，可以临时先执行一次：

RMAN> DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE-3';

这条命令不检查备份，直接删掉3天前的所有归档日志。执行这个命令前，你必须确认最近的备份基线和归档日志能支撑数据库恢复到3天内任意时间点。这是拿恢复窗口换故障恢复时间的应急手段。

第三层：情况最紧急、恢复点目标（RPO）可以放松时，也可以考虑彻底删除更早的归档日志，但务必在操作前做一份控制文件的备份：

RMAN> BACKUP CURRENT CONTROLFILE; RMAN> DELETE NOPROMPT ARCHIVELOG ALL;

这一步相当于“格式化重来”，不到万不得已不碰。清理完成后，要尽快恢复完整备份能力，马上做一次全备或增量备份，把备份基线重建起来。

5. 常见报错与排查思路：实战中踩过的坑

5.1 经典报错：ORA-00257与RMAN-08137

ORA-00257是DBA最熟悉的归档错误之一，完整信息通常是“archiver error. Connect internal only, until freed”。触发原因几乎只有一个：快速恢复区（FRA）空间满了。数据库此时会中止正常事务，强制进入一种只能由DBA介入的状态。

处理顺序我一般这样走：

SELECT * FROM V$RECOVERY_FILE_DEST; SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE;

先看是哪类文件把快速恢复区占满了。如果归档日志占大头，马上看一下最近的备份是否能“接得住”，能则执行RMAN清理；如果闪回日志占大头，可以考虑关闭闪回或缩小闪回保留时间，这个后续再细说。

RMAN-08137的典型场景是：你在RMAN里执行DELETE ARCHIVELOG，报“not backed up”的警告，拒绝删除。这条报错其实是保护机制在工作，不要和它硬刚。正确的应对是检查备份是否成功，先把数据文件备份做了，再回来清理。

5.2 Linux文件系统层面的残留与文件句柄问题

RMAN删除归档日志的操作会先把控制文件里的记录标记为已删除，再删除物理文件。如果删除时数据库实例还在运行，某些进程可能还持有这些文件的文件句柄。尤其是有Oracle Data Guard的场景，主库删除日志后，备库如果正在读取该日志做应用，可能出现文件消失的脏状态。最直接的排查方法是用lsof检查：

lsof | grep deleted

如果有进程仍然持有已删除的归档文件句柄，磁盘空间不会立刻释放，但文件已经不可见。遇到这种情况，先确认文件确实已经不需要，再评估是重启进程还是等待文件描述符自行关闭。生产环境重启操作要谨慎，一般建议观察一段时间，大部分场景是备库应用进程短暂持有。

5.3 Data Guard环境下清理归档日志的特殊策略

Data Guard环境中，主库清理归档日志前必须确认对应日志已经在备库应用完毕，否则主库删了、备库还没应用，就会造成备库断档，后续不得不重新增量恢复。

最稳妥的方法是连续几日观察主备库的归档日志序列号是否同步：

SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID = 1; -- 备库执行 SELECT APPLIED_SEQUENCE# FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;

主库的最大序列号大于备库的APPLIED_SEQUENCE#，说明有日志还没应用完。此时不要急着清理，让备库追一追，追不上再排查网络或应用进程问题。

Data Guard环境里我常用的清理条件加上了“已备份且已在备库应用”之外的保护：

RMAN> DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE DISK;

但这条命令本身不检查备库状态，所以我的习惯是先通过脚本确认备库延迟为0，再执行RMAN清理。自动化脚本里加一段备库延迟检查，可以避免99%的备库断档事故。

5.4 排查清单速查表

这张表不追求包治百病，但覆盖了大多数归档日志清理相关的典型场景。遇到问题先按表定位，多半能少走弯路。

6. 脚本与命令综合示例：可以直接抄作业的配置

到这里，给出一份比较完整的、可以直接改环境变量后投入生产的RMAN维护脚本模板。这段内容把前文涉及的要点都整合在了一起，稍微花点时间读一遍注释，比单条命令更管用。

#!/bin/bash # ============================================================ # 归档日志备份与清理脚本，适用于单机/单实例Oracle # 执行前请确认：数据库归档模式开启、备份存储路径可用 # ============================================================ export ORACLE_SID=orcl export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH BACKUP_DIR=/backup/oracle_arch LOG_DIR=/home/oracle/archive_clean_log DT=`date +%Y%m%d_%H%M%S` LOG_FILE=${LOG_DIR}/arch_manage_${DT}.log # 归档日志备份目录必须存在 mkdir -p ${BACKUP_DIR} mkdir -p ${LOG_DIR} rman target / nocatalog log=${LOG_FILE} << EOF # 1. 配置备份保留策略：磁盘上保留至少1份备份 CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # 2. 修正控制文件与物理文件的差异 CROSSCHECK ARCHIVELOG ALL; # 3. 清理已失效记录 DELETE NOPROMPT EXPIRED ARCHIVELOG ALL; # 4. 备份数据库（含归档日志），备份完成后立即删除输入文件 BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT; # 5. 清理冗余备份 DELETE NOPROMPT OBSOLETE; # 6. 兜底：再删除一次已备份过的归档日志（防止第4步未完整覆盖） DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE DISK; EXIT; EOF # 简单检查： # 备份日志里有没有ORA-错误 if grep -iE "ORA-|RMAN-" ${LOG_FILE} | grep -v "RMAN-08137" > /dev/null 2>&1; then echo "发现异常，请检查日志：${LOG_FILE}" | mail -s "RMAN Archive Clean Error" dba@example.com fi

这里有一个容易被忽略的细节：第2步CROSSCHECK ARCHIVELOG ALL在归档日志数量庞大的环境里可能耗时较长，几万份日志的检查可能要几分钟。但这条不能省，因为RMAN在做第4步备份时，如果控制文件里有大量过期记录，性能会受影响。

第6步有“兜底”效果，是因为第4步的PLUS ARCHIVELOG只负责备份“那一刻”存在的归档日志，如果备份过程中数据库继续切换产生了新的日志，第6步会再检查一次，把已备份过的再清一遍。两步叠加，归档目录才可能真正控制住。

7. 最后的经验之谈

写到这里，归档日志清理这件事的核心链路算是交代完整了：原理、前置检查、单条命令、组合实践、自动化脚本和应急方案。但根据我这些年处理相关故障的经验，有几句“不写在文档里”的话，还是想再啰嗦一遍。

第一，清理归档日志的本质不是“删文件”，而是“维护备份链路的完整性”。人的精力有限，手工清理只是应急手段，一定要把“备份->归档清理”这套联动逻辑固化到脚本里，让它每天自动跑。我在多个环境里验证过，自动化清理上线之后，归档空间相关告警的数量肉眼可见地下降。

第二，RMAN的报错大部分时候不是“拦你”，而是在“保护你”。看到DELETE ARCHIVELOG报“未备份”时，第一反应不是绕过它，而是去备份。安全性和便利性冲突的时候，选安全性，这是数据库运维的铁律。

第三，任何清理操作都要留日志、留痕迹。手工清理时也要先敲一条SELECT或LIST命令，把“删之前”和“删之后”的对比记录存档。这种事我吃过亏——上线后某天需要恢复到过去时间点，翻遍记录找不到当时清理的日志范围，最后只能按备份点恢复，倒掉了不少业务数据。教训换来一个习惯：凡是删除类操作，日志留档时间至少半年。

第四，备份存储的告警和监控一定要做。很多归档日志问题往上追，根因都是“备份存储满了”或者“备份任务悄悄失败”，却没人发现。给备份任务加上成功/失败通知，给备份存储加上空间告警，归档日志堆积的概率至少降一半。

这个方案后续还能扩展的方向不少：比如把归档日志直接备份到云存储对象桶里长期留档，或用增量备份策略配合更快的大规模归档清理节奏。但不管怎么演化，最底层的逻辑仍然是那句话：归档日志是恢复的生命线，删除权永远属于“已经安全备份过”的记录。希望通过这篇梳理，你能把归档日志清理从“半夜踩雷”变成“每天自动发生的小事”。