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

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

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

圖片

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

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

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

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

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

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

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

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