哪些是數據庫智能化運維必踩的坑？

內容來源：2018 年 11 月 10 日，SOUG聯合創始人周亮在「2018 SOUG年度數據庫技術峯會」進行《Oracle AI 性能優化指南探討》的演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3313 | 9分鐘閱讀

獲取嘉賓演講視頻及PPT，請點擊：t.cn/EyZX8Q6。

摘要

Oracle AI 性能優化指南探討。如今咱們絕大部分的運維工做仍是集中在文檔化定位、腳本化、運維工具化，雖然這三大塊裏面已經有不少企業實現了部分的自動化運維，可是我相信不少時候仍是靠人肉爲主。

運維發展階段

運維發展的第一個階段是無序化運維，也就是所謂的水來土淹，兵來將擋，有故障了就處理，沒故障就喝茶看報，文檔也沒有，全靠人工處理。下一階段是文檔化運維，這應該是如今絕大部分的人所處的階段，一些故障和心得會被寫到文檔裏面，造成知識手冊，或者博客文章等。

再往下是腳本化運維，有了腳本以後下一任的人員接手就會簡單不少，他只須要知道腳本的用途和使用方式就好了，至於細節方面，一開始並不須要瞭解太多，除非是要對腳本進行量身定製化，

工具化運維是腳本化運維的升級，將腳本打包成工具使用，好比說自動化運維平臺、性能優化平臺、監控平臺，簡單來講就是將所用的腳本歸檔集中起來。而後是自動化運維，關於這方面的討論這幾年很是火，各類大會上都在講自動化。根據個人觀察，目前自動化運維主要在作那麼一件或兩件事，大可能是一些不須要太多的流程，不須要太多的人工智能的事情。好比說安裝部署、空間擴容。雖然自動化在互聯網企業中推行了開來，可是在傳統企業裏面，自動化有一個很大的瓶頸在，那就是不夠標準化。所謂的不夠標準化，指的是咱們的機房環境錯綜複雜，自動化運維很難部署下去。

最後是智能化運維，這是也本次要講的一個比較重要的主題。所謂的智能化運維就是讓機器去幹人的事情，讓機器學習人的思想，再經過人工智能的一些手段實現出來。

如今咱們絕大部分的運維工做仍是集中在文檔化定位、腳本化、運維工具化，雖然這三大塊裏面已經有不少企業實現了部分的自動化運維，可是我相信不少時候仍是靠人肉爲主。

所謂的自動化運維也只是在簡單的接受一些告警，這些告警每每是海量的，運維人員看多了也就麻痹掉了，不會再去看。因此說自動化運維只是實現了部分告警讓機器去作，可能安裝部所巡檢仍是人在作。而智能化運維甚至還在起步階段，或者說在概念的階段。

AI性能運維需求

做爲一個非甲方公司，咱們考慮的智能化性能，必需要兼容全部的數據，這是一個大的前提。不一樣的數據庫的類型，智能化運維需求是不同的。好比小型數據庫，主機的負載很低的，併發也不高的，空間每每小於500G，其性能問題每每是有SQL執行效率引發的，好比SQL執行計劃發生變異，一個索性忽然變成全量。

對於中大型數據庫，他們的主機資源負載或者事務併發都比較高，大體狀況多是每秒鐘有100個以上SQL再解析，每一個節點有200個左右的當前的事務在執行。它的性能問題每每不是一條簡單的SQL致使的，更多的是受到主機資源不足、數據庫資源衝突、SQL執行效率等因素影響。

在這種狀況下到底有哪些人須要AI運維呢？我我的來看多是一些基礎不是特別牢固的人員，以平臺的形式提供給他們使用，該平臺以結果爲導向，提供簡介明瞭的操做指南，實現過程性的關聯告警，明確問題方向。

咱們作性能優化的時候面臨的首要難點就是不報錯，這對於水平比較低的人來說就徹底沒有頭緒了。若是有報錯，還能夠去百度，谷歌或者其餘地方查詢，只要有足夠的時間，就能找到一個問題的方向。所以在智能化運維性能這塊，咱們要把這些毫無頭緒的環節梳理出來。

性能優化的目標

全部的性能優化的目標都是讓拐點後移動， 所謂的拐點後移動，就是當壓力或者併發積累到必定程度的時候，數據庫的吞吐量時間會急劇上升，從緩慢上升到急劇上升的突變點就叫拐點。隨着性能優化的持續的投入，咱們會把這個點儘可能的日後移，讓數據庫能承受更多的壓力，這就是全部的數據庫的性能優化的目標。

