ORACLE告警日誌文件

告警日誌介紹

 

告警日誌文件是一類特殊的跟蹤文件（trace file）。告警日誌文件命名通常爲alert_<SID>.log，其中SID爲ORACLE數據庫實例名稱。數據庫告警日誌是按時間順序記錄message和錯誤信息。

 

告警日誌位置

在ORACLE 10g中，BACKGROUND_DUMP_DEST參數肯定了告警日誌的位置，可是告警日誌的文件名沒法修改，告警日誌的名稱爲：alert_<SID>.log ,其中<SID>是實例的名稱。BACKGROUND_DUMP_DEST參數是動態的。

SQL> show parameter background_dump_dest;

NAME                       TYPE        VALUE

--------------------- ----------- ------------------------------

background_dump_dest   string      /u01/app/oracle/admin/GSP/bdump

SQL> 

告警日誌以及全部後臺跟蹤文件都會被寫至BACKGROUND_DUMP_DEST參數所指定的目錄。

在ORACLE 11g 以及ORACLE 12c中，告警日誌文件的位置有了變化。主要是由於引入了ADR(Automatic Diagnostic Repository:一個存放數據庫診斷日誌、跟蹤文件的目錄)，關於ADR對應的目錄位置能夠經過查看v$diag_info系統視圖。以下所示（ORACLE 12c ）

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

11 rows selected.

如上所示，Diag Trace對應的目錄爲文本格式的告警日誌文件所在的目錄,而Diag Alert對應的目錄爲XML格式的警告日誌(對應爲log_x.xml)

[oracle@gettestlnx01 trace]$ pwd

/u01/app/oracle/diag/rdbms/ignite/epps/trace

[oracle@gettestlnx01 trace]$ ls alert_epps.log 

alert_epps.log

[oracle@gettestlnx01 trace]$ cd ../alert/

[oracle@gettestlnx01 alert]$ pwd

/u01/app/oracle/diag/rdbms/ignite/epps/alert

[oracle@gettestlnx01 alert]$ ls

log_1.xml  log_2.xml  log_3.xml  log_4.xml  log_5.xml  log_6.xml  log_7.xml  log_8.xml  log_9.xml  log.xml

 

告警日誌內容：

那麼告警日誌很是關鍵與重要，那麼告警日誌裏面包含了那些內容信息呢？告警日誌包含了下面一些內容的信息。像一些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目錄下的跟蹤文件除了告警日誌外都能刪除，若是刪除告警日誌文件有可能會產生意想不到的錯誤，我半信半疑，在測試服務器刪除告警日誌，驗證後發現沒有什麼影響，系統會從新生成告警日誌文件（時間上不會當即生成告警日誌文件，而是當進程向告警日誌寫入記錄時就會生成新的告警日誌文件）。

 

參考資料：

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1352202934074