告警日誌介紹

shilei1發表於2017-03-08


 

告警日誌檔案是一類特殊的跟蹤檔案（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.

clip_image001

如上所示，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目錄下的跟蹤檔案除了告警日誌外都能刪除，如果刪除告警日誌檔案有可能會產生意想不到的錯誤，我半信半疑，在測試伺服器刪除告警日誌，驗證後發現沒有什麼影響，系統會重新生成告警日誌檔案（時間上不會立即生成告警日誌檔案，而是當程式向告警日誌寫入記錄時就會生成新的告警日誌檔案）。

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/196700/viewspace-2134961/，如需轉載，請註明出處，否則將追究法律責任。

相關文章