寫在前面的故事 首先，給看官們講個故事：最近遇到過一個客戶，系統上線三年變的越來越慢，直到前幾個月全面爆發，系統前端使用人員不斷抱怨，甚至已經達到了不能使用的程度。這個時候他們的IT主管也是決策者無法忍受這種情況，就召集下麵的運維開會，詢問情況。 領導：現在系統這麼慢，前端都無法使用了，到底什麼情況 ...
寫在前面的故事
首先，給看官們講個故事：最近遇到過一個客戶，系統上線三年變的越來越慢，直到前幾個月全面爆發，系統前端使用人員不斷抱怨，甚至已經達到了不能使用的程度。這個時候他們的IT主管也是決策者無法忍受這種情況，就召集下麵的運維開會，詢問情況。
領導：現在系統這麼慢，前端都無法使用了，到底什麼情況？
運維人員A：我們的伺服器CPU壓力太大，一直處於90%以上！
運維人員B：我們的伺服器記憶體不足總是90%以上！
運維人員C：我們的磁碟速度跟不上了，換SSD會有很大提高！
領導：啥都不行了？那我們換高配伺服器！
。。。。。。。。。。。。。。
換了伺服器，好了半個月又開始慢...和之前一樣基本沒有任何緩解...領導又召集運維人員開會。
領導：伺服器都換了，配置增加了一倍還多，為什麼還慢？
運維人員：我們需要做讀寫分離，做集群分擔壓力！
運維人員：軟體不行了，這個軟體太差！
領導：。。。。
如果你是領導，那麼你該如果決策呢？ 如果你是運維人員，你會有上面的回答麽？
可能你看完會笑，認為這是不可能發生的故事，然而這個故事確實是真實的！反之如果這個故事中看到了自己,那麼請仔細地往下看嘍！
--------------博客地址---------------------------------------------------------------------------------------
Expert 診斷優化系列 http://www.cnblogs.com/double-K/
廢話不多說，直接開整-----------------------------------------------------------------------------------------
資料庫在系統中的角色
這個可能不用多說，大家都知道，一般系統慢都是慢在後端，而後端主要慢在與資料庫的交互！
資料庫可以理解成獨立於你的系統，成為一個單獨的系統。無論從資料庫的物理設計，與前端的交互方式，自身的參數設置，索引的設計，維護方案等都影響著你整個系統中最慢的環節（可以說整個系統中資料庫就是最慢的環節）！
同樣通過資料庫的狀態，也能很大程度上判定出你系統的問題到底在哪。尤其能界定清的一點就是軟體真的慢麽？軟體設計的不好？還是資料庫年久失修？
幾個問題
你瞭解你的資料庫麽
瞭解決定效率
也許很多老司機有這樣的感覺，我運維的效率如何，這取決於我對系統的瞭解！出現什麼樣的情況，我就知道是哪裡的問題，代碼在哪裡，問題在哪裡！看錯誤號、看異常便知問題，也就是未出茅廬，已知三分天下！反過來新手可能需要debug跟一遍還一知半解。對於資料庫道理也是一樣的，資料庫系統出現什麼問題你是否能很準確的定位的可能發生問題的幾個點？或者我需要查看系統哪些指標？系統中存在著哪些隱患？哪些功能慢？哪些語句需要優化？哪些運維策略做的不合理？
出現問題能從容面對麽
從容出自積累
從容面對這個詞說起來容易,但是我自身從小白的開發到現在的DBA一路走來真的是積累了很多，坑也踩了很多才能做到從容面對。
這裡舉幾個現象 :
當你的CPU從穩定的30% 飆升到90%以上,你能想到的可能原因是什麼? 怎麼樣快速排查?
當你平穩的業務出現大面積超時,你能想到的可能原因是什麼? 怎麼樣快速排查?
真的瞭解麽
習慣至深入
在很多次和運維人員交流的過程中發現，我知道的名詞和他知道的名詞完全不是一個東西！比如：死鎖。同樣提到索引，他會說不用講，這我都懂。那麼什麼是聯合索引，什麼是覆蓋索引？覆蓋索引怎麼能降低你的死鎖概率？ 這時他的反應才是：哦...原來還可以這樣，原來還有這麼多東西！
模擬一個場景，領導開會的時候問你如下問題：
領導問：
- 資料庫有多大 ？ 每天增長多少 ?
- 高峰時間卡慢麽 ? 為什麼慢 ? 資料庫問題還是軟體或硬體？
- 系統中那些語句慢 ? 慢到什麼程度？
- 系統中哪些資源是瓶頸 ?
- 存在死鎖情況麽？ 怎麼產生的？
- 有什麼潛在風險 ？
- 怎麼解決 ？
很多人運維人員的回答可能是：
。。。。。。。。。。
而問題發生的時候可能發生的情況就是這樣的：
你是哪一類？
背景：今天，資料庫普遍存在問題，如：性能問題、安全問題、可靠性問題、數據備份問題、結構設計問題等。
結論：
- 當出了問題時，用戶不知道是誰的原因，系統的真實狀況如何？
- 問題一大堆，多數人沒意識到是資料庫問題，很多人想弄但不會弄，還有一部分人會弄但傳統的方法不方便。
你是下麵那個角色？
你是否像救火隊員？犧牲著自己的休息時間隨叫隨到的運維這你的系統？你是否像拆彈兵一樣維護著一個隨時爆炸的系統？你是否又像一個保姆，寸步不離的呵護著你的系統？
怎麼辦？
可能不少看官就是上面的一員，但是又很迷惑，我該怎麼辦？我要從頭深入學習資料庫？學個幾年到精通？ 當然不需要，其實資料庫運維很簡單！你只需要瞭解常規的運維套路，常規的系統指標，和常規的問題排查方式，這樣已經可以解決80%的問題。如果出現搞不定的20%你需要的資料庫專業人員的協作。
運維三步走:
- 發現問題
- 解決問題
- 預防問題
是不是感覺說的很輕巧...本文除了讓運維人員瞭解資料庫在系統中的重要，多關註資料庫，多瞭解一些資料庫的運維方式外，也推薦一款工具，所謂工欲善其事，必先利其器！
推薦一款工具
Expert for SQLServer 一款SQLSERVER的體檢診斷專家。
發現問題
全面體檢（不僅僅是性能），讓你知道資料庫的真實運行狀況、存在的問題及潛在風險
按照6大維度， 108項指標（軟硬體環境、參數配置、結構設計、性能、可用性、備份、安全）建立體檢標準，定期對資料庫進行全面體檢，客觀呈現資料庫的真實運行狀況，所有問題一覽無餘。
解決問題
快速診斷，分析出系統的主要問題併進行分類，同時提供解決之道
通過數據分析，將資料庫的問題按照嚴重程度進行分類，按照提示的方式進行調整，所有問題。不管你懂資料庫還是不懂資料庫，你都可以清晰地知道，應該從哪入手，進而快速地解決問題，讓天下沒有難用的資料庫。
預防問題
定期體檢，才能消滅隱患，買輛車還定期保養呢，這就是所謂的防患於未然，把問題消滅在萌芽中。
個人建議，不管你用什麼工具，或使用腳本。
核心系統體檢：1月/次
重要系統：2月或3月/次
有功能上線，或結構變更等都需要做一次體檢。
多人或大牛協作
就像一個系統運轉有硬體，網路，程式，資料庫，需要多方、多人協作一樣，資料庫的問題一樣，每個人都有擅長的部分，那麼多人協作就是可以更全面的解決系統問題，這款工具的最大優勢在於提供了多人協作的基礎數據。這份體檢數據包含了資料庫運行中的大部分指標，所有時間點的狀況，計數器的指標，語句間的阻塞等等信息，這遠勝於傳統運維中拼湊堆砌出來的腳本數據。
這就像醫院的電子病歷，對全身有了全面的檢查，X光片子、各種檢驗、化驗數據在手，可能你去到哪個醫院，找哪個專家或醫生匯診都可以作為他們協作的依據！
--------------博客地址---------------------------------------------------------------------------------------
Expert 診斷優化系列 http://www.cnblogs.com/double-K/
-----------------------------------------------------------------------------------------------------
總結 ： 親身處理了上百家客戶的系統，大部分系統資料庫都存在著各種資料庫問題，而資料庫問題往往被忽視，直接被歸結為軟體的問題，廠商的問題！
資料庫應該被我們重視起來，很多時候只是在資料庫上做一些常規的配置或簡單的優化，就能讓系統有幾倍甚至幾十倍的提升，而這些優化可能只是簡簡單單的資料庫層面完全不用改代碼的行為！
系統運維需要定期體檢，這點真心希望運維人員能夠重視起來，也真心希望系統運維人員可以加深一下對資料庫的瞭解，多掌握一些常規的手段和必要的運維策略。
工欲善其事，必先利其器，運維同樣需要一些簡單方便的工具！
本文提到的工具下載鏈接：
Expert for SQLServer 工具下載鏈接： http://zhuancloud.com/ReceptionViews/Install.html
本人使用工具優化的相關文章鏈接 ：
SQL SERVER全面優化-------Expert for SQL Server 診斷系列
----------------------------------------------------------------------------------------------------
註：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文鏈接！
若您覺得這篇文章還不錯請點擊下右下角的推薦，非常感謝！
引用高大俠的一句話 ：“拒絕SQL Server背鍋，從我做起!”
