为什么Azure数据库表reserved_pa​​ge_count大小远高于实际数据大小？

Question

编辑：我想澄清一下我的问题及其动机。这不是我们唯一的表格。按目前的增长率，我们很快就会达到S3层数据库的250GB大小限制。如果数据库大小报告表中仍然可以看到哪些数据，我们不会担心长时间达到该限制。我想知道在将blob设置为null之后消耗所有空间的内容以及是否有办法减轻达到数据库大小限制的威胁。感谢。

我在Azure Sql中有一个表，它有一些小字段和一个varbinary（max）字段（ImageBlob），它几乎占每个记录中的所有字节。从一个客户端上传数据并将其存储在记录中后，其他客户端会在几分钟内下载该数据。 varbinary字段在第二个客户端下载后或在晚上由维护过程设置为空。

当我查看system stat reserved_pa​​ge_count时，它不成比例地大于记录中的实际数据大小。以下是我使用的查询及其结果的副本。

SELECT sys.objects.name [Name]
, format(SUM(row_count), 'N0') [RowCount]
, format(ROUND(SUM(reserved_page_count) * 8.0 / 1024, 0), 'N0') AS 'TableSizeMB'
, (select format(sum(datalength(ImageBlob) / 1024.0 / 1024.0), 'N0') from dbo.tblJobImages with(nolock)) as SumDatalengthImageBlobMB
, (select format( sum(BlobSize / 1024.0 / 1024.0), 'N0' ) from dbo.tblJobImages with(nolock)) as SumBlobSizeMB
FROM sys.dm_db_partition_stats with(nolock), sys.objects with(nolock)
WHERE sys.dm_db_partition_stats.object_id = sys.objects.object_id and sys.objects.name = 'tblJobImages'
GROUP BY sys.objects.name

产生这些结果：

  

名称--------------行数--- --- TableSizeMB --- SumDatalengthImageBlobMB SumBlobSizeMB

     

tblJobImages --- 77820 --------- 57320 ------------- 579 ------------------ ---------------------- 37670

这种差异对Azure报告的整体数据库大小产生了重大影响。为何如此区别？我有什么可以做的吗？

修改：修改查询以获取更多详细信息

SELECT sys.objects.name [Name]
, format(SUM(row_count), 'N0') [RowCount]
, format(ROUND(SUM(reserved_page_count) * 8.0 / 1024, 0), 'N0') AS 'reserved_page_count'
, format(ROUND(SUM(in_row_used_page_count) * 8.0 / 1024, 0), 'N0') AS 'in_row_used_page_count'
, format(ROUND(SUM(lob_used_page_count) * 8.0 / 1024, 0), 'N0') AS 'lob_used_page_count'
, format(ROUND(SUM(row_overflow_used_page_count) * 8.0 / 1024, 0), 'N0') AS 'row_overflow_used_page_count'
, (select format(sum(datalength(ImageBlob) / 1024.0 / 1024.0), 'N0') from dbo.tblJobImages with(nolock)) as SumDatalengthImageBlobMB
, (select format( sum(BlobSize / 1024.0 / 1024.0), 'N0' ) from dbo.tblJobImages with(nolock)) as SumBlobSizeMB
FROM sys.dm_db_partition_stats with(nolock), sys.objects with(nolock)
WHERE sys.dm_db_partition_stats.object_id = sys.objects.object_id and sys.objects.name = 'tblJobImages'
GROUP BY sys.objects.name

产生这些结果

Answer 1

根据此处的讨论Why is Azure database table reserved_page_count size much higher than actual data size?

used_pa​​ge_count是一个比reserved_pa​​ge_count更好的指标，但我对于used_pa​​ge_count的总和与Azure Portal报告的大小之间的差异仍然没有很好的答案。

Azure SQL支持DBCC SHRINKDATABASE并且每周运行看起来是我可用的最佳选择。

Answer 2

我最终在Azure SQL Database size growing out of control DBCC SHRINKDATABASE doesn't work

处更好地定义了问题

这是涉及幽灵记录的微软问题。