开发者社区> 技术小甜> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

ORACLE告警日志文件

简介:
+关注继续查看

ORACLE告警日志文件

        


告警日志介绍  

 

告警日志文件是一类特殊的跟踪文件(trace file)。告警日志文件命名一般为alert_<SID>.log,其中SID为ORACLE数据库实例名称。数据库告警日志是按时间顺序记录message和错误信息。  

 

告警日志位置  

在ORACLE 10g中,BACKGROUND_DUMP_DEST参数确定了告警日志的位置,但是告警日志的文件名无法修改,告警日志的名称为:alert_<SID>.log ,其中<SID>是实例的名称。BACKGROUND_DUMP_DEST参数是动态的。

SQL> show parameter background_dump_dest;
 
NAME                       TYPE        VALUE
--------------------- ----------- ------------------------------
background_dump_dest   string      /u01/app/oracle/admin/GSP/bdump
SQL>

告警日志以及所有后台跟踪文件都会被写至BACKGROUND_DUMP_DEST参数所指定的目录。

在ORACLE 11g 以及ORACLE 12c中,告警日志文件的位置有了变化。主要是因为引入了ADR(Automatic Diagnostic Repository:一个存放数据库诊断日志、跟踪文件的目录),关于ADR对应的目录位置可以通过查看v$diag_info系统视图。如下所示(ORACLE 12c )

SQL> select * from v$diag_info;
 
INST_ID NAME                 VALUE                                               CON_ID
------- -------------------- -------------------------------------------------- -------
      1 Diag Enabled         TRUE                                                     0
      1 ADR Base             /u01/app/oracle                                          0
      1 ADR Home             /u01/app/oracle/diag/rdbms/ignite/epps                   0
      1 Diag Trace           /u01/app/oracle/diag/rdbms/ignite/epps/trace             0
      1 Diag Alert           /u01/app/oracle/diag/rdbms/ignite/epps/alert             0
      1 Diag Incident        /u01/app/oracle/diag/rdbms/ignite/epps/incident          0
      1 Diag Cdump           /u01/app/oracle/diag/rdbms/ignite/epps/cdump             0
      1 Health Monitor       /u01/app/oracle/diag/rdbms/ignite/epps/hm                0
      1 Default Trace File   /u01/app/oracle/diag/rdbms/ignite/epps/trace/epps_       0
                             ora_13810.trc
 
      1 Active Problem Count 0                                                        0
      1 Active Incident Coun 0                                                        0
        t
 
 
11 rows selected.

clip_image001

如上所示,Diag Trace对应的目录为文本格式的告警日志文件所在的目录,而Diag Alert对应的目录为XML格式的警告日志(对应为log_x.xml)

[oracle@gettestlnx01 trace]$ pwd
/u01/app/oracle/diag/rdbms/ignite/epps/trace
[oracle@gettestlnx01 trace]$ ls alert_epps.log
alert_epps.log
[oracle@gettestlnx01 trace]$ cd ../alert/
[oracle@gettestlnx01 alert]$ pwd
/u01/app/oracle/diag/rdbms/ignite/epps/alert
[oracle@gettestlnx01 alert]$ ls
log_1.xml  log_2.xml  log_3.xml  log_4.xml  log_5.xml  log_6.xml  log_7.xml  log_8.xml  log_9.xml  log.xml

 

告警日志内容:

那么告警日志非常关键与重要,那么告警日志里面包含了那些内容信息呢?告警日志包含了下面一些内容的信息。像一些ORA错误,对于监控数据库有极其重要的作用。

1:所有的内部错误(ORA-600)信息,块损坏错误(ORA-1578)信息,以及死锁错误(ORA-60)信息等。

2:管理操作,例如CREATE、ALTER、DROP语句等,以及数据库启动、关闭以及日志归档的一些信息。

        2.1 涉及物理结构的所有操作:例如创建、删除、重命名数据文件与联机重做日志文件的ALTER DATABASE命令,此外还涉及重新分配数据文件大小以及将数据文件联机与脱机的操作。

        2.2 表空间操作,例如DROP与CREATE命令,此外还包括为了进行用户管理的备份而将表空间置入和取出热备份模式的操作

3:与共享服务器或调度进程相关功能的消息和错误信息。

4:物化视图的自动刷新过程中出现的错误。

5:动态参数的修改信息。

 

告警日志监控:

既然告警日志如此重要,而我们也不可能随时手工去查看告警日志文件,那么我们就必须监控告警日志,那么监控告警日志有哪些方案呢?下面归纳一下

方案1:Tom大师给出的一个方案(仅适用于ORACLE 10g),将告警日志文件信息读入全局临时表,然后我们就可以定制一些SQL语句查询告警日志的信息。

create global temporary table alert_log
( line   int primary key,
 
  text   varchar2(4000)
)
on commit preserve rows
/
 
 
 
 
 
create or replace procedure load_alert
as
 
    l_background_dump_dest   v$parameter.value%type;
 
    l_filename               varchar2(255);
 
    l_bfile                  bfile;
 
    l_last                   number;
 
    l_current                number;
 
    l_start                  number := dbms_utility.get_time;
