Oracle的自治數(shù)據(jù)庫(kù)技術(shù)很強(qiáng)大，也有不少國(guó)產(chǎn)數(shù)據(jù)庫(kù)想跟進(jìn)。最近這段時(shí)間里我和很多國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商都探討過如何學(xué)習(xí)Oracle的自治數(shù)據(jù)庫(kù)技術(shù)，利用AI技術(shù)讓國(guó)產(chǎn)數(shù)據(jù)庫(kù)的運(yùn)維與優(yōu)化變得更加簡(jiǎn)單。因?yàn)樽罱液虳BAIOPS社區(qū)一起在利用大模型做智能化分析方面做了一些探索，在Oracle數(shù)據(jù)庫(kù)上取得了不錯(cuò)的效果。因此剛開始的時(shí)候，我覺得利用在Oracle上做智能運(yùn)維的方法論復(fù)制到國(guó)產(chǎn)數(shù)據(jù)庫(kù)上應(yīng)該不是特別難的事情。

不過經(jīng)過這段時(shí)間的探索，我越來越覺得難度很大。目前的數(shù)據(jù)庫(kù)智能診斷與分析依舊是對(duì)人類專家的一種模仿，而并沒有創(chuàng)造出新的方法，可以繞過數(shù)據(jù)庫(kù)的基礎(chǔ)原理與專家經(jīng)驗(yàn)去實(shí)現(xiàn)強(qiáng)大的AI運(yùn)維。既然是模仿人類專家的工作方法和思維方式，通過大模型的數(shù)據(jù)分析、數(shù)據(jù)處理和推理能力去做AI分析，那么其天花板就是人類專家的能力極限。有人說既然AI分析無法突破人類專家的極限，那么還有什么意義呢？實(shí)際上有沒有意義并非這么簡(jiǎn)單的，首先是AI推理的效率要遠(yuǎn)遠(yuǎn)高于人類專家，人類專家可能需要通過數(shù)個(gè)小時(shí)去分析和推理的工作，AI可能只需要數(shù)分鐘。另外一點(diǎn)是AI推理是可以固化到系統(tǒng)中去復(fù)制的，而人類專家是無法復(fù)制的。

雖然AI推理的價(jià)值很大，但是面對(duì)國(guó)產(chǎn)數(shù)據(jù)庫(kù)的時(shí)候，依然面臨巨大的挑戰(zhàn)。首先是可觀測(cè)性的問題，這方面PG系的國(guó)產(chǎn)數(shù)據(jù)庫(kù)稍微好一點(diǎn)，PG的客觀性能力雖然與O記相比，還有很大差距，不過基礎(chǔ)的數(shù)據(jù)大多數(shù)還是有的，再加上以PG為內(nèi)核研發(fā)的國(guó)產(chǎn)數(shù)據(jù)庫(kù)在PG的系統(tǒng)視圖上又模仿Oracle做了一些增強(qiáng)。因此目前看來PG系的國(guó)產(chǎn)數(shù)據(jù)庫(kù)的可觀測(cè)性還是最為豐富的。MySQL本身的可觀測(cè)性能力就比較弱，不過因?yàn)镸ySQL足夠簡(jiǎn)單，也湊合用了。反而是一些自研比例比較高的國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)品的可觀測(cè)性能力挺令人崩潰的。

