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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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