数据库大小不明

我目前有一个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) 
* [email protected]<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。
当我通过图形用户界面收缩时，它会报告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。这是我可以解决的问题吗？或者我只需要处理它？常规脚本显示图像表大小为6MB。

更新5：

我想我只是将不得不经过进一步的研究来对付它。这些图像的大小已调整为大约2-5KB，而在普通文件系统上占用的空间不多，但在SqlServer上消耗的空间似乎更多。从长远来看，真正的答案可能会将该表分离到另一个分区或类似的东西。

来源

2008-12-11 Kenny Mann

尝试此查询：

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

来源

2008-12-11 14:33:22 edosoft

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

数据库使用基于页面的文件系统，所以由于删除繁重的行，您可能会遇到很多松弛（页面之间的空白空间）：如果dbms期望在该位置插入行，则可能会最好让这些景点开放。你使用基于unique_identifier的PK有聚集索引吗？

来源

2008-12-11 08:33:50

您可能还需要更新的SYSTABLES使用您运行查询，以确保它们是准确了。

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

来源

2008-12-11 08:48:21

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

希望这有助于。

来源

2008-12-11 08:58:27 adam

你如何做数据库真空？ – 2008-12-11 12:01:13

我认为这是一个特定的pgsql，但我可能是错的。 – Kev 2008-12-11 14:04:54

您是否在“收缩数据库”对话框中检查了统计信息？在SQL Server Management Studio（2005/2008）中，右键单击数据库，单击任务 - >收缩 - >数据库。这会告诉你有多少空间分配给数据库，以及多少分配的空间目前未被使用。

来源

2008-12-11 09:03:02

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

来源

2008-12-11 14:05:31

你有保证的空间没有被事务日志消耗？如果您处于完全恢复模式，则在执行事务日志备份之前，t日志不会收缩。

来源

2008-12-12 00:33:35

数据库大小不明

回答

相关问题