磁盘空间已满但数据库中有可用的逻辑空间

Question

我们有一个相当大的 MS SQL 2008R2 数据库，它驻留在 SSD 驱动器上。驱动器本身只有大约 110Gb 的空间，并且数据库文件是驱动器上唯一的文件。

数据库处于“简单”恢复模式，只有两个文件，.MDF 和.LDF。

磁盘现在几乎已满：MDF 目前的大小为 109Gb。但是，SSMS 告诉我有将近 18Gb 的“可用空间”（在“常规”属性页面中），如果我完成Shrink文件的操作，它还会告诉我有 18Gb 的可用空间。SSMS 还告诉我数据库大小约为 132Gb，这让我感到惊讶 - 这不适合驱动器！

从我所读到的，这shrink是一个非常糟糕的主意。但是，我开始看到复制错误 ( could not allocate space for object)。我们之前曾尝试缩小数据库，但在几个小时内，文件又恢复到原来的大小。

我们应该如何进行 - 鉴于显然有 18Gb 的可用空间，SQL 是否应该自动使用该可用空间？或者就这么简单：我们真的需要更多的磁盘空间？

Answer 1

数据库内部有可用空间，因为数据已被移动。也许您有很高级别的页面拆分，或者最近删除了以前导致数据文件增长的大部分数据。

当您释放数据库文件中的空间时，SQL Server 不会自动收缩它们，因为逻辑假设是，如果您使用过一次该空间，您将再次使用它。如果您只是暂时释放了空间（在此期间您可以用所有这些可用空间做什么？），自动增长可能是一项昂贵且不必要的事件。出于同样的原因，您也不应该尝试临时回收空间。当您添加更多数据时，只需让 SQL Server 使用 18 GB 的可用空间即可。如果您认为以后需要 18 GB 以上的额外空间（在这种情况下，您需要在其他磁盘上添加文件，或移至更大的磁盘）。

sp_spaceused（反过来，您正在查看的 UI 对话框）可能会返回比可能更多的空间，因为有关您的表/索引/文件的元数据中存在同步问题。为了确保它反映准确的空间，请运行：

DBCC UPDATEUSAGE(0);

我还见过需要重建索引以纠正计数/空间的情况，但自 SQL Server 2000 以来我还没有见过这种特定情况。

（我怀疑这不是您的数据库已经跨越多个磁盘的简单情况，或者您肯定会在问题中提到这一点。）

话虽如此，当您缩小数据文件时，几乎立即扩展这一事实让我相信您实际上正在使用该空间，但还必须执行大量删除或更新以释放它（当您看到 18 GB 时）自由）。不幸的是，我们无法确切了解为什么数据文件正在扩展然后自行清除 - 也许您有正在截断/重新填充大表、执行大量存档操作等的事务。