共計 2744 個字符，預計需要花費 7 分鐘才能閱讀完成。
今天就跟大家聊聊有關如何解決 HIS 系統數據庫的癱瘓，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
系統環境
首先我們來看一下這個系統配置及現狀，為什么說這個客戶經典? 那就是因為這個客戶已經達到可以慢的地方都慢，不該慢的地方也慢!
首先這是一套醫院的 HIS 系統，慢到什么程度呢? 各種功能卡死不管是交款、醫囑、開藥一些列幾乎所有的功能都慢。但是卡慢的現象只出現在上午的高峰期!
先來看看系統配置：
數據庫版本是 SQL SERVER 2008R2，數據量大概 1 個多 T，服務器 64CPU、128G 內存，服務器只運行數據庫。
咋一看服務器確實有點老了，數據量也大了，內存和 CPU 什么的明顯不夠用了!
數據庫指標
那么我們再看一下數據庫的一些表象：
每秒請求數量：
語句執行情況：
等待情況：
等待時間：
CPU 指標：
內存一些指標：
磁盤隊列：
還有很多指標就不一一展示了。
看到這些基本的指標，除了慢你能看出什么? 問題出在哪里? 怎么樣快速解決? 能有一個優化的步驟呈現在眼前么?
優化階段一 (常規優化)
很多時候系統慢要究其原因，難道上線時候就這么慢? 那不可能，廠商根本無法交付的! 那么問題來了，什么時候開始慢的? 對系統做過哪些調整?
簡單的調研開始，給我的只有不到半天的調研時間，得知的基本問題就是系統在最近一月增加了很多功能，有上線了很多其他系統接口!
那么直接就搞新功能、新程序接口語句? 我認為并不是這樣，從一名數據庫從業人員來說，看到這樣的系統一定要先解決大面積等待問題! 個人經驗來看很多系統大面積等待解決系統會有個很大的提升和改善!
配合一些常規的調優手段階段一開始了, 主要給系統大面積創建影響高開銷大的索引，調整系統參數，優化 tempDB、開啟快照讀等 ….
預期：
一般系統上面一輪優化會有明顯的改善，我認為這一輪以后系統會明顯變快，語句 CPU 會下降到 70% 左右，內存壓力也會有所減少。
結果：
自信滿滿的我第二天去了各個科室 …. 部分功能依然超時還是各種慢 …CPU 依然 90% 以上，內存壓力依然明顯。但是收集的數據來看，長時間語句數量已經大幅降低，系統等待阻塞情況也明顯好轉。
優化前
優化后
優化前
優化后
優化階段二 (針對語句)
再次分析解決大面積語句阻塞的系統，發現現在的情況，主要有如下幾個：
由于內存不足導致的 IO 壓力。
系統 CPU 依然彪高。
部分功能語句依然慢，消耗的資源很高。
再次對系統調研：
哪些功能慢，執行的語句是什么。
系統的接口語句問題。
系統中還有哪些消耗資源高的語句，是否能優化。
調研后，我遇到了最常見也是 *** 的問題：語句慢由于程序! 很多人看到這會說程序慢就改唄，那有啥問題? 問題就在于你來做優化直接了當的和人家開發人員說你程序太爛必須改! 如果你是程序開發人員你會有什么樣的反應?
他會說：對不起，影響太大改不了!
那么這個優化項目黃了，或者你要付出更大的代價繞過這樣的問題。
分析中發現程序使用了大量各種自定義函數，有一定經驗的人都應該知道，語句在篩選的列上使用函數是沒有辦法使用索引查找的，這樣相對于這種單表數據就幾百甚至幾千萬的表，是何等的災難! 但是不能冒然突出修改程序，那還能怎么優化呢? 大概分析后得出結論，程序主要消耗在幾部分：
部分業務功能語句慢。
接口語句慢 (主要是視圖，供其他程序調用)。
還有報表程序。
針對 *** 部分在不能改程序的情況下，嘗試添加計劃向導改變語句執行情況;
針對第二部分修改接口視圖，包括替換掉函數、添加索引等;
針對第三部分報表這東西不是短期就可以優化的，所以再原有鏡像的方案上添加快照，實現了簡單的讀寫分離，直接分走;
語句優化的效果：
優化前
優化后
優化前
優化后
預期：
90% 消耗高的語句都得到了優化，系統應該可以快起來了，CPU、內存指標也應該正常了!
結果：
語句的消耗和時間都降下來了，系統卡慢現象有明顯好轉，但是 CPU 依然 90% 以上、內存壓力依然明顯，磁盤隊列還是很高! 系統性能問題依然存在。
優化階段三 (深入指標分析)
經過前兩個階段的優化一般系都會明顯好轉，并且指標正常，這也是前面提到的可以慢的地方慢已經解決，那么為什么 CPU、內存壓力沒有緩解? 難道真的是 64CPU、128G 內存不能支持了? 需要加內存換 CPU? 難道要做負載均衡? 各種拆分?
CPU 分析
首先我對 CPU 壓力進行了分析，綜合語句的 CPU 消耗和 CPU 的表象來看，很大一部分應該不是語句執行消耗的! 那么服務器上確實也沒有跑其他程序，CPU 資源哪里去了?
看看這個計數器：
SQL 的編譯次數高峰時間段達到每秒 2000 多次! 很多書上寫過，相信很多看官也知道，語句不參數化會給 CPU 造成壓力，這就是個鮮活的例子! 那么解決辦法也是比較粗暴，程序無法修改那么就在數據庫上開啟強制參數化。
看下效果：
我想不用多說什么了!
內存分析
看到了 CPU 的現象那么內存的問題也有眉目了，這么多編譯即席查詢，首先看一下內存中緩存了那些數據：
SQLOPTIMIZER Singlepage 占到了 80 多個 G，而在查詢數據頁的緩存只有 20 個 G，而且仍然在被不斷壓縮，那么內存沒壓力就怪了! 這個 SQLOPTIMIZER Singlepage 嘗試了一下是無法通過 DBCC FREExxxxx 的操作釋放的，所以在半夜直接重啟了 SQL 服務! 將近 2 年沒有重啟的 SQL 服務就這么折在我的手里了!
重啟后頁生命周期：
內存這個問題，不知道是不是微軟的一個小 BUG，查詢計劃的緩存個人理解不會一直壓榨數據緩存的，客戶的數據庫沒有補丁，但是查閱 08 的各個補丁也沒有找到相關問題的修復。
也請遇到過或了解的朋友給點提示!
預期：
語句已經優化，阻塞情況也被解決，CPU、內存、磁盤壓力也沒有了，系統肯定快起來了!
結果：
系統快起來了!
總結
文章只是簡單地描述了一下某醫院 HIS 系統的優化過程，當然一周的工作僅僅通過一篇文章寫出全過程細節必然不那么詳盡，還望看官們見諒!
整個的優化過程是程序只修改了 2 條語句，其他都是通過數據庫優化手段完成。而且沒有添加任何硬件資源!(文章中用到的工具鏈接： http://www.grqsh.com/product_Expert.html)
優化過程主要分為：
系統整體調研：和科室用戶溝通慢的情況，系統最近變更情況，并收集數據。
常規優化：調整數據庫參數配置，添加索引，解決阻塞。
再次調研：系統慢功能，慢語句。
針對語句優化：寫法不足，是否缺失索引，是否能加提示、計劃向導等
整體壓力是否緩解：如果仍然壓力很大找到瓶頸，是否可以解決? 如果不能解決才考慮添加硬件或選用分離、分離等方案。
看完上述內容，你們對如何解決 HIS 系統數據庫的癱瘓有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。
