ORACLE运维实例分享（二）小心alert日志与trc文件

ORACLE运维实例分享（二）小心alert日志与trc文件

背景在上一篇ORACLE审计日志的运维案例中介绍了很典型的一个由于审计日志文件数量过多，导致在业务运行时报ORA-02002:无法写入审计日志的错误。有兴趣的朋友可以参见上期文章：ORACLE运维实例分享－文件与空间管理（一）。PS：这是从金庸先生的作品中学来的习惯。我们知道，ORACLE之所以够强大，除了本身的数据库强大的管理功能外，完善的日志与跟踪信息的记录，对于分析定位故障的帮助也是非常大的。但是《道德经》有云：福兮祸之所伏；有时过多的日志和跟踪信息，反而有可能会引起系统运行的异常。今天为您讲解下alert日志与TRC文件的相关运维案例。

本期案例

客户在进行法人清算时，突然数据库出现宕机情况，业务无法正常运行，使用PLSQL也无法连接，但通过PING与TELNET检查网络是正常的。

排查步骤

一、检查alert日志文件，看看有没有明显的错误提示；

先了解下客户的数据库版本是11G，并询问ORACLE的实例名与安装路径，到/opt/oracle/diag/rdbms/esim6/alert下去检查  alert_esim6.log文件，发现出现大量的Error: 28: No space left on device的提示。（/opt/oracle/是ORACLE安装所在的根路径，esim6是数据库的实例名称）

二、怀疑是不是磁盘空间满了，引起无法写入文件或日志的错误；

在LINUX命令行下，输入DF –h命令，发现在 挂载点下果然used是100%

三、排查具体是什么样的文件，导致磁盘分区空间会占满掉；

因为该分区不是存放数据文件和备份文件的，客户又没有使用OBAR和RMAN等需要使用到alert日志的备份系统。那引起分区空间占满的，只能是ORACLE自身产生的一些系统必需的文件或日志。

凭借着已有的ORACLE知识，怀疑可能是alert或TRC文件占用空间过大，导致ORACLE无法再写入磁盘文件。

四、排查alert日志与TRC文件数量与大小，看是否较大，在进行处理；

检查alert_esim.log 文件大小，发现这个文件也有10多G，确实比较大。

检查TRC文件的大小，到 opt/oracle/diag/rdbms/esim6/trace 目录下，通过du --max-depth=1 –h 检查该目录下的文件总大小也有几十个G，而且通过ll命令也能发现大量的trc 与 trm文件，也都是很久以前的。

问题原因

问题已经能基本明确，就是因为一直累积的trc文件与增长的alert日志，导致数据库无法再写入新的日志文件，最终使磁盘空间占满，影响业务的正常开展。

解决方案

一、清空alert.log文件；

步骤1：

使用CP/opt/oracle/diag/rdbms/esim6/alert/alert_esim6.log/frqs/alert_esim6bak.log的命令来备份 alert日志文件到其它分区中；

步骤2：

截断alert日志： echo dev/null >/opt/oracle/diag/rdbms/esim6/alert/alert_esim6.log。

二、清理下过期的这些TRC和TRM文件；

进入到/opt/oracle/diag/rdbms/esim6/trace，使用LINUX命令清理30天以前的文件。

LINUX命令：find trace -ctime +30 |xargs rm -f

三、重新启动数据库实例，进行业务操作，一切正常。

总结

由于alert日志和trace文件会记录数据库系统的事件与异常记录，一些等待事件与已发生的内部错误、死锁错误，DDL 语句以及启动关闭数据库等记录都会在里面，特别有异常时内容就会更多。这种预警日志不建议关闭，当出现系统方面的故障时，提供日志与相应的TRACE文件有助于较快的定位问题。

PS:想了解更多（alert预警日志、trace文件）相关信息大家可以登录“新意客服服务平台—知识库—技术运维”专栏查阅哦！