SQL Server 中的 PAGE 压缩对运行查询的影响

Question

我计划对我的数据库（数据仓库）中的一些大表应用 PAGE 压缩。这些表相当大，有超过 150 亿行。

当我在测试环境中应用压缩时，整个过程大约需要 22 个小时。这些表每天都会通过运行很长时间的查询进行访问。

1. 在应用压缩时，是否会对正在运行的查询产生任何影响？任何锁等我应该知道？
2. 是否有交错的方法来应用压缩？
3. 您可能有任何其他输入/反馈？

Answer 1

离线ALTER ... REBUILD 在表上使用一个大的胖模式修改锁，并发绝对为 0（即使脏读也不能扫描表）。

Online ALTER ... REBUILD，顾名思义，允许任何并发查询或 DML 操作。

MSDN 文章How Online Index Operations Work描述了三个阶段（准备、构建和完成）以及每个阶段（IS、IS、SCH-M）所需的对象锁。构建器分批运行并在取得进展时获取数据锁，但它会在发生冲突时退出，并且在使用构建器处理死锁时有一些特殊的方法：

持有批处理事务锁的索引生成器事务和 DML 语句之间可能会出现死锁，但在内部处理，因此 DML 操作和索引生成器事务都不应在生成阶段因死锁而终止。

更多详细信息请参见 SQL Server 2005白皮书中的在线索引操作。

话虽如此，对于 15B 行的 DW 表，最好的选择可能是Columnstore Indexes。

Answer 2

我通过运行测试了该场景

ALTER TABLE test_tbl REBUILD WITH (DATA_COMPRESSION=PAGE,ONLINE=ON)

在事务中，它在页面上使用独占锁，所以是的，存在阻塞的可能性，但是对于大表来说，阻塞的情况会非常少，因为它会逐页压缩，因此只有大型全表扫描选择才能获得被阻止，而不是插入或更新，所以答案是：

1. 是的，它可以阻止大型查询，该进程将在正在压缩的页面上获取排他锁
2. 如果您使用分区，则可以采用交错方法，但是如果您使用聚合查询而不对分区列进行过滤，那么这对您没有多大帮助，如果您无论如何选择整个表，那么压缩哪个分区并不重要
3. 除了磁盘空间之外，您还将获得性能优势，因为您可以在内存中容纳更多的表，您可以通过观察压缩前后的页面预期寿命来测试这一点