1. 程式人生 > >第十五章:Oracle12c 數據庫 警告日誌

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

closed 外部表 hid dbms bfile 歸納 echo ole leo


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

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:



歸檔告警日誌文件

告警日誌文件如果不加管理的話,那麽文件會持續增長,有時候文件會變得非常大,不利於讀寫。一般建議將告警日誌按天歸檔,歸檔文件保留三個月(視情況而定),下面來看看將告警日誌文件歸檔的兩個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 數據庫 警告日誌