DBA在運維工作中遇到最難的問題是如何判斷數(shù)據(jù)庫是否存在某個問題，特別是在國產(chǎn)數(shù)據(jù)庫大行其道的今天，這方面的知識都需要重新構(gòu)建。DBA能力的提升也正是判斷能力提升所加持的，今天我們就來聊聊這方面的問題。

圖片

對于各個階段的DBA分析問題的主要方法，我簡單總結(jié)一下，大概有四個階段，每前進(jìn)到一個新的階段都說明DBA在能力上的斷崖式提升。最初的時候，他們是根據(jù)現(xiàn)象來分析問題的。某個現(xiàn)象遇到過，那么就容易解決，如果沒遇到過，可能就抓瞎了。

圖片

在這個階段遇到問題，首先根據(jù)現(xiàn)象去腦子里分析，是否曾經(jīng)遇到過類似案例，如果沒有，那么只能去網(wǎng)上搜索，再解決不了，就只能去向高手咨詢了。這是一個DBA技能的初級階段，還沒有形成比較有價值的知識庫，因此解決問題往往要憑運氣。這是DBA靠天吃飯的階段。

圖片

隨著DBA的能力的提升，分析問題不再是憑運氣了。因為中級的DBA 已經(jīng)對數(shù)據(jù)庫的一些基本性的原理有所了解，因此不再僅僅依靠表象來分析問題，可以通過對內(nèi)在原理的思考定位問題了。這個階段中，指標(biāo)是十分關(guān)鍵的東西。某些指標(biāo)異常說明了什么，哪怕自己還不是很清楚，也知道通過一些渠道去找到比較靠譜的答案了。

在這個階段中，唯一麻煩的就是，如何判斷某個指標(biāo)的正常與否，在這方面的積累還不夠，因此判斷問題的準(zhǔn)確性還不夠。有時候分析問題如水銀瀉地，有時候又像遇到一個堰塞湖一樣前進(jìn)不得。

圖片

高級DBA對于上面的問題有比較標(biāo)準(zhǔn)的解決方案，那就是通過基線來分析問題。

圖片

什么是基線呢？說起基線，可能有很多朋友在腦子里立馬會浮現(xiàn)出一張指標(biāo)的折線圖，上下各有一條線，這是狹義的“基線”，不過并不是我今天想和大家分享的“基線”。我個人認(rèn)為“從數(shù)據(jù)庫運維的角度就系統(tǒng)而言，基線-BASELINE是某個運行狀態(tài)在某個時間上的快照”，某個指標(biāo)、某個運維經(jīng)驗、某個現(xiàn)象都可以成為運維基線；對于DBA，有價值的基線來自于長期運維的經(jīng)驗，并非僅僅對于某個指標(biāo)的學(xué)習(xí)和理解。基線十分重要，因為基線是用于判別某個指標(biāo)甚至某個現(xiàn)象是否正常的重要依據(jù)。

基線的積累十分困難，需要DBA經(jīng)過長期的工作與思考才能逐漸豐富起來。哪些指標(biāo)對于分析哪些問題有幫助，哪些基線的合理范圍在哪個區(qū)間，哪些基線出現(xiàn)異常后可以使用的分析溯源方案有哪些，隨著這些運維知識的不斷積累，DBA的能力就會大幅提升。能夠很好地利用基線去分析問題，是一個高級DBA的主要特征。

不過有些時候，基線也不見得能發(fā)揮作用了。比如有人問你某個系統(tǒng)，在2萬IOPS下，IO延時是5毫秒，存儲系統(tǒng)的狀態(tài)是好是壞？某臺服務(wù)器，HTTPS請求達(dá)到10萬/秒，CPU使用率是20%，合理不合理？某個Oracle 數(shù)據(jù)庫的library cache pin 等待時間是50毫秒，系統(tǒng)共享池是否存在問題？當(dāng)前的系統(tǒng)，數(shù)據(jù)表空間會不會在3個月內(nèi)用滿？

要回答這些問題，僅僅依靠基線就不夠了，這需要容量方面的知識。利用容量進(jìn)行分析，不僅僅考慮基線的問題，還需要考慮系統(tǒng)的總體負(fù)載能力，考慮數(shù)據(jù)庫標(biāo)準(zhǔn)操作產(chǎn)生的資源消耗情況，考慮不同硬件之間的容量差異，考慮信息系統(tǒng)長期發(fā)展的可持續(xù)問題。如果你已經(jīng)積累了足以應(yīng)對日常運維工作中的容量知識，那么恭喜你，在這個領(lǐng)域內(nèi)，你已經(jīng)是專家級別的存在了。

圖片

比如說有這樣一個案例，如上圖的AWR數(shù)據(jù)。有一個系統(tǒng)，8月2日CPU從早上7點30開始到下午5點30都基本上處于100%，平時這個系統(tǒng)的CPU使用率不超過40%，8月3日起未見異常。如果DBA能夠清晰地描述出上述問題，說明他已經(jīng)初步掌握了基線分析的方法。我們?nèi)绻龠M(jìn)一步利用基線的知識做分析，是可以完成問題定位的。

圖片

不過實際上，分析工作沒那么簡單，因為導(dǎo)致出現(xiàn)上述現(xiàn)象的可能性很多。我們需要利用自己所掌握的知識去做排除。上述問題，僅僅能夠依靠現(xiàn)象進(jìn)行分析的朋友可能就無從入手了。

圖片

而對于掌握了根據(jù)指標(biāo)去分析問題的朋友首先會看到Library cache pin/lock等待事件延時很高。很容易就認(rèn)為共享池問題可能是問題的關(guān)鍵。

圖片

而更高一層次的DBA懂得了以基線分析作為分析問題的方法。他會發(fā)現(xiàn)共享池問題雖然存在，但是占比不高，邏輯讀過高可能對CPU使用率過高產(chǎn)生的影響更大。他通過比對正常與非正常時段的邏輯讀指標(biāo)，就可以找到更加準(zhǔn)確的分析路徑。

懂得容量分析的專家則更加直接，從180W+邏輯讀和每個事務(wù)1W+邏輯讀這這些指標(biāo)上，馬上發(fā)現(xiàn)了其中的不正常，可以比僅僅懂得基線分析的高級DBA更快地找到問題的關(guān)鍵點。