「vacuum reindex」操作がスタックしており、これほど長い時間がかかる原因は何なのか疑問に思っています。
最近、Redshift テーブルの 1 つのスキーマを変更しました。変更したスキーマで新しいテーブルを作成し、「select into」を使用してデータをディープ コピーしました (「ディープ コピーの実行」を参照)。私の基本的な理解は、テーブルをディープコピーした後、テーブルのソートキーに従ってデータをソートする必要があるということでした。テーブルには、インターリーブされた 4 列のソート キーがあります。念のため、ディープ コピーを行った後、「インターリーブ スキュー」クエリを実行しました ( Decision When to Reindex を参照)。結果はすべての列で 1.0 であり、スキューがないことを意味します。
次に、テーブルで 'vacuum reindex' を実行しました。データは既にソートされているため、非常に高速です。ただし、掃除機は 30 時間後も稼働しています。バキューム中、定期的に svv_vacuum_progress を調べてバキューム操作の状態を確認しました。「並べ替え」フェーズは約 6 時間後に終了しましたが、現在、「マージ」フェーズは「増分 23」で 12 時間以上スタックしています。
ディープ コピー操作によってデータが既に並べ替えられているはずの場合、長いバキューム操作の原因は何でしょうか? 将来のバキューム操作についても、これらの時間を期待できますか? テーブルには最大 35 億行が含まれており、その合計サイズは最大 200 GB です。