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

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

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

于是我們?cè)俅窝芯苛隋e(cuò)誤信息，發(fā)現(xiàn)OS報(bào)錯(cuò)的errno和普通的系統(tǒng)物理內(nèi)存耗盡導(dǎo)致的ORA-4030不同，而是errno=12，無(wú)法mmap進(jìn)程內(nèi)存。隨后通過(guò)分析發(fā)現(xiàn)這是因?yàn)関m.max_map_count參數(shù)不足，導(dǎo)致進(jìn)程的內(nèi)存映射表溢出而無(wú)法分配進(jìn)程內(nèi)存，并不是OS真的沒(méi)有內(nèi)存可分配了。

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

周六早上沒(méi)事的時(shí)候，我又想起了這個(gè)案例，想和CHATGPT聊聊這件事?；钜?jiàn)鬼了，CHATGPT秒回的處置方案與我們折騰了小半天得到的居然是完全相同的。從這個(gè)案例中我又想到了如果經(jīng)過(guò)訓(xùn)練，讓CHATGPT來(lái)幫助我們分析日志是否可行呢。于是我找了一個(gè)以前的ora-01555報(bào)錯(cuò)的案例輸入CHATGPT來(lái)分析。

這個(gè)回答中規(guī)中矩，不算太出彩，不過(guò)也大體上沒(méi)問(wèn)題，大多數(shù)DBA對(duì)于ORA-01555的認(rèn)知也差不多如此。

我輸入了另外一條SQL，這里有一個(gè)小變化，Query Duratinotallow=0,這種ORA-01555錯(cuò)誤是另外一個(gè)原因?qū)е碌模⒉皇荱NDO RETENTION不足，不過(guò)CHATGPT的回答還是老一套，并沒(méi)有能夠區(qū)分出這個(gè)小小的不同。

于是我把相關(guān)的BUG報(bào)告輸入，繼續(xù)訓(xùn)練CHATGPT，訓(xùn)練完成之后，再來(lái)問(wèn)這個(gè)問(wèn)題。可以看出，CHATGPT已經(jīng)能夠發(fā)現(xiàn)Query Duration的問(wèn)題了，看樣子我剛才的訓(xùn)練是有效的。當(dāng)然回答并不完美，這和我剛才的訓(xùn)練比較簡(jiǎn)單有關(guān)。

通過(guò)這幾個(gè)案例，我們也看出了大語(yǔ)言模型在運(yùn)維上的一個(gè)前景，那就是只要有足夠的并且相對(duì)準(zhǔn)確的語(yǔ)料訓(xùn)練，大語(yǔ)言模型可以在智能運(yùn)維中發(fā)揮很大的作用。起碼在日志分析方面，目前CHATGPT在基礎(chǔ)能力上已經(jīng)相當(dāng)不錯(cuò)了。下面我們?cè)賮?lái)看幾個(gè)例子，這些例子輸入之前，我并沒(méi)有做針對(duì)性的語(yǔ)料訓(xùn)練，完全是依靠CHATGPT原有的模型完成的。

我想一個(gè)不是很資深的DBA很可能都沒(méi)法回答的如此到位，這個(gè)回答雖然達(dá)不到專(zhuān)家的水平，已經(jīng)遠(yuǎn)超出一般的高級(jí)DBA了。

這個(gè)對(duì)Oracle State object數(shù)據(jù)的解讀也十分到位，通過(guò)代碼要解析這樣的數(shù)據(jù)還是需要花點(diǎn)時(shí)間的。

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

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

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

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

第二個(gè)方面是知識(shí)的準(zhǔn)確性問(wèn)題，如果大量的錯(cuò)誤的知識(shí)被用來(lái)訓(xùn)練，那么基于概率，錯(cuò)誤的答案會(huì)將正確的模型驅(qū)逐出答案中。而判斷知識(shí)的正確性是個(gè)十分困難的問(wèn)題，對(duì)于同一個(gè)問(wèn)題，甚至不同的專(zhuān)家都會(huì)有歧義。因此模型的訓(xùn)練必須有大量的專(zhuān)家參與。

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