對(duì)于數(shù)據(jù)庫出現(xiàn)的復(fù)雜問題的分析往往是對(duì)DBA的嚴(yán)峻考驗(yàn)，哪怕在要求盡可能把問題在應(yīng)用層面解決號(hào)稱不怎么需要運(yùn)維的MySQL數(shù)據(jù)庫上也遇到過spinlock、網(wǎng)絡(luò)延時(shí)不穩(wěn)定、隨機(jī)熵等十分棘手的問題。這些問題現(xiàn)在廣為人知了，所以可能發(fā)現(xiàn)和解決起來也不覺得有多難了，早幾年如果你遇到這些問題，還真的不知道該如何去分析。

自從去O以后，使用費(fèi)Oracle數(shù)據(jù)庫的用戶可能覺得大多數(shù)問題都出在SQL上，因此讓開發(fā)人員多優(yōu)化優(yōu)化應(yīng)用就能解決數(shù)據(jù)庫的問題了。今年年初的一個(gè)數(shù)據(jù)庫大會(huì)上，我看到一個(gè)團(tuán)隊(duì)做了一個(gè)SQL與CPU資源關(guān)聯(lián)分析的監(jiān)控系統(tǒng)，在系統(tǒng)中計(jì)算CPU波動(dòng)與SQL語句執(zhí)行次數(shù)等指標(biāo)的關(guān)聯(lián)性，從而找出可能引發(fā)CPU問題的SQL語句?；貋砗?，我也讓公司的弟兄們做了一個(gè)類似的工具放在D-SMART里，不過似乎效果一般。因?yàn)樵诤唵蔚那闆r下，TOP SQL預(yù)警可能更有效，而在復(fù)雜的情況下，引發(fā)系統(tǒng)問題的不是一條SQL或者甚至不是SQL。

復(fù)雜問題往往與SQL并不強(qiáng)相關(guān)，而分析SQL相關(guān)的問題的方法相對(duì)簡單。實(shí)際上DBA需要掌握更多的分析非SQL引發(fā)問題的技巧。因?yàn)閿?shù)據(jù)庫系統(tǒng)極其復(fù)雜，找到分析問題的入口往往是最終定位問題的關(guān)鍵。在以前使用Oracle數(shù)據(jù)庫的時(shí)候，因?yàn)镺racle強(qiáng)大的可觀測(cè)性能力以及豐富的診斷工具與接口，讓分析十分體系化，也相對(duì)簡單。    

圖片

上圖是我梳理的Oracle數(shù)據(jù)庫運(yùn)維中的一些常用問題診斷入口，大部分可以從ALERT LOG、AWR、ASH或者v$session這幾個(gè)常用工具進(jìn)行分析。雖然一些復(fù)雜問題的分析依然需要較高的技術(shù)水平和豐富的經(jīng)驗(yàn)，不過對(duì)于運(yùn)維專家來說，入口相對(duì)是清晰的，十分便于開展問題分析。    

再來看看非Oracle數(shù)據(jù)庫，包括國產(chǎn)數(shù)據(jù)庫和開源數(shù)據(jù)庫。除了慢SQL這個(gè)問題診斷點(diǎn)比較清晰之外，其他的問題診斷似乎都比較麻煩。其主要原因是“等待事件”的豐富性與指向的準(zhǔn)確性都十分不足。就像昨天我發(fā)的那個(gè)OB優(yōu)化的例子，系統(tǒng)都出現(xiàn)十分嚴(yán)重的問題了，等待事件上好像看不到任何蛛絲馬跡。雖然現(xiàn)在幾乎所有的國產(chǎn)數(shù)據(jù)庫都提供類似Oracle AWR報(bào)告的診斷報(bào)告，但是我看過的幾乎所有的國產(chǎn)數(shù)據(jù)庫的類AWR報(bào)告后，覺得除了慢SQL外，這分報(bào)告幾乎沒有任何用處。其主要原因有以下幾點(diǎn)。

首先，等待事件的水平不足，導(dǎo)致等待事件這種最能體現(xiàn)出數(shù)據(jù)庫當(dāng)前運(yùn)行狀態(tài)的可觀測(cè)性體系無法發(fā)揮作用。其中原因一方面是等待事件的數(shù)量不足，統(tǒng)計(jì)不準(zhǔn)確，指向性也不明確。另外一方面是等待事件的含義十分模糊，DBA根本無從知道某個(gè)等待事件意味著什么。實(shí)際上Oracle的OWI剛剛開始提供的時(shí)候，DBA們也不大喜歡使用AWR的前身statspack報(bào)告的。其實(shí)二十多年前，我從Oracle 7.3.4開始就在使用statspack報(bào)告了，這個(gè)從Oracle 8.0才正式提供的功能可以backport到734中。這也讓我對(duì)于分析Oracle數(shù)據(jù)庫的性能問題上能比別人看到更多的東西。不過當(dāng)時(shí)我給很多DBA推薦過這個(gè)工具，大家用了之后并沒有覺得這個(gè)報(bào)告有什么用處，其中最主要的原因是大家對(duì)于等待事件和stats的含義并不了解。隨著Oracle owi知識(shí)的不斷推廣，大家對(duì)這方面的認(rèn)知也更加清晰了，再加上MOS上大量的NOTES可以提供很好的解釋，AWR才變得越來越流行了。目前國產(chǎn)數(shù)據(jù)庫也存在這樣的問題，其知識(shí)的封閉性讓大家無法理解等待事件和系統(tǒng)中的 STATS的含義，從而讓他們提供的AWR報(bào)告變成了雞肋。

