一個近30年的老DBA希望資料庫廠商提供什麼樣的文件？

昨天說了把簡單留給客戶，把複雜留給研發。昨天上午在一個和某資料庫廠商的交流中我就把這句話送給了他們。昨天上午做了一場資料庫文件的交流，因為我以前寫過一篇吐槽國產資料庫文件的文章，於是某資料庫廠商就和我約了這場交流，為了避免廣告輸出的嫌疑，廠商的名稱我就隱去了。

他們上來就問我，作為一個用了快三十年的老DBA，你希望資料庫廠商能夠提供什麼樣的文件出來。我並沒有直接回答這個問題，而是講了一些目前資料庫廠商文件中存在的一些用起來不方便的問題。有些資料庫廠商整個文件體系就是一本使用者手冊，雖然不怎麼厚，大體上而內容看似也挺全的，只不過某個使用者要去找某個知識點的時候，往往找起來很麻煩，甚至找不到，哪怕找到了，也是寥寥幾句話，根本解不了渴。還有些資料庫廠商的文件很豐富，很多本，但是有時候為了找一句建表的完整語法，找了各種手冊都沒有找到完整的。

實際所有國產資料庫廠商的文件都缺一本《完全參考手冊》，這本手冊就像字典一樣，包含了所有的資料庫產品特性的最完整的描述。實際上Oracle資料庫早期也是沒有這份文件的，第一份《Complete Reference》還是一個從Oracle離職後的人寫的。後來Oracle收購了這本書的版權，在隨後的任何一個Oracle發行版裡，都多了一本《Reference》的手冊。所有的SQL語句語法，系統統計資料、等待事件、系統表和檢視的詳細描述，都可以納入到完全參考手冊裡。在其他的手冊裡，只需要介紹用到的語法就可以了，只要是想查詢完整的資訊的時候，都只需要翻閱完全參考手冊就可以了。

有了這本完全參考手冊後，資料庫廠商就可以按照閱讀者的角色來組織相關的手冊了。資料庫的手冊可以做成能夠讓各種角色的人都可以很方便的閱讀的模式。而不需要讓DBA在一本程式設計師參考指南里跳躍式查詢自己所需要的表碎片整理的語法;也不需要讓開發人員不斷跳過看不懂的運維管理指導，去查詢一條修改資料庫引數的語句。用各種角色最適合閱讀的形式組織各種專項手冊，可以讓使用者有更好的使用體驗，不過對於文件編制來說，要麻煩不少，因為很多內容可能要重複出現在多本不同的手冊中，並且很可能每次出現都不完全相同。

除了完全參考手冊外，《架構與原理》也是目前國產資料庫廠商文件裡比較缺乏的內容，理解某個資料庫產品的架構與原理有助於更好的使用這個資料庫，並在遇到問題的時候能夠找到解決問題的正確方向。如果這本書能夠寫成《Oracle Concepts》這樣就最完美了，只不過很可能我們沒辦法一下子寫得很完美。Oracle也是到了8.0才開始有這本手冊的。現在很多國產資料庫的文件裡有些這方面的章節，只不過寫的還比較粗淺，內容覆蓋也不夠全面。實際上保持現在的深度，能夠把內容覆蓋全了，就已經十分有價值了。

昨天最後談到的話題是專題文庫和知識庫的問題，這個資料庫廠商已經準備上線知識庫網站，並已經準備好了大量的文件。我建議學習一下SQL SERVER的專題文庫，把一些常見案例，常見運維維護方法，巡檢方法，診斷方法等整理成最佳實踐手冊，按照主題整理好釋出出來。實際上Oracle的MOS上也有一些這樣的主題，Oracle編寫了大量的Master Notes，並按照一些主題歸類，讓使用者可以透過Master Notes系統的瞭解某個知識。類似Oracle和SQL SERVER的經驗，實際上我們的資料庫廠商去他們的網站看看，就可以學到很多東西了。

對於知識庫，我建議必須基於知識圖譜，能夠做深度搜尋，否則隨著知識庫規模的擴大，就很難找到我們所需要的內容了。從我個人的感覺來看，現在的MOS絕對沒有二十年前好用，想找到一個很匹配的知識，需要搜尋半天才行。

雖然開頭說了不想在文章中做廣告，不過最後還是做一個我們自己的小廣告。我們正在梳理各種國產、開源資料庫的運維知識圖譜，我也衷心希望有合作意願的朋友加入到我們的行列中，大家分享運維經驗與運維案例，對於參與合作的朋友，可以免費使用我們的知識庫，並可以探討更豐富的合作模式。

原文標題：我希望資料庫廠商提供什麼樣的文件