Bundle 2022_02¶

Requêtes de données hiérarchiques : les limites d’itération ne sont plus appliquées¶

Lorsque vous interrogez des données hiérarchiques, vous pouvez utiliser des CTEs récursives ou la commande CONNECT BY pour itérer sur chaque niveau de la hiérarchie.

La limite du nombre d’itérations, qui était précédemment fixée à 100 (en interne par Snowflake), n’est plus appliquée :

Précédemment:

Si une requête dépassait le nombre maximum d’itérations (100), la requête échouait avec le message d’erreur suivant :

Recursion exceeded max iteration count (n)

où n était le nombre maximum d’itérations autorisées.

Le code d’erreur pour cette erreur était 100189.

Actuellement:

Il n’y a pas de limite au nombre d’itérations effectuées.

Les requêtes qui échouaient auparavant avec le message d’erreur ci-dessus (en particulier, les requêtes qui aboutissent à des boucles infinies) n’échouent plus et continuent de s’exécuter jusqu’à ce que la requête réussisse ou expire, ce qui peut être contrôlé en définissant le paramètre STATEMENT_TIMEOUT_IN_SECONDS.

Pour déterminer si vous aviez des requêtes ayant dépassé le nombre maximum d’itérations avant que le changement ne soit actif, consultez la vue QUERY_HISTORY pour connaître les requêtes qui ont échoué avec le code d’erreur 100189 :

SELECT * FROM snowflake.account_usage.query_history WHERE error_code = 100189;

Copy

Une fois le changement actif, si ces mêmes requêtes sont exécutées, elles n’échoueront pas. Si une boucle infinie se produit, la requête ne s’arrêtera pas prématurément. Au lieu de cela, la requête s’exécutera jusqu’à ce qu’elle réussisse ou qu’elle expire (c’est-à-dire qu’elle dépasse le nombre de secondes défini dans le paramètre STATEMENT_TIMEOUT_IN_SECONDS).

Voir Dépannage d’une CTE récursive pour des informations sur la façon dont les boucles infinies peuvent se produire, comment les identifier et comment les corriger.

Time Travel : paramètre DATA_RETENTION_TIME_IN_DAYS hérité conservé dans des tables de transitoires¶

Le comportement des tables transitoires lorsque le paramètre DATA_RETENTION_TIME_IN_DAYS est défini de façon explicite sur 0 (jours) pour un objet parent (compte, base de données ou schéma) a été modifié comme suit :

Précédemment:

Les tables transitoires n’héritaient pas de la configuration du paramètre DATA_RETENTION_TIME_IN_DAYS des objets parents lorsque la durée de conservation des données était de 0 jour. Les tables transitoires étaient créées avec une durée de conservation des données de 1 jour, indépendamment de la durée de conservation des données de l’objet parent.

Actuellement:

Les tables transitoires héritent de la durée de conservation des données définie sur un objet parent (schéma, base de données, compte) si le paramètre DATA_RETENTION_TIME_IN_DAYS de l’objet parent est défini sur 0.

Pour générer une liste de tables transitoires dans un compte dont au moins un des parents (schéma ou base de données) a la valeur DATA_RETENTION_TIME_IN_DAYS définie sur 0, exécutez les instructions de l’exemple suivant. Toutefois, notez les points suivants avant l’exécution des instructions :

• La liste comprend des tables transitoires dont le paramètre DATA_RETENTION_TIME_IN_DAYS est explicitement défini sur 1.

  Si DATA_RETENTION_TIME_IN_DAYS est défini sur 0 au niveau du compte, exécutez la série d’instructions du deuxième exemple ci-dessous pour répertorier toutes les tables transitoires pour lesquelles DATA_RETENTION_TIME_IN_DAYS est défini sur 1.

• Avant de désactiver le paramètre pour une table, nous vous recommandons de vérifier si Time Travel doit être désactivé pour cette table.

show tables in account;
set
  table_qid = (
    select
      last_query_id()
);

show schemas in account;
set
  schema_qid = (
    select
      last_query_id()
);

show databases in account;
set
  database_qid = (
    select
      last_query_id()
);

with table_v as (
    select
      "database_name" as database_name,
      "schema_name" as schema_name,
      "name" as table_name,
      "kind" = 'TRANSIENT' as is_transient,
      "retention_time" as table_retention_time
    from
      table(result_scan($table_qid))
  ),
  schema_v as (
    select
      "name" as schema_name,
      iff(
        try_to_number("retention_time") is null,
        0,
        try_to_number("retention_time")
      ) as schema_retention_time
    from
      table(result_scan($schema_qid))
  ),
  database_v as (
    select
      "name" as database_name,
      "retention_time" as database_retention_time
    from
      table(result_scan($database_qid))
  )
