STL_VACUUM
バキュームされたテーブルの行およびブロックに関する統計を表示します。
このビューは、各バキュームオペレーションが開始および終了したときの固有の情報を保持し、バキュームオペレーションを実行する利点を示します。このコマンドを実行するための要件については、VACUUM コマンドの説明を参照してください。
STL_VACUUM はスーパーユーザーにのみ表示されます。詳細については、「システムテーブルとビューのデータの可視性」を参照してください。
このテーブルの一部またはすべてのデータは、SYS モニタリングビュー SYS_VACUUM_HISTORY でも確認できます。SYS モニタリングビューのデータは、使いやすく理解しやすいようにフォーマットされます。クエリには、SYS モニタリングビューを使用することをお勧めします。
テーブルの列
| 列名 | データ型 | 説明 |
|---|---|---|
| userid | integer | エントリを生成したユーザーの ID。 |
| xid | bigint | VACUUM ステートメントのトランザクション ID。このテーブルを STL_QUERY ビューに結合することにより、特定の VACUUM トランザクションで実行された個々の SQL ステートメントを確認できます。データベース全体をバキュームする場合、各テーブルが別々のトランザクションでバキュームされます。 |
| table_id | integer | テーブル ID。 |
| status | character(30) | 各テーブルの VACUUM 操作のステータス。取り得る値には以下のものがあります。
VACUUM ソートしきい値を設定する方法の詳細については、VACUUMを参照してください。 |
| 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...
