前陣子有個做數據庫運維的朋友有個數據庫總是有些問題，前陣子問題嚴重的時候還宕了一次機?，F象是活躍會話數突然增大，然后突然數據庫就宕了。因為宕機，以及系統上沒裝什么監控工具，因此分析比較困難。而我在遠程，也沒辦法很好地幫他分析。

從宕機前一小時的AWR報告上看，當時的負載并不算高，等待事件主要是DB CPU的開銷，排在第二、第三的是latch:shared pool和log file sync。數據庫重啟后現在的狀態還算正常，負載也小了很多，因此也不是太好分析問題在哪。于是我建議他下載一下D-SMART社區版，跑上一兩天的數據，然后發給我，我遠程幫他分析分析。

昨晚他把數據發過來了，大概10M左右。我這幾天因為疫情一直遠程辦公，早飯后就一邊敲著這篇文字，一邊上傳數據。

在遠程通過VPN還是比較慢的，每秒只有142K的上傳速度，不過還好文件不大，74秒就上傳到了我們實驗室的服務器上。然后啟動呼啦上傳到D-SMART中。

數據上傳完畢后，我就可以在實驗室的D-SMART中觀察這些數據了。

從健康分上看，系統中的存在一定的波動。找一個點看看雷達圖，可以看到負載和并發維度出現了一些丟分。

點擊查看詳情發現每秒硬解析比較嚴重。點擊調用歷史查看工具。

可以看到硬解析波動很厲害，最高時接近400/秒。結合到前天我看到的一些AWR報告里的情況。這個系統似乎總是存在較多的共享池等待事件排在前面。很可能這個系統的波動與這個硬解析較高有關。

正好前幾天有家銀行也發來了類似的案例。最終定位也是硬解析導致了執行性能下降，于是我又分析了一下兩者的特點，很多特性上都十分類似。因此我看到數據的時候，就建議客戶今天試試調整cursor_sharing參數。

從這個案例我也總結出一個故障模型，那就是如果活躍會話數超過某個閾值，同時軟解析比例異常下降，并且硬解析數量異常并不低于邏輯CPU的2倍，則系統存在性能風險。這個模型可以隨著下一次D-SMART補丁包的發布，更新到D-SMART的數據庫中去。

這樣，我們只花了不到二十分鐘，就幫一個朋友遠程分析了問題，同時也總結了一個新的知識，這種現場與一線運維的互動因為有了共同的數據視角和標準化的工具而變得更加簡單了，效率也提高了很多。正是因為如此，我們這個小團隊才能為很多朋友免費地遠程分析問題。

前陣子有個朋友希望我幫他遠程分析一個PG的性能問題，說是可以VPN連上去做。我手頭的事情也比較多，大致了解這樣去分析一下需要花費的時間不少，因此我建議他下載一個D-SMART，采集一些數據，我遠程幫他分析一下。他可能覺得我是在推托或者說是非要推廣我們的工具，可能感到不太高興了，就沒再繼續溝通。實際上在沒有工具的幫助下，分析一個簡單的問題可能都要花上很多時間，連接遠程桌面，再跳轉到生產環境，上去采集數據，同時通過溝通了解現場的情況，效率比直接面對數據要低太多了。有了holadata，這一切就簡單得多了。

最近這5年時間，我參與其他事情越來越少，更多的時間都用在了如何利用數據來看數據庫的運行狀態，從中發現問題上了，我們研發的D-SMART也已經有了數百個裝機用戶。我每天也會看很多D-SMART采集上來的數據，因此已經習慣了用這些數據來思考問題。

數據庫運維工具是十分豐富的，種類繁多，功能與側重點也不同，可以滿足不同用戶的需求。兩個運維工具可能滿足了用戶的不同的運維場景需求，因此并不存在某個工具好或者不好的問題，只是對于某個客戶是否適用而已。對于用戶來說，自己用得起來，并且能夠給他的運維帶來幫助的工具，就是好工具。就像有些DBA總說sqlplus是最好的運維工具，不接受辯駁一樣。你覺得好用的，就是好工具。

經常我給客戶介紹產品的時候，他們總會提出一些需求，某某功能你有沒有。實際上他們可能需要的是另外一種數據庫運維或者監控工具，D-SMART可能不是他們最需要的工具。通過這樣的交流，我發現D-SMART并不是每個客戶都需要的工具，對于需要在現場獲得一些深度分析，精準報警能力，并且能夠通過工具積累運維經驗的用戶，可能D-SMART剛好對他們的胃口。而對于僅僅想知道數據庫是不是活著，并且希望這個工具能夠幫他們解決一些繁重的日常操作的用戶，D-SMART幫不了他們太大的忙。

于是在去年年底我就有了做一個社區版的想法。通過免費的社區版，讓需要D-SMART功能的人，認可這種知識共享，遠程交流的用戶主動找到我們，一起來發展D-SMART這個工具生態。另外就是利用與客戶之間的監控數據分享，加快我們的知識積累的速度。

目前來看，這兩個目標都有可能達成。首先通過社區版的D-SMART，目前已經積累了近300個裝機用戶，他們中有運維服務商，有最終用戶。有些人裝了，試了，覺得工具并不適合他們，就不再用了。有些用戶覺得工具對他們有幫助，于是就用得越來越深了。還有的用戶購買了VIP工具包，有些用戶和我們的客戶聯系，開始了商用版的測試。讓需要這樣工具的朋友了解我們的工具的目的初步達成。

構建生態的工作進展慢一些，不過也已經初步有了進展。下載D-SMART的朋友中，還有一些是做數據庫服務的，他們利用這個工具可以降低運維服務的工作量，從而節約成本。對于這些客戶是我們推出社區版的時候有點擔心的，怕讓人感覺我們是在和他們搶市場。實際上我們做D-SMART這個產品，并不是要參與數據庫運維這個市場競爭，而是通過工具加入到這個生態中而已。我們團隊的DBA不足10人，也很難和傳統的數據庫運維廠商去競爭。我們是希望通過D-SMART這個紐帶把最終用戶、服務廠商、工具廠商都聯合起來，打破壁壘，共同構建一個數據共享、知識共享、能力共享的DBAIOPS生態。通過最近的一些嘗試，我們也有了更大的信心。

隨著信創工作的推進，運維知識積累變得越來越重要，而信創用戶又極為分散，數據庫廠商又沒有類似MOS這樣的知識庫平臺，遇到問題都不知道到哪去問，到哪去查。如果能利用D-SMART作為媒介，構建一個共同知識積累的社區，大家一起來分析數據，積累運維經驗，并將知識存儲到一個大家都可以使用的知識圖譜中去，今后可以幫助我們的數據庫信創用戶解決很大的問題。