select
  *
from
  table_v
  left join schema_v using (schema_name)
  left join database_v using (database_name)
where
  is_transient
  and table_retention_time = 1
  and (
    schema_retention_time = 0
    or database_retention_time = 0
  );

Copy

Si DATA_RETENTION_TIME_IN_DAYS est défini sur 0 au niveau du compte, exécutez les instructions suivantes pour répertorier toutes les tables transitoires pour lesquelles DATA_RETENTION_TIME_IN_DAYS est défini sur 1 :

-- Verify account level DATA_RETENTION_TIME_IN_DAYS setting is 0
show parameters like 'DATA_RETENTION_TIME_IN_DAYS' in account;

show tables in account;

select
  "database_name" as database_name,
  "schema_name" as schema_name,
  "name" as table_name,
  "kind" = 'TRANSIENT' as is_transient,
  "retention_time" as table_retention_time
from
  table(result_scan(last_query_id()))
where
  is_transient
  and table_retention_time = 1;

Copy

Pour annuler le paramètre DATA_RETENTION_TIME_IN_DAYS d’une table transitoire existante, ce qui lui permet d’hériter de la définition du paramètre d’un objet parent, utilisez ALTER TABLE :

ALTER TABLE <table_name> UNSET DATA_RETENTION_TIME_IN_DAYS;

Copy

Pour vérifier la durée de conservation des données définie sur une table, utilisez SHOW TABLES :

SHOW TABLES LIKE '<table_name>';

Copy

Commande SHOW ORGANIZATIONACCOUNTS : nouvelle colonne¶

La colonne suivante a été ajoutée à la sortie de la commande SHOW TAGS :

Commande SHOW PROCEDURES : la sortie inclut des procédures stockées créées par l’utilisateur et intégrées.¶

Snowflake prend en charge la création de procédures stockées en tant qu’objets de niveau schéma dans n’importe quelle base de données d’un compte. La commande SHOW PROCEDURES renvoie des informations sur ces procédures stockées créées par l’utilisateur.

Avec l’introduction de la classification des données, Snowflake fournit désormais également des procédures stockées intégrées qui peuvent être appelées en tant qu’objets globaux, de manière similaire à des fonctions intégrées.

La sortie de la commande SHOW PROCEDURES a été modifiée comme suit pour prendre en charge les procédures stockées intégrées :

Précédemment:

La commande renvoyait uniquement les procédures stockées créées par l’utilisateur dans la base de données/le schéma actuel ou spécifié (ou pour l’ensemble du compte).

Pour afficher les procédures stockées intégrées fournies par Snowflake, vous pouvez utiliser le mot clé BUILTIN dans la commande. Par exemple :

SHOW BUILTIN PROCEDURES;

Copy

Cependant, notez que Snowflake ne fournit qu’une seule procédure stockée intégrée, ASSOCIATE_SEMANTIC_CATEGORY_TAGS.

Actuellement:

La fonction renvoie toutes les procédures stockées, y compris les procédures stockées créées par l’utilisateur et celles intégrées.

Cela rend la commande SHOW PROCEDURES cohérente avec la commande SHOW FUNCTIONS.

Cette modification n’affecte pas les mots-clés BUILTIN ou USER, qui peuvent être utilisés pour renvoyer explicitement des procédures stockées intégrées ou créées par l’utilisateur. Par exemple :

SHOW BUILTIN PROCEDURES;

SHOW USER PROCEDURES;

Copy

Fonction SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS : modifications de la base d’estimation¶

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS est une fonction système que vous pouvez appeler pour déterminer les coûts estimés de l’ajout de l’optimisation de la recherche à une table.

Cette fonction a été modifiée pour utiliser un petit échantillon comme base de l’estimation des coûts. Avec ce changement, la fonction fournit des estimations de coûts plus précises. Cependant, ce changement a un impact sur l’utilisation de l’entrepôt et la sortie de la fonction. Il peut également affecter les performances de la fonction, comme décrit ci-dessous :

Précédemment:

La fonction utilisait un modèle simple pour estimer les coûts. Parce que la fonction utilisait un modèle simple pour estimer les coûts :

• Il n’était pas nécessaire qu’un entrepôt soit en cours d’utilisation lors de l’appel de la fonction.

• Comme la fonction n’utilisait pas d’entrepôt, vous n’étiez pas facturé pour l’utilisation de l’entrepôt pour cette fonction.

• La fonction était exécutée et renvoyait un résultat en quelques secondes.

• Dans la sortie JSON renvoyée, pour les objets nommés BuildCosts et StorageCosts dans le tableau costPositions :

  • Il n’y avait pas de champ comment.

  • Le champ computationMethod a été défini sur "EstimatedUpperBound".

Actuellement:

