メニュー
Amazon Redshift
データベース開発者ガイド (API Version 2012-12-01)

VACUUM

現在のデータベース内の指定されたテーブルまたはすべてのテーブルにある行のスペースの再利用や行の再ソートを行います。

注記

実質的に、テーブルの所有者またはスーパーユーザーのみがテーブルにバキューム処理を実行できます。必要なテーブル権限なしで VACUUM が実行された場合、操作は完了しますが、効果はありません。

デフォルトではVACUUM コマンドで、テーブルの行の 95 パーセント以上がすでにソートされているテーブルのソートフェーズをスキップします。 ソートフェーズをスキップすることにより、VACUUM のパフォーマンスが大幅に向上します。 また、削除フェーズの VACUUM では、残りの行の少なくとも 95 パーセントが削除対象としてマークされていない領域を再利用します。VACUUM では、削除対象としてマークされた数行のみを含む多数のブロックの書き換えをスキップできるため、通常削除された行の 100 パーセントを再利用することに比べて削除フェーズの時間が少なくて済みます。 1 つのテーブルに対するデフォルトのソートあるいは削除しきい値を変更するには、VACUUM を実行する時、テーブル名および TO threshold PERCENT パラメーターを含めます。

注記

Amazon Redshift の VACUUM コマンドの構文と動作は、PostgreSQL の VACUUM 操作とは大幅に異なります。たとえば、Amazon Redshift でのデフォルトのバキューム操作は VACUUM FULL です。これは、ディスク領域を再利用し、すべての行を再ソートします。 これに対して、PostgreSQL のデフォルトの VACUUM 操作は、単純に領域を再利用し、再び使用できるようにするだけです。

詳細については、「テーブルのバキューム処理」を参照してください。

構文

Copy
VACUUM [ FULL | SORT ONLY | DELETE ONLY | REINDEX ] [ [ table_name ] [ TO threshold PERCENT ] ]

パラメーター

FULL

指定されたテーブル (または現在のデータベースのすべてのテーブル) をソートし、直前の UPDATE 操作および DELETE 操作で削除対象のマークが付けられた行によって占有されているディスク領域を再利用します。完全バキュームは、インターリーブテーブルのインデックスを再作成しません。 インターリーブテーブルのインデックスを再作成するには、VACUUM REINDEX オプションを使用します。

デフォルトで、VACUUM FULL は、少なくとも 95 パーセントがソート済みであるテーブルのソートフェーズをすべてスキップします。 VACUUM がソートフェーズをスキップできれば、DELETE ONLY を実行し、削除フェーズで残りの行の少なくとも 95 パーセントが削除対象としてマークされていない領域を再利用します。  

ソートしきい値に達しておらず (たとえば 90 パーセントの行がソートされていて) VACUUM が完全ソートを実行する場合は、完全な削除オペレーションも実行され、削除された行のスペースが 100 パーセント回復されます。

一つのテーブルに対してのみデフォルトの VACUUM しきい値を変更できます。 1 つのテーブルに対するデフォルトの VACUUM しきい値を変更するには、テーブル名および TO threshold PERCENT パラメーターを含めます。

SORT ONLY

削除した行によって解放されたスペースを再利用せずに、指定されたテーブル (または現在のデータベース内のすべてのテーブル) をソートします。このオプションは、ディスク容量の再利用が重要でなく、新しい行の再ソートが重要な場合に役に立ちます。ソートされていない領域が削除済みの行が大量に含んでおらず、ソート済み領域全体にまたがっていない場合に、SORT ONLY のバキューム操作を実行すると、バキューム操作にかかる時間が短縮されます。 ディスク容量による拘束がなく、テーブルの行を常にソート状態に維持するクエリの最適化に依存するアプリケーションは、このようなバキューム操作からメリットを得ることができます。

