數據庫自動收縮帶來的嚴重問題

背景

　　今天早上11點的時候有客戶打電話過來講醫院的cis系統一直有阻塞，致使系統有卡慢的現象，信息中心的電話都快被打爆了，信息科人員很頭疼啊。

萬幸咱們給數據庫裝了‘攝像頭’會把數據庫的一切狀態操做都會記錄下來，趕忙要了遠程以後看到了系統確實存在大量的阻塞（下圖）

 

 

經過點擊紫色圓點以後發現了長長的阻塞鏈，（注：會話標識33的語句是阻塞的源頭，下面的語句爲被阻塞的語句）能夠看到被阻塞的語句確實等待了很長時間，系統由於大量的阻塞，前端人員的使用確實有卡慢的現象。（下圖）

 

那麼系統爲何會有這麼嚴重的阻塞呢？怎麼形成的？會話標識爲33的語句究竟是何方神聖？接下來咱們來一探究竟。

在sql server 管理工具裏邊用語句查詢會話標識爲33的語句爲自動收縮的命令，看了看時間從2018年8月15號自動收縮已經開始運行，進度爲79%，（下圖）

 

接下來從體檢項中能夠看到相關數據庫自動收縮配置爲開啓狀態。

 

 

經過和醫院工程師交流得知，昨天下午三點半有作過數據遷移的操做，刪除了100多G的數據，（下圖）

 

 

   通過分析和查詢一些資料得出如下結論，數據庫中的自動收縮選項在很早以前就已經開啓，可是沒有真正收縮過，昨天下午三點的時候刪除了大量數據，觸發了自動收縮數據庫文件的操做，

那麼爲何今天早上纔有阻塞的狀況呢？收縮數據庫對於sql server來講自己就是一件浪費資源的事情，在昨天下午三點半的時候前端業務量減少，沒有影響到業務，而到了今天早上業務量增多，達到業務高峯期，纔會把業務相關的語句阻塞住，嚴重影響了前端人員的使用。

如何緩解及解決？

由於在收縮數據文件，要從新整理數據，進度到了79%，在這個自動過程當中，數據邊收縮邊釋放，到達100%後收縮完成後，此問題會解決。另一種方法就是重啓sql服務，事務會提交或回滾，此問題也會獲得解決（不建議）

 下面來點技術性的東西，知足一下求知者的慾望……….

 

 什麼是自動收縮？

 

 

隨着數據量的增長數據庫的設備文件(MDF\LDF)會不斷增加,當數據庫中的某些數據刪除,數據庫設備文件的大小並不會隨着數據量的減小而減小,數據庫設備須要佔用的磁盤空間就沒那麼大了,這時候自動收縮就能夠釋放出磁盤空間,主要直觀體如今數據庫設備文件的大小上,避免資源的浪費.

在什麼條件下會觸發？

在開啓自動收縮選項的狀況下，SQL Server按期會檢查文件使用狀況。若是空閒空間大於25%，SQL Server就會自動運行自動收縮數據庫文件的動做。

（附上微軟官方連接：https://docs.microsoft.com/zh-cn/sql/t-sql/statements/alter-database-transact-sql-set-options?view=sql-server-2017&viewFallbackFrom=sql-server-2014）

例如：數據遷移刪除大量數據時，空閒空間大於25%時，會觸發自動收縮功能。

帶來的危害（自動收縮和手動收縮）？

對於一個磁盤空間很緊張的系統，這個設置無疑是有幫助的。可是從數據庫自身的健康和性能考慮，這個設置並不建議多用。這是由於：

一、數據文件收縮致使了索引的徹底碎片化，索引的效率大大下降，嚴重影響性能。

二、數據文件的收縮一樣產生了大量的I/O操做，耗費大量的CPU資源，性能降低。

三、在業務高峯期的時候可能會形成大量的阻塞。

（附上連接資料，有興趣的同窗能夠去研究一下：

https://www.cnblogs.com/kerrycode/archive/2013/06/04/3116339.html ）

一點點小建議：

一、不要開啓自動收縮選項

二、不到萬不得已，千萬不要收縮數據庫。收縮數據庫影響極大。

三、若是磁盤空間真的不足，須要作收縮的時候，必定要手工來作，並且是在維護窗口期間；而且儘可能使用語句來執行，能夠提示錯誤；儘可能一次不要收縮太多，分幾回收縮。