Schéma :

ACCOUNT_USAGE

Vue TABLE_STORAGE_METRICS

Cette vue Utilisation du compte affiche des informations sur l’utilisation du stockage au niveau de la table, qui sont utilisées pour calculer la facturation du stockage pour chaque table du compte, y compris les tables qui ont été supprimées, mais qui continuent à créer des coûts de stockage.

En plus des métadonnées de la table, la vue affiche le nombre d’octets de stockage facturés pour chaque table. Snowflake décompose les octets dans les catégories suivantes :

  • Octets actifs, représentant les données de la table qui peuvent être interrogées.

  • Les octets supprimés qui créent encore des frais de stockage parce qu’ils n’ont pas encore été purgés du système. Ces octets sont classés dans les sous-catégories suivantes :

    • octets dans Time Travel (c.-à-d. récemment supprimés, mais encore comprises dans la période de conservation Time Travel de la table).

    • octets dans Fail-safe (c’est-à-dire les octets supprimés qui ont dépassé la période de conservation de Time Travel, mais sont encore compris dans la période Fail-safe de la table).

    • octets conservés pour les clones (c’est-à-dire les octets supprimés qui ne sont plus dans Time Travel ou Fail-safe, mais qui sont conservés car les clones de la table font référence aux octets).

En d’autres termes, les lignes sont conservées dans cette vue jusqu’à ce que les tables correspondantes ne soient plus facturées pour aucun stockage, quel que soit le statut dans lequel se trouvent les données des tables (c’est-à-dire octets actifs, Time Travel, Fail-safe ou conservés pour les clones).

Pour plus de détails sur le stockage des données dans les tables, voir Remarques relatives au stockage de données.

Colonnes

Nom de la colonne

Type de données

Description

ID

NUMBER

Identificateur interne/généré par le système pour la table.

TABLE_NAME

TEXT

Nom de la table.

TABLE_SCHEMA_ID

NUMBER

Identificateur interne/généré par le système pour le schéma de la table.

TABLE_SCHEMA

TEXT

Schéma auquel la table appartient.

TABLE_CATALOG_ID

NUMBER

Identificateur interne/généré par le système pour la base de données de la table.

TABLE_CATALOG

TEXT

Base de données à laquelle la table appartient.

CLONE_GROUP_ID

NUMBER

Identificateur unique pour le plus ancien ancêtre clone de cette table. Identique à ID si la table n’est pas un clone.

IS_TRANSIENT

TEXT

YES” si la table est transitoire ou temporaire, sinon’NO”. Les tables transitoires et temporaires n’ont pas de période Fail-safe.

ACTIVE_BYTES

NUMBER

Les octets appartenant à (et facturés à) cette table qui sont dans un état actif pour la table.

TIME_TRAVEL_BYTES

NUMBER

Les octets appartenant à (et facturés à) cette table qui sont dans l’état Time Travel pour la table.

FAILSAFE_BYTES

NUMBER

Les octets appartenant à (et facturés à) cette table qui sont dans l’état Fail-safe pour la table.

RETAINED_FOR_CLONE_BYTES

NUMBER

Les octets appartenant à (et facturés à) cette table qui sont conservés après suppression car ils sont référencés par un ou plusieurs clones de cette table.

DELETED

BOOLEAN

TRUE si la table a été purgée du stockage.

TABLE_CREATED

TIMESTAMP_LTZ

Date et heure de création de la table.

TABLE_DROPPED

TIMESTAMP_LTZ

Date et heure à laquelle la table a été supprimée. NULL si la table n’a pas été détruite.

TABLE_ENTERED_FAILSAFE

TIMESTAMP_LTZ

Date et heure auxquelles la table, en cas de destruction, est passée à l’état Fail-safe, ou NULL. Dans cet état, la table ne peut pas être restaurée avec UNDROP.

SCHEMA_CREATED

TIMESTAMP_LTZ

Date et heure auxquelles le schéma de la table a été créé.

SCHEMA_DROPPED

TIMESTAMP_LTZ

Date et heure auxquelles le schéma de la table a été détruit.

CATALOG_CREATED

