?其實剛開始我今天的題目想寫為“國產數據庫，最想吐槽的問題”，不過怕太傷了廣大搞國產數據庫產品的朋友的心，于是，把題目改的柔和一點。這些年國產數據庫的發展十分迅猛，在外部需求的推動下，技術、市場、服務等各方面都取得了較大的提升。不過不幸的是，我們的數據庫產業不是從0起步，前面還有Oracle這樣的巨頭在給我們打著樣子。

前幾天參加了一個活動，活動中有個環節，大家可以針對國產數據庫最值得吐槽的地方展開討論，因為是閉門會議，不錄象不寫會議紀要，因此參會的國產數據庫廠商代表、國外友商代表、產業界、學術界的代表都對國產數據庫進行了一番吐槽。可能有朋友看到這里就知道我今天想要說些什么了，因為目前國產數據庫和Oracle的差距是全方位的，在技術上、性能上、可靠性等方面都存在不小的差距，想要吐槽，確實有很多話題可以講。其實純粹的吐槽沒有意義，也無法幫助我們的國產數據庫產業發展，所以今天我還是聊幾點大家很容易改進，但是被大大忽視的問題吧。

首先是文檔，文檔是我們的用戶能夠獲得的國產數據庫最為全面和完善的技術資料，國外商用數據庫在這方面做的很好。

我們吐槽的國產數據庫的文檔主要有三個方面，一方面是種類太少，內容覆蓋不全。很多數據庫廠商對外資料，除了白皮書等小文檔外，只有一份管理手冊，一份開發人員指南，其他的資料就很少了。這些資料里面雖然覆蓋了絕大多數的和數據庫產品相關的內容，但是很多地方寫的都十分模糊，大體上只是交代了一個概念，很多實際操作部分的細節都不夠全面。實際內容和Oracle官方的concept以及2 DAYS系列的內容相當。實際上，如果要讓用戶把數據庫用好，很多文檔都需要進一步展開。

深度不夠，說的和上面的問題其實是一個問題，因為沒有展開說，所以不僅廣度不夠，深度肯定也不夠，沒有把問題說的很清楚很明晰，因此對運維中遇到的問題，以及運維人員通過文檔理解數據庫產品都幫助不大。

第三點不準確就完全是我們的態度問題了，很多文檔里描述的內容不夠準確，甚至有些官方文檔里某些命令的參數都和當前版本存在差距。這種對于Oracle來說， 被成為文檔bug，這種BUG如果多了，就說明我們的數據庫廠商對文檔不是很重視了。

還有些數據庫廠商手頭是有不錯的文檔的，但是在任何公開的場合都拿不到，我們只能通過一些私人關系，從線下獲得。實際上也大可不必，能夠十分開放的把自己能提供的技術資料都提供給客戶以及第三方服務廠商，對于建設一個良好的國產數據庫應用服務生態十分關鍵。

和我們的友商，相比，在這方面我們做的確實還很不夠。比如Oracle，除了正式的官方文檔外，還提供了大量的最佳實踐文檔，這些文檔在Oracle.com和metalink上都可以找到，此外Oracle還針對高可用提供了大量的MAA（最大可用架構）的實踐性的文檔。這方面，IBM也提供了大量的redbook，供客戶參考。下面幾頁是Oracle11g這個十多年前的數據庫產品的官方文檔中為了讓用戶快速掌握11.2產品的文檔清單,這僅僅是11.2這個版本產品文檔中的一部分，就已經如此豐富了：

整個文檔近400M，特別是Oracle Concepts這份文檔，可以讓從初學者到大師都受益匪淺。可以讓Oracle DBA們理解Oracle的每個組件的技術思想，理解一些監控指標和等待事件的內在原理。

我想，國產數據庫在技術上很快縮短與Oracle的差距，實現全面超越還是很困難的，我們在技術等方面目前能夠做的跟多的還是在某些小領域、小功能上，特別是在和國內典型應用場景緊密適配上的彎道超車。不過我們的國產數據庫和Oracle相比，其差距是全面的，在文檔這樣的一些環節上，我們要提升的地方，我們可以提升的地方就十分多。

首先是，我們能不能學習Oracle，也出一份自己數據庫的concepts的文檔，能從自己數據庫的架構、原理、功能的技術核心說起，把自己的數據庫介紹透，而不要遮遮掩掩的。可能有些廠家怕自己的Concepts出來后會泄露自己企業的核心機密，其實大家也大可不必擔心。國產數據庫廠商最大的對標對象-Oracle都可以把每一個版本的Concepts講的如此清晰，我們還有啥核心機密怕別人看到呢？

第二個我們十分需要國產數據庫廠商能夠在文檔中講清楚的是參數和監控指標的含義。現在我們遇到一些數據庫參數的調整，調整后會產生什么樣的效果或影響，會對數據庫的哪些行為產生影響，調整的建議是什么，這些方面，在官方的文檔中很難看到一些蛛絲馬跡，很多時候只能通過參數名稱來進行猜測，這對于國產數據庫的穩定運行與運維，是十分不利的。

對于一些監控指標、出錯信息的含義也是如此。我們的數據庫廠家能不能針對自己的數據庫的一些監控指標走出詳細的描述，包括這些指標的變化特點，以及和一些主要的數據庫特性之間的關系，這方面能不能在《運維優化手冊》這樣的文檔中做出較為詳細的描述呢？哪怕我們無法對所有的指標都做出很詳細的描述，那么能不能針對一些常見的，較為重要的指標，提供一份參考呢？哪怕只是做到《Oracle Reference》這樣的程度也是好的。

談到文檔，我們更羨慕Oracle的Metalink，這個寶庫我已經使用了20多年了，至今還經常會用到。我們的國產數據庫能不能也豐富一下我們的知識庫，或者說服務支持網站呢？實際上Oracle的Metalink中的大多數資料都來自于一個個的服務請求（SR），一個典型的服務請求處理完之后，就有專門的團隊復雜整理，把有代表性的服務請求整理成MOS的Notes，發布在Metalink上，這樣經過多年的積累，Metalink的內容就十分豐富了。客戶買Oracle的標服，能夠獲得MOS的SR的快速響應，能夠在Metalink上查找自己想要的資料、下載補丁，雖然花錢renew的時候有點心疼，不過總的來說，花了錢還是能見到東西的。

我們的國產數據庫是不是也能夠學習Metalink，建設一個帶有豐富知識庫的服務支持網站呢？其實要做的事情一方面是快速響應客戶的各種服務請求，另外一方面是有專門的人員來整理SR，從中抽象出典型的知識和典型的案例。我想只要堅持做下去，有兩三年時間，你們和國內友商之間的服務水平的差距就能很好的體現出來了，自己的數據庫產品的市場競爭力也會大幅提高了。

今天談的這個和文檔相關的話題，實際上是我們的國產數據庫廠商完全能夠做好，但是并沒有花精力區做的事情。這個事情實際上也不是我們的廠商不愿意去做，而是缺乏這方面的人才。要想做好這樣的事情，必須是有懂自己的數據庫，懂友商的數據庫，懂數據庫運維、優化等方面的人才參與進來才能做好的，而恐怕在我們的國產數據庫廠商中，做這方面的人都不具備這樣的能力。不過不管怎樣，我們希望我們的國產數據庫一天天好起來，也希望有國產數據庫廠商能夠在這方面加大投入。?