第十五章：Oracle12c 数据库警告日志

时间 2019-11-06

标签第十五 oracle12c oracle 数据库警告日志栏目 Oracle 繁體版

原文原文链接

一：查看警告日志文件的位置

Oracle 12c环境下查询，alert日志并不在bdump目录下，看到网上和书上都写着能够经过初始化参数background_dump_dest来查看alter日志路径，还说警告日志文件的缺省位置是%Oracle_base%\admin\orcl\bdump，其实12c中，上述路径都不是真正存放警告日志的路径。html

真是路径是要须要经过v$diag_info视图来查询，为何呢？shell

由于在ORACLE 12c中，引入了ADR(Automatic Diagnostic Repository（自动诊断仓库）:一个存放数据库诊断日志、跟踪文件的目录，关于ADR对应的目录位置能够经过查看v$diag_info系统视图。其实11g中也有v$diag_inifo，说是能够直接经过show parameter background_dump_dest来查看警告日志路径，但我没有测试过。数据库

下面我是我本机测试结果，数据库版本的是12.2.0.1bash

SQL> set linesize 1000;

SQL> col name for  a40;
SQL> col value for a100;
SQL> select name ,value from v$diag_info;

NAME                                     VALUE
---------------------------------------- ----------------------------------------------------------------------------------------------------
Diag Enabled                             TRUE
ADR Base                                 /u01/app/oracle
ADR Home                                 /u01/app/oracle/diag/rdbms/orcl/orcl
Diag Trace                               /u01/app/oracle/diag/rdbms/orcl/orcl/trace
Diag Alert                               /u01/app/oracle/diag/rdbms/orcl/orcl/alert
Diag Incident                            /u01/app/oracle/diag/rdbms/orcl/orcl/incident
Diag Cdump                               /u01/app/oracle/diag/rdbms/orcl/orcl/cdump
Health Monitor                           /u01/app/oracle/diag/rdbms/orcl/orcl/hm
Default Trace File                       /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_28952.trc
Active Problem Count                     1
Active Incident Count                    1

11 rows selected.

SQL>

二：警告日志内容

那么告警日志很是关键与重要，那么告警日志里面包含了那些内容信息呢？告警日志包含了下面一些内容的信息。像一些ORA错误，对于监控数据库有极其重要的做用。服务器

1：全部的内部错误（ORA-600）信息，块损坏错误（ORA-1578）信息，以及死锁错误（ORA-60）信息等。oracle

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

2.1 涉及物理结构的全部操做：例如建立、删除、重命名数据文件与联机重作日志文件的ALTER DATABASE命令，此外还涉及从新分配数据文件大小以及将数据文件联机与脱机的操做。ide

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

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;
/

View Code

可是这又一个问题，若是数据库宕机了的状况下，是没法获取这些错误信息，比方案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>

View Code

方案3：

查看此文：http://www.cnblogs.com/kerrycode/p/3168662.html

归档告警日志文件

告警日志文件若是不加管理的话，那么文件会持续增加，有时候文件会变得很是大，不利于读写。通常建议将告警日志按天归档，归档文件保留三个月（视状况而定），下面来看看将告警日志文件归档的两个Shell脚本：
---alert_log_archive.sh version 1


#*************************************************************************
#  FileName     :alert_log_archive.sh
#*************************************************************************
#  Author       :Kerry
#  CreateDate   :2013-07-02
#  blogs　　     :www.cnblogs.com/kerrycode
#  Description  :this script is made the alert log archived every day
#*************************************************************************

#! /bin/bash

date=`date +%Y%m%d`

alert_log_path="$ORACLE_BASE/admin/$ORACLE_SID/bdump"

alert_log_file="alert_$ORACLE_SID.log"

alert_arc_file="alert_$ORACLE_SID.log""."${date}

cd ${alert_log_path};


if [ ! -e "${alert_log_file}" ]; then
        echo "the alert log didn't exits, please check file path is correct!";
        exit;
fi


if [ -e ${alert_arc_file} ];then

        echo "the alert log file have been archived!"

else

        cat ${alert_log_file} >> ${alert_arc_file}

        cat /dev/null > ${alert_log_file}

fi
View Code
其实脚本1和脚本差异不大，仅仅是mv与cat >>的区别

alert_log_archive.sh version 2
#*************************************************************************
#  FileName     :alert_log_archive.sh
#*************************************************************************
#  Author       :Kerry
#  CreateDate   :2013-07-02
#  blogs　　     :www.cnblogs.com/kerrycode
#  Description  :this script is made the alert log archived every day
#*************************************************************************

#! /bin/bash

date=`date +%Y%m%d`

alert_log_path="$ORACLE_BASE/admin/$ORACLE_SID/bdump"

alert_log_file="alert_$ORACLE_SID.log"

alert_arc_file="alert_$ORACLE_SID.log""."${date}

cd ${alert_log_path};


if [ ! -e "${alert_log_file}" ]; then
        echo "the alert log didn't exits, please check file path is correct!";
        exit;
fi


if [ -e ${alert_arc_file} ];then

        echo "the alert log file have been archived!"

else

        mv ${alert_log_file}  ${alert_arc_file}

        cat /dev/null > ${alert_log_file}

fi
View Code
而后在crontab定时任务里面加上下面语句，天天23点59对告警日志进行归档。

[oracle@DB-Server scripts]$ crontab -l

# the alert log archived every day Add by kerry 2013-07-02

59 23 * * * /home/oracle/scripts/alert_log_archive.sh >/dev/null 2>$1

细心的朋友可能已经发现上面的脚本、配置错误了，我在部署测试的过程当中，是指定二十分钟执行一次，可是等了四十分钟，发现定时任务一次都没有执行，手工执行上面脚本是彻底没有问题的，最后仔细的检查一遍，竟然发现悲剧的发现时本身一时粗心将&符号写成了$,真是很二的一个错误

59 23 * * * /home/oracle/scripts/alert_log_archive.sh >/dev/null 2>$1

59 23 * * * /home/oracle/scripts/alert_log_archive.sh >/dev/null 2>&1

接下来测试发现脚本执行有问题，在crontab 里执行该shell脚本时，获取不到ORACLE的环境变量，这是由于crontab环境变量问题，Crontab的环境默认状况下并不包含系统中当前用户的环境。因此，你须要在shell脚本中添加必要的环境变量的设置，修改的脚本以下：

第十五章：Oracle12c 数据库 警告日志