oracle ai 效能優化指南**。現在我們絕大部分的運維工作還是集中在文件化定位、指令碼化、運維工具化，雖然這三大塊裡面已經有很多企業實現了部分的自動化運維，但是我相信很多時候還是靠人肉為主。
運維發展的第乙個階段是無序化運維，也就是所謂的水來土淹，兵來將擋，有故障了就處理，沒故障就喝茶看報，文件也沒有，全靠人工處理。下一階段是文件化運維，這應該是現在絕大部分的人所處的階段，一些故障和心得會被寫到文件裡面，形成知識手冊，或者部落格文章等。
再往下是指令碼化運維，有了指令碼之後下一任的人員接手就會簡單很多，他只需要知道指令碼的用途和使用方式就行了，至於細節方面，一開始並不需要了解太多，除非是要對指令碼進行量身定製化，
工具化運維是指令碼化運維的公升級，將指令碼打包成工具使用，比如說自動化運維平台、效能優化平台、監控平台，簡單來說就是將所用的指令碼歸檔集中起來。然後是自動化運維，關於這方面的討論這幾年非常火，各種大會上都在講自動化。根據我的觀察，目前自動化運維主要在做那麼一件或兩件事，大多是一些不需要太多的流程，不需要太多的人工智慧的事情。比如說安裝部署、空間擴容。雖然自動化在網際網路企業中推行了開來，但是在傳統企業裡面，自動化有乙個很大的瓶頸在，那就是不夠標準化。所謂的不夠標準化，指的是我們的機房環境錯綜複雜，自動化運維很難部署下去。
最後是智慧型化運維，這是也本次要講的乙個比較重要的主題。所謂的智慧型化運維就是讓機器去干人的事情，讓機器學習人的思想，再通過人工智慧的一些手段實現出來。
現在我們絕大部分的運維工作還是集中在文件化定位、指令碼化、運維工具化，雖然這三大塊裡面已經有很多企業實現了部分的自動化運維，但是我相信很多時候還是靠人肉為主。
所謂的自動化運維也只是在簡單的接受一些告警，這些告警往往是海量的，運維人員看多了也就麻痺掉了，不會再去看。所以說自動化運維只是實現了部分告警讓機器去做，可能安裝部所巡檢還是人在做。而智慧型化運維甚至還在起步階段，或者說在概念的階段。
作為乙個非甲方公司，我們考慮的智慧型化效能，必須要相容所有的資料，這是乙個大的前提。不同的資料庫的型別，智慧型化運維需求是不一樣的。比如小型資料庫，主機的負載很低的，併發也不高的，空間往往小於500g，其效能問題往往是有sql執行效率引起的，比如sql執行計畫發生變異，乙個索性突然變成全量。
對於中大型資料庫，他們的主機資源負載或者事務併發都比較高，大致情況可能是每秒鐘有100個以上sql再解析，每個節點有200個左右的當前的事務在執行。它的效能問題往往不是一條簡單的sql導致的，更多的是受到主機資源不足、資料庫資源衝突、sql執行效率等因素影響。
在這種情況下到底有哪些人需要ai運維呢？我個人來看可能是一些基礎不是特別牢固的人員，以平台的形式提供給他們使用，該平台以結果為導向，提供簡介明了的操作指南，實現過程性的關聯告警，明確問題方向。
所有的效能優化的目標都是讓拐點後移動， 所謂的拐點後移動，就是當壓力或者併發積累到一定程度的時候，資料庫的吞吐量時間會急劇上公升，從緩慢上公升到急劇上公升的突變點就叫拐點。隨著效能優化的持續的投入，我們會把這個點盡量的往後移，讓資料庫能承受更多的壓力，這就是所有的資料庫的效能優化的目標。
我們在說效能優化的時候有個關鍵點——變化，明確的說是尋找變化。因為效能優化是不報錯的，所以當資料庫出現效能問題的時候，需要資料庫出現效能問題前後的比較報告。通過比較兩份報告，可以更容易的看出資料庫發生了哪些變化，並以此分析出問題點。
ai效能優化的關鍵點之一是流程化肢解。如果不把效能優化肢解掉，那就只一筆所謂的一筆糊塗賬，我們只知道資料庫變慢了，但卻不知道具體問題在哪。所以才要把整個資料庫效能肢解成幾個環節。
從資料庫內部的角度來講，整個資料庫本質上是用來讀取和儲存資料的。現在我們可以把這一環節肢解掉，進一步細分為五個步驟。第乙個環節是會訪登陸，第二個環節是sql解析，第三個環節是sql執行，接著是提交和返回環節。
這樣肢解之後，有些問題就可以進行針對性的比較了。如果不這樣做，比較的東西就太多了，無法抓住關鍵點。
另外乙個關鍵點是尋找拐點和突破點。每個系統所有的資料庫，只要放大到一定的時間時間軸後都是有業務節奏的，當其中的某部分不符合業務節奏的時候就會出現問題，這個點就是突破點。
現在業內在做效能優化的時候，大多情況下是沒有效能相關的告警的，資料庫報錯可能會告警出來，但資料庫變慢了，我相信很少會有報警，最多也就是cpu 80%以上、空間不足的時候才會有報警。
而如果能尋找出拐點跟突破點的話，完全可以進行效能方面的報警。比如我們通過機器學習已經了解到了系統的業務節奏是什麼樣的，之後的業務週期內，如果產生新的突破點，在業務感知之前就可以進行報警，指出當前的資料庫效能違背了平常的波動規律，可能會出現問題。除了效能告警之外，還可以做一些效能預警。因為已經學習了效能波動曲線，所以可以**未來的波動情況。
第三個關鍵點是機器學習，首先學習曲線規律，也就是資料庫的指標特徵，學習完成後要開始**變化趨勢。隨著時間的推移，機器還有很重要的特點，即根據業務節奏的變化，要不停的修正告警閾值，因為業務系統是會不停發展的，另外還有效能預警。
那麼怎樣提取核心環節和核心指標呢？肯定是從主機資源開始，主機的四大資源必須要提取出來，cpu記憶體、記憶體資源、i/o資源、網路資源。再往上是資料庫層，它反應了資料庫的典型特徵，包括事務數、事務響應時間、邏輯讀取數、邏輯讀取時間、top sql、top owi。
其中邏輯讀的次數是乙個很能直觀反映資料庫效能的指標，當sql執行計畫發生變異的時候，比如說正常的索引讀取，一條sql讀一條資料可能要十個邏輯讀，在比較高效的時候，其實十個資料塊都不要，如果索引讀剛好在這個資料塊的索引裡面或者是在根節點裡面，可能只要1到2個資料塊就行了。但是sql執行計畫發生變異了的話，可能就要全表掃瞄，這樣的話邏輯讀的次數就會直線上公升。而如果有機器學習抓取的指標在，經過對比後就會告警出來。
接下來是將資料庫肢解後的4個階段，登入、解析、執行、提交返回，分別在這幾個階段進行橫向對比。
假設應用報出了資料庫慢的問題，你在完全比對了這四個環節之後，發現登陸階段、解析階段指標沒有波動，但是在執行階段指標發生波動了，那麼就基本可以確定是執行階段的效能問題導致整個資料庫變慢。
上圖是我設想的後台架構，最上方的效能解析模組分成5個部分，下面的登入解析引擎和變化監測引擎互相補充，機器學習引擎是去學習上面五個模組的各種指標，變化檢測通過機器學習的指標解釋效能的突變點或者拐點在**。然後是主機資源和資料庫資源，他們是資料庫能正常執行的乙個前提。
以上為今天的分享內容，謝謝大家！
如何快速構建資料庫智慧型化運維平台（一）
顧名思義，自動化是將手工操作變革為機器自動操作。但是，許多人在平台建設初期往往會進入乙個誤區 要窮舉可能用到的所有場景，把所有的運維工作都做成自動化，徹底解放人工。想法固然是好，但是由於資料庫運維的複雜性，在實際建設過程中會舉步維艱，難以為繼。我所理解的自動化，是要解決dba的痛點，而且是最痛的點，...
騰訊雲資料庫智慧型化海量運維的建設與實踐
資料庫架構師團隊的組建 自動化運維平台的建設 智慧型海量運維的實踐 由於資料庫產品的特殊性和複雜性，我們在平時服務客戶的過程中常遇到一些問題，例如 分布在各行各業的客戶，他們會有不同的場景需求，這對於資料庫的應用來說存在有非常大的差別。而我們的售前架構師可能沒辦法對各行各業在資料庫方面的應用 對不同...
騰訊雲資料庫智慧型化海量運維的建設與實踐
資料庫架構師團隊的組建 自動化運維平台的建設 智慧型海量運維的實踐 由於資料庫產品的特殊性和複雜性，我們在平時服務客戶的過程中常遇到一些問題，例如 分布在各行各業的客戶，他們會有不同的場景需求，這對於資料庫的應用來說存在有非常大的差別。而我們的售前架構師可能沒辦法對各行各業在資料庫方面的應用 對不同...