TIMESTAMP_LTZ

Date et heure de création de la base de données de la table.

CATALOG_DROPPED

TIMESTAMP_LTZ

Date et heure auxquelles la base de données de la table a été détruite.

COMMENT

TEXT

Commentaire pour la table.

INSTANCE_ID

NUMBER

Identificateur interne/généré par le système pour l’instance à laquelle l’objet appartient.

Notes sur l’utilisation

  • La latence pour la vue peut aller jusqu’à 90 minutes.

  • ID et CLONE_GROUP_ID :

    • ID ne change pas pour une table tout au long de son cycle de vie, y compris si la table est renommée ou détruite.

    • CLONE_GROUP_ID est l’ID de l’ancêtre le plus ancien d’un clone, y compris si la table a été détruite, mais qu’il y a encore des coûts de stockage. Par exemple :

      1. La table t2 est clonée à partir de t1.

      2. La table t3 est clonée à partir de t2.

      Les trois tables listent les ID pour t1 comme leur CLONE_GROUP_ID, même si t1 est détruite et éventuellement purgée de Snowflake.

    • Si les IDs sont identiques, la table n’est pas un clone.

    • Les octets de stockage sont toujours la propriété de la table dans laquelle ils ont été initialement ajoutés et sont donc facturés. Si la table est ensuite clonée, les métriques de stockage pour ces octets initiaux ne sont jamais transférées vers les clones, même si les octets sont supprimés de la table source.

  • Les tables clonées partagent le même stockage sous-jacent (au niveau de la micro-partition) jusqu’à ce que la table originale ou la table clonée soit modifiée. Avec chaque modification apportée à l’une ou l’autre table, la table devient « propriétaire » des octets modifiés.

  • Les tables détruites sont affichées dans la vue tant qu’elles entraînent encore des coûts de stockage :

    • Les tables détruites conservent leurs paramètres de stockage actifs, indiquant combien d’octets seront actifs si la table est restaurée.

    • Les tables détruites dans la période de conservation Time Travel de la table peuvent être restaurées à l’aide de la commande UNDROP.

    • Les tables détruites dans Fail-safe (TABLE_ENTERED_FAILSAFE n’est pas NULL) afficheront potentiellement des valeurs NULL dans la plupart des colonnes, sauf pour :

      les colonnes ID:

      ID , CLONE_GROUP_ID

      les colonnes d’octets:

      ACTIVE_BYTES , TIME_TRAVEL_BYTES , FAILSAFE_BYTES , RETAINED_FOR_CLONE_BYTES

      Ces tables ne peuvent pas être restaurées avec la commande UNDROP.

  • Lorsque des données sont supprimées d’une table avec une période de conservation Time Travel est de 0 jour, des processus d’arrière-plan asynchrones purgent les octets actifs ou les déplacent directement vers un stockage Fail-safe, selon le type de table. Cette opération peut prendre un certain temps. Pendant cette période, la colonne TIME_TRAVEL_BYTES peut contenir une valeur non nulle, même si la période de conservation Time Travel est de 0 jour.

  • FAILSAFE_BYTES indique les octets qui ont dépassé la période Time Travel. Tous ces octets sont facturés à la table courante.

  • Si plusieurs lignes ont la même valeur dans la colonne TABLE_NAME, cela indique que plusieurs versions de la table existent. Une version est créée à chaque fois qu’une table est détruite et qu’une nouvelle table portant le même nom est créée, y compris lorsqu’une commande CREATE OR REPLACE TABLE est émise sur une table existante. Notez que la version actuelle aura une valeur NULL pour la colonne TABLE_DROPPED ; toutes les autres versions auront une valeur d’horodatage. Ceci est important à noter, car chaque version d’une table entraîne des coûts de stockage associés à Time Travel (et à Fail-safe, si la table est permanente).

  • Toute donnée figurant dans la colonne DELETED avant le mois d’août 2018 peut ne pas être exacte.

  • Dans certains cas, les octets actifs peuvent inclure des octets pour des données dans une colonne supprimée. Pour plus d’informations, consultez les notes sur l’utilisation pour ALTER TABLE.