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

圖片

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

圖片

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

圖片

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

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

圖片

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

圖片

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

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

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

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

圖片

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

圖片

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

圖片

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

圖片

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

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