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