メニュー
Amazon Redshift
データベース開発者ガイド (API Version 2012年12月1日)

STL_VACUUM

バキュームされたテーブルの行およびブロックに関する統計を表示します。

このテーブルは、各バキューム操作が開始および終了したときの固有の情報を保持し、バキューム操作を実行するメリットを示します。このコマンドを実行するための要件については、VACUUM コマンドの説明を参照してください。

このテーブル はスーパーユーザーのみに表示されます。詳細については、「システムテーブルとビューのデータの可視性」を参照してください。

テーブルの列

列名 データ型 説明
userid integer The エントリを生成したユーザーの ID。
xid bigint VACUUM ステートメントのトランザクション ID。このテーブルを STL_QUERY テーブルに結合することにより、特定の VACUUM トランザクションで実行された個々の SQL ステートメントを確認できます。データベース全体をバキュームする場合、各テーブルが別々のトランザクションでバキュームされます。
table_id integer The テーブル ID。
status character(30)

各テーブルの VACUUM 操作のステータス。取り得る値には以下のものがあります。

  • 開始

  • Started Delete Only

  • Started Delete Only (Sorted >= nn%)

    VACUUM FULL の削除フェーズのみを開始しました。テーブルはすでにソートされているかソートしきい値を超えているため、ソートフェーズはスキップされました。

  • Started Sort Only

  • Finished

    テーブルのオペレーションが完了した時刻。特定のテーブルに対してバキューム操作にかかった時間を計算するために、特定のトランザクション ID およびテーブル ID について終了時刻から開始時刻を引きます。

  • Skipped

    テーブルが完全にソートされ削除対象としてマークされた列はないため、テーブルはスキップされました。

  • Skipped (delete only)

    DELETE ONLY が指定され、削除対象としてマークされた列はないため、テーブルはスキップされました。

  • Skipped (sort only)

    SORT ONLY が指定され、テーブルはすでに完全にソートされたため、テーブルはスキップされました。

  • Skipped (sort only, sorted>=xx%).

    SORT ONLY が指定され、テーブルはすでにソートされているかソートしきい値を超えているため、テーブルはスキップされました。

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 バキューム操作が開始または終了した時刻。

サンプルクエリ

次のクエリは、テーブル 108313 のバキューム統計をレポートします。テーブルは一連の挿入、削除後にバキューム処理されています。

Copy
select xid, table_id, status, rows, sortedrows, blocks, eventtime from stl_vacuum where table_id=108313 order by eventtime; xid | table_id | status | rows | sortedrows | blocks | eventtime -------+----------+----------------------+------------+------------+--------+--------------------- 14294 | 108313 | Started | 1950266199 | 400043488 | 280887 | 2016-05-19 17:36:01 14294 | 108313 | Finished | 600099388 | 600099388 | 88978 | 2016-05-19 18:26:13 15126 | 108313 | Skipped(sorted>=95%) | 600099388 | 600099388 | 88978 | 2016-05-19 18:26:38

VACUUM の開始時に、テーブルには 1,950,266,199 行が 280,887 1 MB ブロックに含まれていました。削除フェーズ (トランザクション 14294) が完了し、バキュームが削除された行の容量を再利用します。ROWS 列の値は 400,043,488 となり、BLOCKS 列は 280,887 から 88,978 に減少しました。バキュームは、191,909 ブロック (191.9 GB) のディスク容量を再利用しました。

ソートフェーズ (トランザクション 15126) で、行がソートキー順序で挿入されバキュームはテーブルをスキップできました。

次の例では、大きな INSERT 操作の後に SALES テーブル (この例ではテーブル 110116) の SORT ONLY のバキュームの統計が表示されます。

Copy
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...

このページの内容: