SHRINKFILE最佳做法和经验

Question

序言:一般来说，这是一个大的不-不，但相信我，这是罕见的情况下，空间是真正需要的。例如，速成版限制在10 to以内。假设您发现，通过数据类型转换( blob列)，您可以释放大量空间。但在此之后，DB文件的大小仍与我们所知道的相同，并且10 DB的限制也没有神奇地改变。所以需要某种心理医生。这就是一个例子。

在我的测试环境中，我执行了：

DBCC SHRINKFILE (DBFile, NOTRUNCATE)
DBCC SHRINKFILE (DBFile, TRUNCATEONLY)

这就成功了(我知道这会使自由空间最小化，在现实世界中，我会留下自由空间)。花了好几个小时才完成。正如我们所知道的，它是一个单线程进程奇怪行为DBCC Shrinkfile，“它作为一系列非常小的系统事务工作，因此没有什么可回滚的。”- Paul http://www.sqlservercentral.com/Forums/Topic241295-5-1.aspx。我们还知道，它会破坏索引碎片，大时间使用http://www.mssqltips.com/sqlservertip/2055/issues-with-running-dbcc-shrinkfile-on-your-sql-server-data-files/，我可以确认这一点。虽然在http://www.karaszi.com/SQLServer/info_别_shrink.asp中描述过，但我没有经历日志文件的增长

我发布了一些INDEX REBUILD和REORGANIZE，它们在几秒钟内就完成了。

我的问题：

1. 如果我能在几秒钟内修复收缩后的索引碎片，那么收缩有什么大不了的呢？我不明白。在database上，“收缩”主题(https://dba.stackexchange.com/tags/shrink/info)说“这是对Server数据库所能做的最糟糕的事情。简而言之:它牺牲性能以获得空间。”另外还提到了另一篇关于它的流行文章。但是索引分割可以被修正。
2. 为什么我没有经历任何日志文件增长？
3. 如果在空间释放操作之后重建索引会怎样？这能替代第一个DBCC SHRINKFILE (DBFile, NOTRUNCATE)，所以我只需要DBCC SHRINKFILE (DBFile, TRUNCATEONLY)吗？我有一种感觉，这两种工作在不同的逻辑层次，但我必须问这一点。

底线:我保证我不会经常收缩什么的。但是，在这种情况下，需要设置上限并进行收缩。

回答我的第二个问题:我没有经历事务日志文件的增长，因为我在开发人员测试环境中摆弄。事务日志文件将在生产环境中增长(假设为完全恢复模型)。您也应该在您的测试环境中模仿这一点。tr日志文件的增长实际上大于数据库文件中可以释放的空间。最后，您不仅希望收缩数据库文件，还希望缩小事务日志(如何以及何时进行此操作取决于恢复模型)。我所看到的生产环境已经把索引碎片搞得乱七八糟，所以它可以变得更好。我的脚本重新索引了碎片级别超过30%的每个索引。

要处理增长，您可能必须切换从完全恢复到简单，而您正在进行一生一次的转换。但那会打破后备链。

回答我的第三个问题:在DB文件收缩后进行重新索引/索引重建，因为收缩会破坏索引碎片。

我还没有试验过所有这些对查询统计的影响。

重新编制索引的脚本:参见TechNet sys.dm_数据库_索引_物理性_stats (Transact-SQL)的示例D。一篇关于增量收缩的文章，它将导致其他有价值的内容：http://www.mssqltips.com/sqlservertip/3178/incrementally-shrinking-a-large-sql-server-data-file-using-powershell

Answer 1

如果你想：

1. 忽略所有来自非常聪明的人的警告，他们在Server方面有丰富的经验；
2. 假设在这种情况下，您没有经历日志增长，而且在这种情况下，修复碎片是很快的，并且不会导致任何进一步的增长，这将永远是这样的。
3. 不确认此增长/收缩/增长/收缩周期对查询时间有任何影响；

您先请。既然你说你只会在罕见的情况下这样做，我不知道你在这里寻找什么答案。你想要一个大拇指，你可以忽略它的所有你已经读到的，并掷骰子？

我建议至少有一件事:如果你有10 if的数据，在Express中达到10 if的限制就会发生。您可以通过删除数据文件中的数据(或在多个数据库中传播数据)来避免这种情况。如果您在数据文件中释放了大量空间，该空间将被重用(如果您删除了一个表，这将是自动的；如果您删除了行或更改了列结构，您将需要重新构建--这至少会占用一些空间)。因此，如果您在文件中释放了5GB的数据，仅仅因为文件是9GB，并不意味着如果添加2GB，它就会尝试变成11 2GB-它将重用文件中的空间，直到找不到为止。如果将文件缩小到4GB，然后强制它增长以适应新的数据，这将是一个更昂贵的操作。这就像洗一条已经干净的毛巾，你要用它来擦拭一团乱东西.