如何回收 Sql Server Azure 上的空间

Question

我有一个 Azure Sql Server 数据库（在云中，而不是在 VM 上）（不是托管实例），当前分配有 270 GB 的空间。

然而，实际使用的空间为 27%（81 个演出）。

我想回收该空间，就像在 Azure 上一样，他们按分配的空间量向您收费。大量未使用空间是由于删除 varbinary(Max) 列造成的。该列每行最多包含 40 兆数据。

我检查了文档，它说要运行：

DBCC SHRINKDATABASE ([JGWeiss_Prod_V2])

或者

DBCC CLEANTABLE ([JGWeiss_Prod_V2],'dbo.Attachments', 0)

我执行了第一个并让它运行了 12 小时，然后第二个又运行了 12 小时，但它导致了零空间被回收。我最终取消了它们，没有让它们运行完成。

我还尝试过“TruncateOnly”选项，但似乎没有效果。

难道我做错了什么？或者我只需要等待，比如让其中之一运行几天？

我理解不定期执行此类命令的概念，但我想减少 Azure 费用。

我读过的另一个选项是创建一个 bakpak 文件，然后恢复整个数据库，然后删除原始数据库。

建议表示赞赏。

更新 DBCC CLEANTABLE终于运行完成，但我分配的空间仍然显示相同。

DatabaseDataSpaceAllocatedInMB  DatabaseDataSpaceAllocatedUnusedInMB
270941.312500                   188090.187500

然后我跑了DBCC SHRINKDATABASE ([JGWeiss_Prod_V2])

几秒钟之内就完成了。

数据库ID	文件编号	目前的规模	最小尺寸	已用页面	预计页数
11	2	90624	1024	90624	1024

我也尝试过DBCC SHRINKDATABASE ([JGWeiss_Prod_V2], TRUNCATEONLY)

但是，分配的空间量仍然没有变化。

我还需要做些什么吗？

更新2

奇怪的是，即使没有运行 DBCC 命令，数据库的实际使用空间仍在不断缩小。下降至16.95%。减少需要花费很多时间，但似乎正在运行某些东西，继续减少实际使用的空间。但分配的空间保持不变。所以现在，我只想等待，直到已用空间不再减少。

更新 3 大约 4 天后，数据库的实际使用空间逐渐减少到 4 GB（从超过 250 个！）。在此期间，分配的空间保持在 270 个演出。但一旦到达收缩末尾，尾部就被截断为 5 GB 的分配空间。这让我大大降低了数据库的成本。所以，任务完成了。

Answer 1

现在已经DBCC CLEANTABLE运行完成，任何释放的大对象页面都应该被标记为未分配。但这不会减少数据库的大小，因为分配的页面可能位于物理文件中的任何位置。

现在你有了一块带孔的奶酪，需要将奶酪压在一起，使孔都在末端，此时可以使用节省空间的刀。

DBCC SHRINKDATABASE最终应该实现这一目标。使用该WAIT_AT_LOW_PRIORITY选项。

笔记：

DBCC SHRINKDATABASE 操作可以在过程中的任何点停止，并保留所有已完成的工作。

它确实不会很快，尤其是当您的 Azure 数据库的 I/O 或日志吞吐量不太惊人时。请参阅相关的问答，了解根本原因以及您可能需要考虑的事项：

• 在 SQL Server 中收缩 LOB 数据的最快方法
• DBCC SHRINKFILE 实际上在做什么？
• 为什么dbcc的shrinkdatabase和shrinkfile不起作用？
• 从其中包含分区和 LOB 数据的半满巨大 FG 中回收空间

从大对象数据中回收空间可能很棘手。请遵循上面链接中概述的分析步骤和方法，以获得最佳获胜机会。做好遭受挫折的准备。

奇怪的是，即使没有运行 DBCC 命令，数据库的实际使用空间仍在不断缩小。

该过程完成后，您可能仍然看不到 Azure SQL 数据库上的完整空间恢复，直到完全清理所有中止的事务（无法在该版本中禁用加速数据库恢复）并且持久版本存储 (PVS) 收缩。

该文档包含以下查询来查看状态：

SELECT
 db_name(pvss.database_id) AS DBName,
 pvss.persistent_version_store_size_kb / 1024. / 1024 AS persistent_version_store_size_gb,
 100 * pvss.persistent_version_store_size_kb / df.total_db_size_kb AS pvs_pct_of_database_size,
 df.total_db_size_kb/1024./1024 AS total_db_size_gb,
 pvss.online_index_version_store_size_kb / 1024. / 1024 AS online_index_version_store_size_gb,
 pvss.current_aborted_transaction_count,
 pvss.aborted_version_cleaner_start_time,
 pvss.aborted_version_cleaner_end_time,
 dt.database_transaction_begin_time AS oldest_transaction_begin_time,
 asdt.session_id AS active_transaction_session_id,
 asdt.elapsed_time_seconds AS active_transaction_elapsed_time_seconds,
 pvss.pvs_off_row_page_skipped_low_water_mark,
 pvss.pvs_off_row_page_skipped_min_useful_xts,
 pvss.pvs_off_row_page_skipped_oldest_aborted_xdesid -- SQL Server 2022 only
FROM sys.dm_tran_persistent_version_store_stats AS pvss
CROSS APPLY (SELECT SUM(size*8.) AS total_db_size_kb FROM sys.database_files WHERE [state] = 0 and [type] = 0 ) AS df 
LEFT JOIN sys.dm_tran_database_transactions AS dt
ON pvss.oldest_active_transaction_id = dt.transaction_id
   AND
   pvss.database_id = dt.database_id
LEFT JOIN sys.dm_tran_active_snapshot_database_transactions AS asdt
ON pvss.min_transaction_timestamp = asdt.transaction_sequence_num
   OR
   pvss.online_index_min_transaction_timestamp = asdt.transaction_sequence_num
WHERE pvss.database_id = DB_ID();

清理在后台线程上异步运行。您可以使用以下方法加快速度：

EXEC sys.sp_persistent_version_cleanup [database name];

该命令同步运行，并且在完成之前不会返回。

有关更多信息，请参阅故障排除文档页面。