第十五章：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腳本中添加必要的環境變量的設置，修改的腳本以下：