《只改2條語句，治好HIS系統(tǒng)數(shù)據(jù)庫“葛優(yōu)癱”！》要點：
本文介紹了只改2條語句，治好HIS系統(tǒng)數(shù)據(jù)庫“葛優(yōu)癱”！，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者介紹

吳虞,SQL專家云團隊成員,擅長解決SQL?SERVER數(shù)據(jù)庫性能、高可用、負(fù)載均衡等問題.

記得在自己學(xué)習(xí)數(shù)據(jù)庫知識的時候特別喜歡看案例,因為優(yōu)化的手段是容易掌握的,但是整體的優(yōu)化思想是很難學(xué)會的,所以我自己特別喜歡看案例.

今天整理了一下自己做過的100家以上優(yōu)化或各種方案的客戶案例,本文分享的案例算是在這些客戶中比較典型的了!沒有什么高大上,都是常見的問題!

廢話不多說,直接開整!

系統(tǒng)環(huán)境

首先我們來看一下這個系統(tǒng)配置及現(xiàn)狀,為什么說這個客戶經(jīng)典?那就是因為這個客戶已經(jīng)達(dá)到可以慢的地方都慢,不該慢的地方也慢!

首先這是一套醫(yī)院的HIS系統(tǒng),慢到什么程度呢?各種功能卡死不管是交款、醫(yī)囑、開藥一些列幾乎所有的功能都慢.但是卡慢的現(xiàn)象只出現(xiàn)在上午的高峰期!

先來看看系統(tǒng)配置 ：

數(shù)據(jù)庫版本是SQL SERVER 2008R2,數(shù)據(jù)量大概1個多T,服務(wù)器64CPU 、128G內(nèi)存,服務(wù)器只運行數(shù)據(jù)庫.

咋一看服務(wù)器確實有點老了,數(shù)據(jù)量也大了,內(nèi)存和CPU什么的明顯不夠用了!

數(shù)據(jù)庫指標(biāo)

那么我們再看一下數(shù)據(jù)庫的一些表象：

• 每秒請求數(shù)量：

• 語句執(zhí)行情況：

• 等待情況：

• 等待時間：

• CPU指標(biāo)：

• 內(nèi)存一些指標(biāo)：

• 磁盤隊列：

還有很多指標(biāo)就不一一展示了.

看到這些基本的指標(biāo),除了慢你能看出什么?問題出在哪里?怎么樣快速解決?能有一個優(yōu)化的步驟呈現(xiàn)在眼前么?

優(yōu)化階段一(常規(guī)優(yōu)化)

很多時候系統(tǒng)慢要究其原因,難道上線時候就這么慢?那不可能,廠商根本無法交付的!那么問題來了,什么時候開始慢的?對系統(tǒng)做過哪些調(diào)整?

簡單的調(diào)研開始,給我的只有不到半天的調(diào)研時間,得知的基本問題就是系統(tǒng)在最近一月增加了很多功能,有上線了很多其他系統(tǒng)接口!

那么直接就搞新功能、新程序接口語句? 我認(rèn)為并不是這樣,從一名數(shù)據(jù)庫從業(yè)人員來說,看到這樣的系統(tǒng)一定要先解決大面積等待問題!個人經(jīng)驗來看很多系統(tǒng)大面積等待解決系統(tǒng)會有個很大的提升和改善!

配合一些常規(guī)的調(diào)優(yōu)手段階段一開始了,主要給系統(tǒng)大面積創(chuàng)建影響高開銷大的索引,調(diào)整系統(tǒng)參數(shù),優(yōu)化tempDB、開啟快照讀等….

預(yù)期：

一般系統(tǒng)上面一輪優(yōu)化會有明顯的改善,我認(rèn)為這一輪以后系統(tǒng)會明顯變快,語句CPU會下降到70%左右,內(nèi)存壓力也會有所減少.

結(jié)果：

自信滿滿的我第二天去了各個科室….部分功能依然超時還是各種慢…CPU依然90%以上,內(nèi)存壓力依然明顯.但是收集的數(shù)據(jù)來看,長時間語句數(shù)量已經(jīng)大幅降低,系統(tǒng)等待阻塞情況也明顯好轉(zhuǎn).

• 優(yōu)化前

• 優(yōu)化后

• 優(yōu)化前

• 優(yōu)化后

優(yōu)化階段二(針對語句)

再次分析解決大面積語句阻塞的系統(tǒng),發(fā)現(xiàn)現(xiàn)在的情況,主要有如下幾個：

1. 由于內(nèi)存不足導(dǎo)致的IO壓力.
2. 系統(tǒng)CPU依然彪高.
3. 部分功能語句依然慢,消耗的資源很高.

再次對系統(tǒng)調(diào)研：

1. 哪些功能慢,執(zhí)行的語句是什么.
2. 系統(tǒng)的接口語句問題.
3. 系統(tǒng)中還有哪些消耗資源高的語句,是否能優(yōu)化.

調(diào)研后,我遇到了最常見也是最大的問題： 語句慢由于程序!很多人看到這會說程序慢就改唄,那有啥問題? 問題就在于你來做優(yōu)化直接了當(dāng)?shù)暮腿思议_發(fā)人員說你程序太爛必須改!如果你是程序開發(fā)人員你會有什么樣的反應(yīng)?

他會說：對不起,影響太大改不了!

那么這個優(yōu)化項目黃了,或者你要付出更大的代價繞過這樣的問題.

