國產(chǎn)數(shù)據(jù)庫的外圍，需要做些什么

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

1 監(jiān)控告警

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

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

除常規(guī)監(jiān)控以外，EM提供的監(jiān)控還可以可以實現(xiàn)：

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

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

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

• 通過實時ADDM報告，可以快速判斷數(shù)據(jù)庫是否出現(xiàn)各類瓶頸

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

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

2 逃逸機制

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

• 預防

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

• 手段

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

• 高可用

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

• 演練

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

• 記錄

：在生產(chǎn)中，所有的操作、隱患、處置過程等都需要詳細的記錄下來，并盡可能形成完整嚴謹?shù)奈臋n。

3 AI

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

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

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

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

總結

好好做數(shù)據(jù)庫，也要好好做數(shù)據(jù)庫的外圍配套。