隨著數(shù)字化的不斷深入，數(shù)據(jù)庫爆炸式增長已經(jīng)是一個(gè)現(xiàn)實(shí)了。如此數(shù)量眾多，種類繁雜，還包含大量國產(chǎn)數(shù)據(jù)庫的中小型數(shù)據(jù)庫如何運(yùn)維，是未來擺在每個(gè)企業(yè)IT部門面前的一道難題。傳統(tǒng)的企業(yè)IT運(yùn)維都是抓大放小，關(guān)鍵、核心系統(tǒng)花大價(jià)錢招人或者請第三方服務(wù)商駐場服務(wù)，一些不重要的，小型的的數(shù)據(jù)庫就放任不管，出了問題再去解決。不過隨著數(shù)字化轉(zhuǎn)型的不斷深入，大量的不能放任不管的中小系統(tǒng)又?jǐn)[在運(yùn)維人員面前了。再加上以前一套Oracle數(shù)據(jù)庫干的事情，現(xiàn)在可能需要分解為多套國產(chǎn)數(shù)據(jù)庫來干。

以前雖然Oracle運(yùn)維起來難度大一些，不過關(guān)鍵系統(tǒng)數(shù)量有限，人還是干得過來的?，F(xiàn)在的國產(chǎn)、開源數(shù)據(jù)庫雖然比Oracle簡單多了，不過原來運(yùn)維Oracle的模式似乎也不大靈光了。平時(shí)不出問題的時(shí)候人工去監(jiān)控也沒多大價(jià)值，出了問題，人工去處理似乎也經(jīng)常發(fā)揮不出啥作用。再加上面對如此龐大的數(shù)量，總是覺得力不從心。

確實(shí)如此，Oracle時(shí)代行之有效的運(yùn)維模式到了現(xiàn)在國產(chǎn)、開源數(shù)據(jù)庫時(shí)代似乎不大好使了。轉(zhuǎn)變思路，轉(zhuǎn)變工作模式迫在眉睫。實(shí)際上既然業(yè)務(wù)都在數(shù)字化轉(zhuǎn)型，IT運(yùn)維也應(yīng)該數(shù)字化轉(zhuǎn)型了。今天我們就來討論一下數(shù)據(jù)庫的數(shù)字化運(yùn)維能力是如何構(gòu)建出來的。

圖片

數(shù)據(jù)庫的數(shù)字化能力來源是數(shù)據(jù)庫產(chǎn)品自身的可觀測性接口。通用數(shù)據(jù)庫的可觀測性接口一般來說還是比較豐富的，一些開源的專用數(shù)據(jù)庫（比如clickhouse、mongodb等）相對少一些。一般來說，面對場景的復(fù)雜性和多樣性越多的數(shù)據(jù)庫產(chǎn)品就需要越多的可觀測性能力來支撐其運(yùn)維。上面的圖中左側(cè)是數(shù)據(jù)庫需要對外提供的可觀測性能力，右側(cè)是IT部門需要構(gòu)建的數(shù)字化運(yùn)維能力?？捎^測性是數(shù)據(jù)庫提供給運(yùn)維的基礎(chǔ)數(shù)據(jù)，數(shù)字化運(yùn)維能力是IT部門建設(shè)的自動(dòng)化分析與處置能力。

IT部門對于數(shù)字化運(yùn)維能力的終極目標(biāo)是自動(dòng)化處置與故障自愈，不過這個(gè)要求很高，可以在一個(gè)組織內(nèi)部，通過對自己運(yùn)維對象與運(yùn)維流程的深入理解不斷的演進(jìn)與完善。不過個(gè)性化定制的工程量很大，極難做成通用產(chǎn)品去銷售。前陣子和螞蟻的同學(xué)做了一次深入的交流，觀看了他們支付寶的運(yùn)維管理平臺，他們的業(yè)務(wù)自動(dòng)限流、SQL自動(dòng)優(yōu)化、故障自動(dòng)隔離等方面的能力已經(jīng)做得很強(qiáng)大了。我當(dāng)時(shí)看得十分眼饞，問他們這部分能力能不能開放到OCP里。他們很坦誠的告訴我，這些能力都是基于對他們的系統(tǒng)充分了解的基礎(chǔ)上構(gòu)建起來的，甚至和他們的關(guān)鍵業(yè)務(wù)系統(tǒng)的代碼都是關(guān)聯(lián)的，想要開放成通用功能是有一定難度的。

雖然構(gòu)建高級目標(biāo)是需要長時(shí)間積累的，不過飯可以一口一口的吃，先把基礎(chǔ)能力構(gòu)建起來還是可以做的。不過要想構(gòu)建基礎(chǔ)的數(shù)字化運(yùn)維能力也還是有一定的基礎(chǔ)條件的。數(shù)據(jù)庫的可觀測性接口的能力強(qiáng)弱限制了數(shù)字化運(yùn)維能力的建設(shè)。傳統(tǒng)的數(shù)據(jù)庫監(jiān)控是網(wǎng)管理念的監(jiān)控，數(shù)據(jù)庫的幾個(gè)關(guān)鍵指標(biāo)合理，不宕機(jī)就行了，因?yàn)榕袛嘞到y(tǒng)是否存在問題主要還是靠人。數(shù)字化運(yùn)維是要考算法來判斷系統(tǒng)是否存在問題 ，那么所需要的監(jiān)控指標(biāo)就復(fù)雜多了。