雖然各大國(guó)產(chǎn)數(shù)據(jù)庫(kù)都推出了類似Oracle AWR/ASH報(bào)告的診斷報(bào)告，號(hào)稱可以像Oracle一樣給DBA提供最直接的幫助。但是我目前看到的國(guó)產(chǎn)數(shù)據(jù)庫(kù)的AWR報(bào)告，沒有一個(gè)真正能像Oracle一樣，讓人能夠從中分析出數(shù)據(jù)庫(kù)存在的各種問題。有朋友說，這是因?yàn)閲?guó)產(chǎn)數(shù)據(jù)庫(kù)沒有類似Oracle的MOS，其實(shí)這只說出了一個(gè)方面。除了缺乏Mos這樣的知識(shí)庫(kù)之外，國(guó)產(chǎn)數(shù)據(jù)庫(kù)指標(biāo)體系的不完善，是一個(gè)更大的問題。從國(guó)產(chǎn)數(shù)據(jù)庫(kù)的AWR報(bào)告中，我們唯一能夠看到的類似Oracle的數(shù)據(jù)就是TOP SQL，除了TOP SQL之外，其他的數(shù)據(jù)的價(jià)值差距太大。

對(duì)于這個(gè)問題，以前沒有做AI診斷的時(shí)候還沒有特別關(guān)注，因?yàn)槲覀儗?duì)這些數(shù)據(jù)庫(kù)產(chǎn)品的使用和研究也比較粗淺，看到某些數(shù)據(jù)庫(kù)中的指標(biāo)數(shù)量也不少，就以為可能也夠用了。當(dāng)我們要把問題交給AI去分析的時(shí)候，我們必須給AI輸入足夠豐富的數(shù)據(jù)，以便于實(shí)現(xiàn)自動(dòng)化診斷。這個(gè)時(shí)候我們就會(huì)發(fā)現(xiàn)，分析某些問題所需要的指標(biāo)缺失得比較多。比如我們?nèi)绻胍谀硞€(gè)數(shù)據(jù)庫(kù)中分析是否存在較多的全表掃描問題的時(shí)候，在Oracle和PG數(shù)據(jù)庫(kù)中我們可以根據(jù)每秒表掃描/每秒大表掃描等指標(biāo)來粗略地判斷。而在某些國(guó)產(chǎn)數(shù)據(jù)庫(kù)中無法找到類似的指標(biāo)，或者說某些指標(biāo)被定義了，但是里面并沒有輸出統(tǒng)計(jì)數(shù)據(jù)，有些是需要開啟一些非默認(rèn)的采集才能看到數(shù)據(jù)，有些則壓根兒就是個(gè)擺設(shè)，僅僅是為今后提供這些數(shù)據(jù)預(yù)留了接口。

我曾經(jīng)就這個(gè)問題咨詢了某個(gè)國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商，他的回答很干脆，目前這些指標(biāo)都有，但是實(shí)際上內(nèi)核都沒有統(tǒng)計(jì)。我就問他，那么我如何去發(fā)現(xiàn)數(shù)據(jù)庫(kù)中的表掃描問題比較嚴(yán)重呢？他說，那不是很簡(jiǎn)單的事情，分析SQL的執(zhí)行計(jì)劃不就知道了。

當(dāng)然，分析SQL的執(zhí)行計(jì)劃我們肯定可以發(fā)現(xiàn)SQL中存在的不合理的表掃描，進(jìn)一步發(fā)現(xiàn)索引設(shè)計(jì)不合理等問題。但是一竿子直接打到SQL，是不是有點(diǎn)過于簡(jiǎn)單粗暴了呢？如果我事先并不知道哪些SQL有問題，難道我還得一個(gè)個(gè)SQL去分析？

事實(shí)上，在目前的的大多數(shù)國(guó)產(chǎn)數(shù)據(jù)庫(kù)用戶那邊，現(xiàn)在的絕大多數(shù)國(guó)產(chǎn)數(shù)據(jù)庫(kù)運(yùn)維僅僅限于分析數(shù)據(jù)庫(kù)日志和優(yōu)化SQL。除此之外的運(yùn)維分析手段是十分有限的。如果現(xiàn)場(chǎng)運(yùn)維人員無法從日志和SQL中解決問題，那么就比較麻煩了，非原廠工程師無法處置這樣的故障，甚至有時(shí)候原廠工程師來了也解決不了。