分析中發(fā)現(xiàn)程序使用了大量各種自定義函數(shù),有一定經(jīng)驗的人都應(yīng)該知道,語句在篩選的列上使用函數(shù)是沒有辦法使用索引查找的,這樣相對于這種單表數(shù)據(jù)就幾百甚至幾千萬的表,是何等的災(zāi)難!但是不能冒然突出修改程序,那還能怎么優(yōu)化呢?大概分析后得出結(jié)論,程序主要消耗在幾部分：

1. 部分業(yè)務(wù)功能語句慢.
2. 接口語句慢(主要是視圖,供其他程序調(diào)用).
3. 還有報表程序.

• 針對第一部分在不能改程序的情況下,嘗試添加計劃向?qū)Ц淖冋Z句執(zhí)行情況；
• 針對第二部分修改接口視圖,包括替換掉函數(shù)、添加索引等；
• 針對第三部分報表這東西不是短期就可以優(yōu)化的,所以再原有鏡像的方案上添加快照,實現(xiàn)了簡單的讀寫分離,直接分走；

語句優(yōu)化的效果：

• 優(yōu)化前

• 優(yōu)化后

• 優(yōu)化前

• 優(yōu)化后

預(yù)期：

90%消耗高的語句都得到了優(yōu)化,系統(tǒng)應(yīng)該可以快起來了,CPU、內(nèi)存指標(biāo)也應(yīng)該正常了!

結(jié)果：

語句的消耗和時間都降下來了,系統(tǒng)卡慢現(xiàn)象有明顯好轉(zhuǎn),但是CPU依然90%以上、內(nèi)存壓力依然明顯,磁盤隊列還是很高!系統(tǒng)性能問題依然存在.

優(yōu)化階段三(深入指標(biāo)分析)

經(jīng)過前兩個階段的優(yōu)化一般系都會明顯好轉(zhuǎn),并且指標(biāo)正常,這也是前面提到的可以慢的地方慢已經(jīng)解決,那么為什么CPU、內(nèi)存壓力沒有緩解?難道真的是64CPU、128G內(nèi)存不能支持了?需要加內(nèi)存換CPU?難道要做負(fù)載均衡?各種拆分?

• CPU分析

首先我對CPU壓力進行了分析,綜合語句的CPU消耗和CPU的表象來看,很大一部分應(yīng)該不是語句執(zhí)行消耗的!那么服務(wù)器上確實也沒有跑其他程序,CPU資源哪里去了?

看看這個計數(shù)器：

SQL的編譯次數(shù)高峰時間段達(dá)到每秒2000多次!很多書上寫過,相信很多看官也知道,語句不參數(shù)化會給CPU造成壓力,這就是個鮮活的例子!那么解決辦法也是比較粗暴,程序無法修改那么就在數(shù)據(jù)庫上開啟強制參數(shù)化.

看下效果：

我想不用多說什么了!

• 內(nèi)存分析

看到了CPU的現(xiàn)象那么內(nèi)存的問題也有眉目了,這么多編譯即席查詢,首先看一下內(nèi)存中緩存了那些數(shù)據(jù)：

SQLOPTIMIZER Singlepage占到了80多個G,而在查詢數(shù)據(jù)頁的緩存只有20個G,而且仍然在被不斷壓縮,那么內(nèi)存沒壓力就怪了!這個SQLOPTIMIZER Singlepage嘗試了一下是無法通過DBCC FREExxxxx的操作釋放的,所以在半夜直接重啟了SQL 服務(wù)!將近2年沒有重啟的SQL服務(wù)就這么折在我的手里了!

重啟后頁生命周期：

內(nèi)存這個問題,不知道是不是微軟的一個小BUG,查詢計劃的緩存?zhèn)€人理解不會一直壓榨數(shù)據(jù)緩存的,客戶的數(shù)據(jù)庫沒有補丁,但是查閱08的各個補丁也沒有找到相關(guān)問題的修復(fù).

也請遇到過或了解的朋友給點提示!

預(yù)期：

語句已經(jīng)優(yōu)化,阻塞情況也被解決,CPU、內(nèi)存、磁盤壓力也沒有了,系統(tǒng)肯定快起來了!

結(jié)果：

系統(tǒng)快起來了!

總結(jié)

文章只是簡單地描述了一下某醫(yī)院HIS系統(tǒng)的優(yōu)化過程,當(dāng)然一周的工作僅僅通過一篇文章寫出全過程細(xì)節(jié)必然不那么詳盡,還望看官們見諒!

整個的優(yōu)化過程是程序只修改了2條語句,其他都是通過數(shù)據(jù)庫優(yōu)化手段完成.而且沒有添加任何硬件資源!(?文章中用到的工具鏈接：?http://www.grqsh.com/product_Expert.html)

優(yōu)化過程主要分為：

• 系統(tǒng)整體調(diào)研 ：和科室用戶溝通慢的情況,系統(tǒng)最近變更情況,并收集數(shù)據(jù).
• 常規(guī)優(yōu)化 ： 調(diào)整數(shù)據(jù)庫參數(shù)配置,添加索引,解決阻塞.
• 再次調(diào)研：系統(tǒng)慢功能,慢語句.
• 針對語句優(yōu)化：寫法不足,是否缺失索引,是否能加提示、計劃向?qū)У?/li>
• 整體壓力是否緩解：如果仍然壓力很大找到瓶頸,是否可以解決?如果不能解決才考慮添加硬件或選用分離、分離等方案.

文章出處：DBAplus社群

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4449.html