1. 项目概述为什么清理 Archive Logs 是 DBA 的必修课如果你是一名 Oracle 数据库管理员那么$ORACLE_BASE/fast_recovery_area/db_name/archivelog/这个目录通常简称为 Arch 目录对你来说一定不陌生。它就像数据库的“时光机”记录舱里面塞满了名为arch_1_12345_987654321.log的归档日志文件。这些文件是数据库恢复的基石但如果不加管理它们会像滚雪球一样迅速吞噬你的磁盘空间最终导致数据库挂起所有业务停摆。我见过太多因为归档日志爆满而引发的生产事故轻则手忙脚乱清理重则数据丢失、恢复时间以小时甚至天计。因此定期、安全地清理 Arch 目录中的归档日志绝不是一项可有可无的日常维护而是保障数据库高可用性的核心操作。简单来说归档日志是 Oracle 数据库在开启归档模式后对在线重做日志文件的持久化备份。每当一个在线重做日志写满并发生切换时Oracle 就会将其复制一份到 Arch 目录形成归档日志。它的核心价值在于实现数据的不完全丢失。结合备份你可以将数据库恢复到历史上的任意时间点。然而这个“时光机”的燃料——磁盘空间——是有限的。如果 Arch 目录满了数据库就无法生成新的归档日志紧接着所有需要写入归档日志的数据库操作包括大部分 DML都会挂起整个系统瞬间僵死。所以这个项目的核心目标非常明确建立一套自动化、安全、可控的机制来清理 Arch 目录中那些已经不再被数据库恢复和备份所需要的旧归档日志文件从而释放宝贵的磁盘空间确保数据库持续稳定运行。这不仅仅是执行几条rm命令那么简单它涉及到对 Oracle 恢复机制的理解、对备份策略的联动以及一系列防止误操作的防护措施。接下来我将拆解整个清理工作的设计思路、具体步骤和避坑指南。2. 清理策略设计在安全与空间之间寻找平衡点清理归档日志最忌讳的就是“一刀切”。直接删除物理文件是最快释放空间的方法但也是风险最高的。万一这些文件还被数据库的恢复流程或最近的备份所需要你的删除操作就可能酿成无法恢复的数据灾难。因此一个稳健的清理策略必须基于一个核心原则只删除那些已经被数据库自身标记为“可废弃”的归档日志。2.1 核心策略解析基于 RMAN 的交叉验证Oracle 提供的官方工具 RMAN 是我们执行清理操作的唯一推荐工具。RMAN 的聪明之处在于它能理解数据库的备份和恢复元数据。我们主要依赖以下两种交叉验证的策略基于备份的保留策略这是最常用、最自动化的方法。你可以在 RMAN 中配置一个保留策略例如CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;。这条命令告诉 RMAN我需要保留足够多的备份和归档日志以便能将数据库恢复到最近7天内的任意时刻。任何早于这个时间窗口的备份和归档日志都会被标记为“过时”。执行DELETE OBSOLETE命令时RMAN 就会自动删除这些过时的文件。基于冗余副本数的保留策略另一种策略是CONFIGURE RETENTION POLICY TO REDUNDANCY 2;。这意味着对于任何数据文件我都至少保留2个可用的备份副本。超过这个数量的旧副本及其相关的归档日志会被视为过时。在实际操作中“恢复窗口”策略更直观也更符合业务对数据可恢复性的要求。我们的清理操作本质上就是让 RMAN 根据已配置的策略找出并删除那些物理上存在、但逻辑上已“过时”的归档日志。2.2 关键考量与决策点在设计策略时你需要明确以下几个问题清理阈值是多少不要等到磁盘使用率达到100%才行动。通常我会设置一个预警阈值如80%和一个紧急清理阈值如90%。当达到预警阈值时触发常规的、策略性的清理任务达到紧急阈值时可能需要更激进的检查比如确认是否有异常的日志生成并立即执行清理。清理频率如何这取决于你的数据库每日产生的归档日志量。对于一个每天产生100GB归档的生产库可能每天都需要清理。对于一个每天只产生几个G的测试库每周清理一次或许就够了。自动化脚本通常结合cron或任务计划程序来定时执行。是否需要保留额外的安全副本在某些极端严格的合规场景下即使 RMAN 认为可以删除业务也可能要求将归档日志额外备份到磁带或对象存储上再保留一段时间。这时清理脚本就需要和备份脚本联动确保物理删除前文件已被成功转储。注意绝对不要直接在操作系统层面使用rm、del命令删除 Arch 目录下的.log文件除非你百分百确定这些文件对应的归档日志信息也已从控制文件和恢复目录中清除。否则当数据库需要这些日志进行恢复时会报错ORA-00308: cannot open archived log导致恢复失败。3. 实操流程详解从连接到验证的完整闭环理论清楚了我们进入实战环节。以下是一套标准的、可脚本化的清理操作流程。我假设你的 Oracle 数据库已处于归档模式并且 Arch 目录位于FRAASM或/u01/app/oracle/fast_recovery_area/ORCL/archivelog/这样的文件系统路径下。3.1 环境准备与初步检查在动手之前先做一次全面的“体检”。确认归档模式与目录-- 以 sysdba 身份登录 sqlplus sqlplus / as sysdba SQL archive log list;查看输出确认“Database log mode”是Archive Mode并记录“Archive destination”的路径。这就是你的 Arch 目录。检查磁盘空间使用情况# 如果 Arch 在文件系统 df -h /u01/app/oracle/fast_recovery_area # 如果 Arch 在 ASM asmcmd lsdg asmcmd du -g FRA/ORCL/ARCHIVELOG/记录下已用空间和剩余空间评估紧迫性。查看当前归档日志序列与状态SQL SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME, NAME, STATUS FROM V$ARCHIVED_LOG ORDER BY FIRST_TIME DESC FETCH FIRST 20 ROWS ONLY;这让你对最新的归档日志情况有个概览。3.2 执行 RMAN 清理操作这是最核心的步骤。我们将使用 RMAN 命令让 Oracle 自己决定哪些可以删。启动 RMAN 并连接目标数据库rman target / # 或者使用密码连接 # rman target sys/passwordorcl可选但推荐交叉检查归档日志 这条命令会对比磁盘上的物理文件和 RMAN 资料库中的记录列出所有在磁盘上但不在资料库中的文件可能是被误删了记录以及所有在资料库中但不在磁盘上的文件可能是被误删了文件。RMAN CROSSCHECK ARCHIVELOG ALL;如果发现状态为EXPIRED的归档日志意味着 RMAN 在磁盘上找不到对应的文件。这通常发生在有人手动用rm删除了文件之后。对于EXPIRED的记录我们可以用DELETE EXPIRED ARCHIVELOG ALL;来清理资料库中的元数据保持一致性。删除过时备份与归档日志 这是根据你配置的保留策略来执行清理的关键命令。RMAN DELETE OBSOLETE;执行前RMAN 会列出所有它认为“过时”的文件包括数据文件备份、归档日志备份、归档日志文件等并请求确认。你可以先使用REPORT OBSOLETE;命令预览将要删除的内容确认无误后再执行DELETE OBSOLETE。针对性删除指定时间点之前的归档日志 如果你没有配置保留策略或者想进行一次性的历史清理可以使用更精确的命令。例如删除所有在3天前生成的、并且已经备份过至少2次的归档日志RMAN DELETE ARCHIVELOG UNTIL TIME ‘SYSDATE-3’ BACKED UP 2 TIMES TO DEVICE TYPE DISK;或者直接删除所有已经备份到磁带的归档日志RMAN DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE SBT;3.3 清理后的空间回收与验证执行完DELETE OBSOLETE后空间可能不会立即释放这取决于你的存储类型。文件系统空间通常会立即释放可以通过df -h再次验证。ASM 磁盘组ASM 的空间管理是延迟的。删除文件后空间只是被标记为可重用并不会立即返还给磁盘组。你可以通过asmcmd du看到文件被删除了但lsdg显示的空间使用率可能变化不大。ASM 会在后台自动回收。如果想强制清理可以对磁盘组进行REBALANCE操作但这在生产环境需谨慎因为会消耗 I/O 资源。SQL ALTER DISKGROUP FRA REBALANCE POWER 1;最后再次运行检查命令确认 Arch 目录下文件数量减少并且数据库运行状态正常没有因日志无法归档而出现的等待事件。4. 自动化脚本与监控方案手动执行毕竟容易遗忘将清理工作自动化是必由之路。下面是一个简单的 Shell 脚本模板它整合了检查、清理和日志记录。#!/bin/bash # 文件名purge_archive_logs.sh # 描述自动清理过时归档日志的脚本 set -o nounset set -o errexit # 环境变量 ORACLE_SIDORCL ORACLE_HOME/u01/app/oracle/product/19c/dbhome_1 LOG_DIR/home/oracle/scripts/log LOG_FILE${LOG_DIR}/purge_archive_$(date %Y%m%d_%H%M%S).log MAIL_LISTdba-teamyourcompany.com # 函数记录日志 log() { echo [$(date %Y-%m-%d %H:%M:%S)] $* | tee -a ${LOG_FILE} } # 主函数 main() { log 开始归档日志清理任务。 # 1. 检查磁盘空间 ARCH_DIR/u01/app/oracle/fast_recovery_area/${ORACLE_SID}/archivelog USAGE$(df -h ${ARCH_DIR} | awk NR2 {print $5} | sed s/%//) log 归档目录磁盘使用率: ${USAGE}% if [ ${USAGE} -lt 80 ]; then log 磁盘空间充足无需清理。任务结束。 exit 0 fi # 2. 执行 RMAN 清理 log 启动 RMAN 清理过时文件... ${ORACLE_HOME}/bin/rman target / EOF ${LOG_FILE} 21 CROSSCHECK ARCHIVELOG ALL; DELETE EXPIRED ARCHIVELOG ALL; REPORT OBSOLETE; DELETE OBSOLETE; EXIT; EOF # 3. 检查 RMAN 执行结果 if grep -q RMAN-00571 ${LOG_FILE} || grep -q ORA- ${LOG_FILE}; then log 错误RMAN 执行过程中出现错误 # 可以在这里添加发送告警邮件的逻辑 mail -s 紧急归档日志清理任务失败 - ${ORACLE_SID} ${MAIL_LIST} ${LOG_FILE} exit 1 else log RMAN 清理任务执行完毕。 fi # 4. 清理后检查 NEW_USAGE$(df -h ${ARCH_DIR} | awk NR2 {print $5} | sed s/%//) log 清理后磁盘使用率: ${NEW_USAGE}% log 归档日志清理任务完成。 } # 执行主函数 main你可以将这个脚本放入crontab每天在业务低峰期例如凌晨2点执行一次0 2 * * * /home/oracle/scripts/purge_archive_logs.sh监控方面除了脚本自带的日志和邮件告警你更应该将 Arch 目录的磁盘使用率纳入到整体的数据库监控平台如 Zabbix, Prometheus Grafana中设置清晰的告警线如 85% 警告 95% 严重确保问题能在影响业务前被及时发现和处理。5. 常见问题与深度排错指南即使按照标准流程操作你也可能会遇到一些棘手的情况。下面是我在实践中总结的几个典型问题及其解决方法。5.1 RMAN 删除失败ORA-00257这是最常见的错误之一错误信息通常是ORA-00257: archiver error. Connect internal only, until freed。这表示归档进程因为磁盘空间不足而无法归档新的日志但此时你可能连 RMAN 都连接不上因为数据库已经处于一种受限状态。解决步骤尝试用 SQL*Plus 本地连接sqlplus / as sysdba。如果连得上立即执行清理命令。如果连不上尝试重启到 mount 阶段# 关闭数据库 sqlplus / as sysdba EOF shutdown immediate; startup mount; exit; EOF在 mount 状态下归档器不工作此时你可以用 RMAN 连接并执行DELETE ARCHIVELOG ALL;命令来紧急释放空间。注意DELETE ARCHIVELOG ALL会删除所有归档日志风险极高仅在所有其他方法无效且你有近期完整备份时使用。释放空间后ALTER DATABASE OPEN;打开数据库。根本预防建立有效的监控在空间使用率达到70%时就触发清理避免走到这一步。5.2 归档日志被标记为 “A” (Active) 状态无法删除在V$ARCHIVED_LOG视图中STATUS为A的归档日志表示它仍然是当前在线重做日志文件的前身是实例恢复所必需的。RMAN 的DELETE OBSOLETE不会删除它们。解决方法通常不需要手动干预。当发生日志切换这个日志不再被需要时其状态会自动变为I(Inactive)。如果你在清理后空间仍然紧张可以检查是否有长时间未提交的事务导致日志无法失效必要时可以尝试手动切换日志SQL ALTER SYSTEM SWITCH LOGFILE; -- 多执行几次切换所有线程的日志然后再次检查状态并尝试清理。5.3 ASM 环境下空间释放延迟如前所述在 ASM 中删除文件后asmcmd du显示空间释放了但asmcmd lsdg显示的总使用率下降不明显。排查与处理使用asmcmd lsdg查看磁盘组的FREE_MB和USABLE_FREE_MB。USABLE_FREE_MB才是考虑冗余后的真实可用空间。检查是否有待清理的临时文件或已删除文件占用的空间尚未回收SQL SELECT * FROM V$ASM_OPERATION; -- 查看是否有正在进行的 REBALANCE如果空间确实紧张且没有正在进行的操作可以考虑在维护窗口发起一个低优先级的重平衡SQL ALTER DISKGROUP FRA REBALANCE POWER 1 WAIT;POWER 1表示低负载WAIT会让语句等待操作完成。请务必在低峰期进行。5.4 清理脚本误删未备份的归档日志这是最可怕的人为失误。如果你的备份任务失败但清理脚本照常运行DELETE OBSOLETE可能会根据策略删除那些未被成功备份的归档日志导致恢复链断裂。防护措施在 RMAN 脚本中强制验证备份状态在删除前先检查最后一次成功备份的时间。RMAN LIST BACKUP SUMMARY;确认最新的备份是成功的、完整的。使用DELETE ARCHIVELOG ... BACKED UP ...语法如前所述明确指定只删除已备份过 N 次的日志为备份失败留出缓冲期。将清理脚本与备份脚本耦合最安全的方式是将清理作为备份作业的最后一步。只有备份成功完成后才触发清理对应时间点之前的归档日志。这可以通过在备份脚本末尾调用清理脚本来实现。清理 Oracle Arch 目录的日志文件是一项融合了知识、工具和谨慎态度的工作。它没有太多高深的技术但每一个细节都关乎数据的安危。我的习惯是在任何清理操作前问自己三个问题这些日志真的没用了吗我的备份是好的吗操作失败了怎么回退想清楚再动手你的数据库生涯会平稳很多。