過節(jié)期間，我們?cè)跍y(cè)試一個(gè)某國(guó)產(chǎn)數(shù)據(jù)庫(kù)的鎖阻塞場(chǎng)景的時(shí)候，阻塞鎖已經(jīng)模擬出來了，但是在會(huì)話狀態(tài)的阻塞標(biāo)志中，就是查不到這個(gè)阻塞的存在。而幾天前這個(gè)場(chǎng)景是能夠輕松模擬出來的，可能是我們這兩天調(diào)整了一些數(shù)據(jù)庫(kù)參數(shù)，就出問題了。這很可能是某個(gè)BUG，也可能是某種特殊狀態(tài)，但是對(duì)于我們來說，這個(gè)是一個(gè)黑盒子，完全無從分析。這種情況是國(guó)產(chǎn)數(shù)據(jù)庫(kù)可觀測(cè)性問題的第二種問題，那就是可觀測(cè)性接口不能夠比較準(zhǔn)確地反映出國(guó)產(chǎn)數(shù)據(jù)庫(kù)的運(yùn)行情況。

第三種常見的問題是與運(yùn)維經(jīng)驗(yàn)缺失有關(guān)的。前幾天我們?cè)谡{(diào)試一個(gè)故障模型的時(shí)候發(fā)現(xiàn)調(diào)整某個(gè)參數(shù)有助于提升數(shù)據(jù)庫(kù)并發(fā)處理的能力。但是我們?cè)谧稍兡承┯脩艉驮瓘S工程師的時(shí)候，他們都認(rèn)為這個(gè)參數(shù)是不建議調(diào)整的。要提升并發(fā)處理能力，一般都是建議給某個(gè)租戶分配更多的資源，而不是通過調(diào)整這個(gè)參數(shù)，但是為什么必須這么做，誰都說不清楚。在官方文檔中我看到了不建議調(diào)整該參數(shù)的警告，說是如果調(diào)得太小，影響性能，調(diào)得太大，消耗過多的CPU和內(nèi)存資源，都會(huì)引發(fā)數(shù)據(jù)庫(kù)運(yùn)行的不穩(wěn)定。能夠在官方文檔里有這樣得說明，在國(guó)產(chǎn)數(shù)據(jù)庫(kù)得文檔里算是不錯(cuò)了，起碼在文檔里包含了一定的運(yùn)維經(jīng)驗(yàn)。不過這還不夠，需要有幾篇類似MOS文檔的知識(shí)庫(kù)來專門闡述這個(gè)問題。既然這個(gè)參數(shù)存在，那就肯定不是當(dāng)擺設(shè)用的，怕用戶調(diào)錯(cuò)出問題，這個(gè)出發(fā)點(diǎn)是好的，不過不夠好，如果能夠讓用戶學(xué)會(huì)通過調(diào)整這個(gè)參數(shù)來優(yōu)化自己的系統(tǒng)，那才是真的好。

數(shù)據(jù)庫(kù)原廠可能都不知道如何維護(hù)和調(diào)整數(shù)據(jù)庫(kù)，這是目前我們?cè)谑褂脟?guó)產(chǎn)數(shù)據(jù)庫(kù)的時(shí)候面臨的一個(gè)更加尷尬的場(chǎng)面。國(guó)產(chǎn)數(shù)據(jù)庫(kù)，想讓用戶用好并不容易，除了穩(wěn)定性和性能之外，可觀測(cè)性能力是國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商急需補(bǔ)課的地方，如果搞不好這方面的技術(shù)問題，數(shù)據(jù)庫(kù)就會(huì)變成一個(gè)黑盒子，想用好數(shù)據(jù)庫(kù)產(chǎn)品，必須依賴于原廠研發(fā)輔助分析，這樣的業(yè)務(wù)模式在目前階段服務(wù)于少量頭部客戶的時(shí)候，還湊合能頂?shù)米。脩舳嗔耍瑪?shù)據(jù)庫(kù)廠商首先就支撐不住了。