在 1.5TB 表上启用页面压缩

Question

我需要想出最好的方法来在大小为 1500 GB 的表上启用页面压缩，有 363,957,740 行。数据库大小本身为 1.71 TB，并保存存档数据。

如果我理解正确，它需要磁盘空间（可能是相同的数量，只是为了更安全），以便它可以创建启用页面压缩的表副本并释放空间。这是在FULL恢复模型中，因此将被大量记录。

我已与我的容量规划资源进行了交谈，他同意为此维护提供额外的临时所需空间，并在此活动完成后收回空间。说了这么多，你认为最好的方法是：

1. 进行完整备份
2. 将备份还原到新的临时驱动器上
3. 将恢复模式更改为 SIMPLE
4. 启用页面压缩
5. 压缩后进行完整备份并恢复原始数据库
6. 将恢复模型更改为 FULL

此外，而不是启用页面压缩。Step #3 之后，截断最大的表，启用页面压缩，然后执行

SELECT * INTO ReplicaDB.dbo.ReplicaTbl

这是否在现有索引上启用页面压缩？

我没有测试环境来测试上述步骤。或者，如果有更好的方法可用，请告诉我。

目标是最大限度地减少当前增长所需的未来磁盘空间。我们是一家 ERP 软件公司，我们拥有企业版许可。该表仅用于在执行某些检查并且所有数据都驻留在该表中时存档。我有 2 个索引（1 个 CI，1 个非 CI）。没有任何列是VARCHAR (MAX)，它们要么是NVARCHAR，int要么是date类型。

Answer 1

你的计划听起来不错，除了这个：

此外，而不是启用页面压缩。在第 3 步之后，截断最大的表，启用页面压缩，然后执行 SELECT * INTO ReplicaDB.dbo.ReplicaTbl ?

如果您截断一个表并启用页面压缩，您必须这样做INSERT而不是SELECT INTO，此时您应该使用TABLOCK页面压缩而不是仅行压缩。

除此之外，压缩重建比插入压缩表要快得多，我们在大型表上有 3-5 倍的差异。

看看这里：数据加载性能指南，数据压缩和批量加载部分：

当数据被批量加载到压缩表或分区时，页级和行级压缩通常在批量加载时完成。但是，您应该注意一个例外情况：当批量加载到页面压缩堆中时，您必须使用 TABLOCK 提示来实现页面压缩。如果未使用 TABLOCK 提示，则仅在堆上进行行级压缩。在批量目标上使用页面压缩通常会降低批量加载速度——特别是如果 I/O 系统能够提供足够的速度来使 CPU 饱和。

Answer 2

在表或索引级别启用页面压缩。您可以拥有带有页压缩索引的未压缩表或带有未压缩索引的压缩表。如果您希望对索引进行页面压缩，则需要单独执行此操作。

我的印象是，此次搬迁最重要的考虑因素是能够归还分配给您的所有临时空间。SELECT INTO不是您想要做的事情的好选择。该表将在未压缩且没有聚集索引的情况下构建。构建这将需要一个REBUILD会增加您的数据文件的，这正是您想要避免的。

这是我会考虑这样做的方式：

1. 对旧数据库进行完整备份。
2. 将备份还原到同一台服务器上的临时数据库。
3. 在临时数据库上将恢复模式更改为简单。
4. 截断日志。
5. 截断目标表。
6. 创建具有页面压缩聚集索引且没有非聚集索引的目标表。
7. 使用TABLOCK提示将旧数据库中的所有行插入到目标表中。此操作可能需要很长时间，但应该最少记录并且不需要排序。
8. 使用页面压缩一次构建一个非聚集索引。
9. 切换到完整恢复模式。
10. 进行完整备份。在切换恢复模式后执行此操作意味着您不必再进行备份。
11. 在原始数据库上恢复临时数据库。
12. 在您测试之后删除旧数据库的备份，并且您确信一切都已检查完毕。