デフォルトで、VACUUM SORT ONLY は少なくとも 95 パーセントがソート済みであるテーブルをスキップします。 1 つのテーブルに対するデフォルトのソートしきい値を変更するには、VACUUM を実行する時、テーブル名および TO threshold PERCENT パラメーターを含めます。

DELETE ONLY

直前の UPDATE 操作と DELETE 操作で削除対象のマークが付けられた行によって占有されているディスク容量を回収し、テーブルを圧縮して、消費されている領域を解放します。DELETE ONLY バキューム操作を実行しても、テーブルのデータはソートされません。 このオプションは、ディスク容量が重要で、新しい行の再ソートが重要でない場合に、バキューム操作にかかる時間を短縮します。このオプションは、クエリのパフォーマンスが既に最適で、行の再ソートのためにクエリのパフォーマンスを最適化する必要がない場合にも役立ちます。

デフォルトでは、VACUUM DELETE ONLY は、残りの行の少なくとも 95 パーセントが削除対象としてマークされていない領域を再利用します。 1 つのテーブルに対するデフォルトの削除しきい値を変更するには、VACUUM を実行する時、テーブル名および TO threshold PERCENT パラメーターを含めます。 

REINDEX

インターリーブソートキー列の値の分散を分析した後、完全バキューム処理を実行します。VACUUM REINDEX では、VACUUM FULL よりも大幅に長い時間が必要です。これは、インターリーブソートキーを分析するための追加パスを作成するためです。インターリーブテーブルでは、ソートオペレーションおよびマージオペレーションの時間が長くなる場合があります。これは、インターリーブソートでは、複合ソートよりも多くの行の再調整が必要になることがあるためです。

VACUUM REINDEX オペレーションがその完了前に終了した場合、次の VACUUM は完全バキュームオペレーションの実行前に REINDEX オペレーションを再開します。

VACUUM REINDEX は TO threshold PERCENT でサポートさていません。 

table_name

バキューム操作を実行するテーブルの名前。テーブル名を指定しない場合、バキューム操作は現在のデータベースのすべてのテーブルに適用されます。 ユーザーが作成した常設テーブルまたは一時テーブルを指定できます。このコマンドは、ビューやシステムテーブルなど、他のオブジェクトに対しては意味を持ちません。

TO threshold PERCENT パラメーターを含める場合は、テーブル名が必要です。

TO threshold PERCENT

VACUUM が削除フェーズをスキップする最低のしきい値、および削除フェーズでスペースを再利用する対象となるしきい値を指定する句です。 ソートしきい値は、バキューム処理の前の指定されたテーブルにおけるソート済みの行の合計の割合です。  削除しきい値は、バキューム処理後に削除対象としてマークされていない行の合計の最低割合です。

VACUUM は、テーブルのソート済みの行の割合がソートしきい値以下の場合のみ行を再ソートするため、Amazon Redshift は、バキューム処理の時間を大幅に削減できます。 同様に、VACUUM は削除対象としてマークされた行のスペースを 100 パーセント再利用するよう制約を受けない場合、削除対象としてマークされた行を数行のみ含むブロックの書き換えをスキップできます。

たとえば、しきい値に 75 を指定すると、VACUUM はテーブルの行の 75 パーセント以上がすでにソート済みの場合ソートフェーズをスキップします。 削除フェーズでは、バキューム処理後に削除対象としてマークされていない行がテーブルに 少なくとも 75 パーセントあるようなテーブルを VACUUM はディスク領域の再利用の対象として設定します。 しきい値の値は、0 から 100 の間の整数でなければなりません。 デフォルトは 95 です。100 という値を指定すると、VACUUM はすでに完全にソートされていない限り常にテーブルをソートし、削除対象としてマークされたすべての行のスペースを再利用します。 0 という値を指定すると、VACUUM は一切テーブルをソートせず、一切スペースを再利用しません。

TO threshold PERCENT パラメーターを含める場合、テーブルの名前を指定する必要があります。 テーブル名を省略すると、VACUUM は失敗します。

