Server数据库不收缩

Question

我有一个SQL数据库，它有很多未使用的空间。但是，当我运行来自Management的“任务”、“收缩”、“数据库”和“任务”的“收缩”文件时，它不会释放任何空间。

不幸的是，它正在运行的机器正在耗尽硬盘空间。关于为什么这个空间不被解放的想法。

另外，DB上的恢复模式被设置为simple。

下面是当我收缩文件时出现的未使用的对话框：

我也尝试过通过this来完成这个任务。

(myDatabase，5)

我得到以下答复：

database :数据库ID 6的文件ID 1被跳过，因为该文件没有足够的空闲空间来回收。database :数据库ID 6的文件ID 2被跳过，因为该文件没有足够的空闲空间来回收。DBCC执行完成。如果DBCC打印错误消息，请与系统管理员联系。

Answer 1

这可能有很多原因。我将提到所有可能的原因，然后确定解决这一问题的办法。

1. 正如您的DBCC输出所提到的，您没有足够的磁盘空间来缩小数据库文件。换句话说。尝试将页面从数据库文件移动到新创建的文件。在此期间，页面存在两次。之后，Server将删除旧的数据库文件，并将新创建的文件用于生产。您可能必须增加您的磁盘空间或遵循下面提到的解决方案。
2. 防止收缩的另一点可能是数据库锁(这不是您的情况)。如果数据库在DDL更改期间被锁定，它将无法收缩数据库文件。如果使用向导收缩文件，则可能不时会遇到超时消息。如果您以脚本的形式运行它，它通常会一直等到锁被释放，然后收缩文件。

可能的解决方案

最简单的解决办法是计划！检查您的数据库并尝试评估每天插入多少数据，确定增长速度。默认情况下，Server将使文件增长10%。这对于只容纳100 be的数据库来说并不坏，因为增长仅为10 be。但是，如果您的数据库变得更大更大，增长将花费许多资源和时间(100 GB -> 10 GB，1TB -> 100 GB等等)。定义以MB为单位的增长因子。它不应该太小(例如1MB)，因为它会在大事务上强调您的磁盘，并会减慢您的操作速度，但不会太大而导致巨大的写操作(例如，10 as )。

此外，对可能升级的数据库(例如日志数据库)定义增长限制。如果达到限制，事务可能会失败，但它不会对日志数据库造成太大影响。但是，如果日志数据库耗尽了所有可用的磁盘空间，则可能会导致生产数据库上的事务中止/回滚。

如果您有这样的问题，即您的磁盘空间太小，无法再次容纳已使用的磁盘空间(例如:140 to文件，40 to空闲，意味着100 to用于重组-> --在移动操作收缩时，您需要最少额外的100 to空闲空间)，您仍然可以使用TRUNCATEONLY标志获得一些空间。

DBCC SHRINKFILE (1,TRUNCATEONLY)

这将用file_id = 1切断数据库文件末尾保留的所有空数据页。回到我们的140 to示例:如果您的140 to数据库文件以120 to的位置保存最后一个写入页面，则将几乎立即返回20 to。这个过程非常快，因为它只是将文件结束标记移动到120 it的位置，并将通知您的操作系统有关空闲空间的信息。

您可以使用以下查询快速了解数据库文件：

SELECT *
FROM sys.sysfiles

如果您有足够的空闲磁盘空间(或者在您对每个文件运行TRUNCATEONLY之后)，您应该能够真正清理数据库文件，并真正缩小它们。

这可以通过使用以下声明来实现：

DBCC SHRINKFILE (1);

如果您有一个经常编写或运行的数据库表(通常是更大的事务)，我建议定义一个目标限制。这取决于您使用此数据库的经验。通常是5-10% (取决于数据库的大小)，但至少应该设置100-1000MB。例如，在我们的140 to数据库文件(40 to为空)上，目标大小应该设置为110 to(100 to使用+ 10%保留)。

您可以通过使用以下语句来实现这一点：

DBCC SHRINKFILE (1,112640); -- 110GB in MB

但请注意，这可能会运行很长时间(取决于您的文件大小和I/O子系统)。由于您将在I/O子系统上创建更大的工作负载，我建议在低负载时间(可能是一夜之间)运行这样的脚本。

如果您真的想清理数据库文件，最好检查所有索引以及具有高度分段性的REBUILD或REORGANIZE所有索引。

如果您在开发机器上，或者真的愿意冒险，那么您可以运行以下语句。它将遍历数据库中的每个索引并重新构建它。

DECLARE @sql nvarchar(max), @sch nvarchar(max), @obj nvarchar(max), @ind nvarchar(max)

DECLARE cur CURSOR FOR
    SELECT s.name, o.name, i.name
    FROM sys.objects as o
    INNER JOIN sys.schemas as s
            ON o.schema_id = s.schema_id
    INNER JOIN sys.indexes as i
            ON o.object_id = i.object_id
    WHERE i.type > 0 

OPEN cur

FETCH NEXT FROM cur INTO @sch, @obj, @ind

WHILE @@FETCH_STATUS = 0 BEGIN

    SET @sql =  N'ALTER INDEX ['+@ind+'] ON ['+@sch+'].['+@obj+'] ' 
                + N'REBUILD PARTITION = ALL '
                + N'WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, '
                + N'ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)'
    PRINT(@sql) EXEC (@sql)

    FETCH NEXT FROM cur INTO @sch, @obj, @ind
END

CLOSE cur
DEALLOCATE cur

在这个过程之后，您的数据库文件可能会再次增长。但是您可以将其缩小到更低的文件大小，因为每个索引中的空闲空间都会被删除。

警告和附加信息

在缩小数据库文件时要小心。Server提前分配文件空间是有充分理由的。磁盘分配是昂贵的，尽量少做是一个好主意。如果您有一个非常敏捷的数据库，每天产生几GB的开销，并在一段时间后发布它，那么总是将文件缩小到最小是不好的。您浪费光盘电源来增长文件，做您的材料，并再次浪费磁盘电源，以再次缩小文件。在这种情况下，要注意浪费一些磁盘空间来改进您的数据操作。

希望这篇长篇总结能帮助您解决问题，甚至帮助您为数据库制定计划。

Answer 2

我要做一个粗略的猜测，说你的数据库是为使用完全恢复而设置的。您从未根据上面的图像进行日志备份(更不用说完整的日志了)。如果是这样的话，那么日志文件就会不断增长，并且由于没有备份而无法清除。

如果您让房间采取完全备份，然后日志备份，并再次尝试您的心理医生。应该能正常工作。

最坏的情况(我指的是最坏的情况，特别是如果这是生产数据库)是将数据库设置为简单的恢复、收缩，然后进行备份。这应该是有效的，即使你没有足够的空间作为一个正常的心理医生。

此时，请确保为数据库设置定期备份。

您可以去这里了解更多细节。

编辑：

您能告诉我们日志相对于数据文件释放的%是多少吗？此外，您还可以查看log_reuse_wait_desc in sys.databases。

SELECT name, log_reuse_wait_desc FROM sys.databases 

最后，但当然不是最不重要的是，你曾经尝试过TRUNCATEONLY的收缩选项吗？

DBCC SHRINKFILE (Adventureworks2008R2_Log, TRUNCATEONLY)

Answer 3

还必须收缩文件才能检索磁盘空间:中的任务/收缩/文件

您需要检查选项“在释放未使用的空间之前重新组织文件”，并根据数据库的预期增长来设置一个百分比的空闲空间。