舉個(gè)例子，哪怕是最簡單的配置信息，如果是人工運(yùn)維時(shí)代，那么很多配置信息記錄在系統(tǒng)里或者保存在文檔里還問題不大，大不了人工去檢查。而如果要數(shù)字化運(yùn)維，那么數(shù)據(jù)庫的備份策略，備份作業(yè)的完成情況等配置信息都必須要數(shù)字化了。這方面Oracle數(shù)據(jù)庫的完備程度是十分高的，值得國產(chǎn)數(shù)據(jù)庫去學(xué)習(xí)。通過系統(tǒng)視圖，我們可以知道大量的數(shù)據(jù)庫運(yùn)行于配置變更的細(xì)節(jié)，這對于數(shù)字化運(yùn)維和最終實(shí)現(xiàn)數(shù)據(jù)庫自治十分重要。

活躍會話歷史（ASH）是數(shù)據(jù)庫數(shù)字化運(yùn)維高級階段不可缺少的數(shù)據(jù)支撐。精準(zhǔn)的故障預(yù)警和根因分析都需要ASH數(shù)據(jù)的支持才能實(shí)現(xiàn)。因此ASH也是很多數(shù)據(jù)庫故障自愈能力構(gòu)建的基礎(chǔ)。數(shù)據(jù)庫要提供ASH的能力并不簡單，需要在數(shù)據(jù)庫核心代碼中能夠?qū)⒋罅康臅捇顒?dòng)數(shù)據(jù)轉(zhuǎn)儲出來，最終固化到系統(tǒng)表中。為了實(shí)現(xiàn)更精準(zhǔn)的分析，ASH要求的采樣頻率一般是1秒鐘，這對于數(shù)據(jù)庫內(nèi)核也是一個(gè)巨大的考驗(yàn)。目前應(yīng)有一些國產(chǎn)數(shù)據(jù)庫已經(jīng)開始提供ASH數(shù)據(jù)了，比如openGauss、Polardb、KingbaseES等。

Top SQL的發(fā)現(xiàn)與分析是另外一種十分關(guān)鍵的可觀測能力，在以人為核心的運(yùn)維時(shí)代，對數(shù)據(jù)庫的Top SQL可觀測能力要求也不是很高。支持慢SQL輸出就夠用了。當(dāng)系統(tǒng)出問題的時(shí)候，啟動(dòng)慢SQL日志輸出，人工去看日志分析問題就行了。而如果要想實(shí)現(xiàn)自動(dòng)化分析，那么就需要運(yùn)維平臺主動(dòng)采集系統(tǒng)中的SQL語句。

僅僅分析“慢SQL”可能也不大夠用，因?yàn)橛泻芏鄦栴}并不是“慢SQL”引發(fā)的，一條平時(shí)執(zhí)行時(shí)間10毫秒的SQL，突變?yōu)?0毫秒也可能引發(fā)一場系統(tǒng)大災(zāi)難。而把“慢SQL”的門檻設(shè)定在50毫秒肯定是不合理的。

還是那句話，Oracle在Top SQL可觀測性方面做得很好，而國產(chǎn)數(shù)據(jù)庫在這方面還差強(qiáng)人意。很多數(shù)據(jù)庫僅僅提供最近執(zhí)行的SQL的采集接口（條數(shù)可以設(shè)定，不過設(shè)多大才夠用呢？），有些數(shù)據(jù)庫雖然在內(nèi)存中保存著cursor的所有SQL語句，但是無法采集到的SQL的執(zhí)行計(jì)劃，而要自動(dòng)做explain又因?yàn)閰?shù)或者綁定變量的問題而往往無法完成。無法自動(dòng)采集到這些信息，就無法發(fā)現(xiàn)SQL存在的問題，做自愈也就無從談起了。

本來今天還想多寫一點(diǎn)，不過現(xiàn)在已經(jīng)九點(diǎn)了，暫時(shí)先寫到這里，明天再繼續(xù)聊吧。