自治數據庫是我們這代DBA二十多年前就開始的一個夢，現在O記離我們那個夢想越來越近了，其實哪怕沒有自治數據庫技術的加持，O記的運維也越來越便捷，讓人放心。為了提升客戶使用體驗，很多國產數據庫也在學O記的經驗，模仿出了國產版的AWR/ASH/ADDM，也在做自治數據庫相關的組件。我使用過很多國產數據庫的這方面的工具，總覺得學得還不太到位。

我運維過從ORACLE 5.1到19C的多個數據庫版本，深深感受到O記這些年在運維便捷性上的巨大提升。從早期的黑盒子到6.x之后可以通過各種命中率來分析和優化數據庫應用的性能；7.3的utlbstat/utlestat工具終于讓我看到了數據庫內部的一些詳細數據；后來有了Oracle 8的statspack報告，DBA終于不用在黑暗中摸索了；Oracle 10g的AWR/ASH和ADDM則開創了深度分析平民化的道路，哪怕不太懂Oracle OWI和Time Model 的DBA也能快速從中找到一些有用的數據。

運維ORACLE數據庫的時候，哪怕沒有自治技術加持，有了強大的OWI，METRIC，Time Model 等數據和工具，加上MOS網站（Metalink）的加持，總是會讓人很放心。因為只要問題可再現，發現根因只是時間問題，實在不行開個SR就OK了。

國產數據庫雖然也在學著O記做類似的事情，但是效果往往不佳。雖然各個廠商都號稱自己的可觀測性能力以及自制數據庫的能力都強大無比，但是在實際的用戶場景中卻很難看到真實的成功案例，用戶遇到SQL以外的嚴重問題，基本上還是要靠原廠才能搞得定，這到底是怎么回事呢？

實際上自治數據庫的自治能力并非一蹴而就的，而是要依賴于一層一層的基礎能力，往上堆疊出來的。要想實現真正的自治，從底層能力而言，必須完成數據庫全面的數字化建模，數據庫本身的底層數據邏輯能夠覆蓋問題分析所需要的所有層面，而要完成數字化建模，又必須依賴于豐富并且準確的可觀測性體系（指標、日志、跟蹤），要想有豐富而準確的可觀測性體系，必須在數據庫內核里構建出豐富而準確的數字化模型，并高效地完成相關數據的采樣與處理，又不能影響數據庫的性能。在上層，又必須構建起完善的知識庫體系，對這些數據的解析與分析都是構建在知識體系之上的。

經過三十多年的發展，O記在此的技術積累已經十分豐富。而國產數據庫在這方面還差之甚遠，甚至在某些領域還處于空白階段。很多國產數據庫廠商根本不清楚，要想獲得強大的數據庫自治能力，不是開發幾個工具就可以解決的，數字化基礎是關鍵，首先要把能夠準確描述數據庫運行狀態的各種指標體系建立起來才有可能實現數字化描述，最終實現自動化分析和故障自愈。不夯實基礎這一切都是空中樓閣，無從實現的。哪怕在數據庫內核上已經打牢了基礎，缺乏上層的知識庫體系，這些基礎能力也無法構建起能夠在用戶側發揮作用的高層能力，這方面又是需要花錢花精力去補缺的。

不幸的是我們的絕大多數國產數據庫廠商并沒有著手夯實基礎，而是直接在沙地上蓋起樓閣，于是眼見著起高樓，眼見著樓就塌了。我曾經和某個國產數據庫廠商的朋友交流這個問題，看到他兩眼茫然的樣子，我就知道作為產品經理的他，其實對數據庫運維沒有太多的經驗，對數據庫的可觀測性能力如何支撐上層的運維是沒有概念的。連產品經理都搞不清這些問題，那么也就別指望數據庫的研發人員能夠在這個領域有所作為了。

這些年的技術發展可以看出，在數據庫可觀察性能力以及自治數據庫方面，O記是一步一個腳印的走出來的，每上一個臺階都是踏著前面堅實的基礎的。很多國產數據庫的產品經理并沒有理解上層能力是依托于底層能力構建起來的，只是把上層能力當成做一個數據庫的功能來設計，這樣的話，就只能做出一些花架子了。長此以往，在這個領域，國產數據庫廠商被O記遠遠甩在后面，而且差距越來越大就很正常了。

今天的這個話題似乎很沉重，可能很多國產數據庫廠商的朋友也不愿意接受，不過良藥苦口利于行。自己分析一下，為什么你的數據庫出問題之后那么難以定位？為什么你的指標體系，日志，等待事件并沒有能夠真實的反映出你數據庫的運行狀態和所發生的問題？這中間到底缺了些什么？參考O記的體系去仔細想一想。這中間缺的東西其實就是支撐上層分析能力所需的底層能力，也正是你的產品中需要加強的地方。這方面不是你們的研發能力不足，而是你們對數據庫的理解還只停留在數據庫產品的研發上，而沒有把數據庫與用戶的應用場景深度融合在一起。