TO threshold PERCENT パラメーターを REINDEX で使用することはできません。

使用に関する注意事項

ほとんどの Amazon Redshift アプリケーションでは、完全バキュームをお勧めします。詳細については、「テーブルのバキューム処理」を参照してください。

バキューム操作を実行する前に、以下の動作に注意してください。

  • トランザクションブロック (BEGIN ... END) 内で VACUUM を実行することはできません。

  • 一度にクラスターで実行できる VACUUM コマンドは 1 つだけです。 複数のバキューム動作を同時に実行しようとすると、Amazon Redshift はエラーを返します。

  • テーブルのバキュームを実行すると、ある程度のテーブル容量の増加が発生することがあります。 再利用の対象となる削除済みの行が存在しない場合や、テーブルの新しいソート順によりデータ圧縮率が低下する場合、これは想定される動作です。

  • バキューム操作の実行中、クエリのパフォーマンスがある程度低下することが予想されます。バキューム操作が終了すると直ちに通常のパフォーマンスに戻ります。

  • バキューム操作中に同時書き込み操作が行われますが、バキューム処理を実行中に書き込み操作を実行することは推奨されていません。 バキューム操作を実行する前に、書き込み操作を終了する方がより効率的です。 また、バキューム操作開始後に書き込まれたすべてのデータは、その操作ではバキュームすることはできません。この場合、2 回目のバキューム操作が必要になります。

  • ロード操作または挿入操作が既に進行中の場合、バキューム操作を開始できないことがあります。バキューム操作を開始するには、テーブルへの一時的な排他アクセスが必要になります。この排他アクセスは短時間しか必要でないため、バキューム操作により同時ロードと同時挿入が長時間ブロックされることはありません。

  • 特定のテーブルに対して実行する作業がない場合、バキューム操作はスキップされます。ただし、操作がスキップ可能かどうかの検出に関連して、ある程度のオーバーヘッドが発生します。テーブルがあまり使われていないことが判明している場合、または、バキュームのしきい値を満たさないことが判明している場合は、これに対してバキューム操作を実行しないでください。

  • 小さなテーブルに対して DELETE ONLY バキューム操作を実行した場合、データの保存に使われるブロック数が減少しないことがあります。特にテーブルに多数の列が存在している場合、またはクラスターがノードごとに多数のスライスを使用している場合、この傾向が顕著になります。このようなバキューム操作はテーブルへの同時挿入を実現するため、1 列ごとに 1 ブロックを各スライスに追加します。また、このようなオーバーヘッドが発生した場合、ブロック数の削減の方が再利用されるディスク容量を上回る可能性があります。例えばバキューム操作前に、8 ノードクラスター上の 10 列のテーブルが 1000 ブロックを占有している場合、削除された行が原因で 80 ブロックを超えるディスク容量が再利用されない限り、バキュームを実行しても実際のブロック数は減少しません。 (各データブロックは 1 MB 使用します。)

すべてのテーブルで、デフォルトのバキュームしきい値 95 パーセントに基づいて、容量とデータベースの再利用と行の再ソートを実行します。

Copy
vacuum;

SALES テーブルで、デフォルトのしきい値 95 パーセントに基づいて、容量の再利用と行の再ソートを実行します。

Copy
vacuum sales;

SALES テーブルで、常に容量の再利用と行の再ソートを実行します。

Copy
vacuum sales to 100 percent;

SALES テーブルで、すでにソートされている行が 75 パーセント未満の場合のみ、行の再ソートを実行します。

Copy
vacuum sort only sales to 75 percent;

バキューム処理後に削除対象としてマークされていない行が残りの行の 少なくとも 75 パーセント以上である SALES テーブルで容量の再利用を実行します。

Copy
vacuum delete only sales to 75 percent;

LISTING テーブルのインデックスを再作成した後、バキューム処理を実行します。

Copy
vacuum reindex listing;

次のコマンドはエラーを返します。

Copy
vacuum reindex listing to 75 percent;