SQL Server 2008 Standard中的“主文件组已满”无任何理由

我们的数据库目前在64 GB，我们的一个应用程序开始失败，出现以下错误：

System.Data.SqlClient.SqlException ：由于'PRIMARY'文件组已满，无法为数据库'travelgateway'对象'cnv.LoggedUnpreparedSpos'.'PK_LoggedUnpreparedSpos'分配空间。 通过删除不需要的文件，删除文件组中的对象，向文件组中添加其他文件或为文件组中的现有文件设置自动增长来创build磁盘空间。

我仔细检查了一切：允许单个文件组中的所有文件以合理增量进行自动增长（数据文件为100 Mb，日志文件为10％），数据库可用空间超过100 Gb， tempdb被设置为自动增长以及其驱动器上有大量的可用硬盘空间。

为了解决问题，我添加了第二个文件到文件组，错误消失了。 但是我对整个情况感到不安。

哪儿有问题，伙计？

Answer 1

好的，让它工作。 原来，数据库文件所在的NTFS卷被严重分散。 停止了SQL Server，整个过程都进行了整理，所有这一切都很好。

Answer 2

安东，

作为最佳实践，不应在主文件组中创build用户对象。 当你有带宽的时候，创build一个新的文件组并移动用户对象，并把系统对象保留为主。

以下查询将帮助您识别每个文件中使用的空间以及具有最多行数的顶层表，以及是否有堆。 调查这个问题是一个很好的起点。

 SELECT ds.name as filegroupname , df.name AS 'FileName' , physical_name AS 'PhysicalName' , size/128 AS 'TotalSizeinMB' , size/128.0 - CAST(FILEPROPERTY(df.name, 'SpaceUsed') AS int)/128.0 AS 'AvailableSpaceInMB' , CAST(FILEPROPERTY(df.name, 'SpaceUsed') AS int)/128.0 AS 'ActualSpaceUsedInMB' , (CAST(FILEPROPERTY(df.name, 'SpaceUsed') AS int)/128.0)/(size/128)*100. as '%SpaceUsed' FROM sys.database_files df LEFT OUTER JOIN sys.data_spaces ds ON df.data_space_id = ds.data_space_id; EXEC xp_fixeddrives select t.name as TableName, i.name as IndexName, p.rows as Rows from sys.filegroups fg (nolock) join sys.database_files df (nolock) on fg.data_space_id = df.data_space_id join sys.indexes i (nolock) on df.data_space_id = i.data_space_id join sys.tables t (nolock) on i.object_id = t.object_id join sys.partitions p (nolock) on t.object_id = p.object_id and i.index_id = p.index_id where fg.name = 'PRIMARY' and t.type = 'U' order by rows desc select t.name as TableName, i.name as IndexName, p.rows as Rows from sys.filegroups fg (nolock) join sys.database_files df (nolock) on fg.data_space_id = df.data_space_id join sys.indexes i (nolock) on df.data_space_id = i.data_space_id join sys.tables t (nolock) on i.object_id = t.object_id join sys.partitions p (nolock) on t.object_id = p.object_id and i.index_id = p.index_id where fg.name = 'PRIMARY' and t.type = 'U' and i.index_id = 0 order by rows desc 

Answer 3

碰到同样的问题，起初碎片整理似乎工作。 但这只是短暂的。 发现客户使用的服务器，运行的是Express version ，并且具有大约10gb的许可限制。

所以即使尺寸设置为“无限”，也不是。

Answer 4

我也遇到了同样的问题，初始的dtabase大小设置为4Gb，自动增长设置为1Mb。 数据库所在的虚拟encryptionTrueCrypt驱动器似乎有足够的空间。

我改变了一些（上述）的东西：

• 我将Sql Server Express的Windows服务从自动转为手动 ，所以只有“常规”的Sql Server正在运行。 （即使我正在运行Sql Server 2008 R2，它应该允许10 GB）
• 我将自动增长从1 MB改为10％
• 我将自动增长增量大小从10％更改为1000 MB
• 我整理了驱动器的碎片
• 我缩小了数据库：
  • 手动DBCC SHRINKDATABASE('...')
  • 自动右键点击数据库| “属性”| “自动收缩”| “截断login检查点”）

所有的一点点（我可以插入更多的logging，但很快就遇到了同样的问题）。 Tobbi提到的页面文件让我尝试了一个更大的虚拟驱动器。 （即使我的驱动器不应该包含任何这样的系统文件，因为我运行没有被安装很多时间。）

• 我用TrueCrypt做了一个新的更大的虚拟驱动器

当做这个时，我遇到了一个TrueCrypt问题，如果我要存储大于4GB的文件（ 如这个超级用户的问题所示 ）。

• 我告诉TrueCrypt我会存储大于4 GB的文件

在最后两个人之后，我做得很好，而且我认为这最后一个做了诀窍。 我认为TrueCryptselect了一个exfat文件系统（ 如下所述 ），它将所有文件限制为4GB。 （所以我可能不需要放大驱动器，但是我仍然无论如何。）

这可能是一个非常罕见的边界案例，但也许对某个人有帮助。

Answer 5

做一件事，去数据库select文件的属性，并增加数据库的初始大小，并设置主文件组为自动增量。 重新启动sql服务器。

您将能够像以前一样使用数据库。

Answer 6

我遇到了同样的问题。 原因是虚拟内存文件“pagefile.sys”与我们的数据库（D：驱动器）的数据文件位于相同的驱动器上。 它的大小已经翻了一番，装满了磁盘，但是窗户并没有拿起来，也就是说，我们实际上没有80GB的空间。

重新启动SQL服务器没有帮助，也许碎片整理会给操作系统时间来释放页面文件，但我们只是重新启动服务器，瞧，页面文件已经收缩，一切工作正常。

有趣的是，在30分钟内我们正在调查，窗口没有计算pagefile.sys的大小（80GB）。 重新启动窗口后，确实find了页面文件，并将其包含在磁盘总使用量（现在是40GB – 这仍然太大）。

Answer 7

请加快数据库文件的增长types，如果限制使其不受限制的话

Answer 8

我发现这是因为： http : //support.microsoft.com/kb/913399

当满足以下条件时，SQL Server仅释放堆表使用的所有页面：在此表上发生删除。 一个表级锁正在举行。 注意堆表是不与聚集索引关联的任何表。

如果页面未被释放，数据库中的其他对象将无法重新使用页面。

但是，在SQL Server 2005数据库中启用基于版本控制的行隔离级别时，即使正在保持表级锁，也不能释放页面。

微软的解决scheme： http : //support.microsoft.com/kb/913399

要解决此问题，请使用下列方法之一：如果未启用基于行版本控制的隔离级别，请在DELETE语句中包含TABLOCK提示。 例如，使用类似于以下的语句：

DELETE FROM TableName WITH（TABLOCK）

注意代表表格的名称。 如果要删除表中的所有logging，请使用TRUNCATE TABLE语句。 例如，使用类似于以下的语句：

TRUNCATE TABLE TableName

在表的列上创build一个聚集索引。 有关如何在表上创build聚簇索引的详细信息，请参阅SQL中的“创build聚簇索引”主题

你会注意到在链接的底部，没有注意到它适用于SQL Server 2008，但我认为它确实如此

Answer 9

我们的问题是，硬盘驱动器可用空间为零。