?目前國內外的運維工具中，SQL SERVER的工具偏少，而且也僅僅偏向于簡單的狀態監測和一些關鍵指標基線告警。缺乏深度問題的分析與發現能力，也缺乏復雜問題溯源的能力。因此我們可能知道某個指標異常了，但是不知道為什么異常，是什么引發的異常，我們該如何去優化它。微軟雖然提供了一些診斷分析工具，不過這些工具用起來太復雜了，一般人也真的不太容易掌握。再加上Windows的問題本身就比較難以分析，這導致了SQL SERVER這個看似用起來很簡單的數據庫，反而不那么好分析了。

微軟提供了一些基于Windows平臺的分析工具，不過大多數是交互式分析工具，問題發生時進行在線分析的能力雖然較強，但是使用起來專業性太強，另外也無法分析歷史情況，因此無法滿足運維優化的全面需求。

基于此原因，DBAIOPS社區對SQL SERVER的需求還是挺旺盛的，很多朋友都認為D-SMART中SQL SERVER的監控功能和診斷功能比Oracle等其他數據庫弱很多，希望我們在今后的版本中能夠加強。經過這段時間的社區推廣，我們發現確實在政務、醫療文教、制造業等行業，SQL SERVER的使用量是相當高的，為了這些客戶，我們有必要對D-SMART的SQL SERVER做一些加強。

前陣子社區的一個朋友通過Hola發來一個SQL SERVER的監控數據，讓我們幫助分析一下SQL語句經常出現執行時間抖動的問題。從月檢報告上，我們發現了數據庫存在IO_COMPLETION指標的異常。當時基于SQL SERVER的知識圖譜并不完整，因此分析過程完全通過人工，我們花了數個小時，發現了一個疑點，SQL語句執行時間變長總是和物理內存100%，PAGEFILE使用率接近100%有關，最終定位了問題主因是物理內存不足。

如果利用智能診斷工具，我們是可以大大簡化分析的過程的，有了完整的知識圖譜，我們就可以使用各種智能診斷工具來輔助我們發現問題了。比如上面所說的問題完全可以通過“指標關聯性分析”工具進行分析，比如我們發現數據庫的閂鎖等待有點不正常，從“指標關聯度分析”的結論上看，這個指標相關聯的問題主要幾種在IO并發量過大上，而最終定位的問題是操作系統IO延時過大，IO能力不足引發了IO性能問題。整個分析只需要點擊下按鈕，是不是很簡單？

在D-SMART V2.1.6.20221010月度升級版中，我們著重加強了SQL SERVER的監控與運維診斷能力。針對SQL SERVER的指標做了一定的增強，增加了一些對于分析診斷十分有價值的新指標。另外健康模型也做了較大的調整，新的模型能夠更好地反映出SQL SERVER數據庫實例的運行狀態。而最大的升級來自于SQL SERVER的知識圖譜在這個版本中已經完成了對所有指標的覆蓋，因此這個版本的“智能診斷”功能真正可以發揮作用了。

點擊智能指標分析，D-SMART的智能診斷引擎可以根據知識圖譜的數據自動對當前的問題進行歸類和分析。

當我們發現某個關鍵指標出現異常時，我們也可以十分方便地利用智能診斷工具中的“關聯度分析”工具，去分析可能的關聯因素。

選取指標存在問題的時間段，點擊“智能指標分析”，就可以選擇其中的工具進行分析了。當我們對某個單一指標異常沒有頭緒，不知道該如何分析的時候，使用“指標關聯度分析”工具就可以去發現與該指標的波動特征較為相似的指標，這些指標很可能與這個你不知道該如何分析的指標有關聯關系的指標。

相似因子越小的指標可能關聯度越強。智能診斷工具還可以通過根因分析算法，自動歸納引發指標波動的可能問題。

不過這個問題是通過關聯關系推斷的，而并不是系統當前可能存在的問題。在報告的后面，會提供這個分析。

隨后的問題分析工具會自動分析這些關聯性的指標中存在的異常，從而推導可能存在的系統問題，最終原因還是IO能力不足，而誘因可能是大量的SQL加大了IO。智能診斷工具采用純數學計算的方式來分析問題，不過其分析的規則來自于知識圖譜中的專家經驗。智能診斷充分利用已有的專家知識，結合異常檢測算法，自動對指標進行檢測，并且通過知識圖譜中積累的模型，自動進行根因歸類，將一系列指標異常收斂到有限的問題點上。這樣就好像給我們的DBA裝上了一只透視眼一樣，能夠比較方便地看透問題現象背后的本質。

當然，目前的智能診斷僅僅是為我們提供了一雙透視眼，讓我們能夠更好的看數據，幫我們自動分析數據，其大腦目前還不夠聰明，分析的最后一公里依然需要依靠人的判斷，不過已經為我們的運維人員，特別是三線專家提供了很好的分析方向。

隨著不斷積累新的故障模型，優化知識體系，分析診斷的能力也會不斷提升。隨后我們會在DBAIOPS社區開展SQL SERVER的智能診斷測試工作，也希望有興趣的朋友參與測試，并給我們反饋測試結果，用于改善知識庫。