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

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

19C的自動診斷也發現了活躍會話數的問題，不過定位的結論不是很準確，發現了提交與回滾較多，SGA配置問題，會話存在短鏈接以及因為invaliation導致的硬解析比較多這幾個問題。

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

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

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

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

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

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

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

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

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

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

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

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

說實在的，這類十分復雜的問題，使用深度學習構建模型是最好的，因為這上千個指標里面的復雜的關系，可能專家也不一定都能夠總結和分析的清楚。不過理論上的最好實際上不一定能夠實現。此類問題，我最近的5/6年里也不過遇到過四五次，沒有足夠的樣本，深度學習也好，人工智能也好，都無法構建出模型出來。

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

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

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

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