背景 今天早上11點的時候有客戶打電話過來說醫院的cis系統一直有阻塞，導致系統有卡慢的現象，信息中心的電話都快被打爆了，信息科人員很頭疼啊。 萬幸我們給資料庫裝了‘攝像頭’會把資料庫的一切狀態操作都會記錄下來，趕緊要了遠程之後看到了系統確實存在大量的阻塞（下圖） 通過點擊紫色圓點之後發現了長長的阻 ...
背景
今天早上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就會自動運行自動收縮資料庫文件的動作。
例如：數據遷移刪除大量數據時，空閑空間大於25%時，會觸發自動收縮功能。
帶來的危害（自動收縮和手動收縮）？
對於一個磁碟空間很緊張的系統，這個設置無疑是有幫助的。但是從資料庫自身的健康和性能考慮，這個設置並不建議多用。這是因為：
1、數據文件收縮導致了索引的完全碎片化，索引的效率大大降低，嚴重影響性能。
2、數據文件的收縮同樣產生了大量的I/O操作，耗費大量的CPU資源，性能下降。
3、在業務高峰期的時候可能會造成大量的阻塞。
（附上鏈接資料，有興趣的同學可以去研究一下：
https://www.cnblogs.com/kerrycode/archive/2013/06/04/3116339.html ）
一點點小建議：
1、不要開啟自動收縮選項
2、不到萬不得已，千萬不要收縮資料庫。收縮資料庫影響極大。
3、如果磁碟空間真的不足，需要做收縮的時候，一定要手工來做，而且是在維護視窗期間；並且儘量使用語句來執行，可以提示錯誤；儘量一次不要收縮太多，分幾次收縮。
