1

因此，我们正在使用的一些数据库出现了一个相当大的问题。出于某种原因，人们的数据库已经增长到一个荒谬的文件大小，而表的数据没有任何变化。虽然我不知道是什么突然导致了这种情况，但我现在更关心的是清除它使用的磁盘空间。我已经运行 sp_spaceused 并将罪魁祸首追踪到 2 个表中的 1 个（取决于数据库）。对于每个数据库，其中一个表为保留空间分配了超过半 GB 的空间，而数据只有 50 MB 左右。它显示 index_size 约为 113 MB。该表没有聚集索引，大约有 15 列，除了 2 列长度为 255 的 nvarchar 类型（这些列在表中通常为 null 或空）外，所有列的长度都相对较小。

我试过运行 DBCC 收缩数据库和截断表，但它没有做任何事情。我对此进行了一些研究，其他一些人也遇到了这个问题，但是如果 shrinkdatabase 没有修复它，那么也没有为他们找到解决方案。

让我知道你们是否需要了解有关表或数据库设置的任何其他信息。我不知道还能尝试什么，这对我们来说是一个重大问题，因为人们的数据库突然占用了之前 10 倍的空间。

编辑：在尝试运行 DBCC DBREINDEX 并尝试通过企业管理器更改为聚集索引后，我收到一条错误消息：

无法为数据库“DB”分配新页面。文件组 PRIMARY 中没有更多可用页面。可以通过删除对象、添加其他文件或允许文件增长来创建空间。

我也试过从这个表中删除行，它对表的大小没有影响。日志文件按预期增加，但这是表大小的唯一变化。

4

1 回答 1

2

这些是堆（没有聚集索引）？为什么？

如果用户做了很多更新或删除，我会尝试重建表。Shrinkdatabase 不是这样做的方法。它不会修复碎片、删除时未恢复的空间或更改列的宽度，或者作为转发指针浪费的行。我敢打赌，重建和/或聚集索引的表会更好。在 SQL Server 2000 中，您可以通过以下任一方式执行此操作：

(a) 添加聚集索引。（我无法为您提供添加聚集索引（或更改现有索引之一或要聚集的非聚集主键）的确切语法，因为我没有关于您的表的足够信息。）

(b) DBCC DBREINDEX('dbo.tablename');

这将在您的堆上重建非聚集索引，但这可能对您没有好处，具体取决于浪费空间的发生位置。我仍然建议您应该创建一个聚集索引。如果您可以分享有关您的表的一些详细信息（例如，存在的索引、通常运行的查询类型、您当前如何唯一标识行以及该表的数据更改/添加的性质），我们可能会提供更多信息详细的建议。

于 2012-06-19T18:23:56.667 回答