Amazon Redshift での VACUUM に関する問題をトラブルシューティングする方法を教えてください。

簡単な説明

VACUUM はリソースを大量に消費する操作であり、次の原因で処理速度が低下する可能性があります。

• ソートされていないデータの割合が高い
• 過大な列を持つ大きなテーブルがある
• インターリーブソートキーを使用している
• VACUUM の使用状況が不規則か稀である
• 同時実行テーブル、クラスターのクエリ、DDL ステートメント、ETL ジョブ

svv_vacuum_progress クエリを使用して、vacuum 操作のステータスと詳細を確認します。次に、VACUUM のベストプラクティスに従ってトラブルシューティングを行い、今後の問題を回避します。

解決策

VACUUM のパフォーマンスを解決する

注: 次の内容は、プロビジョニングされた Amazon Redshift クラスターに適用されます。次のシステムテーブルとクエリは、Amazon Redshift Serverless では機能しません。

svv_vacuum_progress クエリを実行し、VACUUM 操作が進行中かどうかを確認します。

dev=# SELECT * FROM svv_vacuum_progress;
table_name |          status                 | time_remaining_estimate
-----------+---------------------------------+-------------------------
 data8     |  Vacuum: initialize merge data8 | 4m 55s
(1 row)

svv_vacuum_progress クエリには、テーブルの名前、vacuum のステータス、完了までの推定残り時間も含まれます。VACUUM が実行されていない場合、 svv_vacuum_progress クエリは最後に実行された VACUUM のステータスを表示します。

注: svv_vacuum_progress クエリは 1 行の結果のみを返します。

vacuum が実行されているテーブルの詳細を確認します。WHERE 句にテーブル名とスキーマ名を指定します。

SELECT schema, table_id, "table", diststyle, sortkey1, sortkey_num, unsorted, tbl_rows, estimated_visible_rows, stats_off
FROM svv_table_info
WHERE "table" IN ('data8');

出力例:

Schema     | table_id | table | diststyle | sortkey1 | sortkey_num | unsorted | tbl_rows  | est_visible_rows | stats_off
------------+----------+-------+-----------+----------+-------------+----------+-----------+------------------+-----------
testschema | 977719   | data8 | EVEN      | order_id |  2          |    25.00 | 755171520 | 566378624        | 100.00

上記の出力で、sortkey1 列にメインソートキーが表示されます。

テーブルにインターリーブソートキーがある場合、この列には INTERLEAVED 状態が表示されます。

• sortkey_num 列には、ソートキーの列数が表示されます。
• unsorted 列には、ソートが必要な行の割合が表示されます。
• tbl_rows 列には、削除された行と更新された行を含む行の総数が表示されます。
• estimated_visible_rows は、削除された行を除いた行数です。
• vacuum の完了後 (削除とソート) は、tbl_rows および estimated_visible_rows の値はほぼ同じになり、unsorted の値は 0 になります。注: テーブル内のデータはリアルタイムで更新されます。VACUUM の進行状況を確認するには、引き続きクエリを実行します。VACUUM が進行するにつれて、ソートされていない行が徐々に減少することに着目します。ソートされていないデータの割合が高いかどうかを確認するには、特定のテーブルの VACUUM 情報を確認します。

次のクエリを実行して、テーブルの VACUUM 情報を確認します。上記のクエリでテーブル ID を指定します。

SELECT table_id, status, rows, sortedrows, blocks, eventtime
FROM stl_vacuum
WHERE table_id=977719
ORDER BY eventtime DESC LIMIT 20;

出力例:

table_id |             status             |    rows    | sortedrows | blocks |         eventtime
         ----------+--------------------------------+------------+------------+--------+----------------------------
  977719 | [VacuumBG] Finished            |  566378640 |          0 |  23618 | 2020-05-27 06:55:33.232536
  977719 | [VacuumBG] Started Delete Only | 1132757280 |  566378640 |  47164 | 2020-05-27 06:55:18.906008
  977719 | Finished                       |  566378640 |  566378640 |  23654 | 2020-05-27 06:46:04.086842
  977719 | Started                        | 1132757280 |  566378640 |  45642 | 2020-05-27 06:28:17.128345
(4 rows)

上記の例では、出力には最新のイベントが最初に表示され、その後に古いイベントがソート順に表示されます。

• 最後の VACUUM 処理は自動 VACUUM DELETE であり、2020-05-27 06:55:18.906 008 UTC に開始され、数秒で完了しました。
• この VACUUM により、削除された行が占めていたスペースが解放されました。この状態は、VACUUUM 操作の開始および完了時に表示される行とブロックの数によって確認されます。

VACUUM の開始時と終了時にテーブルが占めるブロック数の変化に着目します。

注: Amazon Redshift は、バックグラウンドでテーブルに対して自動的に VACUUM SORT および VACUUM DELETE 操作を実行します。これらのバックグラウンドでの VACUUM 操作は、負荷が軽い期間に実行し、負荷が高い期間には一時停止します。この自動 VACUUM が行われることで、VACUUM コマンドを頻繁に実行する必要がなくなります。

