简介这份文档面向 Oracle 数据库运维与 DBA 人员聚焦归档日志写满引发的 ORA-00257 报错提供一套可落地的处理思路与操作记录。内容围绕 Archivelog 机制展开先说明该错误产生的原理再给出「删除物理文件 登录 RMAN 释放逻辑空间」两条主线并附上查看归档占用比例、确认日志存放路径、crosscheck 与 delete expired 等关键命令的实际执行过程同时提醒选择性删除日志、避免影响数据库可恢复性等注意事项。资源包共 1 个 doc 文件约 76KB属于纯文档型资料便于随时查阅与对照操作。目前已有 579 人学习适合遇到归档空间告警、需要快速排错并恢复数据库正常运行的运维人员参考也可作为日常巡检与应急处理的流程备忘。1. ORA-00257 报错那一刻数据抽取任务为什么突然停了凌晨两点数据抽取任务突然停了日志里只有一行冷冰冰的ORA-00257: archiver error. Connect internal only, until freed。这不是数据库崩了而是 Oracle 的归档日志把闪回恢复区撑满了。归档日志archivelog是数据库为了可恢复性记录的所有变更一旦db_recovery_file_dest_size配额被占满Oracle 就会拒绝新的归档写入连带所有依赖归档的操作全部挂起。这份文档记录的正是我处理这类故障的完整思路先删物理文件再进 RMAN 释放逻辑空间。适合每天跟 Oracle 打交道的 DBA 和运维尤其是那些被rman备份老是满折磨过的同行。下面把每一步拆开参数、命令、坑点都摆出来。2. 先看清空间去哪了v$flash_recovery_area_usage 与 recover 参数处理 ORA-00257 最忌讳上来就删文件。你得先确认两件事归档日志到底占了多少、恢复区配额设了多大。Oracle 提供了两个视图和参数一个看占用比例一个看路径和上限。搞清楚这两个数后面删多少、删哪里才有依据。2.1 用 v$flash_recovery_area_usage 定位占用比例登录数据库后第一件事不是删是查。v$flash_recovery_area_usage这个视图会按文件类型列出恢复区的使用百分比其中ARCHIVED LOG那一行就是归档日志的占用。文档里查到的是 89.78%这个数字一旦逼近 100%数据抽取任务就会停。查询命令如下-- 切换到 oracle 用户后登录数据库 -- su - oracle -- sqlplus /nolog SQL conn /as sysdba SQL select * from v$flash_recovery_area_usage;执行后会看到类似ARCHIVED LOG | 89.78 | ...的输出。PERCENT_SPACE_USED列就是占用比例PERCENT_SPACE_RECLAIMABLE列表示可通过删除过期归档回收的比例。如果RECLAIMABLE很高但USED也高说明有大量已失效的归档没被清理这正是 RMANcrosscheck要解决的问题。注意这个视图查的是逻辑配额不是物理磁盘的df -h两者可能不一致因为恢复区大小由参数控制。2.2 show parameter recover 确认路径与配额上限知道占用比例后得确认归档到底写在哪个目录、配额给了多少。show parameter recover会列出db_recovery_file_dest和db_recovery_file_dest_size两个关键参数。文档里路径是/backup/flash_recovery_area大小 160G。命令和输出解读如下SQL show parameter recover;输出中db_recovery_file_dest是归档存放的根目录db_recovery_file_dest_size是恢复区能用的最大空间。常见做法是把这个值设成磁盘实际可用空间的 80% 左右留出余量。如果这个值设得比磁盘实际空间还大Oracle 会以为还能写直到操作系统层面写不进去才报错那时候排查就更绕。我一般会同时开一个终端跑df -h /backup对照看确认物理磁盘没满。两个数都清楚了再决定删哪些、删多少。3. 删物理文件与 RMAN 释放两条命令链的配合ORA-00257 的处理分两个层面操作系统层面删掉物理归档文件数据库层面让 RMAN 知道这些文件没了并释放逻辑空间。只删物理文件不跑 RMAN恢复区占用比例不会降因为 Oracle 元数据里还记着这些文件。只跑 RMAN 不删物理文件空间也释放不出来。两条链必须配合。3.1 选择性删除物理归档文件登录 Oracle 服务器切到 oracle 用户进入归档路径。文档里的路径是/backup/flash_recovery_area下面按日期分了2012_06_10、2012_06_11这样的目录。删除时要选择性删不要rm -rf整个 archivelog 目录。文档里因为是新库没有其他操作记录才全删生产库绝对不能这么干。操作如下# 切换到 oracle 用户 su - oracle # 查看归档目录结构确认日期目录 ls -l /backup/flash_recovery_area/*/archivelog/ # 选择性删除较早的日期目录保留最近的 rm -rf /backup/flash_recovery_area/*/archivelog/2012_06_10rm -rf后面跟的是具体日期目录不是整个archivelog。删之前用ls确认目录内容删之后再用ls确认文件确实没了。这里有个血泪经验如果数据库还在运行且归档目标没改删掉的目录可能马上被新归档重新创建所以删完要尽快进 RMAN 做crosscheck否则新归档又写进来占用比例降不下去。另外删除操作最好在业务低峰期做避免正在进行的备份或抽取任务读到不存在的归档文件而报错。3.2 crosscheck 与 delete expired 释放逻辑空间物理文件删完后进 RMAN 执行crosscheck archivelog all。这条命令会扫描恢复区把物理上已经不存在的归档在控制文件中标记为EXPIRED。注意crosscheck只是标记不删除记录也不释放空间。真正释放空间的是delete expired archivelog all。命令序列如下# 登录 RMAN rman target / # 检查所有归档将物理不存在的标记为 expired RMAN crosscheck archivelog all; # 删除已标记为 expired 的归档记录释放恢复区空间 RMAN delete expired archivelog all;执行delete expired时会提示确认输入YES即可。完成后回到 SQLPlus 再查一次v$flash_recovery_area_usageARCHIVED LOG的占用比例应该明显下降。这里有个参数细节crosscheck archivelog all会检查所有归档如果归档量很大执行时间可能较长可以加channel并行但单实例库一般不需要。另外delete expired只删控制文件里标记为 expired 的记录不会碰物理文件所以顺序不能反——先删物理文件再crosscheck再delete expired。如果先delete expired再删物理文件控制文件里记录没了物理文件还在空间照样占着。4. 避坑与排查ORA-00257 处理中的五个常见翻车点这套流程看着简单但实际操作里翻车的地方不少。下面五条是我和同行踩过的坑每条按现象、原因、解决写清楚。4.1 删完物理文件占用比例纹丝不动现象rm -rf执行完ls确认文件没了但v$flash_recovery_area_usage里ARCHIVED LOG还是 89%。原因只删了物理文件没跑 RMANcrosscheck和delete expiredOracle 控制文件里还记着这些归档逻辑空间没释放。解决按顺序执行crosscheck archivelog all和delete expired archivelog all再查视图确认。4.2 crosscheck 报 ORA-08186 或文件不存在现象crosscheck archivelog all执行时报ORA-08186: invalid timestamp或提示文件不存在。原因物理文件已经删了但控制文件里的记录还在crosscheck找不到文件就会报这个。这其实是正常现象crosscheck的目的就是把它们标记为 expired。解决忽略这个提示继续执行delete expired archivelog all。如果报错导致crosscheck中断可以加crosscheck archivelog all后跟delete expired archivelog all一起跑。4.3 删除了还在备份集里的归档现象删完归档后RMAN 备份任务失败提示找不到归档日志。原因删掉的归档文件被某个备份集或 Data Guard 依赖物理删除后备份链断了。解决删之前用list archivelog all确认哪些归档还被需要或者用delete archivelog until time sysdate-7这种带条件的 RMAN 删除而不是直接rm。生产库建议保留最近 7 天归档删更早的。4.4 恢复区配额设得比磁盘实际空间大现象db_recovery_file_dest_size设了 160G但/backup分区实际只有 100G归档写到 100G 时操作系统报磁盘满Oracle 却还没报 ORA-00257。原因Oracle 按参数配额判断不直接感知磁盘物理上限。解决把db_recovery_file_dest_size设成磁盘实际可用空间的 80% 左右并定期用df -h对照。修改命令alter system set db_recovery_file_dest_size120G scopeboth;。4.5 归档删除后新归档立刻又写满现象刚释放完空间没过多久 ORA-00257 又来了。原因归档产生速度太快或者归档删除策略没配只靠手动删治标不治本。解决配置 RMAN 自动删除策略比如configure retention policy to recovery window of 7 days;再配一个定时任务跑delete obsolete。另外检查log_archive_dest是否指向了正确的恢复区避免归档写到别处又占满另一个分区。5. 进阶用 RMAN 保留策略替代手动删除手动删物理文件加crosscheck能救急但不是长久之计。真正稳的做法是配 RMAN 保留策略让 Oracle 自己管归档的生命周期。我现在的习惯是新库上线第一件事就是配retention policy然后每天定时跑delete obsolete再也没被 ORA-00257 半夜叫醒过。5.1 配置保留策略与自动删除RMAN 的保留策略有两种按恢复窗口recovery window和按冗余份数redundancy。按恢复窗口更直观比如保留 7 天意思是能恢复到过去 7 天内任意时间点。配置命令如下rman target / # 配置保留策略为 7 天恢复窗口 RMAN configure retention policy to recovery window of 7 days; # 查看当前策略 RMAN show retention policy; # 手动执行一次删除过期归档 RMAN delete obsolete;delete obsolete会根据保留策略判断哪些归档不再需要然后删除物理文件和控制文件记录。注意obsolete和expired是两回事expired是物理文件没了但记录还在obsolete是按策略不再需要的。两者可以一起用先crosscheck标记 expired再delete expired清理记录最后delete obsolete按策略删多余归档。5.2 用 until time 精确控制删除范围有时候不想全删只想删某个时间点之前的归档。RMAN 的delete archivelog until time比rm精确得多而且会同步更新控制文件。常用命令对比命令作用适用场景delete archivelog until time sysdate-7删除 7 天前的归档日常清理delete archivelog until sequence 1000删除序列号 1000 之前的归档按序列精确控制delete archivelog all completed before sysdate-1删除 1 天前完成的归档配合备份窗口crosscheck archivelog all标记物理不存在的归档物理文件已删后这些命令执行前建议先跑list archivelog until time sysdate-7看会删哪些确认无误再执行delete。我一般会先list再delete这个习惯救过我好几次——有一次sysdate-7写成了sysdate-70list一看要删 70 天的归档赶紧改回来。5.3 验证释放效果与日常巡检配完策略后验证方法很简单查v$flash_recovery_area_usage看ARCHIVED LOG占用是否稳定在低位再查v$archived_log确认归档记录数和时间范围符合预期。日常巡检我会跑这几条-- 查看恢复区占用 select * from v$flash_recovery_area_usage; -- 查看归档日志数量和最早最晚时间 select count(*), min(first_time), max(first_time) from v$archived_log; -- 查看恢复区参数 show parameter db_recovery_file_dest;如果PERCENT_SPACE_USED持续高于 70%就该检查保留策略是不是太宽松或者归档产生速度是不是异常。另外v$archived_log里DELETED列为YES的记录如果很多说明crosscheck后没及时delete expired逻辑空间没释放干净。从那以后我每次处理 ORA-00257 都强制走一遍「查视图 → 看参数 → 删物理 → crosscheck → delete expired → 复查」的流程再也没出现过删了文件空间不释放的玄学问题。希望帮到你。本文还有配套的精品资源点击获取