La fonction prend désormais un petit échantillon de données de la table spécifiée, produit un chemin d’accès de recherche temporaire, analyse le coût du processus et extrapole les résultats pour estimer le coût pour la table entière. Parce que la fonction utilise l’échantillonnage pour estimer les coûts :

• Pour appeler la fonction, vous devez avoir un entrepôt en service. Si aucun entrepôt n’est actuellement utilisé, la fonction affiche le message suivant :

  No active warehouse selected in the current session.

  Sélectionnez un entrepôt actif avec la commande USE WAREHOUSE. Pour exécuter cette fonction, vous pouvez utiliser un entrepôt X-Small. La taille de l’entrepôt n’a aucun effet sur la vitesse et les performances de cette fonction.

• Comme la fonction utilise un entrepôt, vous êtes maintenant facturé pour l’utilisation de l’entrepôt pour cette fonction.

• La fonction prend plus de temps pour s’exécuter et renvoyer les résultats (entre 20 secondes et 10 minutes). Comme indiqué ci-dessus, l’utilisation d’une taille d’entrepôt plus importante n’entraîne pas une exécution plus rapide de cette fonction.

• Dans la sortie JSON renvoyée, pour les objets nommés BuildCosts et StorageCosts dans le tableau costPositions :

  • Le champ comment est défini sur "estimated via sampling".

  • Le champ computationMethod est défini sur "Estimated".

Vue LOGIN_HISTORY (Account Usage) : nouvelle colonne¶

La nouvelle colonne suivante a été ajoutée à la vue ACCOUNT_USAGE.LOGIN_HISTORY :

Vues QUERY_HISTORY (Account Usage) : sortie cohérente avec la fonction QUERY_HISTORY¶

Les valeurs des octets de transfert de données entrants et sortants sont incohérentes entre les éléments suivants :

• Vues ACCOUNT_USAGE.QUERY_HISTORY et READER_ACCOUNT_USAGE.QUERY_HISTORY

• Sortie de fonction de table INFORMATION_SCHEMA.QUERY_HISTORY

Les vues Account Usage incluent des octets de transfert de données entrants et sortants lorsque la valeur Cloud de transfert de données (INBOUND_DATA_TRANSFER_CLOUD ou OUTBOUND_DATA_TRANSFER_CLOUD respectivement) est nulle.

Ces vues ont évolué comme suit :

Précédemment:

Les vues QUERY_HISTORY dans ACCOUNT_USAGE et READER_ACCOUNT_USAGE comprenaient les éléments suivants :

• La colonne INBOUND_DATA_TRANSFER_BYTES incluait des octets de transfert de données lorsque la valeur INBOUND_DATA_TRANSFER_CLOUD était nulle.

• La colonne OUTBOUND_DATA_TRANSFER_BYTES incluait des octets de transfert de données lorsque la valeur OUTBOUND_DATA_TRANSFER_CLOUD était nulle.

Actuellement:

Les vues sont maintenant cohérentes avec la sortie de la fonction table INFORMATION_SCHEMA.QUERY_HISTORY.

Les colonnes INBOUND_DATA_TRANSFER_BYTES et OUTBOUND_DATA_TRANSFER_BYTES ne comprennent pas d’octets provenant de transferts de fichiers lorsque la valeur INBOUND_DATA_TRANSFER_CLOUD ou OUTBOUND_DATA_TRANSFER_CLOUD associée est nulle.

Commandes DESCRIBE STREAM / SHOW STREAM : nouvelles colonnes dans la sortie¶

La sortie des commandes DESCRIBE STREAM et SHOW STREAMS comprend maintenant les colonnes supplémentaires suivantes :

Les nouvelles colonnes ont été insérées entre les colonnes TABLE_NAME et TYPE existantes.

Tables de répertoire : métadonnées actualisées une fois automatiquement lors de la création de la zone de préparation¶

Lorsque vous créez une zone de préparation qui inclut une table de répertoire, les métadonnées de la table de répertoire sont désormais automatiquement actualisées immédiatement, une seule fois. L’actualisation des métadonnées de la table de répertoire synchronise les métadonnées avec la liste actuelle des fichiers de données dans le chemin de zone de préparation spécifié.

Auparavant, afin d’enregistrer les fichiers de données existants dans les métadonnées de la table de répertoire, les utilisateurs devaient exécuter une instruction ALTER STAGE … REFRESH après la création de la zone de préparation.

Cette amélioration est implémentée par le biais du nouveau paramètre REFRESH_ON_CREATE de la commande CREATE STAGE. Lorsque REFRESH_ON_CREATE = TRUE (valeur par défaut), Snowflake actualise automatiquement les métadonnées de la table de répertoire une seule fois lors de la création de la zone de préparation.