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

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

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

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

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

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

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

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

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

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

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