为什么SHRINKFILE是件非常糟糕的事情及应该怎么办

        原文出自：http://www.sqlservercentral.com/articles/SHRINKFILE/71414/

        Joe.TJ翻译整理，仅用于传播资讯之目的。注意：原文中的引用资讯和一个重建索引的存储过程，在翻译整理时未加入译文中。

问题：

尽可能避免收缩数据库文件(使用SSMS或者T-SQL)。在理想环境中，最好从一开始就确定文件大小，然后使其按需增长。

当然，在现实世界中总是有文件超出所分配大小和数据膨胀，或者我们需要从文件中回收，因数据被删除或者压缩的空闲出的那部分空间。

当发生前述情况，我们只限于使用SHRINKFILE命令。SQLServer不是很在意把文件尾部已分配页移动到文件首部未分配页时所安放的位置，这样就导致两个问题：

1. 数据变得碎片化，有可能达到100%的碎片率，这是一个数据库的性能杀手。
2. 这个操作很慢。所有被移动的页或行的指针，必须要被修正。SHRINKFILE是一个单线程操作，所以它会很慢。SHRINKFILE的单线程性质也不会很快被改变。

SHRINKDATABASE vs SHRINKFILE vs AutoShrink：

SHRINKDATABASE命令实际上是按顺序对数据库的每个数据文件执行SHRINKFILE命令。所以本文接下来 的内容只引用SHRINKFILE，但是同样适用于SHRINKDATABASE。

请查看联机丛书，了解两者的区别和用法。自动收缩(AutoShrink)设置不是SHRINKFILE或者SHRINKDATABASE的替代方法，它实际上是执行SHRINKDATABASE命令。

 

建议做法(1):尝试TRUNCATONLY选项

      首先应尝试使用DBCC SHRINKFILE TRUNCATONLY：它只是移除文件尾部的空闲空间，并不重新组织已经使用的数据页。

      这可能不会产生令你满意的效果，即不会释放足够的空间。但是值得去尝试，特别是因为它的速度比没有使用TRUNCATEONLY选项时的DBCC SHRINKFILE快很多。

 

建议做法(2):在SHRINKFILE之后重新组织或者重建索引

     如果一定要执行SHRINKFILE，请分配足够的等待时间给此处理完成这一操作。但要注意，你可以在任何时候停止此操作，并且不会引起回滚。

     所有已做的处理会被记录，但是任何取消点之前已完成的操作将会生效，所以稍后你可以接着再执行并且前面所花的时间并不完全算是浪费。

这样的缺点就是，你制造了很数据碎片。

一旦完成SHRINKFILE，就要确定需要重建和重组的索引，并执行。这里最棘手是获知需要多少时间。这时间不仅仅是包括完成收缩文件，

而且还有在完成收缩后重建或重组索引所需的时间。这还有文件再次增长带来的负面影响，但是希望它增长的量不要跟我们收缩的量一样多。

 

建议做法(3):把用户数据移到新的文件

添加一个包括一个或多个文件的新文件组到数据库，重建索引时把数据导入到新的文件组。然后再收缩原来的文件。这个方法有几个优势：

1. 避免了SHRINKFILE原文件时的碎片问题，因为没有用户数据需要移来移去，也没有碎片。
2. 对原来的文件执行SHRINKFILE会快很多，因为没有用户数据需要移动。
3. 因为你不需要re-index原来文件中的表，所以就不会再次增长其大小。
4. 你可以在一个更小的，更易于管理的块中执行收缩，并且不会影响留在原来文件中的数据。

    当然，你需要把新的文件组设置为默认文件组，否则你将会把新增的表和对象加进了旧的文件组。

因为很多理由(没有足够的磁盘空间给新文件组，堆表上没有索引，不便于管理等)，这样做也许不大可能。

但是，这种做法是分离数据库中的用户数据和系统数据的最佳实践。

 

结束语

     这篇文章不并意味着是对SHRINKFILE的详尽说明，只是让你注意到对数据库执行SHRINKFILE,SHRINKDATABASE和AutoShrink极有可能是一件非常糟糕事情。

     如果您又不得不这样做时，可供您选择的一些做法。

转载于:https://www.cnblogs.com/Joe-T/archive/2011/12/22/2298051.html