基于Oracle 數據庫性能異常診斷模型探析

韓 超，梁 策，賈琦婧

（中國民航信息網絡股份有限公司 北京 101318）

0 引言

當前， 數據庫系統成為信息技術（information technology， IT）架構下的重要支撐環節，數據庫系統的健康狀態在整個IT 業務系統的可用性指標中起到了決定性的作用［1］。基于此背景，實現數據庫服務異常點快速定位，提前識別當前數據庫系統隱患的工作變得至關重要。維持數據庫系統的健康程度、快速地定位數據故障并能有效率地解決故障，使數據庫系統狀態健康、數據庫系統的性能穩定地保持在一個相對良好的水平，成為當前數據庫管理員（database administrator， DBA）與業務系統運維管理人員的長期目標。因此，如何快速發現數據庫異常與隱患、如何有效率地收集故障現場dump trace 信息，為數據庫當前出現的異常找到根因，成為DBA 的首要痛點。

本文基于Oracle 數據庫軟件（版本11gR2），立足數據庫軟件自身的特點、運行機理，結合現有的數據庫專家故障處理經驗，進行了一系列數據庫軟件異常點的組合建模，最終形成了基于Oracle 數據庫的故障自動診斷系統。針對該系統實際工程落地的思路與難點，進行了剖析與展望，為該領域有關的后續研究提供參考。

1 數據庫性能異常診斷模型

1.1 數據庫性能異常診斷模型的定義

在數據庫異常診斷模型中，故障模型是一個十分重要的模型，數據庫性能異常診斷依賴故障模型中專家經驗的豐富程度與算法的健壯性，進行數據庫異常原因分析判斷與計算。結合問題發現（監控預警）、建模分析（異常點組合）、報告分析（建議輸出）3 個維度，最終可以快速定位數據庫異常點，并自動提供有效的異常處置建議。

例如，當前數據庫系統如果發現性能問題，DBA 可借助此自動化診斷分析模型進行故障處置。首先，該模型的故障診斷依據是由預先定義完備的一系列程序腳本組成的，這些程序腳本由數據庫運維專家多年的運維經驗匯總提煉得出，由平臺自動執行并利用向量模型計算出異常的概率預期，最后向DBA 輸出針對異常的已知解決方案。

1.2 數據庫性能異常診斷模型的作用

目前，以本文所探究的Oracle 數據庫軟件為例，該數據庫軟件系統共涉及了375 個標準參數，2 914 個隱含內核參數和4 412 個動態性能視圖，每一個參數、動態性能視圖均有不同的作用。例如，某個特定參數控制著特定數據庫功能的開關，某個動態性能視圖提供了基于特定功能點的可觀測性數據，各項數據指標的依賴關系十分復雜。如果當前數據庫發生故障，DBA 可借助該異常診斷模型快速定位當前數據庫系統異常點，避免了故障處置人進行繁瑣的數據庫指令輸入，故障處置人無需具備豐富的數據庫故障處置經驗，按照模型提供的處置建議操作即可。除此之外，因將多個操作封裝成了程序腳本，異常分析模型對于日常運維工作的便捷性也有了極大提高，針對各項運維工作提供了“一鍵式”“白屏化”的可能。

2 現有探索成果綜述

數據庫性能異常診斷模型可細化為專家經驗模型、診斷路徑模型和分析報告建議模型，共3 個維度。首先，專家經驗模型需要預先定義已知異常故障點，如何對經過數據庫專家積累、框架化的經驗進行合理的編排與組合，是構建異常診斷模型的核心工作之一。其次，經驗經過輸出后，通過診斷路徑模型進行自動化判定計算，形成最終的分析報告，從而提供對故障有價值的、經過專家經驗計算的分析報告。

2.1 專家經驗模型

在以Oracle 產品為研究數據庫軟件目標的背景下，專家經驗可以借助Oracle 軟件體系中的時間、等待事件模型，進而構建一系列的數據庫故障圖譜［3］。

2.1.1 數據庫性能緩慢之異常等待事件模型實例

Oracle 數據庫11G R2 版本開放提供了1 367 個等待事件，Oracle 數據庫19c 版本上開放提供了1 920 個等待事件，數據庫系統如出現性能異常，可以利用各個等待事件的關系進行組合編排，如表1、表2、圖1 所示。

圖1 新建故障檢查項示意圖

表1 異常等待事件Library Cache Lock 檢查點示例

表2 等待事件Log File Sync 異常檢查點示例

2.1.2 數據庫SQL 效率健康度檢查模型

在數據庫系統中，結構化查詢語言（structured query language， SQL）性能的優劣決定了數據庫整體性能健康程度。數據庫中的SQL 問題往往非常隱蔽（因為SQL 問題與數據量、表中的數據分布的變化有極大的關系），所以需要在SQL 出現隱患初期盡量將SQL 進行優化，在日常期間進行數據庫中的SQL 巡檢、風險SQL 的提前識別。針對SQL 問題，同樣可借助專家經驗進行封裝，根據SQL優化的經驗與對數據庫優化器的理解，識別出數據庫系統中當前低效SQL、低效索引進行優化［4－5］。如表3、圖2、圖3 所示。

圖2 數據庫中出現低效訪問路徑全表掃描的SQL 信息檢查結果

圖3 數據庫中出現結果集偏小但使用了HASH JOIN 連接方式的SQL 信息檢查結果

