第十五章:Oracle12c 數據庫 警告日志


 

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

         Oracle 12c環境下查詢,alert日志並不在bdump目錄下,看到網上和書上都寫着可以通過初始化參數background_dump_dest來查看alter日志路徑,還說警告日志文件的缺省位置是%Oracle_base%\admin\orcl\bdump,其實12c中,上述路徑都不是真正存放警告日志的路徑。

真是路徑是要需要通過v$diag_info視圖來查詢,為什么呢?

          因為在ORACLE 12c中,引入了ADR(Automatic Diagnostic Repository(自動診斷倉庫):一個存放數據庫診斷日志、跟蹤文件的目錄,關於ADR對應的目錄位置可以通過查看v$diag_info系統視圖。其實11g中也有v$diag_inifo,說是可以直接通過show parameter background_dump_dest來查看警告日志路徑,但我沒有測試過。

下面我是我本機測試結果,數據庫版本的是12.2.0.1

 

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)信息等。

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;
/
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腳本中添加必要的環境變量的設置,修改的腳本如下:


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM