大語言模型與資料庫故障診斷

上週五客戶那邊出現了一個很奇怪的故障，剛開始我們以為很簡單，一個使用者環境的Oracle 11g資料庫報了一個ORA-4030錯誤，對於DBA來說，這個錯誤太常見了，馬上聯想到實體記憶體不足了。

不過D-SMART的監控並未產生實體記憶體不足的告警，從監控指標上看，也沒有出現實體記憶體突然下降的時點。

D-SMART的診斷工具中也沒有發現任何實體記憶體不足的情況，從ULIMIT上看也沒有看到任何異常，和記憶體相關的限制都是unlimited。當時有點一頭霧水的感覺，這肯定是一個我們以前比較少遇到的場景，並且在我們的運維知識圖譜中並沒有收錄這個故障模型。

於是我們再次研究了錯誤資訊，發現OS報錯的errno和普通的系統實體記憶體耗盡導致的ORA-4030不同，而是errno=12，無法mmap程式記憶體。隨後透過分析發現這是因為vm.max_map_count引數不足，導致程式的記憶體對映表溢位而無法分配程式記憶體，並不是OS真的沒有記憶體可分配了。

這個資料庫的硬體配置很高，實體記憶體有1.5TB，SGA就分配了1TB，所以在這種環境下，預設的CENTOS的max_map_count(65530)不夠用了。實際上在一些Oracle官方文件上對於這個引數也有建議，在實體記憶體較大的環境下，至少應該設定為20萬以上，Oracle 12C的典型設定為262144。

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

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

我輸入了另外一條SQL，這裡有一個小變化，Query Duration=0,這種ORA-01555錯誤是另外一個原因導致的，並不是UNDO RETENTION不足，不過CHATGPT的回答還是老一套，並沒有能夠區分出這個小小的不同。

於是我把相關的BUG報告輸入，繼續訓練CHATGPT，訓練完成之後，再來問這個問題。可以看出，CHATGPT已經能夠發現Query Duration的問題了，看樣子我剛才的訓練是有效的。當然回答並不完美，這和我剛才的訓練比較簡單有關。

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

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

這個對Oracle State object資料的解讀也十分到位，透過程式碼要解析這樣的資料還是需要花點時間的。

我們再來看一些稍微複雜一些的，這段reconfiguration的解釋也十分到位了，雖然從回答上看還沒有包含太多的Oracle RAC的內部原理，不過對日誌的解讀已經十分細緻了。如果我們用一些關於reconfiguration的內部實現的技術資料來訓練一下，我想分析的會更為深入。

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

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

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

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

今天我僅僅看到了大語言模型用於資料庫故障診斷，日誌分析，系統最佳化等方面的一種可能性，而並沒有找到真正實現它的路徑。要想實現它，除了技術，更重要的是資本的參與。不過既然可行，那麼總有一天，我們能看到它。