數據庫日檢是一個對于DBA來說又愛又恨的工作，恨的是每天面對相同的數據，重復性的勞動，但是又不得不做，有時候做一年日檢也沒有啥收獲；愛的是，有時候日檢確實能夠幫助我們發現一些嚴重的威脅，如果不做日檢，后果不堪設想。

想把日檢做好其實不易，很多DBA干了一輩子數據庫運維，也沒掌握好日檢的技巧。我見過很多企業的日檢腳本，檢查項很豐富的很多，但是做的比較到位的不多。日檢需要技術積累，更需要與時俱進。從別的企業抄一個日檢腳本來做自己的日檢，沒有自己的運維經驗積累，沒有針對自己的業務特點和業務場景，那么做出來的日檢也是一項例行工作而已，并不能對我們的運維工作有任何幫助。

對于金融、證券、運營商、互聯網企業來說，日檢是發現系統中存在比較急迫的隱患的一種最常用的技術手段。而中長期的問題發現往往可以通過優化和月度/季度巡檢來實現。如果我們的日檢報告里發現的問題都不是當前比較緊迫需要解決的問題，而都是一些中長期優化的問題，那么這個日檢的路子就走錯了。日檢的檢查項應該是日常監控不容易發現，但是一旦出現又比較容易很快觸發問題的項目，或者是一些和系統安全有關的問題。系統安全有關的問題往往不會立即觸發故障，但是一旦安全問題被入侵者利用，后果十分嚴重，一些中了勒索病毒的系統就是因為弱密碼等問題導致的，這些問題潛伏期很長，也往往容易被忽視。昨天我發了一個關于勒索病毒防范的文章，一個朋友在留言區留言說他們剛挫敗了一起勒索病毒。在做災備演練時重啟備庫發現了勒索病毒，幸虧主庫還沒有重啟，因此主庫數據數據還沒被加密，從而躲過了一劫。

其實一般企業都有數據庫日檢的需求，但是往往因為成本過高而無法真正開展日檢工作。因此在D-SMART中我們設計了一個專門的自動化日檢功能，每天下半夜（默認是3點鐘），任務調度器會針對每個數據庫實例發起一個日檢任務。這個任務會對前一天數據庫運行的指標進行一次分析，并對一些重點問題進行分析。

雖然日檢是個很簡單的業務，不過日檢工具要做好也不容易。數據庫日檢功能剛剛上線的時候，用戶就吐槽說用起來不方便。當時我們的日檢結果清單里沒有異常日檢項這一列，當用戶看到日檢結果里有扣分的時候，必須點擊報告詳情去查看。用戶一下子接入了大幾十個多個數據庫，一個個這么看下來很累。于是我們改進了一下，把異常日檢項直接在第一頁顯示出來，如果太多，鼠標移過去就能看全了。

后來日檢功能變成了用戶每天都必須使用的功能了，他們也大量的把系統接入D-SMART。隨著接入數量的增加，新問題又出現了。他們接入了近1000個實例的時候，覺得這么看日檢結果還是太麻煩了。于是日檢匯總報告又出現了。

日檢匯總報告可以讓他們每天只打開一份報告，就可以看清楚自己負責的所有數據庫的日檢情況，從而避免了翻幾十頁去查看日檢結果的繁瑣工作。運維自動化的目的就是這樣，通過工具體驗的改善，讓人用更少的時間，完成更多的工作。

不過問題還沒結束，使用一段時間后，客戶發現有些日檢項告警，并不一定能夠馬上去解決。我們和他們討論是不是從日檢里拿掉，放到月檢里去。他們又覺得這些檢查十分必要，如果一個月做一次恐怕會來不及，還是在日檢里做比較好。只是希望在報告里有所區分，把新發型問題和老問題做個區分，讓人一目了然的就能看到某個問題是今天發現的新問題就可以了。這么改造完了，確實日檢報告好用多了。

可能講到這里，有些朋友有點不耐煩了，說了半天，數據庫日檢到底要做點啥啊？實際上日檢因人而異，因各個企業的特點而異。比如在二十年前，存儲空間是個奢侈品，因此每天檢查是否存在可能無法擴展的SEGMENT是一個重點，而在目前的數據庫版本，以及存儲容量條件下，這個檢查就不一定需要了。在D-SMART中，日檢模板是可以根據用戶的需求去做調整的。也可以自己定制日檢的檢查項。

D-SMART社區版的日檢模板無法自定義，不過我們也提供了十分豐富的日檢項。大家有興趣的話可以去“DBAIOPS社區”下載一個免費的D-SMART社區版，體驗一下數據庫日檢的功能。

只要日檢變得很方便了，任何用戶都可以做數據庫日檢，而日檢工作帶來的提升是顯而易見的。不過從我們對日檢的理解來看，數據庫日檢不僅僅是一項工作，更是一種能力。如果無法低成本，快捷，高效，準確的進行日檢，那么日檢只能是一個討厭的，煩人的，沒有效率的，沒有必要的工作。而一旦我們把工具化，便捷化，實用化做到位了，那么這個能力對數據庫運維來說，是受益無窮的。