昨天我發了一篇診斷事件的文章，建議國產數據庫參考一下Oracle的診斷事件，能夠為用戶提供一些常用的診斷事件。隨后有朋友問我，Oracle都有哪些診斷事件，能不能寫篇文章歸類分析一下，他們也好參考。今天我就簡單介紹一下Oracle等待事件的總體情況，特別重點介紹一些與數據庫優化相關的診斷事件。
Oracle的診斷事件主要用于四個方面，1）根據需要DUMP數據用于分析；2）當某個ORA錯誤發生時產生DUMP；3）修改數據庫運行特性；4）在數據庫運行的時候獲取額外的TRACE信息。
從trace的分類上也分為immediate dump、ON-ERROR DUMP、變更運行特性、附加輸出性trace等幾種。
Immediate dump主要是用于做一些當前數據、內存的DUMP，用于分析問題。比如：alter session set events 'immediate trace name controlf level 10';用于將控制文件DUMP出來，可以用于分析控制文件里的一些信息，并用于定位ORACLE的BUG，或者用于分析數據庫出現問題時的內在原因。
ON-ERROR DUMP是為了獲得數據庫錯誤的更為詳細的信息，從而用于分析數據庫的某個錯誤的更深層次的原因。比如event = "60 trace name errorstack level 1"可以在數據庫出現死鎖時生成LEVEL 1級的TRACE。某些系統如果頻繁出現死鎖，動不動把TRACE寫滿了，那么也可以用這個事件關閉ORA-60產生的TRACE。
變更運行特性的事件一般是用于修復某些BUG或者讓數據庫針對某種業務場景做一些運行調整，從而滿足用戶的需求。
第四類TRACE是要求數據庫輸出更多的調試信息，從而分析某些問題。昨天說的10046、10053等TRACE都是此類TRACE。
TRACE可以在系統級設置，也可以在會話級設置，上面這張圖說明了系統級TRACE和會話級TRACE之間的關系。會話會繼承系統級TRACE，也可以覆蓋系統級TRACE的設置。某些TRACE也可以單獨在會話級設置。
不管TRACE的能力有多強，對于運維人員來說，TRACE的主要作用是兩個：故障診斷和性能優化。常見的可用TRACE進行分析的故障報考實例或者進程crash （Internal errors /ora-600/ORA-7445、OS與RDBMS之間的兼容性引發的問題、Segmentation violations, UNIX/linux的bus errors 、windows的Access violations等）、可能由于等待某個事件而 hang 住數據庫或者某些會話、進程陷入非正常的循環（loop）、系統變慢等等。
如果沒有出現HANG或者LOOP現象，那么很可能是數據庫系統出現了性能問題，性能優化可以從硬件、DB、應用等層面進行，此時除了TRACE外，應該同時使用AWR/ADDM進行基礎性能分析，EVENT 10046和TKPROF是很好的應用性能分析工具，也是十分常用的性能診斷工具。
當數據庫出現HANG或者LOOPING的時候，各級STATE DUMP（SYSTEM STATE DUMP/PROCESS STATE DUMP）都是十分重要的分析工具。此外HANGANALYZE也是一個十分有效的TRACE工具。此外V$SESSION_WAIT, V$LOCK, V$LATCH, V$LATCHHOLDER這些系統視圖也是很好的輔助分析工具。
比如某個數據庫HANG住，被迫重啟，需要了解為什么會HANG住。一般情況下我們可以查找diag的TRACE，在Oracle 10g之后，當數據庫出現HANG或者十分緩慢的時候，DIAG會自動產生一個SYSTEM STATE DUMP或者HANGANALYZE，這個可以作為事后分析問題的十分重要的素材。
此時的分析還是要從分析故障的起點ALERT LOG中去查找答案。這是很多缺乏經驗的DBA經常犯的錯誤，那就是當問題出現的時候沒有第一時間去查看ALERT LOG，而是盲目的去做各種分析。在這個案例中，ALERT LOG里無明顯線索，只有一個SYSTEM STATE DUMP可供分析，那么使用ass.awk分析SYSTEM STATE DUMP可能可以找到一些供下一步分析的蛛絲馬跡，并了解當時系統的總體情況。
圖片
上面是ass分析的結果可以看出以下的信息：1）BLOCKER未知，latch c0000000c2df3b70可能是分析的關鍵；2）存在一個PR鎖，說明有進程正在啟動，PR鎖的持有者是41號進程，
latch c0000000c2df3b70的持有者也是41號進程。因此41號進程是下一步分析的要點。
通過在SYSTEM STATE DUMP中搜索發現41號進程是MMON進程，正在等待某個子進程啟動完畢。因此可以得到信息，下一步分析的要點是查看MMON正在啟動哪個進程。
圖片
OSP REQ HOLDER對象中，我們看到了MMON在啟動m000的時候，進程啟動狀態是“DEAD”。我們獲得了一個十分重要的信息。mmon是否持有了某個資源，hang住了本系統，大量會話等待log file switch(checkpoint incomplete)，需要查看ckpt的PROCESS STATE DUMP。
圖片
從上面的信息可以看出，阻塞CKPT的會話是fbf5e4278，就是mmon本身。至此，monn啟動m000失敗的原因還需要進一步排查，不過從上面的分析我們可以獲得足夠的信息了。故障原因是mmon啟動m000失敗導致了mmon HANG住，mmon持有的pr鎖阻塞了ckpt
ckpt阻塞了log file switch。這個問題在宕機4小時前故障就發生了，同時xit中出現了大量的ROW CACHE LOCK WAIT TOO LONG的告警。如果我們能夠及時發現這個告警，殺掉mmon或者調整statistics_level可解決問題，避免宕機出現。
