使用收缩 SQL Server 的最佳做法是什么？

Question

我读了很多，不推荐使用收缩数据库的做法，因为它会导致碎片化，从而导致性能降低。

参考：

https://www.brentozar.com/archive/2017/12/whats-bad-shrinking-databases-dbcc-shrinkdatabase/

https://straightpathsql.com/archives/2009/01/dont-touch-that-shrink-button/

但是，数据文件似乎是这样，如果日志已满，缩小日志应该不是问题吧？

如果数据文件很大，占用大量空间，我确实需要更多空间来插入和更新一些新数据，缩小显然会减少驱动器上文件的大小，我认为我可以使用可用空间来插入新数据。 但如果不建议缩小，我该如何解决？ 什么时候使用收缩最好

Answer 1

如果数据文件很大，占用大量空间，我确实需要更多空间来插入和更新一些新数据，缩小显然会减少驱动器上文件的大小，我认为我可以使用可用空间来插入新数据。

如果您的数据文件占用大量空间，并不意味着该空间是空的。

您应该使用sp_spaceused来确定数据文件中是否有未使用的空间。

如果有未使用的空间，将已被使用“插入和更新了一些新的数据”，如果有没有做shrink将改变什么： shrink不会删除你的数据，它的作用是在开始移动数据文件在最后腾出空间以便将其还给OS 。

当您有一个 2Tb 的数据文件并且删除了 1Tb 的数据并且您不打算在未来 10 年内插入另一个 Tb 的数据时，缩小数据文件会很有用。

你可以把你的data file想象成一个 1m x 1m x 1m 的盒子。 如果您只有一半的玩具箱，即使您不使用shrink您也可以将其他玩具放入此箱中（ insert / update ）。 shrink作用是将所有玩具聚集在一个角落，然后切割您的盒子，使其成为 50 厘米 x 50 厘米 x 50 厘米。 这样，您的房间 (OS) 现在拥有更多可用空间，因为您的玩具盒只占用了缩小前的一半空间。

...如果您的盒子已经满了，即使您尝试shrink ，也无法添加更多玩具。

如果日志已满，缩小日志应该不是问题吧？

Shrinkig log是另一个过程， log file内不能移动任何东西，从这个意义上说， shrink当然不会像data file那样造成太大的伤害：它不需要服务器资源，不会造成任何碎片等。但是如果它成功与否取决于您的“日志已满”的原因。

如果您的日志由于full model而full model ，缩小日志文件不会改变任何内容：保留日志是为了让您有可能拥有log backup chain （或使mirroring 、或log shipping等成为可能）。

相反，如果您的数据库recovery model很simple ，并且长时间打开的transaction出现了一些问题，或者有大量data loading （可能有完整的日志记录，例如insert into without tablock ）并且您的log file变成比data file ，并且您发现并解决了问题，并且您不需要这么大的log file ，是的，您可以将其缩小到合理的大小，而且没有害处。