SQL Server 中的 PAGE 壓縮對執行查詢的影響

我計劃將 PAGE 壓縮應用於我的數據庫（數據倉庫）中的一些大表。這些表相當大，有超過 150 億行。

當我在測試環境中應用壓縮時，整個過程大約需要 22 小時。每天都會通過執行時間很長的查詢訪問這些表。

1. 在應用壓縮時，是否會對正在執行的查詢產生任何影響？我應該注意的任何鎖等？
2. 是否有交錯的方法來應用壓縮？
3. 您可能有任何其他輸入/回饋？

Offline ALTER … REBUILD 在表上採用一個大的胖模式修改鎖，並發絕對為 0（即使是臟讀也不能掃描表）。

Online ALTER … REBUILD，顧名思義，允許任何並發查詢或 DML 操作。

MSDN 文章How Online Index Operations Work描述了三個階段（準備、建構和完成）以及每個階段所需的對象鎖（IS、IS、SCH-M）。builder 分批操作，並在取得進展時獲取數據鎖，但它會在發生衝突時退出，並且在使用 builder 處理死鎖方面有一些特殊的技巧：

持有批處理事務鎖的索引建構器事務和 DML 語句之間的死鎖是可能的，但在內部處理，因此 DML 操作和索引建構器事務都不應在建構階段由於死鎖而終止。

更多詳細資訊請參見 SQL Server 2005 中的聯機索引操作白皮書。

話雖如此，對於 15B 行 DW 表，最好的選擇可能是Columnstore Indexes。

我通過執行測試了場景

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

在事務中，它在頁面上採取排他鎖，所以是的，有可能阻塞，但是對於大表來說它會非常少，因為它逐頁壓縮，所以只有大的全表掃描選擇可以獲得被阻止，而不是插入或更新，所以答案是：

1. 是的，它可以阻止大型查詢，該程序將對正在壓縮的頁面進行排他鎖
2. 如果您使用分區，則可以使用交錯的方法，但是如果您在分區列上使用沒有過濾器的聚合查詢，這對您沒有多大幫助，如果您仍然選擇整個表，那麼您壓縮的分區無關緊要
3. 除了磁碟空間之外，您還將獲得性能優勢，因為您可以在記憶體中容納更多的表，您可以通過觀察壓縮前後的 Page Life Expectancy 來測試這一點

引用自：https://dba.stackexchange.com/questions/27940