管理不善的数据库表已经变得非常庞大。48个以上的孤儿记录。我正在尝试清理它并将危险的满硬盘驱动器恢复到正常状态。我将从该表中删除大约4亿条记录。当我键入时，它正在运行。我注意到我的硬盘驱动器空间没有减少，但是系统表查询的内存减少了，我正在运行以获取表大小。该数据库正在使用“简单恢复模型”。
有许多与此类似的问题，有答复说您需要缩小数据库。但是他们继续解释由于数据等的分散，这样做是多么的糟糕/可怕。
即使阅读了shrink的标签说明，我也不想这样做。还有另一种方法吗？
Answers:
我将从该表中删除大约4亿条记录。
希望您可以分块执行此操作 -避免使事务日志膨胀。
请注意，我的硬盘空间没有下降
您不会，因为您必须显式收缩数据库文件以释放空间。只是删除记录，SQL Server不会将空间释放回OS。
- 由于数据库不应该具有此大小。缩小它仍然对我有害吗？
通常，这是一个不好的做法，因为应该正确调整数据库的大小。如果您100％确定数据库不会再次达到此大小，则可以缩小数据库大小 （在您的方案中）。
- 这是一个生产数据库。如果缩小，会导致停机或锁定数据库吗？
缩小数据库非常耗费IO。建议DBCC SHRINKFILE在维护时段或活动很少的情况下收缩使用。
- 在Management Studio中，您有两个选择，数据库或文件。根据我的情况，最好的选择是什么？
您应该使用TSQL进行收缩。（自从您询问以来，缩小FILE是代替数据库的一种方式）。您可以按块使用收缩数据库-tsql脚本按块进行收缩。
请记住，收缩时会碎片化索引。
- 数据库应具有的可用空间百分比是否有规定？
您可以参考估计数据库的磁盘空间要求一文。没有修复规则，您必须考虑数据库的增长方式。您还必须考虑数据库的自动增长。
您有充分的理由要担心，因为SQL Server中的DB经常“吮吸”。SQL 2005存储引擎负责人Paul Randal表示，ShrinkDB的编写非常糟糕。它会通过在最末端获取数据并将其放在最开始来查找空白空间，并继续这样做，直到在DB文件的“末端”具有可用空间为止。此时，它可以从SQL Server释放空间并将其分配回OS。您正在有效地反转数据库文件，因此通常会看到大量碎片。您可以在此博客文章或此MCM Internals视频上了解他的观点。
与所有内容一样，您实际上必须首先在您的环境中对其进行测试。更好的方法是将数据移动到另一个文件组。您可以使用聚簇索引进行联机索引重建，然后在新文件组中重建索引。然后，您可以删除旧的并释放空间，几乎没有碎片。请注意，这会占用大约120％的额外空间。这样做的问题是，您甚至需要额外的可用空间，看起来好像没有。这是企业功能。
如果可用空间非常重要，那么您可能不得不硬着头皮，一次将DB慢慢缩小一小块，以避免长时间运行的进程。请注意，您的数据将非常分散，您将需要重新为所有内容重新编制索引。请注意，在对所有内容重新编制索引之后，您将稍微增加使用的空间并返回到具有额外的可用空间。请参阅此处的 Brent建议。
至于有多少可用空间对您有好处，这取决于您可以负担多少碎片和文件增长活动。启用IFI后，文件增长几乎是即时的，但仍然会产生碎片。一个好的经验法则是根据需要预分配尽可能多的空间，或者监视增长并根据需要定期进行调整。这样可以减少物理碎片。
另外，日志文件的增长更为重要。其他日志文件可能会导致VLF碎片化。这会使您的还原速度变慢，并可能影响检查点/截断。 使用零散的日志会带来一些性能风险。DBCC LOGINFO();在每个数据库上执行一个。尝试将每个Kim Tripp的数量保持在50欧元左右，但是如果看到数百个，就会出现碎片问题，这意味着必须增加日志文件才能支持操作。查看每个Paul Randal日志文件的好方法是让它增长一周并重新索引。那可能是个好主意，也许您可以在上面留下更多的可用空间，以防万一。确保您的日志没有被DBCC LOGINFO（）分割；再一次，如果他们是，这意味着他们成长了很多。使用以下命令缩小并重新扩展日志文件这种方法。