昨天我發(fā)了一篇診斷事件的文章，建議國產(chǎn)數(shù)據(jù)庫參考一下Oracle的診斷事件，能夠為用戶提供一些常用的診斷事件。隨后有朋友問我，Oracle都有哪些診斷事件，能不能寫篇文章歸類分析一下，他們也好參考。今天我就簡單介紹一下Oracle等待事件的總體情況，特別重點介紹一些與數(shù)據(jù)庫優(yōu)化相關(guān)的診斷事件。

Oracle的診斷事件主要用于四個方面，1）根據(jù)需要DUMP數(shù)據(jù)用于分析；2）當(dāng)某個ORA錯誤發(fā)生時產(chǎn)生DUMP；3）修改數(shù)據(jù)庫運行特性；4）在數(shù)據(jù)庫運行的時候獲取額外的TRACE信息。

從trace的分類上也分為immediate dump、ON-ERROR DUMP、變更運行特性、附加輸出性trace等幾種。

Immediate dump主要是用于做一些當(dāng)前數(shù)據(jù)、內(nèi)存的DUMP，用于分析問題。比如：alter session set events 'immediate  trace name controlf level 10';用于將控制文件DUMP出來，可以用于分析控制文件里的一些信息，并用于定位ORACLE的BUG，或者用于分析數(shù)據(jù)庫出現(xiàn)問題時的內(nèi)在原因。

ON-ERROR DUMP是為了獲得數(shù)據(jù)庫錯誤的更為詳細(xì)的信息，從而用于分析數(shù)據(jù)庫的某個錯誤的更深層次的原因。比如event = "60 trace name errorstack level 1"可以在數(shù)據(jù)庫出現(xiàn)死鎖時生成LEVEL 1級的TRACE。某些系統(tǒng)如果頻繁出現(xiàn)死鎖，動不動把TRACE寫滿了，那么也可以用這個事件關(guān)閉ORA-60產(chǎn)生的TRACE。

變更運行特性的事件一般是用于修復(fù)某些BUG或者讓數(shù)據(jù)庫針對某種業(yè)務(wù)場景做一些運行調(diào)整，從而滿足用戶的需求。

第四類TRACE是要求數(shù)據(jù)庫輸出更多的調(diào)試信息，從而分析某些問題。昨天說的10046、10053等TRACE都是此類TRACE。

TRACE可以在系統(tǒng)級設(shè)置，也可以在會話級設(shè)置，上面這張圖說明了系統(tǒng)級TRACE和會話級TRACE之間的關(guān)系。會話會繼承系統(tǒng)級TRACE，也可以覆蓋系統(tǒng)級TRACE的設(shè)置。某些TRACE也可以單獨在會話級設(shè)置。

不管TRACE的能力有多強，對于運維人員來說，TRACE的主要作用是兩個：故障診斷和性能優(yōu)化。常見的可用TRACE進行分析的故障報考實例或者進程crash （Internal errors /ora-600/ORA-7445、OS與RDBMS之間的兼容性引發(fā)的問題、Segmentation violations, UNIX/LINUX的bus errors 、WINDOWS的Access violations等）、可能由于等待某個事件而 hang 住數(shù)據(jù)庫或者某些會話、進程陷入非正常的循環(huán)（loop）、系統(tǒng)變慢等等。

如果沒有出現(xiàn)HANG或者LOOP現(xiàn)象，那么很可能是數(shù)據(jù)庫系統(tǒng)出現(xiàn)了性能問題，性能優(yōu)化可以從硬件、DB、應(yīng)用等層面進行，此時除了TRACE外，應(yīng)該同時使用AWR/ADDM進行基礎(chǔ)性能分析，EVENT 10046和TKPROF是很好的應(yīng)用性能分析工具，也是十分常用的性能診斷工具。

當(dāng)數(shù)據(jù)庫出現(xiàn)HANG或者LOOPING的時候，各級STATE DUMP（SYSTEM STATE DUMP/PROCESS STATE DUMP）都是十分重要的分析工具。此外HANGANALYZE也是一個十分有效的TRACE工具。此外V$SESSION_WAIT, V$LOCK, V$LATCH, V$LATCHHOLDER這些系統(tǒng)視圖也是很好的輔助分析工具。

比如某個數(shù)據(jù)庫HANG住，被迫重啟，需要了解為什么會HANG住。一般情況下我們可以查找diag的TRACE，在Oracle 10g之后，當(dāng)數(shù)據(jù)庫出現(xiàn)HANG或者十分緩慢的時候，DIAG會自動產(chǎn)生一個SYSTEM STATE DUMP或者HANGANALYZE，這個可以作為事后分析問題的十分重要的素材。

此時的分析還是要從分析故障的起點ALERT LOG中去查找答案。這是很多缺乏經(jīng)驗的DBA經(jīng)常犯的錯誤，那就是當(dāng)問題出現(xiàn)的時候沒有第一時間去查看ALERT LOG，而是盲目的去做各種分析。在這個案例中，ALERT LOG里無明顯線索，只有一個SYSTEM STATE DUMP可供分析，那么使用ass.awk分析SYSTEM STATE DUMP可能可以找到一些供下一步分析的蛛絲馬跡，并了解當(dāng)時系統(tǒng)的總體情況。

圖片

上面是ass分析的結(jié)果可以看出以下的信息：1）BLOCKER未知，latch c0000000c2df3b70可能是分析的關(guān)鍵；2）存在一個PR鎖，說明有進程正在啟動，PR鎖的持有者是41號進程，

latch c0000000c2df3b70的持有者也是41號進程。因此41號進程是下一步分析的要點。

通過在SYSTEM STATE DUMP中搜索發(fā)現(xiàn)41號進程是MMON進程，正在等待某個子進程啟動完畢。因此可以得到信息，下一步分析的要點是查看MMON正在啟動哪個進程。

圖片

OSP REQ HOLDER對象中，我們看到了MMON在啟動m000的時候，進程啟動狀態(tài)是“DEAD”。我們獲得了一個十分重要的信息。mmon是否持有了某個資源，hang住了本系統(tǒng)，大量會話等待log file switch(checkpoint incomplete)，需要查看ckpt的PROCESS STATE DUMP。

圖片

從上面的信息可以看出，阻塞CKPT的會話是fbf5e4278，就是mmon本身。至此，monn啟動m000失敗的原因還需要進一步排查，不過從上面的分析我們可以獲得足夠的信息了。故障原因是mmon啟動m000失敗導(dǎo)致了mmon HANG住，mmon持有的pr鎖阻塞了ckpt

ckpt阻塞了log file switch。這個問題在宕機4小時前故障就發(fā)生了，同時xit中出現(xiàn)了大量的ROW CACHE LOCK WAIT TOO LONG的告警。如果我們能夠及時發(fā)現(xiàn)這個告警，殺掉mmon或者調(diào)整statistics_level可解決問題，避免宕機出現(xiàn)。