缩小 sql 数据库 - 坏主意？

Question

我有一个数据库，由于一些愚蠢的代码问题，它已经大大增长。它现在是 24GB，其中大部分是非常不必要的日志信息（系统生成的调试信息）。

我的服务器位于云托管服务器上。由于文件大小，我现在有两个问题：

1. 我支付存储费用。我很高兴为我的核心业务付费，但为愚蠢的数据付费似乎......

2. 我的备份现在也很大。我每晚进行完整备份，然后将它们发送到 FTP 服务器。这个过程需要的时间越来越长。

鉴于我的问题，萎缩有那么糟糕吗？我将重建我所​​有的索引。我做了一次试运行，并将我的数据库降低到 6GB。

这家伙（谁我一直信任我的SQL大师）表示，它的坏.... mkay “SQL SERVER -收缩数据库是坏的-提高了碎裂-降低性能”

Answer 1

鉴于我的问题，萎缩有那么糟糕吗？我将重建我所​​有的索引。我做了一次试运行，并将我的数据库降低到 6GB

互联网上给出的大部分建议都是复制和传播的，而没有仔细阅读整个主题。毫无疑问，缩小数据文件是不好的，但如果你问任何 SQL 大师，他总是会说，“是的，我已经缩小了数据文件”。他还会告诉你“强迫”他这样做的场景。就像如果您有一个庞大的数据库并且正在归档旧记录。因此，您将数据移出并从数据库中删除了旧数据。现在有很多可用空间，您立即需要它；在这种情况下，您别无选择，只能缩小。

在您的情况下，您最终会为由于愚蠢的代码问题而增长的文件支付大量费用。在你的情况下，你可以缩小它。您知道缩小会导致碎片化并且您需要重建碎片化索引也很好。

整个座右铭是不要让缩小成为一种习惯，它应该始终是您回收空间的最后手段

我建议你阅读Paul Randal关于为什么收缩不好的文章。他在他的文章中指出了收缩的另一种方式，如果您以后遇到类似的问题，可以遵循这一点。

Answer 2

看起来您已经意识到与收缩相关的风险，所以我不会再讨论这些。

由于错误或某种形式的大规模增长而一次性关闭，这种情况只会发生一次，然后进行一次收缩就可以了。

做收缩，重建/重组索引，应该就是这样。

你的数据库是在SIMPLE还是正在FULL恢复？如果已满，请确保您经常进行事务日志备份以减小日志文件的大小。