從Oracle等數據庫遷移到國產數據庫上來，大家可能還有些不適應。如果遇到問題該怎么辦？如何去做分析，如何定位根因呢？

圖片

對于大多數國產數據庫而言，除了數據庫本身存在的問題或者BUG等，大多數的問題還是可以通過一些通用的手段來進行分析的。這兩天老白花了點時間梳理了一張思維導圖。下面我來簡單介紹一下這張導圖。

圖片

分析的第一步肯定是查看日志，數據庫日志永遠是故障定位最為重要的環節，因此查看數據庫日志是一切故障、性能分析的起點。有些日志問題可能很快就能幫你定位數據庫故障，不過有時候可能遇到了BUG，或者你根本看不懂國產數據庫的日志（某些國產分布式數據庫的日志是極難閱讀的），如果你的數據庫廠商提供比較及時的服務，將日志采集好發送給國產數據庫原廠售后人員是十分關鍵的。

有些時候遇到數據庫性能問題，也可以開啟慢日志來抓取相關SQL，不過開啟慢日志會帶來一定的開銷，因此只能在分析問題的短時間內開啟。

如果數據庫日志沒有發現問題，那么下一步就要做操作系統日志的分析。如果OS日志沒有發現問題，那么下一步就是做OS資源分析。

圖片

一般情況下OS資源使用率應該處于較為正常的范圍，如果有OS監控系統，能夠看到歷史數據，通過歷史數據的比對就更容易發現問題了。在OS資源分析的時候，更加注重于發現“異常”，而不是看絕對值。

對于內存，不能僅看內存使用率，內存使用率在LINUX系統中是一個指向性不強的指標。內存不可用率或者內存可用率的指向性更強。發現內存問題的另外一個方法是看系統中是否存在嚴重的換頁。如果內存資源存在問題，出現了換頁或者OOM KILLER，那么可以通過分析TOP 內存占用進程來找到可能存在的內存殺手。仔細查看MEMINFO文件，找出其中的問題關鍵是必須要做的事情。是CACHE占用內存過多了，還是沒有啟用大頁，導致頁表的內存占用過大。亦或是透明大頁導致的內存碎片化，引發了內存的性能問題？

IO問題十分典型的包括IO吞吐量過大、IO延時超標等。如果IO延時過大，那么就要分析后端存儲是否存在問題，多路徑是否出現過切換。這時候有個檢查項是容易被忽視的，那就是異常進程分析。如果D狀態的進程很多，而且長時間不消除，那么大概率是存儲系統的哪個地方出問題了。

CPU的情況比較復雜，不能僅看CPU使用率比較高就認定CPU引發了問題，還要看r隊列的大小（LINUX中稱為load,負載），如果R長期大于CPU線程數的2倍，那么CPU可能真的有瓶頸了，否則只能說系統負載較高，但是還不一定能引發性能問題。如果USR高，說明應用可能是CPU消耗過大的元兇，分析會話和TOP SQL就可以了。如果SYS過高，那么就比較復雜了。SPINLOCK，換頁，內存碎片，存儲系統故障，網絡故障，數據庫閂鎖爭用嚴重，達夢DSC集群爭用等都可能導致SYS CPU使用率異常（這里說的異常不一定是SYS CPU特別高，當CPU使用率總體不高，SYS占比過高的時候，也可能已經出現了系統性能異常了）。如果WIO過高，那么大概率是存儲出問題了。

圖片

如果OS資源沒有發現什么問題，那么我們就必須去從數據庫的角度找問題了。這方面也有一些數據庫通用的診斷方法。首先如果數據庫支持等待事件，而且等待事件相對是準確的，那么通過等待事件可以看出一些端倪。如果等待事件無法發現問題，那么接下來去看長事務和鎖就可以了。

如果這方面沒有問題，那么進一步做會話異常分析，大概率會發現問題。這里要注意的一個是會話執行SQL數量最多的SQL是最需要關注的也是容易被忽視的問題。會話的數量是否異常，活躍會話數量是否異常，會話來自的服務器分布情況是否異常，會話來自的應用程序模塊是否異常等等，都是判別會話是否異常的重要手段。

如果你的系統存在歷史會話信息（類似于Oracle ASH），那么恭喜你，你擁有了更為強大的分析手段。將數據庫會話分析的方法應用于歷史會話分析上，會有更加好的效果。

基于我今天介紹的方案，針對一個集中式國產數據庫，哪怕你以前沒有怎么接觸過，也可以輕松的進行故障、性能分析了。這套方案，基本上可以覆蓋80%以上的常見問題。大家如果有興趣可以在遇到問題的時候試一試。分布式數據庫的診斷方法類似，不過有更復雜的邏輯，等我有空的時候再畫一張圖吧。