表3 SQL 效率健康檢查點示例

2.2 診斷路徑模型

本文通過基于專家經驗的積累與實踐檢驗，將各個定義好的檢查點構建成針對故障點的診斷模型與決策樹。診斷模型通過向量模型的建立，進一步計算根因概率預期，最終可構造決策樹矩陣模型［6－7］。

根據需要定義故障檢查點c與根因檢查點f，借助專家規則從而最終定義CF（故障檢查點與根因檢查點）關系。如圖4 所示，c1與f1、f2有關，f1存在2 個故障檢查點，f2存在3 個故障檢查點，故c1占比f1的權重關系為1/2，c1占比f2的權重關系為1/3，從而構建故障檢查點與根因檢查點的向量模型【R】。

圖4 建立故障根因向量模型矩陣示例【R】

數據庫系統性能出現異常情況時，運行此模型進行CF（故障檢查點與根因檢查點）分析，檢查點c1…c4 結果命中故障檢查點為權重為1，非命中故障檢查點權重為0，故可構建現象矩陣【C】。如圖5 所示。

圖5 建立故障現象檢查點矩陣模型示例【C】

根據檢查點現象矩陣與故障根因向量運算結果的輸入，構建概率矩陣，進行故障根因概率計算，故障現象檢查點矩陣【C】×根因向量矩陣【R】 ＝最終故障原因分析結果－概率矩陣。如圖6 所示，根因檢查點f1概率為1/2，根因檢查點f2概率為1，根因檢查點f3概率為2/3，經過概率分析比較，故當前數據庫系統異常時，由f2根因導致的可能性最大。

圖6 概率運算結果算法示例

根據上述模型運算結果：f1＝1/2，f2＝1，f3＝2/3，所以，故障原因f2的發生概率最大。

2.3 分析報告建議模型工程落地

故障發生時借助前文提到的故障檢查點模型與故障根因模型，通過概率計算預期得出根因報告。故障發生時點擊故障定位按鈕，模型并發執行定義好的故障檢查項，輸出最終定位的可能性。如圖7 所示，檢查“數據庫硬解析類等待嚴重”故障點，并輸出檢查結果，正常為“綠燈”，異常為“紅燈”。

圖7 模型故障分析報告結果

3 數據庫性能異常診斷與健康度檢查模型未來展望

異常診斷與健康度檢查目前已經成為基于機器學習的智能運維（artificial intelligence for IT operations， AIOps）建設道路上最為常見的方法與手段之一。異常診斷最早起步于日志分析，其主要方法是針對各類IT 組件的運行日志進行異常關鍵字的篩選并報警。但是，在分析較為復雜的數據庫故障場景中會發現，故障點并非單一因素，每個數據庫中的異常日志和數據庫可觀測性指標并不能獨立地去審視，需要根據各指標變化的時間點，反復地結合故障現場進行分析。隨著IT 技術的革新，數據庫軟件版本不斷迭代，新的數據庫架構與功能也同步更新。同時，復雜數據庫故障診斷人工成本居高，導致數據庫IT 從業人員在數據庫故障診斷和技術棧知識掌握兩方面增加了挑戰，因此，減少數據庫專家針對異常點的標注，是故障自動診斷處理首先要解決的問題。未來，可采用無監督機器學習的方法對數據庫異常點進行分類，形成一系列獨立的異常檢查規則，針對不同故障，通過對異常檢查規則進行編排，實現減少監督學習的異常點人工標注成本。基于以上背景提出以下展望：

第一，數據庫性能異常的根因（決策樹）、算法模型需要不斷地進行更新與進步。故障點與故障處理知識圖譜是無法窮盡的，通過機器學習手段的引入和算法專家的接入，減輕嚴重依賴專家經驗的現狀，降低故障模型訓練的成本，是當前探研模型中的缺失部分，并成為當前的困境之一。

第二，在通過異常檢測指標進行的異常診斷中，異常檢測指標的判定十分重要。由于數據庫在IT 鏈路上處于重要位置，大多的簡單標準化指標無法使其充分發揮異常自動檢測作用，需要運維團隊結合企業自身應用、運維特點打造個性化的異常檢測模型，并在經過“加工”后進行輸出使用。針對同一個指標，不同的運維自動化系統采集出來的數值可能有所不同；不同能力的團隊，對系統指標的認知也有所不同，因此采集和加工的方法也同樣存在差異。對采集、使用的數據的標準化是建立健壯異常診斷系統的靈魂，否則模型永遠是實驗室中的“玩具”，無法形成最終的生產力。

第三，隨著大數據、人工智能的發展，一條新的原因分析的路徑也展現在面前，構建完善的指標集合，精確地采集動態性能數據，基于專家經驗與案例抽象的“泛知識”體系的道路已經步入正軌。數據庫是一個龐大且復雜的信息系統，同樣要經歷這個過程，只有越來越多的專家經驗的輸入、分享與算法專家的經驗進行有機結合，才能夠加快數據庫在AIOPS 上的成長速度，更快地讓AIOPS 在數據庫領域產生更突出的實戰效應［10－11］。

4 結語

綜上所述，本文對當前主要探究的數據庫系統性能異常診斷與健康度檢查模型進行了論述，介紹了將該模型涉及的專家經驗與涉及模型的建模思路，分享了當前工程化落地的一些成果內容，同時分析了模型現狀的痛點與未來的改進方向，為該領域繼續深入推進提供一定參考。