我有越来越大的ms sql数据库。经检查，我发现某些表中有一堆未使用的空间。我并没有做很多物理删除，所以我不认为它只是删除的记录。 DBCC SHRINK不会使文件变小。但是，如果我将表转储到新的空数据库中，则大小将减少约80％。在当前数据库的该表中，我得到的不是原来的7GB，而是在新数据库中得到了约1.5GB。好像sql server正在分配太多内存。有人遇到过吗？我希望能够通过删除未使用的分配空间来缩小表，而不必创建一个全新的数据库。

添加信息：

使用完整恢复模型。我会尝试重建索引，我认为已经有一段时间了。 ldf每天都会使用一些古怪的存储过程将其缩减。

解决方案

回答

在选项中，我们可以指定增长幅度。默认情况下，我相信它是10％，所以给定一个200MB的数据库，当我们填充最后一页时，它将再分配20MB的页面空间。在7GB时，它将分配700MB。

我不知道在创建数据库后可以在哪里修改它，但是我知道在创建数据库时可以在其中修改它。一点点Google工作将最有可能为我们揭示答案。

注意：我的答案不是如何解决，而是也许如何防止/解释为什么我们可能会看到所有未分配的空间。

回答

我发现，如果我们不小心备份事务日志文件(LDF)，将会得到类似的行为。我不能过分强调拥有良好的备份"卫生"的重要性。如果出现问题，它不仅可以节省培根，而且我还维护一个良好的紧密数据库。

回答

I don't do many physical deletes

表的更新如何，碎片级别是多少？运行DBCC SHOWCONTIG，如果索引高度分散，则重建索引。之后，执行带有TRUNCATE_ONLY的BACKUP LOG，然后执行SHRINK命令

回答

过去这对我有用

USE [DBNAME]
GO

DBCC SHRINKFILE (N'FILENAME' , 0, TRUNCATEONLY)

GO

回答

我曾经有一个类似的问题，我相信我发现如果给定表上没有聚集索引，则重新索引/收缩不会回收所有未使用的空间。

回答

该表可能是在为索引打开填充的情况下构建的。人们建立填充索引的原因是为了防止页面拆分。

右键单击SQL Manager中的表，然后选择"脚本表"。然后查看是否" PAD_INDEX = OFF"。如果使用了" PAD_INDEX"，则可能是表占用空间的地方。