问“DBCC SHRINKDATABASE”还是“DBCC SHRINKDATABASE”：这就是问题所在

EN

来自Tibor Karaszi的博客：

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

• 移动的每个页面都将被记录到事务日志中。假设您有一个50 GB的使用空间(数据和索引页)的数据库，收缩器将在文件开始时洗牌40 GB。此收缩操作的日志文件将需要40 in，可能会自动增长到此大小(如果日志文件中没有40 in的空闲空间)。以下日志备份的大小为40 in，加上“常规”日志记录。如果数据库处于简单恢复模式，则这种情况似乎不会发生，因为检查点可能会在收缩期间对日志进行反向修剪。(适用于数据文件的收缩。)
• 在收缩之后，当用户在数据库中添加行等时，文件必须再次增长。增长一个数据库文件是一个昂贵的操作，它需要时间，它也损害性能(大量的资源使用)。另外，一些修改将被阻止，直到增长操作完成。(适用于数据和日志文件的收缩。)
• Server 2005及更高版本:从Server 2005开始，我们有了“即时文件初始化”，这意味着数据库文件可以创建，而且增长也非常快，因为Windows不会“清除”数据库文件中的数据。即时文件初始化仅适用于数据文件，而不是日志文件。此外，实例文件初始化要求Server服务的服务帐户具有SE_MANAGE_VOLUME_NAME窗口私有，可以使用“执行卷维护任务安全策略”分配该窗口。默认情况下，这仅授予管理员。
• 在某些情况下，autogrow无法“赶上”空间使用要求。这将导致在执行修改时来自Server的错误消息，返回给客户端应用程序:如果数据已满，则为错误1105，如果日志已满，则为9002。(适用于数据和日志文件的收缩。)
• 移动数据将分割您的数据库。假设您重新生成索引(这将需要数据库中的空闲空间)，然后收缩数据库。收缩将从本质上撤消索引重建，留下分段索引。不相信我？这很容易为你自己测试。
• 如果你反过来做，先收缩，然后重建呢？好的，rebuld需要在数据库中为您重建的最大索引留出空间，而且很可能您有一个包含聚集索引的大表。我的一个朋友有一个4GB的空间数据库，其中几乎所有的空间都是一个4GB的表。他做了一个心理医生，然后重建，在那里重建立即“撞”到8GB的db大小。(适用于数据文件的收缩。)
• 数据库文件的大量收缩和增长会使您的文件系统分片，这将进一步损害性能。(适用于数据和日志文件的收缩。)
• 事务日志文件的反复细化和随后的增长通常会导致许多虚拟日志文件的出现，从而导致数据库的长时间启动。这可以表现为数据库启动时间长、恢复时间长、事务复制延迟等。有关更多信息，请查看此博客文章。