告警日志檔案是一類特殊的跟蹤檔案（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目錄下的跟蹤檔案除了告警日志外都能删除，如果删除告警日志檔案有可能會産生意想不到的錯誤，我半信半疑，在測試伺服器删除告警日志，驗證後發現沒有什麼影響，系統會重新生成告警日志檔案（時間上不會立即生成告警日志檔案，而是當程序向告警日志寫入記錄時就會生成新的告警日志檔案）。
![小程式自定義button元件擷取使用者資訊（使用者授權登入）[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)