Question

门户网站中的Azure SQL数据库大小为164GB。有很多二进制大对象通过数据库，这些记录被删除但空间没有被回收。 DBCC SHRINKDATABASE没有帮助，它报告的页面数量多于sys.dm_db_partition_stats中used_page_count的总和。

DBCC SHRINKDATABASE results

DbId    FileId    CurrentSize    MinimumSize    UsedPages    EstimatedPages

5        1        19877520       2048           19877208     19877208

5        2        17024          128            17024        128

sys.dm_db_partition_stats结果中used_page_count的总和：8292675

这表示实际上未使用的11584533页或约90GB的差异，并且无法使用DBCC SHRINKDATABASE回收。数据库报告的大小和实际使用的页面大小之间的差异在过去几周内迅速增长，数据库很快将达到250GB的大小限制。我该怎么做才能解决这个问题？非常感谢任何帮助 - 谢谢。

更新：根据微软的支持，4月份部署到他们的SQL数据库服务器打破了自动化的鬼记录清理。几个星期前，有人能够为我们的服务器手动重新打开它，数据库大小稳定在174GB，但没有收回幽灵记录所消耗的其他空间。 Microsoft支持建议扩展到Premium层，以最大限度地减少以下I / O密集型过程的影响：

declare @db_id int = db_id()
exec ('dbcc forceghostcleanup ('+ @db_id + ', 'visit_all_pages'')')

我缩短到P15，假设周转时间更短，停机时间更短。运行命令结果：

Msg 40518, Level 16, State 1, Line 1
DBCC command 'forceghostcleanup' is not supported in this version of SQL Server.

无法运行命令，我尝试缩小到S3。规模操作运行了24小时，报告它已成功进入活动日志，但数据库仍为P15。下一个建议是分阶段缩减。我试图缩小到P6。规模操作运行了24小时，报告它已在活动日志中成功，但数据库仍然是P15。在这一点上，MS支持正在回到产品支持，我等着收听。我希望在某个地方有退款。

Answer 1

对某些索引进行碎片整理很可能会有所帮助。

您可以使用以下查询来获取已使用和保留页面之间差异最大的索引：

select 
    table_name = object_schema_name(i.[object_id]) + '.' + object_name(i.[object_id]), 
    index_name = i.[name], partition_number, reserved_page_count, used_page_count
from 
    sys.dm_db_partition_stats ps
    inner join sys.indexes i
    on ps.[object_id] = i.[object_id] and ps.index_id = i.index_id
order by reserved_page_count - used_page_count desc

逐个重建列表顶部的索引，直到。

请注意，如果整个数据库上的空间不足或索引特别大，则重建可能会失败或需要很长时间。在这种情况下，你应该回归重组。

有关索引碎片整理的更多信息： https://docs.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes

Answer 2

我添加的更新解释了此问题是幽灵记录问题，希望可以由Microsoft解决。

Azure SQL数据库大小越来越无法控制DBCC SHRINKDATABASE无法正常工作

2 个答案: