web-dev-qa-db-ja.com

1.5TBテーブルでのページ圧縮の有効化

サイズが1500 GB、行数が363,957,740のテーブルでページ圧縮を有効にするには、可能な限り最良の方法を考え出す必要があります。データベースのサイズ自体は1.71 TB=であり、アーカイブデータを保持します。

私が正しく理解している場合は、ページの圧縮を有効にしてテーブルのコピーを作成し、スペースを解放できるように、ディスク領域（おそらく安全のために同じ量）が必要です。これはFULL復旧モデルに含まれているため、頻繁にログに記録されます。

私はキャパシティプランニングリソースと話をしましたが、このメンテナンスのために一時的に必要な追加のスペースを提供し、このアクティビティが完了したらスペースを取り戻すことに同意しました。これを言って、あなたは最善のアプローチがそうであると思いますか：

  1. 完全バックアップを取る
  2. 新しい一時ドライブにバックアップを復元します
  3. 復旧モデルをSIMPLEに変更します
  4. ページ圧縮を有効にする
  5. 圧縮後に完全バックアップを取り、元のデータベースを復元する
  6. 復旧モデルをFULLに変更します

また、ページ圧縮を有効にする代わりに。ステップ3の後で、最大のテーブルを切り捨て、ページ圧縮を有効にしてから、

_SELECT * INTO ReplicaDB.dbo.ReplicaTbl
_

これにより、既存のインデックスでページ圧縮が有効になりますか？

上記の手順をテストするためのテスト環境がありません。または、より良いアプローチが利用できる場合は、お知らせください。

目標は、現在の増加時に必要な将来のディスク容量を最小限に抑えることです。私たちはERPソフトウェア会社であり、Enterprise Editionのライセンスを取得しています。このテーブルは、いくつかのチェックが実行され、すべてのデータがこのテーブルに存在する場合のアーカイブ用です。2つのインデックス（1 CI、 1 NON-CI）。どの列もVARCHAR (MAX)ではなく、NVARCHAR、intまたはdateタイプのいずれかです。

sql-serversql-server-2012compression
5
Sid

ページ圧縮は、テーブルまたはインデックスレベルで有効になります。ページ圧縮インデックスのある非圧縮テーブル、または非圧縮インデックスのある圧縮テーブルを使用できます。インデックスをページ圧縮する場合は、個別に行う必要があります。

この移動の最も重要な考慮事項は、割り当てられた一時スペースをすべて返せるようにすることだという印象を受けます。 SELECT INTOは、実行しようとしていることに対して適切なオプションではありません。テーブルは非圧縮で、クラスター化インデックスなしで構築されます。 REBUILDを必要とするビルドでは、データファイルが大きくなり、まさに回避したいものになります。

ここに私がそれをすることを考える方法があります：

  1. 古いデータベースの完全バックアップを取ります。
  2. 同じサーバー上の一時データベースにバックアップを復元します。
  3. 一時データベースで復旧モデルを単純に変更します。
  4. ログを切り捨てます。
  5. ターゲット表を切り捨てます。
  6. ページ圧縮されたクラスター化インデックスを使用し、非クラスター化インデックスを使用しないターゲットテーブルを作成します。
  7. TABLOCKヒントを使用して、古いデータベースのすべての行をターゲットテーブルに挿入します。この操作には時間がかかる場合がありますが、最小限のログに記録する必要があり、並べ替えは必要ありません。
  8. ページ圧縮を使用して、非クラスター化インデックスを一度に1つずつ作成します。
  9. 完全復旧モデルに切り替えます。
  10. 完全バックアップを取ります。復旧モデルを切り替えた後にこれを行うと、別のバックアップを取る必要がなくなります。
  11. 元のデータベースに一時データベースを復元します。
  12. テストが完了したら、古いデータベースのバックアップを削除し、すべてがチェックアウトされたことを確認します。
5
Joe Obbish

あなたの計画はこれを除いてよく聞こえます：

また、ページ圧縮を有効にする代わりに。ステップ3の後で、最大のテーブルをトランケートし、ページ圧縮を有効にしてから、SELECT * INTO ReplicaDB.dbo.ReplicaTbl？

テーブルを切り捨ててページ圧縮を有効にする場合は、SELECT INTOではなくINSERTを実行する必要があります。この時点では、TABLOCKを使用して、行圧縮のみではなくページ圧縮を取得する必要があります。

これに加えて、圧縮による再構築は、圧縮されたテーブルへの挿入よりもはるかに高速です。大きなテーブルでは3〜5倍の違いがあります。

こちらをご覧ください： データ読み込みパフォーマンスガイド 、セクションデータ圧縮と一括読み込み：

データが圧縮されたテーブルまたはパーティションに一括で読み込まれる場合、通常、ページレベルと行レベルの両方の圧縮が一括読み込み時に行われます。ただし、例外に注意する必要があります。ページ圧縮ヒープに一括読み込みする場合は、TABLOCKヒントを使用してページ圧縮を行う必要があります。 TABLOCKヒントが使用されない場合、行レベルの圧縮のみがヒープで行われます。バルクターゲットでページ圧縮を使用すると、一般的に、特にI/OシステムがCPUを飽和させるのに十分な速度を提供できる場合は、バルクロード速度が低下します。

5
sepupic

テーブルがパーティション化されているのでしょうか（そのような大きなテーブルをパーティション化することは理にかなっています）。

主な関心領域の場合は、各パーティションを個別に圧縮できます。平均で500のパーティションがある場合、それはちょうど30-50GBになります。パーティションのサブセットで圧縮を変更できるため、別の時点で圧縮を実行できるというアプローチのもう1つの利点。

ALTER INDEX <IX_Table_ClusteredIndex>
ON <Table> REBUILD PARTITION = 1 WITH (DATA_COMPRESSION = PAGE);

ここにあなたを生成するクエリがありますINDEX REBUILDすべてのパーティション：

SELECT '    ALTER INDEX ['+ i.name + '] ON [' + s.name + '].[' + o.name + 
    '] REBUILD PARTITION = ' + CONVERT(VARCHAR(MAX), p.partition_number) + 
    ' WITH (DATA_COMPRESSION = PAGE, ONLINE = ON); '
FROM sys.partitions p
    INNER JOIN sys.objects o
        ON p.object_id = o.object_id
    INNER JOIN sys.schemas s
        ON o.schema_id = s.schema_id
    INNER JOIN sys.indexes i
        ON p.index_id = i.index_id
        AND p.object_id = i.object_id
WHERE o.name = 'LargeTable' 
ORDER BY p.partition_number

INDEX REBUILDは 最小ログ記録操作 にすることができます。また、Enterpriseエディションを使用しているため、ONLINE = ON。

3
Alexander Sharovarov