從問題分析的入口談國產資料庫與Oracle在可觀測性方面的差距

對於資料庫出現的複雜問題的分析往往是對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，不過在知識庫的內容上還有太大的差距。這是一個十分花錢也需要時間沉澱的工作，作為國產資料庫的使用者，是十分希望資料庫廠商加大這方面的投入的。