我有一个 Azure Sql Server 数据库(在云中,而不是在 VM 上)(不是托管实例),目前有 270 GB 的空间分配给它。
然而,实际使用的空间是 27%(81 GB)。
我想回收该空间,因为在 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 的分配空间。这让我大大降低了数据库的成本。所以,任务完成了。