TABLE_STORAGE_METRICS ビュー¶

このビューには、テーブルレベルのストレージ使用率情報が表示されます。この情報は、ドロップされたがまだストレージコストが発生しているテーブルを含む、アカウントの各テーブルのストレージ請求の計算に使用されます。

ビューには、テーブルのメタデータに加えて、テーブルごとに請求されるストレージバイト数が表示されます。Snowflakeは、バイトを次のカテゴリに分類します。

クエリ可能なテーブル内のデータを表すアクティブバイト。
システムからまだパージされていないためにストレージ料金が発生している削除済みバイト。これらのバイトは、次のサブカテゴリに分類されます。
- Time Travelのバイト数（最近削除されたが、まだテーブルのTime Travel保持期間内）。
- Fail-safeのバイト（Time Travel保持期間を過ぎているが、テーブルのFail-safe期間内の削除済みバイト）。
- クローン用に保持されたバイト（Time TravelまたはFail-safeにはなくなったが、テーブルのクローンがバイトを参照しているために保持されたままの削除済みバイト）。

つまり、対応するテーブルに対してストレージ料金が一切発生しなくなるまで、そのテーブル内のデータの状態（アクティブ、Time Travel、Fail-safe、クローン用に保持されている）に関係なく、行はこのビューに保持され続けます。

テーブルのデータストレージの詳細については、データストレージに関する考慮事項をご参照ください。

注釈

このビューをクエリするには、 ACCOUNTADMIN ロールを使用する必要があります。ビューは他のビューで表示され、クエリを実行できますが、クエリは行を返しません。

列¶

列名	データ型	説明
TABLE_CATALOG	VARCHAR	テーブルが属するデータベース。
TABLE_SCHEMA	VARCHAR	テーブルが属するスキーマ。
TABLE_NAME	VARCHAR	テーブルの名前。
ID	NUMBER	テーブルの一意の識別子。
CLONE_GROUP_ID	NUMBER	このテーブルの最も古いクローンの先祖の一意の識別子。テーブルがクローンでない場合、ID と同じです。
IS_TRANSIENT	VARCHAR	テーブルが一時または仮テーブルの場合は「YES」、それ以外の場合は「NO」。一時テーブルと仮テーブルには、Fail-safe期間はありません。
ACTIVE_BYTES	NUMBER	このテーブルが所有（および請求）し、テーブルがアクティブ状態にあるバイト。Icebergテーブルストレージでは、アクティブバイトは Iceberg テーブルに請求されません。詳細については、 Icebergテーブルの請求をご参照ください。
TIME_TRAVEL_BYTES	NUMBER	このテーブルが所有（および請求）し、テーブルがTime Travel状態にあるバイト。
FAILSAFE_BYTES	NUMBER	このテーブルが所有（および請求）し、テーブルのFail-safe状態にあるバイト。
RETAINED_FOR_CLONE_BYTES	NUMBER	Bytes owned by (and billed to) this table that are retained after deletion because they are referenced by one or more clones of this table, or by WORM backups that contain the table.
TABLE_CREATED	TIMESTAMP_LTZ	テーブルが作成された日時。
TABLE_DROPPED	TIMESTAMP_LTZ	テーブルがドロップされた日時。テーブルがドロップされていない場合は NULL 。
TABLE_ENTERED_FAILSAFE	TIMESTAMP_LTZ	テーブルがドロップされた場合、Fail-safe状態になった、あるいは NULL になった日時。この状態では、UNDROP を使用してテーブルを復元できません。
CATALOG_CREATED	TIMESTAMP_LTZ	テーブルを含むデータベースが作成された日時。
CATALOG_DROPPED	TIMESTAMP_LTZ	テーブルを含むデータベースがドロップされた日時。
SCHEMA_CREATED	TIMESTAMP_LTZ	テーブルを含むスキーマが作成された日時。
SCHEMA_DROPPED	TIMESTAMP_LTZ	テーブルを含むスキーマがドロップされた日時。
COMMENT	VARCHAR	テーブルのコメント。

