是“DBCC SHRINKDATABASE”还是“DBCC SHRINKDATABASE”：这是个问题

Question

我们正在释放 SQL Server 2008 R2 数据库中的大量空间 - 太棒了！足以关心-（我们丢弃了大量不必要的数据）。但数据库文件会保留其文件大小。我们想重新获得它。

我多次听说使用DBCC SHRINKDATABASE会降低数据库的性能 - 据我所知，因为“...收缩操作不会保留数据库中索引的碎片状态，并且通常会将碎片增加到学位” [MSDN]

所以我打算使用DBCC SHRINKDATABASE然后重建我们的索引。

不使用DBCC SHRINKDATABASE来重新获得磁盘空间还有另一个性能原因吗？

Answer 1

来自Tibor Karaszi 的博客：

那么问题是什么？为什么我不应该定期收缩数据库文件？查看下面的列表，然后您可以自己确定是否要定期收缩数据库文件：

• 移动的每个页面都将记录到事务日志中。假设您有一个具有 50GB 已用空间（数据和索引页）的数据库，并且收缩将向文件开头移动 40GB。此收缩操作的日志文件将需要 40GB，可能会自动增长到该大小（如果日志文件中没有 40GB 可用空间）。以下日志备份的大小为 40GB，加上“常规”日志记录。如果数据库处于简单恢复模式，这似乎不会发生，可能是因为 CHECKPOINT 会在收缩期间定期修剪日志。（适用于数据文件的收缩。）

• 收缩后，随着用户在数据库中添加行等，文件必须再次增长。增长数据库文件是一项昂贵的操作，它需要时间并且还会损害性能（大量资源使用）。此外，一些修改将被阻止，直到增长操作完成。（适用于数据和日志文件的收缩。）

• SQL Server 2005 及更高版本：从 SQL Server 2005 开始，我们具有“即时文件初始化”功能，这意味着可以创建数据库文件并快速增长，因为 Windows 不会将数据库文件中的数据“归零”。即时文件初始化仅适用于数据文件，不适用于日志文件。此外，实例文件初始化要求 SQL Server 服务的服务帐户具有 SE_MANAGE_VOLUME_NAME 窗口权限，可以使用执行卷维护任务安全策略分配该权限。默认情况下，这仅授予管理员。

• 在某些情况下，自动增长无法“赶上”空间使用要求。这将导致在执行修改时来自 SQL Server 的错误消息返回到客户端应用程序：如果数据已满则返回错误 1105，如果日志已满则返回 9002。（适用于数据和日志文件的收缩。）

• 四处移动数据页会使您的数据库碎片化。假设您重建索引（这将需要数据库中有可用空间），然后缩小数据库。收缩基本上会撤消索引重建，从而为您留下碎片化的索引。不相信我？这很容易自己测试。

• 如果你反过来做，先缩小，然后重建怎么办？好吧，rebuld 需要数据库中的可用空间用于您重建的最大索引，并且您可能有一个带有聚集索引的大表。我的一个朋友有一个 4GB 的已用空间数据库，其中几乎所有空间都是一个 4GB 的表。他做了一个收缩然后重建，重建立即将数据库大小“增加”到 8GB。（适用于数据文件的收缩。）

• 数据库文件的大量收缩和增长会使您的文件系统碎片化，这将进一步损害性能。（适用于数据和日志文件的收缩。）

• 事务日志文件的反复收缩和随后的增长通常会产生许多虚拟日志文件，从而导致数据库启动时间过长。这可能表现为数据库启动时间长、恢复时间长、事务复制延迟等。查看此博客文章了解更多信息。