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

圖片

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

圖片

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

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

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

圖片

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

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

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

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

圖片

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

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

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

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