获取 MS SQL Server 以释放磁盘空间

Question

管理不善的数据库表已经变得非常庞大。48+演出孤儿唱片。我正在尝试清理它并将我危险的满硬盘驱动器恢复到正常状态。我将从该表中删除大约 4 亿条记录。这是在我输入时运行。我注意到我的硬盘空间没有任何下降，但我看到系统表查询的内存下降，我正在运行以获取表大小。数据库正在使用“简单恢复模型”。

有很多与此类似的问题，回答说您需要缩小数据库。但是他们继续解释由于数据碎片等原因，这样做有多糟糕/可怕。

1. 由于数据库不应该是这个大小。缩小它对我来说还是不好的吗？
2. 这是一个生产数据库。如果我缩小它会导致停机或锁定数据库吗？
3. 在 SQL Server Management Studio 中，您有两个选项用于收缩、数据库或文件。鉴于我的情况，最好的选择是什么？
4. 是否有关于数据库应具有的可用空间百分比的规则？

甚至阅读shrink 的标签描述也让我不想这样做。还有其他方法吗？

Answer 1

我将从该表中删除大约 4 亿条记录。

希望您是分块进行的- 以避免事务日志膨胀。

请注意，我没有看到我的硬盘空间有任何下降

您不会，因为您必须明确缩小数据库文件以释放空间。只是删除记录，SQL Server 不会将空间释放回操作系统。

1. 由于数据库不应该是这个大小。缩小它对我来说还是不好的吗？

这通常是一种不好的做法，因为应该适当地预先调整数据库的大小。如果您 100% 确定您的数据库不会再次达到这个大小，那么您可以缩小数据库 （在您的场景中）。

2. 这是一个生产数据库。如果我缩小它会导致停机或锁定数据库吗？

缩小数据库是非常 IO 密集型的。建议DBCC SHRINKFILE在维护窗口期间或活动最少时缩小使用范围。

3. 在管理工作室中，您有两个选项，数据库或文件。鉴于我的情况，最好的选择是什么？

您应该使用 TSQL 进行收缩。（既然你问了，缩小FILE是要走的路，而不是数据库）。您可以分块使用收缩数据库 - tsql脚本来分块进行收缩。

请记住，当您收缩时，您正在分割索引。

4. 是否有关于数据库应具有的可用空间百分比的规则？

您可以参考Estimating Disk Space Requirements for Databases 一文。没有固定规则，您必须考虑数据库的预期增长方式。您还必须考虑数据库的自动增长。

参考：为什么事务日志不断增长或空间不足？

Answer 2

您有充分的理由担心，因为 SQL Server 中的 DB 收缩经常“糟糕”。SQL 2005 存储引擎负责人 Paul Randal 表示，ShrinkDB 的编写非常糟糕。它将通过在最后获取数据并将其放在最开始并继续这样做来找到空白空间，直到在 DB 文件的“末尾”有可用空间。此时，它可以从 SQL Server 释放空间并将其返回给操作系统。您正在有效地反转数据库文件，因此您通常会看到大量碎片。您可以在此博客文章或此MCM 内部视频中了解他的观点

与所有事情一样，您确实必须首先在您的环境中测试这些内容。更好的方法是将数据移动到不同的文件组。您可以使用聚集索引进行联机索引重建，然后在新文件组中重新编制索引。然后你可以放下旧的并释放空间并且几乎没有碎片。请注意，这将在它运行时占用大约 120% 的额外空间。这样做的问题是您甚至需要额外的可用空间，而这看起来您可能没有。这是企业功能。

如果可用空间非常宝贵，那么您可能不得不咬紧牙关，一次将数据库缓慢缩小一小块，以避免长时间运行的进程。请注意，您的数据将严重碎片化，您将需要重新索引所有内容。请注意，在对所有内容重新编制索引后，您的已用空间将膨胀一点，然后返回到拥有额外的可用空间。在这里查看布伦特的建议。

至于多少可用空间对您有好处，取决于您能负担多少碎片和文件增长活动。启用 IFI 后，文件增长几乎是即时的，但您仍然会出现碎片。一个好的经验法则是预先分配您认为需要的尽可能多的空间，或者监控增长并在必要时定期调整。这可以减少物理碎片。

此外，日志文件的增长更为重要。其他日志文件可能会导致 VLF 碎片。这会使您的恢复速度变慢，并可能影响检查点/截断。 以下是使用碎片日志可能带来的一些性能风险。DBCC LOGINFO();在每个数据库上做一个。尝试将每个 Kim Tripp 的数量保持在 50 左右，但如果您看到数百个，则说明存在碎片问题，这意味着您的日志文件必须增长以支持操作。查看每个 Paul Randal 的日志文件应该是什么的一个好方法是让它增长一周并重新索引。这可能是个好点子，也许你可以在那里多放一点空闲空间以防万一。确保您的日志没有被 DBCC LOGINFO(); 再次，如果他们是，这意味着他们成长了很多。使用收缩和重新扩展日志文件这个方法。