昨天我發(fā)了一篇診斷事件的文章，建議國(guó)產(chǎn)數(shù)據(jù)庫(kù)參考一下Oracle的診斷事件，能夠?yàn)橛脩籼峁┮恍┏Ｓ玫脑\斷事件。隨后有朋友問(wèn)我，Oracle都有哪些診斷事件，能不能寫(xiě)篇文章歸類分析一下，他們也好參考。今天我就簡(jiǎn)單介紹一下Oracle等待事件的總體情況，特別重點(diǎn)介紹一些與數(shù)據(jù)庫(kù)優(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ù)庫(kù)運(yùn)行特性；4）在數(shù)據(jù)庫(kù)運(yùn)行的時(shí)候獲取額外的TRACE信息。

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

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

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

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

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

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

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

如果沒(méi)有出現(xiàn)HANG或者LOOP現(xiàn)象，那么很可能是數(shù)據(jù)庫(kù)系統(tǒng)出現(xiàn)了性能問(wè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ù)庫(kù)出現(xiàn)HANG或者LOOPING的時(shí)候，各級(jí)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ù)庫(kù)HANG住，被迫重啟，需要了解為什么會(huì)HANG住。一般情況下我們可以查找diag的TRACE，在Oracle 10g之后，當(dāng)數(shù)據(jù)庫(kù)出現(xiàn)HANG或者十分緩慢的時(shí)候，DIAG會(huì)自動(dòng)產(chǎn)生一個(gè)SYSTEM STATE DUMP或者HANGANALYZE，這個(gè)可以作為事后分析問(wèn)題的十分重要的素材。

此時(shí)的分析還是要從分析故障的起點(diǎn)ALERT LOG中去查找答案。這是很多缺乏經(jīng)驗(yàn)的DBA經(jīng)常犯的錯(cuò)誤，那就是當(dāng)問(wèn)題出現(xiàn)的時(shí)候沒(méi)有第一時(shí)間去查看ALERT LOG，而是盲目的去做各種分析。在這個(gè)案例中，ALERT LOG里無(wú)明顯線索，只有一個(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鎖，說(shuō)明有進(jìn)程正在啟動(dòng)，PR鎖的持有者是41號(hào)進(jìn)程，

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

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

圖片

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

圖片

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

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