咱們在說性能優化的時候有個關鍵點——變化，明確的說是尋找變化。由於性能優化是不報錯的，因此當數據庫出現性能問題的時候，須要數據庫出現性能問題先後的比較報告。經過比較兩份報告，能夠更容易的看出數據庫發生了哪些變化，並以此分析出問題點。

AI性能優化關鍵點

AI性能優化的關鍵點之一是流程化肢解。若是不把性能優化肢解掉，那就只一筆所謂的一筆糊塗帳，咱們只知道數據庫變慢了，但殊不知道具體問題在哪。因此纔要把整個數據庫性能肢解成幾個環節。

從數據庫內部的角度來說，整個數據庫本質上是用來讀取和存儲數據的。如今咱們能夠把這一環節肢解掉，進一步細分爲五個步驟。第一個環節是會訪登錄，第二個環節是SQL解析，第三個環節是SQL執行，接着是提交和返回環節。

這樣肢解以後，有些問題就能夠進行鍼對性的比較了。若是不這樣作，比較的東西就太多了，沒法抓住關鍵點。

另一個關鍵點是尋找拐點和突破點。每一個系統全部的數據庫，只要放大到必定的時間時間軸後都是有業務節奏的，當其中的某部分不符合業務節奏的時候就會出現問題，這個點就是突破點。

如今業內在作性能優化的時候，大多狀況下是沒有性能相關的告警的，數據庫報錯可能會告警出來，但數據庫變慢了，我相信不多會有報警，最多也就是CPU 80%以上、空間不足的時候纔會有報警。

而若是能尋找出拐點跟突破點的話，徹底能夠進行性能方面的報警。好比咱們經過機器學習已經瞭解到了系統的業務節奏是什麼樣的，以後的業務週期內，若是產生新的突破點，在業務感知以前就能夠進行報警，指出當前的數據庫性能違背了日常的波動規律，可能會出現問題。除了性能告警以外，還能夠作一些性能預警。由於已經學習了性能波動曲線，因此能夠預測將來的波動狀況。

第三個關鍵點是機器學習，首先學習曲線規律，也就是數據庫的指標特徵，學習完成後要開始預測變化趨勢。隨着時間的推移，機器還有很重要的特色，即根據業務節奏的變化，要不停的修正告警閾值，由於業務系統是會不停發展的，另外還有性能預警。

運維數據

那麼怎樣提取核心環節和核心指標呢？確定是從主機資源開始，主機的四大資源必需要提取出來，CPU內存、內存資源、I/O資源、網絡資源。再往上是數據庫層，它反應了數據庫的典型特徵，包括事務數、事務響應時間、邏輯讀取數、邏輯讀取時間、TOP SQL、TOP OWI。

其中邏輯讀的次數是一個很能直觀反映數據庫性能的指標，當SQL執行計劃發生變異的時候，好比說正常的索引讀取，一條SQL讀一條數據可能要十個邏輯讀，在比較高效的時候，其實十個數據塊都不要，若是索引讀恰好在這個數據塊的索引裏面或者是在根節點裏面，可能只要1到2個數據塊就好了。可是SQL執行計劃發生變異了的話，可能就要全表掃描，這樣的話邏輯讀的次數就會直線上升。而若是有機器學習抓取的指標在，通過對比後就會告警出來。

接下來是將數據庫肢解後的4個階段，登陸、解析、執行、提交返回，分別在這幾個階段進行橫向對比。

假設應用報出了數據庫慢的問題，你在徹底比對了這四個環節以後，發現登錄階段、解析階段指標沒有波動，可是在執行階段指標發生波動了，那麼就基本能夠肯定是執行階段的性能問題致使整個數據庫變慢。

後臺架構

上圖是我設想的後臺架構，最上方的性能解析模塊分紅5個部分，下面的登陸解析引擎和變化監測引擎互相補充，機器學習引擎是去學習上面五個模塊的各類指標，變化檢測經過機器學習的指標解釋性能的突變點或者拐點在哪裏。而後是主機資源和數據庫資源，他們是數據庫能正常運行的一個前提。

以上爲今天的分享內容，謝謝你們！

編者：IT大咖說，轉載請標明版權和出處