Question

我目前有一个20GB大小的数据库。我运行了一些脚本，显示每个表的大小（和其他非常有用的信息，如索引的东西），最大的表是110万条记录，占用150MB的数据。我们只有不到50个表，其中大多数表占用的数据不到1MB。

在查看每个表的大小后，我不明白为什么数据库在缩小后不应该是1GB大小。 SqlServer（2005）报告的可用空间量为0％。日志模式设置为简单。此时我主要担心的是我觉得我有19GB的未用过的空间。还有什么我应该看的吗？

通常情况下我不会关心并且会把这个作为一个被动的研究项目，除非这种特殊情况要求我们每周进行备份和恢复以将副本放在卫星上（没有互联网，所以它必须手动完成）。我宁愿每周复制1GB（或者甚至低至5GB！）而不是20GB的数据。

sp_spaceused报告以下内容：

Navigator-Production    19184.56 MB 3.02 MB

第二部分：

19640872 KB 19512112 KB 108184 KB   20576 KB

虽然我发现了一些其他脚本（例如这里的两个服务器数据库大小问题中的一个，但它们都报告了上面或下面找到的相同信息）。我使用的脚本来自SqlTeam。这是标题信息：

*  BigTables.sql
*  Bill Graziano (SQLTeam.com)
*  graz@<email removed>
*  v1.11

前几张表显示了这一点（表，行，保留空间，数据，索引，未使用等）：

Activity    1143639     131 MB  89 MB   41768 KB    1648 KB 46% 1%
EventAttendance 883261      90 MB   58 MB   32264 KB    328 KB  54% 0%
Person  113437      31 MB   15 MB   15752 KB    912 KB  103%    3%
HouseholdMember 113443      12 MB   6 MB    5224 KB 432 KB  82% 4%
PostalAddress   48870       8 MB    6 MB    2200 KB 280 KB  36% 3%

其余表格大小相同或更小。不超过50张桌子。

更新1： - 所有表都使用唯一标识符。通常一个int每行增加1。

我也重新编制了索引。
我运行了dbcc shrink命令以及更新之前和之后的用法。一遍又一遍。我发现一个有趣的事情是当我重新启动服务器并确认没有人正在使用它时（并且没有维护过程正在运行，这是一个非常新的应用程序 - 在一周之内）并且当我去运行收缩，时不时会说有关数据的变化。谷歌搜索产生了很少的有用答案，明显没有应用（这是凌晨1点，我断开了所有人，因此似乎不可能真的如此）。数据是通过C＃代码迁移的，它基本上是在查看另一台服务器并将其结束。此时删除的数量可能在行中不到50k。即使这些行是最大的行，也不会超过我想象的100M。
当我通过GUI进行缩小时，它报告0％可缩小，表明我已经把它缩小到它想象的那么小。

更新2：

sp_spaceused'活动'产生这个（这似乎是钱）：

活动1143639 134488 KB 91072 KB 41768 KB 1648 KB
填充系数为90。
所有主键都是整数。
以下是我用来'updateusage'的命令：

DBCC UPDATEUSAGE（0）;

更新3：

根据Edosoft的要求：图111975 2407773 19262184 似乎图像表认为它是19GB部分。我不明白这意味着什么。是真的 19GB还是被误传？

更新4：

与同事交谈，我发现这是因为页面，因为这里的其他人也说明了这一点。映像表上唯一的索引是聚簇PK。这是我能解决的问题还是我必须处理它？常规脚本显示Image表的大小为6MB。

更新5：

我想在进一步研究之后我将不得不处理它。图像大小已经调整为大约2-5KB，并且在普通文件系统上不占用太多空间，但在SqlServer上它似乎消耗了更多。从长远来看，真正的答案可能是将该表分成另一个分区或类似的东西。

Answer 1

您可能还希望在运行查询之前更新systables中的用法，以确保它们准确无误。

DECLARE @DbName NVARCHAR(128)
SET @DbName = DB_NAME(DB_ID())
DBCC UPDATEUSAGE(@DbName)

Answer 2

您在重建索引中使用的填充因子是多少？它必须很高。从90-100％，具体取决于PK数据类型。如果您的填充因子很低，那么您将有很多半空页面无法缩小。

Answer 3

尝试此查询：

SELECT object_name(object_id)  AS name, rows,  total_pages, 
  total_pages * 8192 / 1024 as [Size(Kb)]
FROM sys.partitions p
INNER JOIN sys.allocation_units a
  ON p.partition_id = a.container_id

Answer 4

您是否尝试使用dbcc命令缩小目录？如果您将所有数据传输到空目录，它是否也是20GB？

数据库使用基于页面的文件系统，因此您可能会因为大量删除行而遇到很多松弛（页面之间的空白区域）：如果dbms期望在该位置插入行，则可能是最好留下斑点。您是否使用具有聚簇索引的基于unique_identifier的PK？

Answer 5

你可以尝试做一个数据库真空，如果你以前从未做过这样做，这通常会带来很大的空间改进。

希望这会有所帮助。

Answer 6

您是否检查过“收缩数据库”对话框下的统计数据？在SQL Server Management Studio（2005/2008）中，右键单击数据库，单击“任务” - >。收缩 - ＆gt;数据库。这将向您显示为DB分配了多少空间，以及当前未使用的分配空间量。

Answer 7

您是否确保事务日志没有占用空间？如果您处于完全恢复模式，则在执行事务日志备份之前，t-log将不会收缩。

未计入数据库大小

7 个答案: