?昨天晚上項目組向D-SMART研發(fā)報了一個故障案例，這個項目是以D-SMART為基礎監(jiān)控功能的常態(tài)化優(yōu)化機制的項目。他們發(fā)現(xiàn)了一個數(shù)據庫近期偶發(fā)性出現(xiàn)LOGON時間嚴重超長的情況。經過現(xiàn)場DBA的分析，發(fā)現(xiàn)是因為AUD$長期沒有清理，數(shù)據量已經達到數(shù)千萬條導致的。清理AUD$后，暫時還沒有發(fā)現(xiàn)類似現(xiàn)象出現(xiàn)。

基于這個案例，他們向D-SMART項目組報了一個運維經驗，那就是AUD$長期不清理，會存在會話登錄延時加大的風險。

看到這個需求后，我第一反應是D-SMART日檢里應該是有AUD$的檢查項的，于是讓他們現(xiàn)場確認一下，他們而模板里是否禁用了這個檢查項。經過檢查發(fā)現(xiàn)，他們并未禁用，每天也都是有這方面的告警出現(xiàn)的，以前這個日檢告警也向甲方負責人匯報過，因為封網，最近無法做清理操作，所以才積壓了大量的數(shù)據。

處理完這個問題，我就去干其他事情了。不過總覺得這個事情哪里有點不對勁。突然一想，AUD$數(shù)據量過大與LOGON超時有什么內在的關聯(lián)呢？似乎并沒有什么直接關聯(lián)啊。因為LOGON的時候僅僅是往AUD$里插入了一條數(shù)據而已，并沒有去讀取AUD$表的數(shù)據做什么分析，往一張1000條記錄的表里插入一條數(shù)據和往一張1000萬記錄的表里插入一條數(shù)據應該不會有如此巨大的差別啊。于是我在微信里又問了現(xiàn)場的DBA，他怎么發(fā)現(xiàn)AUD$引發(fā)了LOGON超時這個問題的。

他說他分析了故障期間的AUD$的插入語句，244條INSERT花了128秒，而清理了AUD$后，304條花了1.25秒，效果是十分明顯的。于是我讓他查查是否存在LOGON觸發(fā)器之類的機制，或者一些特殊的審計項，他的反饋是沒有。

這就讓人不解了，從機理上看，AUD$表變成5GB+并不會引發(fā)插入一條記錄的性能下降100倍，從而導致LOGON超時。因此我相信一定是其他的原因導致了這個問題。于是我讓他用hola導出數(shù)據發(fā)給實驗室。不巧的是，他們的版本是V2.1的，而且因為要納管上千個運維對象，采用而是分布式部署的模式，目前的hola 1.0.2有個BUG，無法從分布式部署的D-SMART里導出數(shù)據。于是我讓他把今天發(fā)生故障的兩個時點各生成一份“問題分析”報告，發(fā)過來。

從等待事件分析方面可以看出，排在前幾位的都是GC相關的指標，其中也發(fā)現(xiàn)了AUD$這張表存在熱點。

從IO上看，IOPS/IO吞吐量都不算太高。OS方面應該沒有太大的IO壓力。因為客戶那邊的安全限制，這個系統(tǒng)的所有操作系統(tǒng)層面的指標以及日志都沒有采集，因此我們無法分析操作系統(tǒng)IO延時是否正常。

不過從報告中可以看出，幾乎所有的數(shù)據庫寫IO指標都超標，而讀IO指標沒有一個是超標的。這就更讓人費解了。

另外一個節(jié)點也出現(xiàn)了LOGON超時的現(xiàn)象，不過從問題分析報告上看，等待事件完全不同。排在前幾位的是log file sync等與IO相關的指標。同時我們也發(fā)現(xiàn)系統(tǒng)中存在gcs log flush sync的現(xiàn)象。

從這些問題上看，AUD$寫入延時加大并不是因而更像是插入數(shù)據的性能受到了其他方面的問題的影響。于是我讓現(xiàn)場DBA把操作系統(tǒng)日志與數(shù)據庫日志都發(fā)過來。

在出現(xiàn)GC爭用的節(jié)點上，日志一切正常，而在出現(xiàn)Log file sync延時超時的節(jié)點上，我發(fā)現(xiàn)了多路徑抖動的日志告警信息。自此，這個問題的脈絡已經十分清晰了。因為節(jié)點2上的多路徑抖動，導致了IO延時的不穩(wěn)定，從而引發(fā)了AUD$插入數(shù)據的性能問題，最終導致了LOGON超時。

一個不經意的發(fā)現(xiàn)，排除了一個系統(tǒng)的嚴重隱患，這套系統(tǒng)每個月月底和月初是十分繁忙的，要做大量的數(shù)據寫入和計算。幸虧問題在業(yè)務十分小的時候被發(fā)現(xiàn)了。否則月底肯定會出大問題的。而這個問題的發(fā)現(xiàn)過程也有很大的偶然成分。本來現(xiàn)場DBA認為已經解決了這個問題。要不是現(xiàn)場與后端的這個故障案例共享機制的存在，這個隱患很可能要到引發(fā)大問題的時候才會被發(fā)現(xiàn)。

而分析問題，大部分情況下，我們僅僅是從表象入手，問題暫時不重現(xiàn)就算搞定了。而如果分析這個問題的人缺少對數(shù)據庫機理的深入理解，是很難從這些表象中發(fā)現(xiàn)深層次的問題的。而且實際上，在運維體系中，一線工程師也不可能放置如此高水平的DBA的。

正是因為這個原因，我們一直強調，工具不是萬能的，一線駐場運維也不是萬能的。必須形成一個良好的問題閉環(huán)分析生態(tài)，讓高水平的專家、一線、二線運維人員、高質量的監(jiān)控數(shù)據采集與分析工具相結合，形成一個完整的體系，才能夠更為高效與準確的分析問題和解決問題。

而從表象與機理這個問題上，我一直強調問題溯源或者說根因溯源的重要性。以前與一些運維專家討論過這個問題，一些互聯(lián)網企業(yè)出身的人認為系統(tǒng)出問題，有高可用機制可以解決就行了，切掉有問題的部分組件自然就解決問題了。還有一些人認為出問題后盡快回復運行是關鍵，根因分析能做則做，不能做就算了，企業(yè)無法投入如此大的成本。

從某些場景和用戶的角度來說，這些觀點也都沒錯。不過并不是所有的企業(yè)都有互聯(lián)網企業(yè)那么完備的高可用機制，也不是所有的系統(tǒng)都是重啟一下就能解決問題的。因此問題溯源，問題閉環(huán)對于大部分企業(yè)來說，應該還是有價值的。目前無法全面開展的最主要問題還是成本太高，能力不足的問題。IT健康管理機制就是為了解決這種分散分析的成本問題的，通過一二三線聯(lián)動，通過D-SMART豐富的數(shù)據采集與診斷報告，再加上最近推出的holadata數(shù)據交換工具。三線專家可以足不出戶為全國的客戶做服務，其效率提升是十分明顯的。昨天的這個問題，算上在微信群里的討論以及現(xiàn)場采集數(shù)據的時間，專家參與定位問題的時間也不過20分鐘而已。