sortedrows 列には、テーブル内のソートされた行の数が表示されます。前回の VACUUM では自動 VACUUM DELETE 操作が行われたため、ソートは行われませんでした。アクティブな行はソートされなかったため、削除対象としてマークされた行には、VACUUM が開始されたときと同じ数のソートされた行数が表示されます。VACUUM DELETE が完了した後は、ソートされた行が 0 件です。

2020-05-27 06:28:17.128 345 UTC に開始された最初のバキュームでは、完全な VACUUM が行われています。このプロセスにより、約 18 分後に削除された行とソートされた行のスペースが解放されました。VACUUM 操作が完了すると、VACUUM によって行が正常にソートされたため、出力の rows と storedrows には同じ値が表示されます。

既に進行中の VACUUM については、引き続きパフォーマンスを監視し、ベストプラクティスを取り入れてください。

VACUUM で発生したエラーのトラブルシューティング

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

VACUUUM クエリが失敗した原因を調べるには、SYS_QUERY_HISTORY または STL_QUERY を参考にエラーメッセージを確認してください。

STL_QUERY を使用する場合は、STL_ERROR からエラーの詳細を取得する必要があります。STL_ERROR にはクエリ ID 列がないため、STL_QUERY から PID フィールドを特定します。次に、そのフィールドを STL_ERROR クエリで使用します。

例:

SELECT user_id, query_id, transaction_id, session_id,  status, start_time, end_time, execution_time, error_message FROM sys_query_history WHERE query_id IN (<failed queries>)


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

| user_id | query_id   | transaction_id |  session_id | status | start_time              |     end_time                  |  execution_time |   error_message |  
| 100        | 915082632 | 35599398     | 1096641177 | failed  | 2024-10-06 21:09:30.209587 | 2024-10

execute ステートメントを使用して VACUUM クエリを実行する場合は、describe-statement を使用してエラーメッセージを特定します。

例:

aws redshift-data describe-statement --id 7c823348d-be8b-437a-9a0-db8c0ca44f0f
{
    "ClusterIdentifier": "redshift-cluster-1",
    "CreatedAt": "2024-10-07T16:25:27.566000+00:00",
    "Duration": -1,
    "Error": "ERROR: VACUUM cannot run inside a multiple commands statement",
    "HasResultSet": false,
    "Id": "7c823348d-be8b-437a-9a0-db8c0ca44f0f",
    "QueryString": "vacuum full toptem;\nvacuum full tsupport;\nvacuum full supplierxbox;\nvacuum full party;",
    "RedshiftPid": 10723479554,
    "RedshiftQueryId": 42304,
    "ResultRows": -1,
    "ResultSize": -1,
    "Status": "FAILED",
    "UpdatedAt": "2024-10-07T16:25:33.566000+00:00"
}

VACUUM のベストプラクティス

VACUUM のパフォーマンスは、次のベストプラクティスで改善できます。

• VACUUM はリソースを大量に消費する操作なので、ピーク時以外に実行してください。
• オフピーク時に wlm_query_slot_count を実行し、VACUUM 操作のキュー内の同時実行レベルを一時的にオーバーライドします。
• 大きなテーブルでは、最大 99% のしきい値パラメータを設定して VACUUM 操作を実行します。
• VACUUM を実行する適切なしきい値と頻度を決定します。たとえば、VACUUM を 100% のしきい値で実行したい場合や、データを常にソートしたい場合には、Amazon Redshift クラスターのクエリパフォーマンスを最適化するアプローチを使用します。
• VACUUM FULL または VACUUM SORT ONLY は、ソートされていないリージョンが大きいテーブルに蓄積されない程度の頻度で実行します。
• 大きなテーブルにソートされていないデータが大量にある場合は、ディープコピーを実行します。ディープコピーを使用すると、既存のテーブルに VACUUM SORT を実行するのではなく、新しいテーブルにデータをロードすることができます。
• BOOST オプションを指定して VACUUM コマンドを実行します。BOOST オプションは、使用可能なメモリやディスク容量などの追加リソースを VACUUM に割り当てます。BOOST オプションを使用すると、VACUUM は 1 つのウィンドウで動作し、VACUUM 操作中は同時削除と更新をブロックします。
  注: BOOST オプションを指定して VACUUM を実行すると、クエリのパフォーマンスが影響を受ける可能性があります。VACUUM BOOST 操作は、メンテナンス作業中またはオフピーク時にのみ実行するのがベストプラクティスです。
• VACUUM のパフォーマンスを向上させるには、すべての大きなテーブルを時系列テーブルに分割します。時系列テーブルを使用することで、VACUUM を実行するためのニーズを満たすことができる場合もあります。
• 大きなテーブルに列圧縮タイプを選択します。行を圧縮すると、データをソートするときに消費するディスク容量が少なくなります。
• VACUUUM 操作後に、ANALYZE コマンドを使用して統計情報を更新します。クエリプランナーは、これらの値を使用して最適なプランを選択します。
• クラスターが完全にアイドル状態の場合は、失敗した VACUUM の試行に対して MANUAL VACUUM を実行します。詳細については、「手動でテーブルに vacuum と分析を行う」を参照してください。

関連情報

STL_ERROR

Amazon Redshift でクエリがキャンセルされた理由を知りたいです

Amazon Redshift Serverless のクエリがキャンセルされたり停止したりする理由を知りたいです