使用上の注意¶

active_bytes、 time_travel_bytes、 failsafe_bytes、および retained_for_clone_bytes に対するストレージ関連の統計の更新には、1～2時間の遅延が発生する可能性があります。
ID および CLONE_GROUP_ID:
- ID テーブルの名前が変更された場合やドロップされた場合でも、ライフサイクル全体を通してテーブルの変更は行われません。
- テーブルがドロップされたがストレージコストが発生する場合でも、CLONE_GROUP_ID はクローンの最も古い先祖の ID です。例:
  テーブル t2 は、 t1 からクローンされます。
  
  テーブル t3 は、 t2 からクローンされます。
  t1 がドロップされ、最終的にSnowflakeからパージされた場合でも、3つのテーブルはすべて t1 の ID を CLONE_GROUP_ID としてリストします。
- ID と CLONE_GROUP_ID が同一の場合、テーブルはクローンではありません。
- ストレージバイトは常に、バイトが最初に追加されたテーブルによって所有、したがって請求されます。その後、テーブルがクローンされると、ソーステーブルからバイトが削除された場合でも、これら開始時のバイトのストレージメトリックはクローンに転送されません。
クローンテーブルは、元のテーブルまたはクローンされたテーブルのいずれかが変更されるまで、同じ基のストレージ（マイクロパーティションレベルで）を共有します。いずれかのテーブルに変更が加えられるたびに、テーブルは変更されたバイトの「所有権」を取得します。
ドロップされたテーブルは、ストレージコストが発生する限り、ビューに表示されます。
- ドロップされたテーブルはアクティブなストレージメトリックを保持し、テーブルが復元された場合にアクティブになるバイト数を示します。
- テーブルのTime Travel保持期間内にドロップされたテーブルは、UNDROP を使用して復元できます。
- Fail-safeでドロップされたテーブル（TABLE_ENTERED_FAILSAFE は NULL ではない）は、以下を除くほとんどの列に NULL 値を表示する可能性があります。
  
  ID 列:
  
  ID , CLONE_GROUP_ID
  
  バイト列:
  
  ACTIVE_BYTES , TIME_TRAVEL_BYTES , FAILSAFE_BYTES , RETAINED_FOR_CLONE_BYTES
  
  これらのテーブルは、 UNDROP を使用して復元できません。
Time Travelの保持期間が0日のテーブルからデータが削除されると、テーブルの種類に応じて、非同期バックグラウンドプロセスがアクティブなバイトをパージするか、Fail-safeストレージに直接移動します。これが完了するまでに少し時間がかかる場合があります。その間、Time Travelの保持期間が0日であっても、 TIME_TRAVEL_BYTES 列にゼロ以外の値が含まれる場合があります。
FAILSAFE_BYTES は、Time Travelを通過したバイトを示します。そのようなバイトはすべて、現在のテーブルに請求されます。
複数の行の TABLE_NAME 列に同じ値がある場合、テーブルに複数のバージョンが存在することを示します。テーブルがドロップされるたびにバージョンが作成され、同じ名前の新しいテーブルが作成されます。これには、既存のテーブルで CREATE OR REPLACE TABLE コマンドが発行されたときも含まれます。現在のバージョンでは TABLE_DROPPED 列の値が NULL であることに注意してください。他のすべてのバージョンではタイムスタンプ値があります。テーブルの各バージョンにTime Travel（およびテーブルが永続的である場合はFail-safe）に関連するストレージコストが発生するため、これに注意することが重要です。
場合によっては、アクティブバイトに、ドロップされた列のデータのバイトが含まれることがあります。詳細については、 ALTER TABLE の使用上の注意をご参照ください。
Icebergテーブルの場合:
- Snowflakeが Icebergテーブルストレージの請求をすることはありません。詳細については、 Icebergテーブルの請求をご参照ください。
- テーブルが外部管理で、行レベル削除を使用している場合、このビューではストレージ使用率情報が不正確に表示される可能性があります。