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

圖片

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

圖片

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

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

如果數(shù)據(jù)庫日志沒有發(fā)現(xiàn)問題，那么下一步就要做操作系統(tǒng)日志的分析。如果OS日志沒有發(fā)現(xiàn)問題，那么下一步就是做OS資源分析。

圖片

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

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

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

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

圖片

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

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

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

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