Amazon Redshift は、2026 年 6 月 30 日以降、Python UDF の使用をサポートしなくなります。これは段階的に実施されます。Python のサポート終了と移行オプションの詳細については、2025 年 6 月 30 日に公開された[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# STL\_VACUUM
バキュームされたテーブルの行およびブロックに関する統計を表示します。
このビューは、各バキュームオペレーションが開始および終了したときの固有の情報を保持し、バキュームオペレーションを実行する利点を示します。このコマンドを実行するための要件については、[VACUUM](r_VACUUM_command.md) コマンドの説明を参照してください。
STL\_VACUUM はスーパーユーザーにのみ表示されます。詳細については、「[システムテーブルとビューのデータの可視性](cm_chap_system-tables.md#c_visibility-of-data)」を参照してください。
このテーブルの一部またはすべてのデータは、SYS モニタリングビュー [SYS\_VACUUM\_HISTORY](SYS_VACUUM_HISTORY.md) でも確認できます。SYS モニタリングビューのデータは、使いやすく理解しやすいようにフォーマットされます。クエリには、SYS モニタリングビューを使用することをお勧めします。
## テーブルの列
| 列名 | データ型 | 説明 |
| --- | --- | --- |
| userid | integer | エントリを生成したユーザーの ID。 |
| xid | bigint | VACUUM ステートメントのトランザクション ID。このテーブルを STL\_QUERY ビューに結合することにより、特定の VACUUM トランザクションで実行された個々の SQL ステートメントを確認できます。データベース全体をバキュームする場合、各テーブルが別々のトランザクションでバキュームされます。 |
| table\_id | integer | テーブル ID。 |
| status | character(30) | 各テーブルの VACUUM 操作のステータス。取り得る値には以下のものがあります。+ **Started **
+ **Started Delete Only**
+ **Started Delete Only (Sorted >= nn%) **
VACUUM FULL の削除フェーズのみを開始しました。テーブルはすでにソートされているかソートしきい値を超えているため、ソートフェーズはスキップされました。
+ **Started Sort Only**
+ **Started Ranged Partition**
+ **Started Reindex**
+ **Finished**
テーブルのオペレーションが完了した時刻。特定のテーブルに対してバキューム操作にかかった時間を計算するために、特定のトランザクション ID およびテーブル ID について終了時刻から開始時刻を引きます。
+ **Skipped**
テーブルが完全にソートされ削除対象としてマークされた列はないため、テーブルはスキップされました。
+ **Skipped (delete only) **
DELETE ONLY が指定され、削除対象としてマークされた列はないため、テーブルはスキップされました。
+ **Skipped (sort only) **
SORT ONLY が指定され、テーブルはすでに完全にソートされたため、テーブルはスキップされました。
+ **Skipped (sort only, sorted>=xx%)**
SORT ONLY が指定され、テーブルはすでにソートされているかソートしきい値を超えているため、テーブルはスキップされました。
+ **Skipped (0 rows)**
テーブルは空であるため省略されました。
+ **VacuumBG**
自動バキューム操作がバックグラウンドで実行されます。このステータスは、自動的に実行されるときに他のステータスの前に追加されます。例えば、削除のみのバキュームを自動的に実行すると、開始行に `[VacuumBG] Started Delete Only` ステータスが表示されます。
VACUUM ソートしきい値を設定する方法の詳細については、[VACUUM](r_VACUUM_command.md)を参照してください。 |
| rows | bigint | テーブル内にある実際の行と、削除されてまだディスクに保存されている (バキューム待ちの) 行の数の合計。この列は、バキューム開始前にステータスが Started だった行の数と、バキューム後にステータスが Finished だった行の数を示します。 |
| sortedrows | integer | テーブル内でソートされる行の数。この列は、バキューム開始前に Status 列が Started だった行の数と、バキューム後に Status 列が Finished だった行の数を示します。 |
| blocks | integer | バキューム操作前 (ステータスが Started の行) とバキューム操作後 (Finished の列) のそれぞれに、テーブルデータを保存するために使用されたデータブロックの総数。各データブロックのサイズは 1 MB です。 |
| max\_merge\_partitions | integer | この列は、パフォーマンスの分析に使用され、バキュームが 1 回のマージフェーズで処理できるテーブルのパーティションの最大数を表します (バキュームでは、ソートされていないリージョンを 1 つ以上のソートされたパーティションにソートます。テーブルの列数と現在の Amazon Redshift の設定に応じて、マージフェーズでは繰り返しマージ処理のうち 1 回で最大数のパーティションを処理できます。マージフェーズは、ソートされたパーティションの数がマージパーティションの最大数を超えても引き続き有効ですが、繰り返しマージ処理をさらに続ける必要があります。) |
| eventtime | timestamp | バキューム操作が開始または終了した時刻。 |
| reclaimable\_rows | bigint | 現在の cutoff\_xid で再利用可能な行の数。この列は、ステータスが Started の行に対してバキュームを開始する前の Redshift が推定する再利用可能な行の数と、ステータスが Finished のバキューム後に残っている再利用可能な行の実数を示します。 |
| reclaimable\_space\_mb | bigint | 現在の cutoff\_xid 用に再利用可能なスペース (MB 単位)。この列は、ステータスが Started の行に対してバキュームを開始する前の Redshift が推定する再利用可能な空き容量と、ステータスが Finished のバキューム後に残っている再利用可能な空き容量の実数を示します。 |
| cutoff\_xid | bigint | バキューム処理の cutoff トランザクション ID。cutoff 後のトランザクションはバキューム処理に含まれません。 |
| is\_recluster | integer | 1 (true) の場合、バキューム処理で再クラスターアルゴリズムが実行され、0 (false) の場合は実行されませんでした。 |
## サンプルクエリ
次のクエリは、テーブル 108313 のバキューム統計をレポートします。テーブルは一連の挿入、削除後にバキューム処理されています。
```
select xid, table_id, status, rows, sortedrows, blocks, eventtime,
reclaimable_rows, reclaimable_space_mb
from stl_vacuum where table_id=108313 order by eventtime;
xid | table_id | status | rows | sortedrows | blocks | eventtime | reclaimable_rows | reclaimable_space_mb
-------+----------+-------------------------+------+------------+--------+----------------------+------------------+----------------------
14294 | 108313 | Started | 1950 | 408 | 28 | 2016-05-19 17:36:01 | 984 | 17
14294 | 108313 | Finished | 966 | 966 | 11 | 2016-05-19 18:26:13 | 0 | 0
15126 | 108313 | Skipped(sorted>=95%) | 966 | 966 | 11 | 2016-05-19 18:26:38 | 0 | 0
```
バキュームの開始時に、テーブルには 1,950 行が 28 個の 1 MB ブロックに含まれていました。Amazon Redshift は、バキューム処理で 984 行、17 ブロックのディスク容量を回収できると見積もっています。
ステータスが Finished の行では、ROWS 列は 966 の値になり、BLOCKS 列では値が 28 から 11 に減っています。バキューム処理が完了すると、推定量のディスク容量が回収され、再利用可能な行や空き容量がなくなりました。
ソートフェーズ (トランザクション 15126) で、行がソートキー順序で挿入されバキュームはテーブルをスキップできました。
次の例では、大きな INSERT 操作の後に SALES テーブル (この例ではテーブル 110116) の SORT ONLY のバキュームの統計が表示されます。
```
vacuum sort only sales;
select xid, table_id, status, rows, sortedrows, blocks, eventtime
from stl_vacuum order by xid, table_id, eventtime;
xid |table_id| status | rows |sortedrows|blocks| eventtime
----+--------+-----------------+-------+----------+------+--------------------
...
2925| 110116 |Started Sort Only|1379648| 172456 | 132 | 2011-02-24 16:25:21...
2925| 110116 |Finished |1379648| 1379648 | 132 | 2011-02-24 16:26:28...
```