我最近对我的数据进行了一些归档，并执行了以下操作：
我的数据库表包含超过 3300 万条记录，其中许多是重复的。
我备份了表并将唯一数据插入到新表中，然后重命名/交换表名称，这实现了我所需要的。
然而现在我只剩下两张桌子了......
- Table1（良好/活动表）- 1000 万条记录
- Table1_Backup（备份表）- 3300万条记录
执行此操作后，我的 SQL mdf/数据文件已增加到 319.7 GB，我的日志文件已增加到 182 GB。
这占用了我的大部分可用操作系统空间，并且我的 D 驱动器现在空间不足。
我的问题是，一旦我对存档数据感到满意，我将删除 _backup 表，只留下我好的实时表。
但据我了解，SQL 不会给我任何可用空间给操作系统，从日志/mdf 文件中回收该空间的最佳方法是什么，我读过很多关于收缩 db/log 的内容，但很多人说这是不好的做法，任何建议都会很好......
TL;DR:不要收缩数据库。曾经。
但如果你确实需要缩小它怎么办？
根据 SQL Server 专家 Brent Ozar 上面链接的文章 - 在某些情况下，缩小数据库是一个合法的选择：
- 您的数据库为 1TB 或更大
- 您已删除 50% 的数据
- 您有 500GB+ 的可用空间
- 您永远不会需要该空间，因为您现在正在进行定期删除和存档
完整答案：
您写道您一直在阅读有关此内容的文章 - 所以我希望您遇到过类似的帖子布伦特·奥扎尔's 使用 DBCC SHRINKDATABASE 收缩数据库有什么不好？:
您的碎片很高，因此您需要重建索引。
这会留下大量空白空间，因此您会缩小数据库。
这会导致高碎片，因此您需要重建索引，这会导致数据库重新增长并再次留下空白空间，这样的循环就会持续下去。
迈克·沃尔什's 不要触摸 SQL Server 中的收缩数据库按钮！- 他解释了同样的事情：
缩小数据库时会发生什么？
当你收缩数据库时，你要求 SQL Server 从数据库文件中删除未使用的空间。SQL 使用的过程可能很丑陋，并导致索引碎片。从长远来看，这种碎片会影响性能。你已经释放了该空间，并让操作系统用它来做它需要做的事情，所以你至少得到了你所要求的。如果您的数据库不断增长，这意味着数据库将再次增长。根据您的自动增长设置，这种增长可能会超过必要的程度，最终您将再次缩小。充其量这只是额外的工作（收缩增长/收缩增长），并且生成的文件碎片可以很好地处理。更糟糕的是，这会导致索引碎片、文件碎片，并可能在收缩期间导致性能问题。
And 亚伦·伯特兰的回答SHRINKFILE 最佳实践和经验在 dba.StackExchange.com 上 - 他基本上是在说，您可以自由地忽略来自聪明、经验丰富的人的好建议，并假设您的情况有所不同 - 但您需要自担风险。这是他的结案陈词：
将文件缩小到 4GB，然后强制其增长以容纳新数据，这将是一项成本更高的操作。这就像清洗一条已经干净的毛巾，你将用它来擦去脏东西。
综上所述- 你真的、真的应该关注专家所写的内容。需要澄清的是：我并不认为自己是该主题的专家。
我对开发人员方面的 T-SQL 有着牢固的掌握，但我对 DBA 方面的经验很少 - 我可以用一只手数出我必须编写诸如维护计划、数据库迁移或处理任何事务之类的内容的次数。 DBA 会做的系统管理工作。
然而，我提到的所有这些人都是领先的 DBA：Brent Ozar 是 MCM（微软认证大师），Mike Walsh 是 9 次 MVP（自 2011 年以来），Aaron Bertrand 是 22 次 MVP（自 1997 年以来） - 这些人们真的知道他们在写什么。
我会在一周中的任何一天和周日两次接受他们中任何一个人的免费建议。
更新 - 关于日志文件：
缩小日志文件则有些不同——定期这样做是不好的做法。
日志文件大小基本上取决于您的备份策略和所选的恢复模型。
推荐阅读：迈克·沃尔什的在 dba.stackexchange 上自我回答的帖子- 如果您愿意，我建议您阅读他的完整答案以及 Aaron Bertrand 对同一篇文章的完整答案。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
