內容來源：2018 年 11 月 10 日，SOUG聯合創始人周亮在“2018 SOUG年度數據庫技術峯會”進行《Oracle AI 性能優化指南探討》的演講分享。IT 大咖說（微信id：itdakashuo）作爲獨家視頻合作方，經主辦方和講者審閱授權發佈。
閱讀字數：3313 | 9分鐘閱讀
摘要
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個部分，下面的登錄解析引擎和變化監測引擎互相補充，機器學習引擎是去學習上面五個模塊的各種指標，變化檢測通過機器學習的指標解釋性能的突變點或者拐點在哪裏。然後是主機資源和數據庫資源，他們是數據庫能正常運行的一個前提。
以上爲今天的分享內容，謝謝大家！