代码之家 › 专栏 › 技术社区 › Kenny Mann

未计算数据库大小

database sql-server

Kenny Mann · 技术社区 · 16 年前

我目前有一个20GB的数据库。我运行了一些脚本,这些脚本显示在每个表的大小上(以及其他非常有用的信息,如索引资料),最大的表是110万条记录,它占用了150MB的数据。我们只有不到50个表,其中大多数表占用的数据不足1MB。

在查看了每个表的大小之后,我不明白为什么在收缩之后数据库的大小不应该是1GB。SQLServer(2005)报告的可用空间量为0%。日志模式设置为简单。在这一点上,我主要关心的是我觉得我有19GB的未使用空间。还有什么我该看的吗?

通常情况下,我不会在意,也不会把它变成一个被动的研究项目,除非这种特殊的情况要求我们每周备份和恢复一次,以便在卫星上(卫星上没有互联网,所以必须手动进行)。我宁愿拷贝1GB(或者即使是5GB!)每周超过20GB的数据。

sp\u 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。

我还重新索引了所有内容。
我运行了dbcc shrink命令,并更新了前后的用法。一次又一次。我发现一件有趣的事情是,当我重新启动服务器并确认 没有人 在使用它的时候(没有运行任何维护过程,这是一个非常新的应用程序——只有不到一周的时间),当我开始运行收缩时,它时不时会说一些关于数据更改的信息。googling给出的有用答案太少,显然没有应用(当时是凌晨1点,我断开了所有人的连接,所以看起来不可能真的是这样)。数据是通过C代码迁移的,C代码基本上看了另一台服务器并带来了一些东西。此时删除的数量可能在50K以下。即使这些排是最大的一排,也不会超过100米。
当我通过GUI进行收缩时,它报告0%的可用收缩率,这表明我已经得到了它认为可以收缩的最小值。

更新2:

sp_spaceused“activity”产生了这个结果(这似乎在金钱上是正确的):

活动1143639 134488 KB 91072 KB 41768 KB 1648 KB
填充因子为90。
所有主键都是整数。
以下是我用于“updateusage”的命令:

DBCC更新用法(0);

更新3:

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

更新4:

和一个同事交谈,我发现这是因为这些页面,因为这里的其他人也陈述了这种可能性。image表上唯一的索引是聚集的pk。这是我能解决的问题还是我必须解决的问题? 常规脚本显示图像表的大小为6MB。

更新5:

我想我要做进一步的研究才能解决这个问题。图像的大小已经被调整为每个大约2-5Kb,在一个普通的文件系统中,它不消耗太多的空间,但是在SQLServer上,它似乎消耗了相当多的空间。从长远来看,真正的答案可能是将该表分离到另一个分区或类似的分区中。

7 回复 | 直到 14 年前

edosoft 14 年前

尝试这个查询:

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

Bernhard Hofmann 16 年前

在运行查询之前,您可能还需要更新systables中的用法,以确保它们是准确的。

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

Mladen Prajdic 16 年前

你在重新索引中使用的填充因子是什么?一定要很高。从90%到100%,取决于pk数据类型。如果你的填充因子很低,那么你会有很多半空的页面,不能缩小。

Frans Bouma 16 年前

是否尝试了DBCC命令来收缩目录?如果您将所有数据传输到一个空目录,它也是20GB吗?

数据库使用基于页面的文件系统,因此可能会由于大量的行删除而出现大量的松弛(页面之间的空白):如果DBMS希望在该位置插入行,则最好保持这些点处于打开状态。是否使用具有聚集索引的基于唯一标识符的pk?

adam 16 年前

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

希望这有帮助。

Dylan Beattie 16 年前

您检查过“收缩数据库”对话框下的统计信息吗?在SQL Server Management Studio(2005/2008)中,右键单击数据库,然后单击任务->收缩->数据库。这将显示分配给数据库的空间量,以及当前未使用的分配空间量。

Sean Reilly 16 年前

您是否确保您的事务日志不会占用空间?如果您处于完全恢复模式,则在执行事务日志备份之前,T-Log不会收缩。