Mar*_*rat 34 sql-server-2005 sql-server
我不擅长 SQL，但我有一个数据库要维护。
几乎没有地方留给它了，所以我决定删除所有数据，比如说 2008 年。在执行删除查询（清理了大约 10 000 000 行）和清理事务日志后，我发现我的操作对数据库大小没有影响。还有什么我需要做的吗？
Mik*_*lsh 21
由于这里提到的原因，收缩确实是危险的。Jimbo 的回答和 John 的回答之间有一个愉快的媒介......您应该始终认真考虑是否要缩小您的数据库。
在理想的世界中 - 您将创建具有大量可用空间的数据库。我称之为“正确调整大小”您的数据库。你会允许这个可用空间在那里，而不是努力把它归还，并将你的总大小保持在你使用的大小。为什么？因为你的数据库最终会再次增长..然后你会再次收缩..你会陷入这种无用的收缩和增长的可怕模式中 - 并且整个时间，正如一些人指出的那样，你会增加索引碎片。
我已经在博客中告诫人们“不要碰那个收缩按钮！ ”但有时……有时你需要这样做。如果您有一个大型数据库，只是释放了大量空间并且不希望再增长到它 - 那么可以考虑将收缩作为一次性操作，只要您之后可以通过重建处理索引碎片他们。收缩操作可能很耗时，因此您需要计划一段时间，以便您可以支付收缩运行的代价。创建空数据库并将数据复制到其中的方法有效 - 但是对于更大的数据库和大量数据，这可能变得非常困难。
如果您计划在未来通过正常使用和增长模式将该空间添加回数据库，那么您可能只想将空间留在那里。
还
你说你“清除”了你的交易日志。我很想知道您是如何做到这一点的，但是当您阅读我分享的帖子和系列中的其他帖子时，您会看到一些有关事务日志管理的提示。但简而言之 - 如果您处于完全恢复模式，您应该定期进行日志备份以保持日志自身重用。否则 - 在完全模式下没有日志备份 - 日志文件不断增长，增长和增长，并始终保存您所做的事情，因为您告诉 SQL 您不仅想维护该日志以进行崩溃恢复，还想保留一个手动备份它以重播事务/撤消事务以恢复到特定时间点以进行恢复......如果你很简单并且看到日志过度增长，BEGIN TRAN ... do work.... COMMIT TRAN或者您是否只是发布了一个大DELETE声明并在一个隐式事务中删除了一大堆数据。）
我还假设您正在文件系统上寻找这个可用空间。如果您正在 SQL 中和您拥有的那个大文件中寻找它 - 如果在您的操作后立即查看，您可能正在等待 Ghost 清理完成。Paul Randal 关于 Ghost Cleanup 的博客。
小智 11
删除数据库中的行不会减少实际的数据库文件大小。
您需要在行删除后压缩数据库。
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
运行此程序后，您将需要重建索引。收缩通常会导致索引碎片化，这可能会导致显着的性能成本。
我还建议您在缩小后重新增大文件，以便有一些可用空间。这样，当新行进入时，它们不会触发自动增长。自动增长具有性能成本，并且您希望尽可能避免（通过适当的数据库大小调整）。
不要缩小您的数据库！
“为什么会发生这种情况？数据文件收缩操作一次只处理一个文件，并使用 GAM 位图（请参阅存储引擎内部：GAM、SGAM、PFS 和其他分配图）来查找在文件。然后它尽可能地将它移到文件的前面，依此类推。在上面的例子中，它完全颠倒了聚集索引的顺序，将它从完全碎片整理到完全碎片化。 ”
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
“看看Shrinking database的讽刺。一个人缩小数据库以获得空间（认为这有助于性能），这导致碎片增加（降低性能）。为了减少碎片，重建索引，导致大小数据库增加的方式超过数据库的原始大小（收缩前）。好吧，通过收缩，人们没有获得他通常想要的东西。“
| 归档时间： |
|
| 查看次数： |
150481 次 |
| 最近记录： |