基于Oracle 數(shù)據(jù)庫性能異常診斷模型探析

韓 超，梁 策，賈琦婧

（中國民航信息網(wǎng)絡股份有限公司 北京 101318）

0 引言

當前， 數(shù)據(jù)庫系統(tǒng)成為信息技術（information technology， IT）架構下的重要支撐環(huán)節(jié)，數(shù)據(jù)庫系統(tǒng)的健康狀態(tài)在整個IT 業(yè)務系統(tǒng)的可用性指標中起到了決定性的作用［1］?；诖吮尘?，實現(xiàn)數(shù)據(jù)庫服務異常點快速定位，提前識別當前數(shù)據(jù)庫系統(tǒng)隱患的工作變得至關重要。維持數(shù)據(jù)庫系統(tǒng)的健康程度、快速地定位數(shù)據(jù)故障并能有效率地解決故障，使數(shù)據(jù)庫系統(tǒng)狀態(tài)健康、數(shù)據(jù)庫系統(tǒng)的性能穩(wěn)定地保持在一個相對良好的水平，成為當前數(shù)據(jù)庫管理員（database administrator， DBA）與業(yè)務系統(tǒng)運維管理人員的長期目標。因此，如何快速發(fā)現(xiàn)數(shù)據(jù)庫異常與隱患、如何有效率地收集故障現(xiàn)場dump trace 信息，為數(shù)據(jù)庫當前出現(xiàn)的異常找到根因，成為DBA 的首要痛點。

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

1 數(shù)據(jù)庫性能異常診斷模型

1.1 數(shù)據(jù)庫性能異常診斷模型的定義

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

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

1.2 數(shù)據(jù)庫性能異常診斷模型的作用

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

2 現(xiàn)有探索成果綜述

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

2.1 專家經(jīng)驗模型

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

2.1.1 數(shù)據(jù)庫性能緩慢之異常等待事件模型實例

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

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

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

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

2.1.2 數(shù)據(jù)庫SQL 效率健康度檢查模型

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

圖2 數(shù)據(jù)庫中出現(xiàn)低效訪問路徑全表掃描的SQL 信息檢查結果

圖3 數(shù)據(jù)庫中出現(xiàn)結果集偏小但使用了HASH JOIN 連接方式的SQL 信息檢查結果

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

2.2 診斷路徑模型

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

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

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

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

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

根據(jù)檢查點現(xiàn)象矩陣與故障根因向量運算結果的輸入，構建概率矩陣，進行故障根因概率計算，故障現(xiàn)象檢查點矩陣【C】×根因向量矩陣【R】 ＝最終故障原因分析結果－概率矩陣。如圖6 所示，根因檢查點f1概率為1/2，根因檢查點f2概率為1，根因檢查點f3概率為2/3，經(jīng)過概率分析比較，故當前數(shù)據(jù)庫系統(tǒng)異常時，由f2根因?qū)е碌目赡苄宰畲蟆?/p>

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

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

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

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

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

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

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

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

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

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

4 結語

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