了解數據庫狀態的關鍵：基線與容量
DBA在運維工作中遇到最難的問題是如何判斷數據庫是否存在某個問題，特別是在國產數據庫大行其道的今天，這方面的知識都需要重新構建。DBA能力的提升也正是判斷能力提升所加持的，今天我們就來聊聊這方面的問題。
圖片
對于各個階段的DBA分析問題的主要方法，我簡單總結一下，大概有四個階段，每前進到一個新的階段都說明DBA在能力上的斷崖式提升。最初的時候，他們是根據現象來分析問題的。某個現象遇到過，那么就容易解決，如果沒遇到過，可能就抓瞎了。
圖片
在這個階段遇到問題，首先根據現象去腦子里分析，是否曾經遇到過類似案例，如果沒有，那么只能去網上搜索，再解決不了，就只能去向高手咨詢了。這是一個DBA技能的初級階段，還沒有形成比較有價值的知識庫，因此解決問題往往要憑運氣。這是DBA靠天吃飯的階段。
圖片
隨著DBA的能力的提升，分析問題不再是憑運氣了。因為中級的DBA 已經對數據庫的一些基本性的原理有所了解，因此不再僅僅依靠表象來分析問題，可以通過對內在原理的思考定位問題了。這個階段中，指標是十分關鍵的東西。某些指標異常說明了什么，哪怕自己還不是很清楚，也知道通過一些渠道去找到比較靠譜的答案了。
在這個階段中，唯一麻煩的就是，如何判斷某個指標的正常與否，在這方面的積累還不夠，因此判斷問題的準確性還不夠。有時候分析問題如水銀瀉地，有時候又像遇到一個堰塞湖一樣前進不得。
圖片
高級DBA對于上面的問題有比較標準的解決方案，那就是通過基線來分析問題。
圖片
什么是基線呢？說起基線，可能有很多朋友在腦子里立馬會浮現出一張指標的折線圖，上下各有一條線，這是狹義的“基線”，不過并不是我今天想和大家分享的“基線”。我個人認為“從數據庫運維的角度就系統而言，基線-BASELINE是某個運行狀態在某個時間上的快照”，某個指標、某個運維經驗、某個現象都可以成為運維基線；對于DBA，有價值的基線來自于長期運維的經驗，并非僅僅對于某個指標的學習和理解。基線十分重要，因為基線是用于判別某個指標甚至某個現象是否正常的重要依據。
基線的積累十分困難，需要DBA經過長期的工作與思考才能逐漸豐富起來。哪些指標對于分析哪些問題有幫助，哪些基線的合理范圍在哪個區間，哪些基線出現異常后可以使用的分析溯源方案有哪些，隨著這些運維知識的不斷積累，DBA的能力就會大幅提升。能夠很好地利用基線去分析問題，是一個高級DBA的主要特征。
不過有些時候，基線也不見得能發揮作用了。比如有人問你某個系統，在2萬IOPS下，IO延時是5毫秒，存儲系統的狀態是好是壞？某臺服務器，HTTPS請求達到10萬/秒，CPU使用率是20%，合理不合理？某個Oracle 數據庫的library cache pin 等待時間是50毫秒，系統共享池是否存在問題？當前的系統，數據表空間會不會在3個月內用滿？
要回答這些問題，僅僅依靠基線就不夠了，這需要容量方面的知識。利用容量進行分析，不僅僅考慮基線的問題，還需要考慮系統的總體負載能力，考慮數據庫標準操作產生的資源消耗情況，考慮不同硬件之間的容量差異，考慮信息系統長期發展的可持續問題。如果你已經積累了足以應對日常運維工作中的容量知識，那么恭喜你，在這個領域內，你已經是專家級別的存在了。
圖片
比如說有這樣一個案例，如上圖的AWR數據。有一個系統，8月2日CPU從早上7點30開始到下午5點30都基本上處于100%，平時這個系統的CPU使用率不超過40%，8月3日起未見異常。如果DBA能夠清晰地描述出上述問題，說明他已經初步掌握了基線分析的方法。我們如果再進一步利用基線的知識做分析，是可以完成問題定位的。
圖片
不過實際上，分析工作沒那么簡單，因為導致出現上述現象的可能性很多。我們需要利用自己所掌握的知識去做排除。上述問題，僅僅能夠依靠現象進行分析的朋友可能就無從入手了。
圖片
而對于掌握了根據指標去分析問題的朋友首先會看到Library cache pin/lock等待事件延時很高。很容易就認為共享池問題可能是問題的關鍵。
圖片
而更高一層次的DBA懂得了以基線分析作為分析問題的方法。他會發現共享池問題雖然存在，但是占比不高，邏輯讀過高可能對CPU使用率過高產生的影響更大。他通過比對正常與非正常時段的邏輯讀指標，就可以找到更加準確的分析路徑。
懂得容量分析的專家則更加直接，從180W+邏輯讀和每個事務1W+邏輯讀這這些指標上，馬上發現了其中的不正常，可以比僅僅懂得基線分析的高級DBA更快地找到問題的關鍵點。
