DEAデータオペレーションとサポート
あるデータエンジニアリングチームは、Amazon Redshiftを使用して日次ETLパイプラインを運用しています。毎日大量のDELETEおよびUPDATE操作を実行した後、クエリのパフォーマンスが徐々に低下しています。Redshiftのシステムビュー SVV_TABLE_INFO（テーブルのストレージ・ソート状態を確認できるシステムビュー）を参照したところ、主要なファクトテーブルで unsorted_pct（未ソート行の割合）が高く、stats_off（クエリプランナーが使う統計情報の乖離度）も大きくなっていました。クエリパフォーマンスを回復させるための適切な操作はどれですか？
AVACUUM FULL を実行してデータを再ソートし不要な領域を回収した後、ANALYZE を実行してテーブルの統計情報を更新する
✓ 正解
Amazon RedshiftではDELETE/UPDATE操作を繰り返すと論理削除行（ゴーストロウ）が蓄積されてストレージが断片化し、ソートキー順序も乱れます。また統計情報が古くなるとクエリプランナーが非効率な実行計画を選択します。VACUUM FULLでゴーストロウ削除とデータ再ソートを行い、ANALYZEで統計情報を最新化することでクエリパフォーマンスを回復できます。
Bテーブルのソートキー（SORTKEY）の定義を ALTER TABLE で変更し、現在のクエリパターンに最適化する
SORTKEY変更は今回の劣化原因（断片化・統計情報の陳腐化）への直接対処ではなく、テーブルの実質的な再構築を伴う大規模作業です。
Cクラスターの一時停止（Pause）と再開（Resume）を実行して内部キャッシュをクリアする
クラスター一時停止・再開はキャッシュをクリアしますが、データの断片化やソート乱れ・統計情報の問題は解消しません。
D影響を受けているテーブルを DROP して再作成し、バックアップからデータを再ロードする
DROPと再作成はバックアップからの再ロードが必要で時間がかかり、VACUUMとANALYZEで対応できる問題に対して過剰な対応です。
解説
Amazon RedshiftではDELETE/UPDATE操作を繰り返すと論理削除行（ゴーストロウ）が蓄積されてストレージが断片化し、ソートキー順序も乱れます。また統計情報が古くなるとクエリプランナーが非効率な実行計画を選択します。VACUUM FULLでゴーストロウ削除とデータ再ソートを行い、ANALYZEで統計情報を最新化することでクエリパフォーマンスを回復できます。
選択肢BのSORTKEY変更は今回の劣化原因（断片化・統計情報の陳腐化）への直接対処ではなく、テーブルの実質的な再構築を伴う大規模作業です。
選択肢Cのクラスター一時停止・再開はキャッシュをクリアしますが、データの断片化やソート乱れ・統計情報の問題は解消しません。
選択肢DのDROPと再作成はバックアップからの再ロードが必要で時間がかかり、VACUUMとANALYZEで対応できる問題に対して過剰な対応です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →