這是一個(gè)去年的案例，正值疫情期間，我剛剛從機(jī)場出來，因?yàn)?8小時(shí)核酸的問題，我被迫從上海繞道去南京。飛機(jī)落地后打開手機(jī)就看到一個(gè)網(wǎng)友給我在微信上的留言，是一個(gè)客戶的系統(tǒng)有點(diǎn)問題。

客戶那邊反饋是系統(tǒng)有點(diǎn)慢，維保服務(wù)廠商搞不定找到他了。他上去看了看，發(fā)現(xiàn)除了活躍會(huì)話數(shù)多了一些，和平時(shí)差別并不大，做了AWR報(bào)告才發(fā)現(xiàn)似乎系統(tǒng)的IO有問題，因?yàn)閘og file parallel write和db file parallel write都比較差，不過db file sequential read等讀IO的指標(biāo)好像還是正常的。從發(fā)來的AWR的ADDM信息看，似乎也抓不到什么有用的信息。

19C的自動(dòng)診斷也發(fā)現(xiàn)了活躍會(huì)話數(shù)的問題，不過定位的結(jié)論不是很準(zhǔn)確，發(fā)現(xiàn)了提交與回滾較多，SGA配置問題，會(huì)話存在短鏈接以及因?yàn)閕nvaliation導(dǎo)致的硬解析比較多這幾個(gè)問題。

很多經(jīng)驗(yàn)不足的DBA往往會(huì)根據(jù)數(shù)據(jù)庫ADDM等自動(dòng)診斷的結(jié)論去分析問題，而一個(gè)稍微有些經(jīng)驗(yàn)的DBA很容易從下面的Load profile中的信息就把這些問題排除掉了。

因?yàn)槊棵?2.2個(gè)提交，0.1個(gè)rollback,1300+的執(zhí)行，5.1的硬解析，無論如何都是談不上多的，甚至每秒31M+的讀寫IO，也算不得大IO。ADDM的智能化診斷實(shí)際上只是針對(duì)time model的一個(gè)解讀，從中找出TOP n的因素而已，對(duì)于實(shí)際問題的定位往往是不準(zhǔn)確的。

不過這個(gè)案例并不復(fù)雜，在飛機(jī)滑行的這幾分鐘里，我已經(jīng)初步定位了問題。雖然在廊橋那里耽擱了幾分鐘，十幾分鐘后，坐上網(wǎng)約車后，我就給和朋友通了電話，把我的分析結(jié)果告訴了他。

我的初步判斷是，如果客戶存在存儲(chǔ)同步復(fù)制，那么問題應(yīng)該出在同步復(fù)制的鏈路上了，應(yīng)該是有一條復(fù)制鏈路不穩(wěn)定，導(dǎo)致寫IO延時(shí)很大，而讀IO因?yàn)椴簧婕斑h(yuǎn)程復(fù)制鏈路的問題，因此沒有受到影響。

實(shí)際上此類問題如果你以前遇到過，那么還是很快會(huì)找到診斷方向的，如果你沒有遇到過，就比較難于定位問題了。因?yàn)閷?duì)于此類問題有較豐富的經(jīng)驗(yàn)，因此我可以在幾分鐘內(nèi)就完成問題的定位。這個(gè)經(jīng)驗(yàn)不僅僅是讀IO是好的，寫IO是不好的這么簡單。

從TOP 10 前臺(tái)等待事件上看，日志同步，直接路徑寫，BBW，cursor: pin S wait on X等的等待事件平均延時(shí)都很高，而以往常見的db file sequential read等都已經(jīng)在TOP 10里消失了。這還不足以定位為存儲(chǔ)存在問題。在如此小的負(fù)載下出現(xiàn)此類問題，還有好幾種可能性，比如最為典型的numa導(dǎo)致的問題，沒有使用hugepage導(dǎo)致的問題，共享池導(dǎo)致的問題等，都可能出現(xiàn)類似的現(xiàn)象。因此需要首先排除掉這樣的問題，才能做出較為準(zhǔn)確的定位。

這種分析對(duì)于遇到過此類問題的專家來說十分簡單，而對(duì)于沒有遇到過問題的人來說，可能會(huì)一籌莫展，主要原因是里面涉及了十分復(fù)雜的邏輯。

我們首先要通過user_time和sys_time的比例關(guān)系等OS層面的情況來排除NUMA以及HUGEPAGE引起的問題。其次要通過詳細(xì)的前臺(tái)進(jìn)程等待事件中關(guān)于共享池的事件的平均等待延時(shí)來排除共享池導(dǎo)致的問題。

這個(gè)排除工作相對(duì)會(huì)比較麻煩，因?yàn)镮O延時(shí)的異常反過來也會(huì)影響共享池的相關(guān)指標(biāo)，需要多看幾個(gè)，綜合來考慮才能做出正確的判斷。

從柱狀圖中，我們可以看出db file parallel write的大多數(shù)IO都小于2ms，不過還是有3.3%的IO是異常的，而且是大于32毫秒的。

再仔細(xì)看一下就會(huì)發(fā)現(xiàn)，這3.3%的IO都是大于4秒鐘延時(shí)的，如果分析到這里，存儲(chǔ)復(fù)制鏈路存在抖動(dòng)的結(jié)論成立的可能性就超過8成了。正是因?yàn)檫@個(gè)原因，我才能在幾分鐘內(nèi)做出那個(gè)判斷。和朋友通過電話40分鐘后，這個(gè)判斷被確認(rèn)了。

似乎大家看完這個(gè)案例覺得并不復(fù)雜，只要有過這樣的經(jīng)驗(yàn)，下回就能夠分析這個(gè)問題了。確實(shí)是的，遇到過類似問題的DBA下回你遇到這個(gè)問題的時(shí)候就多了一條診斷路徑，這就是運(yùn)維經(jīng)驗(yàn)的積累。做到這一點(diǎn)還不夠，因?yàn)閷?duì)于水平高的DBA，看了我今天的文章后，下回遇到類似問題就可以進(jìn)行分析了。而對(duì)于大多數(shù)人來說，下回遇到此類問題也不一定就能處理的好。這種運(yùn)維經(jīng)驗(yàn)需要固化下來，形成自動(dòng)化診斷分析的模型，才能更好的積累。

說實(shí)在的，這類十分復(fù)雜的問題，使用深度學(xué)習(xí)構(gòu)建模型是最好的，因?yàn)檫@上千個(gè)指標(biāo)里面的復(fù)雜的關(guān)系，可能專家也不一定都能夠總結(jié)和分析的清楚。不過理論上的最好實(shí)際上不一定能夠?qū)崿F(xiàn)。此類問題，我最近的5/6年里也不過遇到過四五次，沒有足夠的樣本，深度學(xué)習(xí)也好，人工智能也好，都無法構(gòu)建出模型出來。

此類小概率發(fā)生的問題的知識(shí)積累還有另外一種方法，那就是依靠專家根據(jù)有限的樣本去進(jìn)行抽象分析，構(gòu)建出知識(shí)圖譜，并通過知識(shí)圖譜來勾畫出一個(gè)故障模型了。

如果我們對(duì)數(shù)據(jù)庫的內(nèi)部原理有了充分的了解后，這種抽象就變得可行了。雖然抽象出來的故障模型的精確性可能還無法一下子達(dá)到很高的水準(zhǔn)，不過一個(gè)故障模型剛剛開始構(gòu)建的時(shí)候達(dá)到70-80%的準(zhǔn)確性還是可以達(dá)到的，隨著在實(shí)際生產(chǎn)環(huán)境中的磨合，通過調(diào)參或者添加關(guān)系等方式，還可以進(jìn)一步優(yōu)化模型。

這個(gè)故障模型的簡圖，有興趣的朋友可以研究研究，這些因素是不是能夠定義這個(gè)故障了。這些分析，人腦去分析，也就幾分鐘就可以完成的。而要讓這個(gè)模型變成自動(dòng)化模型，還是需要繼續(xù)花點(diǎn)心思的。

在企業(yè)的運(yùn)維自動(dòng)化系統(tǒng)中，如果能夠把梳理抽象的結(jié)果變成自動(dòng)化發(fā)現(xiàn)的模型，那么下回類似問題出現(xiàn)的時(shí)候，哪怕分析過此類問題的專家不在現(xiàn)場，稍微有點(diǎn)經(jīng)驗(yàn)的DBA也能夠很快發(fā)現(xiàn)問題，并根據(jù)系統(tǒng)的提示正確地進(jìn)行問題分析了。這種故障模型或者運(yùn)維經(jīng)驗(yàn)的積累，可以讓運(yùn)維知識(shí)真正成為企業(yè)IT部門的核心資產(chǎn)。