TL;DR: Server数据库中的wpr_bucket_table对象是什么,我们如何减少它占用的空间?
我们有一个Azure SQL数据库,它占用了比预期更多的存储空间。我们通过为SQLServer2019数据库创建一个RDS来对其进行基准测试,并使用SSMS中的导入和导出向导将Azure数据库的内容复制到RDS数据库中。
RDS数据库占用15 in,这与我们在测试数据量很小的情况下所期望的一致,而Azure数据库则占用了280 in(几乎20 X!)。
为了找出造成这种差异的原因(S),我们运行了以下SQL命令,这是我们在Azure故障排除文章中发现的:
-- Calculates the size of individual database objects.
SELECT sys.objects.name, SUM(reserved_page_count) * 8.0 / 1024 AS megabytes
FROM sys.dm_db_partition_stats, sys.objects
WHERE sys.dm_db_partition_stats.object_id = sys.objects.object_id
GROUP BY sys.objects.name
ORDER BY megabytes DESC;
GOname megabytes
---- ---------
wpr_bucket_table 243.257812
backup_metadata_store 3.390625
[etc.]RDS中的相同查询显示wpr_bucket_table为0.00000。
我们找不到很多关于wpr_bucket_table的在线文档,只是它可能与所谓的“写页面记录器”相关(但也没有相关的文档)。
wpr_bucket_table对象和“写页面记录器”?wpr_bucket_table的大小吗?我们部署这些测试数据库是为了研究为什么我们的生产数据集从分隔文件中的~5GB变为Azure SQL中的~150 5GB。事实证明,生产中的问题是不同的,但最好能得到这个问题的答案,以及我们是否能摆脱它。
我没有找到关于它的好文档,但是有相当多的谷歌结果指出这是Server的事情。它也存在于RDS SQL Server中,只是没有占用任何空间。
还有一个Microsoft文章会触及它(但不解释它是什么):
当您在Linux上的Microsoft SQL Server中使用“始终对可用性”组时,属于可用性组的数据库可能会被标记为“可疑”。此外,类似于以下内容的错误消息记录在Server错误日志中: Error: 883,严重性: 16,State: 1。无法创建写入页面记录表:数据库WritePageRecorder2 2::CreateWPRBucketTable。
发布于 2023-03-24 13:06:37
您已经发现wpr_bucket_table没有文档化,这意味着它很可能是通过连接数据库而不是Server本身创建的。
如果这是一个测试数据库,只需删除该表并查看哪些中断。以后总是可以还原它,因为这是Azure SQL数据库。
https://dba.stackexchange.com/questions/325094
复制相似问题