释放 azure sql 数据库中的内存

Free up memory in azure sql database

我在 Azure 中有一个数据库,目前有 750GB 的数据。 为了降低 运行 数据库的成本,我希望它尽可能小,尤其是在 1TB 以下。

table暂且称它为“BigTable”吧,它占据了95%的存储内存,份额最大。每天都会有更多的数据存储在这个数据库中,并且这样持续了四年。超过两年的数据将不再需要。这就是我已经做过的事情:

  1. 我使用时间点还原设置了第二个数据库“test_database”,使用“导出”功能对我的数据库进行了备份并将其保存在 blob 存储中。效果不错。

  2. 我用工具 SQL Server Management Studio (SSMS) 删除了不需要的数据 运行 声明:

Delete
From BigTable
Where Year(Date) < 2020

该工具表示删除了 3.07 亿个数据集,但数据库变大了,大约 870GB。我会说这是因为删除会在日志文件中获得一个条目,所以它会变大。

  1. 之后我在 SSMS 中执行了这条语句:
DBCC SHRINKDATABASE (0)

实际结果是蔚蓝门户的画像。 使用的 space 和分配的 space 超过 750GB

所以我的问题是:为什么数据库没有变小?我该怎么做才能真正缩小分配的大小 space?

几天后注意: 一个周末后,我再次检查了 azure 门户并更新了它的值。 现在它说: 已用space:486.86GB 已分配 space:826.62GB 我想知道那是从哪里来的。之后我再次执行了收缩命令。这次成功了。也许这是由于 azure 门户的延迟,但我不能肯定地说。

由于对数据库性能的潜在影响,Azure SQL 数据库不会自动收缩数据文件。可以找到如何手动完成 here

经过多次 tries-and-errors 这是我发现的:

从 Azure 门户显示较少使用存储的意义上说,删除语句何时生效取决于为“point-in-time-restore (PITR)”设置的时间。

如果 PITR 设置为 7 天,它会将删除的数据保留 7 天,并且只有在 7 天后,使用的存储空间才会发生明显变化。因此,为了更快地看到 delete-statement 的结果,您必须将 PITR 设置为 1 天,这也是您可以设置的最小值。

只有在删除生效后,执行一个“shrink-command”才有用,因为只有这样你才能真正收缩。