実行中のクエリに対するSQL ServerのPAGE圧縮の影響
私はデータベース内のいくつかの大きなテーブル（正確にはDW）にPAGE圧縮を適用することを計画しています。これらのテーブルはかなり大きく、150億を超える行があります。テスト環境で圧縮を適用した場合、プロセス全体で約22時間かかりました。これらのテーブルは、非常に長いクエリを実行して毎日アクセスされます。私の質問は
- 圧縮が適用されている間、実行中のクエリに影響がありますか？知っておくべきロックなどはありますか？
- 圧縮を適用するための段階的なアプローチはありますか？
3.あなたが持っているかもしれない他の入力/フィードバック？
どうもありがとう
ショーン
オフラインのALTER ... REBUILDは、同時実行性が絶対に0であるテーブルに対して大きな太いスキーマ変更ロックを取得します（ダーティリードでさえテーブルをスキャンできません）。 Online名前からわかるように、ALTER ... REBUILDを使用すると、任意の同時クエリまたはDML操作を実行できます。 MSDNの記事 オンラインインデックスオペレーションの仕組み は、3つのフェーズ（準備、ビルド、ファイナライズ）と、各フェーズ（IS、IS、SCH-M）で必要なオブジェクトロックについて説明しています。ビルダーはバッチで動作し、進行中にデータロックを取得しますが、競合が発生するとバックオフします。ビルダーでのデッドロックの処理には特別なソースがあります。
バッチトランザクションロックを保持しているインデックスビルダートランザクションとDMLステートメントの間のデッドロックは可能ですが、内部的に処理されるため、デッドロックが原因でビルドフェーズ中にDML操作もインデックスビルダートランザクションも終了しません。
詳細については、アンチマターの動作を含む SQL Server 2005のオンラインインデックス操作 ホワイトペーパーを参照してください。
今言われているように、15B行のDWテーブルの場合、最適なオプションは Columnstore Indexes です。
実行してシナリオをテストしました
ALTER TABLE test_tbl REBUILD WITH (DATA_COMPRESSION=PAGE,ONLINE=ON)
トランザクションでは、ページに排他ロックがかかるため、ブロックされる可能性があります。ただし、ページごとに圧縮するため、大きなテーブルの場合は非常に少なくなります。挿入や更新ではなくブロックされているため、答えは次のとおりです。
- はい、それは大きなクエリをブロックすることができます、プロセスは圧縮されているページに排他ロックをかけます
- パーティションを使用する場合、時間をずらしたアプローチが可能ですが、パーティション化された列にフィルターを使用せずに集計クエリを使用する場合はあまり役に立ちません。テーブル全体を選択する場合は、どのパーティションを圧縮するかは関係ありません。
- ディスク領域に加えて、より多くのテーブルをメモリに収めることができるため、パフォーマンスの利点も得られます。圧縮の前後にページの寿命を観察することで、これをテストできます。