数据库自动收缩带来的严重问题

背景

　　今天早上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%时，会触发自动收缩功能。

带来的危害（自动收缩和手动收缩）？

对于一个磁盘空间很紧张的系统，这个设置无疑是有帮助的。但是从数据库自身的健康和性能考虑，这个设置并不建议多用。这是因为：

1、数据文件收缩导致了索引的完全碎片化，索引的效率大大降低，严重影响性能。

2、数据文件的收缩同样产生了大量的i/o操作，耗费大量的cpu资源，性能下降。

3、在业务高峰期的时候可能会造成大量的阻塞。

（附上链接资料，有兴趣的同学可以去研究一下：

）

一点点小建议：

1、不要开启自动收缩选项

2、不到万不得已，千万不要收缩数据库。收缩数据库影响极大。

3、如果磁盘空间真的不足，需要做收缩的时候，一定要手工来做，而且是在维护窗口期间；并且尽量使用语句来执行，可以提示错误；尽量一次不要收缩太多，分几次收缩。