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 |
TEXT |
テーブルが属するデータベース。 |
TABLE_SCHEMA |
TEXT |
テーブルが属するスキーマ。 |
TABLE_NAME |
TEXT |
テーブルの名前。 |
ID |
NUMBER |
テーブルの一意の識別子。 |
CLONE_GROUP_ID |
NUMBER |
このテーブルの最も古いクローンの先祖の一意の識別子。テーブルがクローンでない場合、ID と同じです。 |
IS_TRANSIENT |
TEXT |
テーブルが一時または仮テーブルの場合は「YES」、それ以外の場合は「NO」。一時テーブルと仮テーブルには、Fail-safe期間はありません。 |
ACTIVE_BYTES |
NUMBER |
このテーブルが所有(および請求)し、テーブルがアクティブ状態にあるバイト。 |
TIME_TRAVEL_BYTES |
NUMBER |
このテーブルが所有(および請求)し、テーブルがTime Travel状態にあるバイト。 |
FAILSAFE_BYTES |
NUMBER |
このテーブルが所有(および請求)し、テーブルのFail-safe状態にあるバイト。 |
RETAINED_FOR_CLONE_BYTES |
NUMBER |
このテーブルが所有(および請求)し、このテーブルの1つ以上のクローンによって参照されるため、削除後も保持されるバイト。 |
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 |
TEXT |
テーブルのコメント。 |
使用上の注意¶
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 の 使用上の注意 をご参照ください。