韓 超,梁 策,賈琦婧
(中國民航信息網(wǎng)絡股份有限公司 北京 101318)
當前, 數(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ù)研究提供參考。
在數(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 輸出針對異常的已知解決方案。
目前,以本文所探究的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ū)⒍鄠€操作封裝成了程序腳本,異常分析模型對于日常運維工作的便捷性也有了極大提高,針對各項運維工作提供了“一鍵式”“白屏化”的可能。
數(shù)據(jù)庫性能異常診斷模型可細化為專家經(jīng)驗模型、診斷路徑模型和分析報告建議模型,共3 個維度。首先,專家經(jīng)驗模型需要預先定義已知異常故障點,如何對經(jīng)過數(shù)據(jù)庫專家積累、框架化的經(jīng)驗進行合理的編排與組合,是構建異常診斷模型的核心工作之一。其次,經(jīng)驗經(jīng)過輸出后,通過診斷路徑模型進行自動化判定計算,形成最終的分析報告,從而提供對故障有價值的、經(jīng)過專家經(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 效率健康檢查點示例
本文通過基于專家經(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ā)生概率最大。
故障發(fā)生時借助前文提到的故障檢查點模型與故障根因模型,通過概率計算預期得出根因報告。故障發(fā)生時點擊故障定位按鈕,模型并發(fā)執(zhí)行定義好的故障檢查項,輸出最終定位的可能性。如圖7 所示,檢查“數(shù)據(jù)庫硬解析類等待嚴重”故障點,并輸出檢查結果,正常為“綠燈”,異常為“紅燈”。
圖7 模型故障分析報告結果
異常診斷與健康度檢查目前已經(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]。
綜上所述,本文對當前主要探究的數(shù)據(jù)庫系統(tǒng)性能異常診斷與健康度檢查模型進行了論述,介紹了將該模型涉及的專家經(jīng)驗與涉及模型的建模思路,分享了當前工程化落地的一些成果內(nèi)容,同時分析了模型現(xiàn)狀的痛點與未來的改進方向,為該領域繼續(xù)深入推進提供一定參考。