Chinaunix首页 | 论坛 | 博客
  • 博客访问: 676330
  • 博文数量: 163
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1625
  • 用 户 组: 普通用户
  • 注册时间: 2014-11-24 11:40
个人简介

资深Oracle数据库专家 OCM认证大师 10年数据库相关服务及开发经验 各类数据库相关方案的编写,管理及实施 数据中心数据库日常运维、大型项目割接、性能优化等方面有丰富的实战经验 客户包括: 电信,银行,保险,航空,国网,汽车,烟草等 想要一起学习探讨数据安全技术的请加qq群 256041954

文章分类

全部博文(163)

文章存档

2017年(2)

2016年(112)

2015年(38)

2014年(11)

我的朋友

分类: Oracle

2016-05-30 20:13:26

告警日志介绍

 

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

 

告警日志位置

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


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

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
 

告警日志内容:

那么告警日志非常关键与重要,那么告警日志里面包含了那些内容信息呢?告警日志包含了下面一些内容的信息。像一些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目录下的跟踪文件除了告警日志外都能删除,如果删除告警日志文件有可能会产生意想不到的错误,我半信半疑,在测试服务器删除告警日志,验证后发现没有什么影响,系统会重新生成告警日志文件(时间上不会立即生成告警日志文件,而是当进程向告警日志写入记录时就会生成新的告警日志文件)。

阅读(5647) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~