ORACLE告警日志檔案

告警日志介紹  

告警日志檔案是一類特殊的跟蹤檔案（trace file）。告警日志檔案命名一般為alert_<SID>.log，其中SID為ORACLE資料庫執行個體名稱。資料庫告警日志是按時間順序記錄message和錯誤資訊。  

告警日志位置  

在ORACLE 10g中，BACKGROUND_DUMP_DEST參數确定了告警日志的位置，但是告警日志的檔案名無法修改，告警日志的名稱為：alert_<SID>.log ,其中<SID>是執行個體的名稱。BACKGROUND_DUMP_DEST參數是動态的。

告警日志以及所有背景跟蹤檔案都會被寫至BACKGROUND_DUMP_DEST參數所指定的目錄。

在ORACLE 11g 以及ORACLE 12c中，告警日志檔案的位置有了變化。主要是因為引入了ADR(Automatic Diagnostic Repository:一個存放資料庫診斷日志、跟蹤檔案的目錄)，關于ADR對應的目錄位置可以通過檢視v$diag_info系統視圖。如下所示（ORACLE 12c ）

如上所示，Diag Trace對應的目錄為文本格式的告警日志檔案所在的目錄,而Diag Alert對應的目錄為XML格式的警告日志(對應為log_x.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語句查詢告警日志的資訊。

但是這又一個問題，如果資料庫當機了的情況下，是無法擷取這些錯誤資訊，比方案3（從作業系統監控告警日志）對比，有些特定場景不适用。另外有一定不足之處，就是日志檔案比較大的時候，監控告警日志資訊比較頻繁的時候，會産生不必要的IO操作。

方案2：通過外部表來檢視告警日志檔案的内容。相當的友善。然後也是使用定制SQL語句來查詢錯誤資訊。

告警日志歸檔

告警日志如果不及時歸檔，時間長了，告警日志檔案會變得非常大，檢視、讀取告警日志會引起額外的IO開銷。是以一般應該按天歸檔告警日志檔案，保留一段時間（例如 90天），超過規定時間的删除。

告警日志是否可以删除呢？ 以前有位同僚說background_dump_dest目錄下的跟蹤檔案除了告警日志外都能删除，如果删除告警日志檔案有可能會産生意想不到的錯誤，我半信半疑，在測試伺服器删除告警日志，驗證後發現沒有什麼影響，系統會重新生成告警日志檔案（時間上不會立即生成告警日志檔案，而是當程序向告警日志寫入記錄時就會生成新的告警日志檔案）。

本文轉自xiaocao1314051CTO部落格，原文連結：http://blog.51cto.com/xiaocao13140/1932956 ，如需轉載請自行聯系原作者