其次是指標(biāo)體系不完善，無法準(zhǔn)確的反映出系統(tǒng)的性能、負(fù)載、故障、異常等情況。指標(biāo)體系是用于分析數(shù)據(jù)庫復(fù)雜問題的關(guān)鍵，如果某些數(shù)據(jù)庫的問題都沒有指標(biāo)可以體現(xiàn)的時(shí)候，那么這些指標(biāo)就無法用于分析了。目前的國產(chǎn)數(shù)據(jù)庫的絕大多數(shù)指標(biāo)都是體現(xiàn)負(fù)載的，缺少很多性能相關(guān)的指標(biāo)，這也導(dǎo)致了指標(biāo)無法在問題定位中發(fā)揮較大的作用。    

第三是僅僅羅列數(shù)據(jù)，沒有可參考的建議。Oracle的STATSPACK在734和8.0、8i的時(shí)候，主要也是羅列數(shù)據(jù)，和現(xiàn)在國產(chǎn)數(shù)據(jù)庫提供的AWR報(bào)告類似。從Oracle 9i開始有了一些建議，到10g/11g其建議也越來越有價(jià)值，數(shù)據(jù)也更加明晰，也變得更加易用了。

少了AWR/ASH這些強(qiáng)大的問題分析入口，我們分析國產(chǎn)數(shù)據(jù)庫的問題，只能首選數(shù)據(jù)庫日志了。在分析昨天的那個(gè)OB問題的時(shí)候，OB的同學(xué)提供的日志分析方法也給了我們一定的幫助，讓我們了解到某個(gè)MERGE任務(wù)是還在進(jìn)行中的。只不過這些日志要在WDIAG級(jí)別才可以使用，在生產(chǎn)環(huán)境中我們是希望關(guān)閉DIAG級(jí)別的日志的。另外一個(gè)問題是，在缺乏原廠工程師支持的情況下，我們幾乎無法閱讀國產(chǎn)數(shù)據(jù)庫提供的十分奇葩的日志信息。錯(cuò)誤信息可能會(huì)與實(shí)際問題相差萬里，或者不知所云，而且也沒有類似Oracle MOS這樣的平臺(tái)可以查找，這些問題讓我們把日志作為分析問題的入口也變得不那么靠譜。在Oracle運(yùn)維的時(shí)代，我給公司的年輕人培訓(xùn)的第一堂課一定是“數(shù)據(jù)庫問題分析，必須從ALERT LOG開始”，這句話恐怕得改改了。

說了半天，可能有朋友著急了：“那么國產(chǎn)數(shù)據(jù)庫遇到復(fù)雜問題難道就沒有分析手段了嗎？”。也不完全如此，昨天我說的perf工具就是一個(gè)十分好的分析工具，昨天的那個(gè)案例最終也是perf最終幫助定位了問題。如果我剛開始的時(shí)候就使用了這個(gè)工具，可能問題早就被反推定位了。通過這個(gè)案例也給了我一個(gè)新的知識(shí)，針對(duì)一些國產(chǎn)數(shù)據(jù)庫的復(fù)雜問題的分析，如果沒有找到好的入口，那么一定要先用perf等OS工具去分析一下?！暗裙ぞ摺币馕吨€有其他一些工具，比如說pstack、top、ntop、netstat等。

使用這些數(shù)據(jù)庫之外的OS工具做分析，對(duì)DBA的要求比較高，從一些更加難懂的數(shù)據(jù)中發(fā)現(xiàn)問題，這需要豐富的經(jīng)驗(yàn)加持才行。因此我們還是希望國產(chǎn)數(shù)據(jù)庫廠商能夠在這些方面提升能力。一方面是把數(shù)據(jù)庫自身的可觀測(cè)性能力做好做強(qiáng)，另外一方面就是盡快構(gòu)建起類似Oracle Mos能力的知識(shí)庫。目前雖然已經(jīng)有一些數(shù)據(jù)庫廠商開始對(duì)外提供免費(fèi)的知識(shí)庫服務(wù)了，其形式也是學(xué)習(xí)了MOS，不過在知識(shí)庫的內(nèi)容上還有太大的差距。這是一個(gè)十分花錢也需要時(shí)間沉淀的工作，作為國產(chǎn)數(shù)據(jù)庫的用戶，是十分希望數(shù)據(jù)庫廠商加大這方面的投入的。