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

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

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

圖片

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

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

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

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

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

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

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

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