國產數據庫的外圍，需要做些什么

對于數據庫圈來說，元旦似乎不大太平，關于事情是什么圈內大概也是知道的，我也從一些非常規渠道了解到了整件事情的來龍去脈，但是由于一些原因不能寫（就看后面有沒有正式點的通告吧）。但是通過這件事情，我還是想說一下，數據庫除了本身健康運行以外，在其外圍工具還需要做好哪些事情。

1 監控告警

這幾乎是數據庫工具中最重要的部分！以我實際工作經驗來說，借助Oracle Enterprise Manager，可以實現對數據庫、Exadata所有硬件組件的全面監控告警。

以告警為例，除了一般的CPU、內存使用率告警、數據庫各類鎖、等待告警和空間用量告警等，EM提供的告警甚至可以觸達每個alert log中的異常信息（告警送達的同時告知絕大多數異常信息），這讓數據庫出現的絕大多數問題我都可以第一時間知曉，甚至很多時候我可以先于業務方得知問題發生并反饋。

除常規監控以外，EM提供的監控還可以可以實現：

• 通過實時ASH監控，可以通過查看數據庫等待事件與對應SQL ID快速定位異常SQL，并及時反饋、解決

• 通過實時SQL監控，可以快速定位長時間運行SQL，避免長SQL、大事務帶來的影響

• 通過實時鎖監控，可以快速定位異常會話并處置

• 通過實時ADDM報告，可以快速判斷數據庫是否出現各類瓶頸

上面的監控能力歸根結底其實想要突出的就是，監控平臺本身需要有足夠的能力能夠幫助數據庫管理者能夠通過監控信息快速找到問題并處理，快是十分重要的！如果只是發現數據庫出現問題，但是沒法通過監控快速定位問題，還需要一點點去找各類日志來排查（尤其是分布式數據庫節點組件多），那么處置問題必然會耗費更多的時間。

最后，能夠實現對數據庫的有效監控并實現有效告警，還需要數據庫本身的支持，并且是一種對數據庫極小影響的方式支持（比如底層接口），而不是通過定時在數據庫跑一堆大SQL來實現監控，這樣即不實時，而且這些監控需求也可能成為數據庫消耗最多的SQL了，對數據庫帶來更多不穩定的因素。

2 逃逸機制

大家在維護一些數據庫的過程中一定遇到過，數據庫連接數異常且無法連接至數據庫管理員用戶進行修復操作的。對于數據庫配置來說，很多數據庫已經在常規業務連接數以外增加額外獨立的管理員訪問連接數可以避免這一情況發生。但然如果是因為操作系統配置或資源耗盡等導致無法連接數據庫并執行相關操作怎么辦？我認為有以下一些方法：

• 預防

：提前以現有硬件、操作系統、軟件為基礎，結合業務壓力特性進行全面測試，制定合理的全局各部分的配置，在預留一定余量的基礎上可以盡可能的避免實際上線后問題的出現。但依然要明確，這并不能完全避免特殊情況的發生。

• 手段

：在標準的連接至數據庫通過命令行進行操作以外，在操作系統（或云底座）一定要有其他的應急操作手段，比如Oracle可以通過sysctl、PG可以通過pg_ctl來對數據庫進行一些如啟停實例、調整參數等操作，以求在緊急情況下能夠處理問題。

• 高可用

：要說IT系統完全不會出問題，這幾乎是不可能的，健壯性足夠高的高可用架構（這里主要說的是跨集群高可用架構），在主用生產集群出現異常時，在緊急情況下甚至可以通過類似于failover的方式讓備用集群接管生產，降低業務影響時間。

• 演練

：即便前面做的再好，各種故障處置、災備切換的演練也是需要做好的，做這些的目的不僅僅是驗證并完善數據庫層面的操作流程，也為了驗證生產業務程序、周邊硬件等是否能正確應對數據庫故障處置的相應場景，發現其中是否有需要完善的地方。避免真正需要的時候數據庫或應用無法響應。

• 記錄

：在生產中，所有的操作、隱患、處置過程等都需要詳細的記錄下來，并盡可能形成完整嚴謹的文檔。

3 AI

接下來的一段話可能不那么好聽：“現在的國產數據庫和國外商業數據庫之間還有不小的差距”，這個差距不只是數據庫本身，也有前面說的外圍工具，以及在這些基礎之上經過實戰檢驗的生產案例。但是現在又是一個比較好的時代，AI的快速發展使得我們可以借助AI少走不少彎路。

我們可以將數據庫的相關信息，包括但不限于數據庫本身的各類文檔與案例、監控平臺、IT架構及自己整理的內容等喂給AI進行學習，在幫助進行日常的監控、巡檢等日常工作以外，也可以幫助進行負載預測、語句優化等工作。在有足夠的高可用相關材料與實際故障處理案例的基礎上，還可以結合AI搭建一套完整的高可用與故障診斷與編排平臺，即可以在出現問題是結合監控與告警快速診斷問題并提供有效的操作建議（甚至可授權自動執行處置操作），也可以幫助模擬各種故障場景，協助進行日常演練操作。

但這也意味著數據庫廠商需要更加開放，能夠把一些可以稱之為“底褲”的東西整理并公開出來，這可以讓客戶與廣大數據庫從業者更加深入的了解數據庫，提前儲備、積累一些故障案例；也可以根據不同的應用場景，使用更加合適的高可用架構，準備好相應合適的應急故障處理流程。有些數據庫廠商在這方面做的很不錯，不僅自己做了比較好的外圍配套，也開放了很多資料。

當然我也理解那些生態封閉的數據庫廠商，一方面是想把比如售后、交付之類的工作牢牢掌握在自己上手，穩定獲得那部分收益；另一方面有些東西一旦給出去了就是把自己的弱點暴露出來，甚至可能會成為友商的攻擊目標。但是我想說的，只有整個生態的繁榮，數據庫才能有效發展，而且如果一些問題平時藏著掖著，在客戶真實生產環境中爆發并造成嚴重后果的話，后果就不用我說了，艱難建立起來的信任也很可能一夜崩塌并波及出去。

總結

好好做數據庫，也要好好做數據庫的外圍配套。