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

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

從trace的分類上也分為immediate dump、ON-ERROR DUMP、變更運(yùn)行特性、附加輸出性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)問題時(shí)的內(nèi)在原因。

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

變更運(yùn)行特性的事件一般是用于修復(fù)某些BUG或者讓數(shù)據(jù)庫針對某種業(yè)務(wù)場景做一些運(yùn)行調(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也可以單獨(dú)在會話級設(shè)置。

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

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

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

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

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

圖片

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

latch c0000000c2df3b70的持有者也是41號進(jìn)程。因此41號進(jìn)程是下一步分析的要點(diǎn)。

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

圖片

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

圖片

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

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