?上周五客戶那邊出現(xiàn)了一個很奇怪的故障，剛開始我們以為很簡單，一個用戶環(huán)境的Oracle 11g數(shù)據(jù)庫報了一個ORA-4030錯誤，對于DBA來說，這個錯誤太常見了，馬上聯(lián)想到物理內(nèi)存不足了。

不過D-SMART的監(jiān)控并未產(chǎn)生物理內(nèi)存不足的告警，從監(jiān)控指標上看，也沒有出現(xiàn)物理內(nèi)存突然下降的時點。

D-SMART的診斷工具中也沒有發(fā)現(xiàn)任何物理內(nèi)存不足的情況，從ULIMIT上看也沒有看到任何異常，和內(nèi)存相關的限制都是unlimited。當時有點一頭霧水的感覺，這肯定是一個我們以前比較少遇到的場景，并且在我們的運維知識圖譜中并沒有收錄這個故障模型。

于是我們再次研究了錯誤信息，發(fā)現(xiàn)OS報錯的errno和普通的系統(tǒng)物理內(nèi)存耗盡導致的ORA-4030不同，而是errno=12，無法mmap進程內(nèi)存。隨后通過分析發(fā)現(xiàn)這是因為vm.max_map_count參數(shù)不足，導致進程的內(nèi)存映射表溢出而無法分配進程內(nèi)存，并不是OS真的沒有內(nèi)存可分配了。

這個數(shù)據(jù)庫的硬件配置很高，物理內(nèi)存有1.5TB，SGA就分配了1TB，所以在這種環(huán)境下，默認的CENTOS的max_map_count（65530）不夠用了。實際上在一些Oracle官方文檔上對于這個參數(shù)也有建議，在物理內(nèi)存較大的環(huán)境下，至少應該設置為20萬以上，Oracle 12C的典型設置為262144。

周六早上沒事的時候，我又想起了這個案例，想和CHATGPT聊聊這件事。活見鬼了，CHATGPT秒回的處置方案與我們折騰了小半天得到的居然是完全相同的。從這個案例中我又想到了如果經(jīng)過訓練，讓CHATGPT來幫助我們分析日志是否可行呢。于是我找了一個以前的ora-01555報錯的案例輸入CHATGPT來分析。

這個回答中規(guī)中矩，不算太出彩，不過也大體上沒問題，大多數(shù)DBA對于ORA-01555的認知也差不多如此。

我輸入了另外一條SQL，這里有一個小變化，Query Duratinotallow=0,這種ORA-01555錯誤是另外一個原因?qū)е碌?，并不是UNDO RETENTION不足，不過CHATGPT的回答還是老一套，并沒有能夠區(qū)分出這個小小的不同。

于是我把相關的BUG報告輸入，繼續(xù)訓練CHATGPT，訓練完成之后，再來問這個問題?？梢钥闯?，CHATGPT已經(jīng)能夠發(fā)現(xiàn)Query Duration的問題了，看樣子我剛才的訓練是有效的。當然回答并不完美，這和我剛才的訓練比較簡單有關。

通過這幾個案例，我們也看出了大語言模型在運維上的一個前景，那就是只要有足夠的并且相對準確的語料訓練，大語言模型可以在智能運維中發(fā)揮很大的作用。起碼在日志分析方面，目前CHATGPT在基礎能力上已經(jīng)相當不錯了。下面我們再來看幾個例子，這些例子輸入之前，我并沒有做針對性的語料訓練，完全是依靠CHATGPT原有的模型完成的。

我想一個不是很資深的DBA很可能都沒法回答的如此到位，這個回答雖然達不到專家的水平，已經(jīng)遠超出一般的高級DBA了。

這個對Oracle State object數(shù)據(jù)的解讀也十分到位，通過代碼要解析這樣的數(shù)據(jù)還是需要花點時間的。

我們再來看一些稍微復雜一些的，這段reconfiguration的解釋也十分到位了，雖然從回答上看還沒有包含太多的Oracle RAC的內(nèi)部原理，不過對日志的解讀已經(jīng)十分細致了。如果我們用一些關于reconfiguration的內(nèi)部實現(xiàn)的技術資料來訓練一下，我想分析的會更為深入。

周日晚上我和幾個搞智能化運維算法的朋友交流了一下這個問題，他們都覺得這個方向值得研究。裴丹老師認為粗略而言，模型都是概率，包括條件概率；只要答案相對確定，模型就會獲得大概率，回答就會相對靠譜。否則不行。這是從算法層面對這個問題的比較準確的總結，答案的唯一性越高，回答的準確性就會越高。

對于日志智能分析來說，有上述的保證已經(jīng)是足夠了，如果我們能收集到大量的案例，提高訓練的語料質(zhì)量也有助于提高模型的準確性。從這個方面來看，利用預訓練的大語言模型來做智能運維中的日志分析，應該是完全可行的。這給我們做智能化日志分析提供了一個新的路線圖。

不過要完成這個工作也并不簡單，首先需要用正確的知識去做訓練，其次需要大量的訓練，從而確保從概率上，正確的回答會占據(jù)優(yōu)勢。在現(xiàn)實工作中，要實現(xiàn)這兩點都需要大量的成本。從目前CHATGPT的回答看，它學習的都是大量的常規(guī)知識，所以對一般性的問題的回答中規(guī)中矩。其水平無法替代一個高級DBA，更無法替代專家了。因為這些訓練中缺乏專家所擁有的在常規(guī)知識基礎上的細節(jié)和深度知識，要想讓CHATGPT具有專家的能力，必須要讓專家來訓練它，或者利用大量已知的專項知識點來訓練它。比如把Oracle Mos的大量note和bug報告輸入訓練。因為訓練所需要的素材（包括經(jīng)驗、知識、案例、BUG報告等）十分龐大，因此這項工作僅僅依靠某個團隊或者某個企業(yè)是很難完成的，必須通過社區(qū)化的運作才更容易成功。

第二個方面是知識的準確性問題，如果大量的錯誤的知識被用來訓練，那么基于概率，錯誤的答案會將正確的模型驅(qū)逐出答案中。而判斷知識的正確性是個十分困難的問題，對于同一個問題，甚至不同的專家都會有歧義。因此模型的訓練必須有大量的專家參與。

今天我僅僅看到了大語言模型用于數(shù)據(jù)庫故障診斷，日志分析，系統(tǒng)優(yōu)化等方面的一種可能性，而并沒有找到真正實現(xiàn)它的路徑。要想實現(xiàn)它，除了技術，更重要的是資本的參與。不過既然可行，那么總有一天，我們能看到它。?