begin
 
    select a.value, 'alert_' || b.instance || '.log'
 
      into l_background_dump_dest, l_filename
 
      from v$parameter a, v$thread b
 
     where a.name = 'background_dump_dest';
 
 
 
    execute immediate
 
    'create or replace directory x$alert_log$x as
 
    ''' || l_background_dump_dest || '''';
 
 
 
 
    dbms_output.put_line( l_background_dump_dest );
 
    dbms_output.put_line( l_filename );
 
 
 
    delete from alert_log;
 
 
 
 
    l_bfile := bfilename( 'X$ALERT_LOG$X', l_filename );
 
    dbms_lob.fileopen( l_bfile );
 
 
 
    l_last := 1;
 
    for l_line in 1 .. 50000
 
    loop
 
 
 
        dbms_application_info.set_client_info( l_line || ', ' ||
 
        to_char(round((dbms_utility.get_time-l_start)/100, 2 ) )
 
        || ', '||
 
        to_char((dbms_utility.get_time-l_start)/l_line)
 
        );
 
        l_current := dbms_lob.instr( l_bfile, '0A', l_last, 1 );
 
        exit when (nvl(l_current,0) = 0);
 
 
 
        insert into alert_log
 
        ( line, text )
 
        values
 
        ( l_line,
 
          utl_raw.cast_to_varchar2(
 
              dbms_lob.substr( l_bfile, l_current-l_last+1,
 
                                                    l_last ) )
 
        );
 
        l_last := l_current+1;
 
    end loop;
 
 
 
    dbms_lob.fileclose(l_bfile);
 
end;
/

但是这又一个问题,如果数据库宕机了的情况下,是无法获取这些错误信息,比方案3(从操作系统监控告警日志)对比,有些特定场景不适用。另外有一定不足之处,就是日志文件比较大的时候,监控告警日志信息比较频繁的时候,会产生不必要的IO操作。

方案2:通过外部表来查看告警日志文件的内容。相当的方便。然后也是使用定制SQL语句来查询错误信息。

SQL> create or replace directory bdump as '/u01/app/oracle/admin/GSP/bdump';
 
Directory created.
 
SQL> create table alert_logs
  2  (
  3     text  varchar2(2000)
  4  )
  5  organization external
  6  (
  7      type oracle_loader
  8      default directory bdump
  9      access parameters
 10    (
 11       records delimited by newline
 12       fields
 13       reject rows with all null fields
 14     )
 15    location
 16   (
 17             'alert_GSP.log'
 18   )
 19  )
 20  reject limit unlimited;
 
Table created.
 
SQL> select * from alert_logs;
 
TEXT
--------------------------------------------------------------------------------
Thu Aug  7 14:50:28 2014
Thread 1 advanced to log sequence 14
  Current log# 1 seq# 14 mem# 0: /u01/app/oracle/oradata/GSP/redo01.log
 
SQL>

 

方案3:我以前一篇博客归档—监控ORACLE数据库告警日志里面介绍了如何对告警日志进行归档、监控。这些脚本也确实很有效的替我监控着数据库的运行。

 

告警日志归档

 

告警日志如果不及时归档,时间长了,告警日志文件会变得非常大,查看、读取告警日志会引起额外的IO开销。所以一般应该按天归档告警日志文件,保留一段时间(例如 90天),超过规定时间的删除。

告警日志是否可以删除呢? 以前有位同事说background_dump_dest目录下的跟踪文件除了告警日志外都能删除,如果删除告警日志文件有可能会产生意想不到的错误,我半信半疑,在测试服务器删除告警日志,验证后发现没有什么影响,系统会重新生成告警日志文件(时间上不会立即生成告警日志文件,而是当进程向告警日志写入记录时就会生成新的告警日志文件)。





















本文转自xiaocao1314051CTO博客,原文链接:http://blog.51cto.com/xiaocao13140/1932956 ,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Oracle自带adrci工具清理告警日志
Oracle自带adrci工具清理告警日志
0 0
Oracle 18.3 : 透过告警日志从安装初始化过程看 18c 的新改变
Oracle Database 18c 已经正式对外发布,第一个公共版本的版本号是 18.3 ,让我们从 18.3 的安装过程来一睹 18c 的改变。
1937 0
oracle 11.2.0.1告警日志报错ORA-03137与绑定变量窥探BUG9703463
2017年12月份第二次oracle数据库巡检中,发现某一地市oracle数据库发现SQL语句触发特定版本BUG
1117 0
ORACLE 告警日志alert过大的处理
  现在,对于我来说,处理ORACLE告警日志alert多大不再是什么难题;但是,由于数据库是公司最重要的设备,不容有失,处理数据库相关的进程或文件还是要特别小心。  目前,ORACLE数据库主要分widows和LINUX/UNIX版本,对于LINUX/UNIX平台,我们可以使用tail -n /path/alert*.log|more来查看,很方便;但是,windows操作平台,我们遇到如下图所示那么大个的告警日志,该怎么查看。
1585 0
Oracle的告警日志之v$diag_alert_ext视图
Oracle的告警日志之v$diag_alert_ext视图   最近由于自己写的一个job老是报错,找不出来原因,数据库linux的terminal由于安全原因不让连接,因此告警日志就没有办法阅读,没有办法就想想其它的办法吧,比如采用外部表的形式来阅读告警日志就是一个不错的办法。
1402 0
QGS
oracle数据库-简易巡检脚本
记oracle数据库-简易巡检脚本
0 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
EasyDBforOracle— 基于阿里云的Oracle最佳实践
立即下载
Oracle云上最佳实践
立即下载
迁移 ORACLE 最佳实践
立即下载