一個數據庫故障的表象與機理，你明白了嗎？
?昨天晚上項目組向D-SMART研發報了一個故障案例，這個項目是以D-SMART為基礎監控功能的常態化優化機制的項目。他們發現了一個數據庫近期偶發性出現LOGON時間嚴重超長的情況。經過現場DBA的分析，發現是因為AUD$長期沒有清理，數據量已經達到數千萬條導致的。清理AUD$后，暫時還沒有發現類似現象出現。
基于這個案例，他們向D-SMART項目組報了一個運維經驗，那就是AUD$長期不清理，會存在會話登錄延時加大的風險。
看到這個需求后，我第一反應是D-SMART日檢里應該是有AUD$的檢查項的，于是讓他們現場確認一下，他們而模板里是否禁用了這個檢查項。經過檢查發現，他們并未禁用，每天也都是有這方面的告警出現的，以前這個日檢告警也向甲方負責人匯報過，因為封網，最近無法做清理操作，所以才積壓了大量的數據。
處理完這個問題，我就去干其他事情了。不過總覺得這個事情哪里有點不對勁。突然一想，AUD$數據量過大與LOGON超時有什么內在的關聯呢？似乎并沒有什么直接關聯啊。因為LOGON的時候僅僅是往AUD$里插入了一條數據而已，并沒有去讀取AUD$表的數據做什么分析，往一張1000條記錄的表里插入一條數據和往一張1000萬記錄的表里插入一條數據應該不會有如此巨大的差別啊。于是我在微信里又問了現場的DBA，他怎么發現AUD$引發了LOGON超時這個問題的。
他說他分析了故障期間的AUD$的插入語句，244條INSERT花了128秒，而清理了AUD$后，304條花了1.25秒，效果是十分明顯的。于是我讓他查查是否存在LOGON觸發器之類的機制，或者一些特殊的審計項，他的反饋是沒有。
這就讓人不解了，從機理上看，AUD$表變成5GB+并不會引發插入一條記錄的性能下降100倍，從而導致LOGON超時。因此我相信一定是其他的原因導致了這個問題。于是我讓他用hola導出數據發給實驗室。不巧的是，他們的版本是V2.1的，而且因為要納管上千個運維對象，采用而是分布式部署的模式，目前的hola 1.0.2有個BUG，無法從分布式部署的D-SMART里導出數據。于是我讓他把今天發生故障的兩個時點各生成一份“問題分析”報告，發過來。
從等待事件分析方面可以看出，排在前幾位的都是GC相關的指標，其中也發現了AUD$這張表存在熱點。
從IO上看，IOPS/IO吞吐量都不算太高。OS方面應該沒有太大的IO壓力。因為客戶那邊的安全限制，這個系統的所有操作系統層面的指標以及日志都沒有采集，因此我們無法分析操作系統IO延時是否正常。
不過從報告中可以看出，幾乎所有的數據庫寫IO指標都超標，而讀IO指標沒有一個是超標的。這就更讓人費解了。
另外一個節點也出現了LOGON超時的現象，不過從問題分析報告上看，等待事件完全不同。排在前幾位的是log file sync等與IO相關的指標。同時我們也發現系統中存在gcs log flush sync的現象。
從這些問題上看，AUD$寫入延時加大并不是因而更像是插入數據的性能受到了其他方面的問題的影響。于是我讓現場DBA把操作系統日志與數據庫日志都發過來。
在出現GC爭用的節點上，日志一切正常，而在出現Log file sync延時超時的節點上，我發現了多路徑抖動的日志告警信息。自此，這個問題的脈絡已經十分清晰了。因為節點2上的多路徑抖動，導致了IO延時的不穩定，從而引發了AUD$插入數據的性能問題，最終導致了LOGON超時。
一個不經意的發現，排除了一個系統的嚴重隱患，這套系統每個月月底和月初是十分繁忙的，要做大量的數據寫入和計算。幸虧問題在業務十分小的時候被發現了。否則月底肯定會出大問題的。而這個問題的發現過程也有很大的偶然成分。本來現場DBA認為已經解決了這個問題。要不是現場與后端的這個故障案例共享機制的存在，這個隱患很可能要到引發大問題的時候才會被發現。
而分析問題，大部分情況下，我們僅僅是從表象入手，問題暫時不重現就算搞定了。而如果分析這個問題的人缺少對數據庫機理的深入理解，是很難從這些表象中發現深層次的問題的。而且實際上，在運維體系中，一線工程師也不可能放置如此高水平的DBA的。
正是因為這個原因，我們一直強調，工具不是萬能的，一線駐場運維也不是萬能的。必須形成一個良好的問題閉環分析生態，讓高水平的專家、一線、二線運維人員、高質量的監控數據采集與分析工具相結合，形成一個完整的體系，才能夠更為高效與準確的分析問題和解決問題。
而從表象與機理這個問題上，我一直強調問題溯源或者說根因溯源的重要性。以前與一些運維專家討論過這個問題，一些互聯網企業出身的人認為系統出問題，有高可用機制可以解決就行了，切掉有問題的部分組件自然就解決問題了。還有一些人認為出問題后盡快回復運行是關鍵，根因分析能做則做，不能做就算了，企業無法投入如此大的成本。
從某些場景和用戶的角度來說，這些觀點也都沒錯。不過并不是所有的企業都有互聯網企業那么完備的高可用機制，也不是所有的系統都是重啟一下就能解決問題的。因此問題溯源，問題閉環對于大部分企業來說，應該還是有價值的。目前無法全面開展的最主要問題還是成本太高，能力不足的問題。IT健康管理機制就是為了解決這種分散分析的成本問題的，通過一二三線聯動，通過D-SMART豐富的數據采集與診斷報告，再加上最近推出的holadata數據交換工具。三線專家可以足不出戶為全國的客戶做服務，其效率提升是十分明顯的。昨天的這個問題，算上在微信群里的討論以及現場采集數據的時間，專家參與定位問題的時間也不過20分鐘而已。
