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

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

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

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

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

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

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

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

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

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

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