Bundle 2022_01¶
Ce chapitre décrit les changements de comportement suivants (le cas échéant) pour le mois :
Les fonctionnalités devenues obsolètes.
Les changements groupés qui ont été activés.
Les autres changements non groupés qui ont été mis en œuvre.
Si vous avez des questions sur ces modifications, veuillez contacter le support Snowflake.
Pour obtenir des détails sur les nouvelles fonctionnalités, les améliorations et les corrections introduites ce mois-ci, voir Mars 2022.
Important
Sauf indication contraire, ces modifications sont contenues dans le bundle 2022_01, qui a été activé par défaut dans la version de changement de comportement 6.7.
Dans ce chapitre :
Changements SQL — Général¶
Transactions : la validation d’une transaction interrompue renvoie un message d’erreur¶
Avec ce changement, la tentative de valider une transaction qui a déjà été interrompue renvoie un message d’erreur :
- Précédemment:
Si vous exécutiez une instruction COMMIT dans une transaction qui était interrompue (par exemple, par un appel SYSTEM$ABORT_TRANSACTION distinct ou parce que la session était inactive), l’instruction semblait réussir avec le message suivant :
Statement executed successfully.
Cependant, la transaction elle-même avait déjà été interrompue.
Le message de sortie de l’instruction COMMIT impliquait à tort que la transaction avait réussi.
- Actuellement:
Si vous exécutez une instruction COMMIT dans une transaction qui a été interrompue (par exemple, par un appel SYSTEM$ABORT_TRANSACTION distinct ou parce que la session était inactive), l’instruction échoue avec le code d’erreur
000670
et le message suivant :000670 (57014): COMMIT failed. Your transaction '<nom>', id '<id>', was already aborted.
Changements SQL — Commandes et fonctions¶
SHOW USERS : ajout de la prise en charge des résultats paginés, des résultats limités et des sorties courtes¶
Le comportement de la commande SHOW USERS a changé comme suit :
- Précédemment:
La commande SHOW USERS limitait la sortie SQL à 10 000 lignes et ne prenait en charge que la syntaxe suivante :
SHOW USERS [ LIKE '<pattern>' ]
- Actuellement:
La commande SHOW USERS peut être utilisée pour renvoyer plus de 10 000 lignes. Elle prend en charge la syntaxe suivante :
SHOW [ TERSE ] USERS [ LIKE '<pattern>' ] [ STARTS WITH '<name_string>' ] [ LIMIT <rows> [ FROM '<name_string>' ] ]
Où :
TERSE
ne renvoie de façon facultative que le sous-ensemble suivant des colonnes de sortie :name, created_on, display_name, first_name, last_name, email, org_identity, comment, has_password, has_rsa_public_key.
Par défaut : aucune valeur (toutes les colonnes sont incluses dans la sortie).
STARTS WITH 'name_string'
(Facultatif) Filtre la sortie de commande en fonction des caractères qui apparaissent au début du nom de l’objet. La chaîne doit être délimitée par des guillemets simples et est sensible à la casse. Par exemple, les clauses suivantes renvoient des résultats différents :... STARTS WITH 'B' ...
... STARTS WITH 'b' ...
Par défaut : aucune valeur (aucun filtrage n’est appliqué à la sortie).
LIMIT rows [ FROM 'name_string' ]
(Facultatif) Limite le nombre maximum de lignes retournées, tout en permettant la « pagination » des résultats. Notez que le nombre réel de lignes retournées peut être inférieur à la limite spécifiée (par exemple, le nombre d’objets existants est inférieur à la limite spécifiée).La sous-clause facultative
FROM 'name_string'
sert effectivement de « curseur » pour les résultats. Ceci permet de récupérer le nombre spécifié de lignes suivant la première ligne dont le nom d’objet correspond à la chaîne spécifiée :La chaîne doit être délimitée par des guillemets simples et est sensible à la casse. De plus, la chaîne n’a pas besoin d’inclure le nom complet de l’objet ; les noms partiels sont pris en charge.
Par défaut : aucune valeur (aucune limite n’est appliquée à la sortie).
Par défaut, SHOW USERS renvoie toujours les 10 000 lignes comme auparavant. Si votre compte a plus de 10 000 utilisateurs, vous pouvez exécuter la commande deux fois pour retourner les utilisateurs au-dessus de la limite de 10 000 :
SHOW USERS; SHOW USERS LIMIT 10000 FROM 'JOE';
La première instruction renvoie les 10 000 premiers utilisateurs. La dernière ligne renvoyée est un utilisateur avec le nom d’utilisateur
JOE
.La deuxième instruction renvoie les 10 000 utilisateurs suivants après
JOE
.
Fonctions SYSTEM$EXTERNAL_TABLE_PIPE_STATUS et SYSTEM$PIPE_STATUS : détails supplémentaires dans la sortie JSON¶
La sortie JSON des fonctions SYSTEM$EXTERNAL_TABLE_PIPE_STATUS et SYSTEM$PIPE_STATUS comprend maintenant les paires nom/valeur de chaînes supplémentaires suivantes pour améliorer la compréhension des chargements de données spécifiques, y compris les erreurs rencontrées pendant les chargements :
Nom |
Description |
Remarques |
---|---|---|
|
Chemin du fichier de données le plus ancien actuellement en attente de traitement. L’horodatage lorsque le fichier a été ajouté à la file d’attente est renvoyé dans la propriété oldestFileTimestamp existante. |
|
|
Horodatage lorsque le fichier le plus récent a été chargé avec succès par Snowpipe dans la table de destination. |
SYSTEM$PIPE_STATUS seulement. |
|
Chemin du fichier chargé à l’heure (horodatage) spécifiée dans lastIngestedTimestamp. |
SYSTEM$PIPE_STATUS seulement. |
|
Horodatage lorsque la compilation de l’instruction COPY INTO dans la définition du canal pour l’exécution a produit une erreur pour la dernière fois. |
SYSTEM$PIPE_STATUS seulement. |
|
Horodatage de la dernière détection d’une erreur interne liée au processus Snowflake. |
|
|
Horodatage du moment où Snowpipe a récupéré pour la dernière fois les notifications d’événement « create object » pour le canal depuis de la file d’attente Amazon Simple Queue Service (SQS), de la file d’attente Google Pub/Sub ou de la file d’attente de stockage Microsoft Azure. |
|
|
Chemin du fichier de données identifié dans le dernier message d’événement « create object » qui a été transmis au canal. |
Les exemples suivants montrent des exemples de sorties pour des problèmes courants rencontrés par Snowpipe. Les détails supplémentaires dans la sortie de la fonction peuvent vous aider à diagnostiquer ces problèmes et d’autres problèmes liés à vos chargements de données :
La file d’attente des notifications est mal configurée :
{"executionState":"RUNNING","pendingFileCount":0,"notificationChannelName":"projects/myproject/subscriptions/mysubscription","numOutstandingMessagesOnChannel":0,"lastPulledFromChannelTimestamp:"2022-01-20T06:24:44.771Z"}
Snowpipe tente d’extraire périodiquement les notifications d’événements « create object » pour le canal à partir de la file d’attente Amazon Simple Queue Service (SQS), de la file d’attente Google Pub/Sub ou de la file d’attente de stockage Microsoft Azure. Une valeur
lastPulledFromChannelTimestamp
manquante ou obsolète indique que Snowpipe n’a pas été en mesure de se connecter à la file d’attente de stockage.Si l’horodatage
lastPulledFromChannelTimestamp
est récent, mais quenumOutstandingMessagesOnChannel
est0
, alors Snowpipe peut recevoir des notifications d’événements de la file d’attente, mais aucune notification n’a été mise en file d’attente. Ce dernier problème peut se produire lorsqu’aucun fichier de données n’a été créé dans l’emplacement de stockage ou que la mise en file d’attente est mal configurée.Problème d’autorisation liée à la file d’attente des notifications :
{"executionState":"RUNNING","pendingFileCount":0,"lastIngestedTimestamp":"2022-01-20T04:30:02.518Z","lastIngestedFilePath":"myfile.csv","notificationChannelName":"projects/myproject/subscriptions/mysubscription","numOutstandingMessagesOnChannel":1,"lastReceivedMessageTimestamp":"2022-01-20T04:30:02.319Z","lastForwardedMessageTimestamp":"2022-01-20T04:30:03.27Z","channelErrorMessage":"no monitoring permission: numOutstandingMessagesOnChannel is not accurate","lastErrorRecordTimestamp":"2022-01-20T04:44:08.461Z","lastPulledFromChannelTimestamp":"2022-01-20T04:44:08.461Z","lastForwardedFilePath":"mypath/myfile.csv"}
La valeur
channelErrorMessage
indique que Snowflake n’a pas reçu les autorisations suffisantes pour accéder à la file d’attente de stockage et récupérer les notifications d’événements.Incohérence entre les chemins spécifiés dans la définition du canal et la configuration des notifications d’événements :
{"executionState":"RUNNING","pendingFileCount":0,"lastIngestedTimestamp":"2022-01-20T06:00:01.669Z","lastIngestedFilePath":"myfile.csv","notificationChannelName":"projects/myproject/subscriptions/mysubscription","numOutstandingMessagesOnChannel":1,"lastReceivedMessageTimestamp":"2022-01-20T06:04:01.089Z","lastForwardedMessageTimestamp":"2022-01-20T06:00:02.741Z","lastPulledFromChannelTimestamp":"2022-01-20T06:05:28.49Z","lastForwardedFilePath":"mypath/myfile.csv"}
L’horodatage
lastForwardedMessageTimestamp
est antérieur àlastReceivedMessageTimestamp
. Cela indique que Snowpipe a récupéré au moins un message d’événement « create object » de la file d’attente de stockage, mais que le message ne correspondait pas au chemin défini dans le canal et n’a donc pas été transmis au canal pour être traité.Problème d’autorisation d’emplacement de stockage externe :
{"executionState":"STALLED_STAGE_PERMISSION_ERROR","pendingFileCount":0,"error":"Failed to access the stage, please check storage permission.", "lastPipeErrorTimestamp":"2022-01-20T04:40:01.747Z", "lastIngestedTimestamp":"2022-01-20T04:30:02.518Z","lastIngestedFilePath":"myfile.csv","notificationChannelName":"projects/myproject/subscriptions/mysubscription","numOutstandingMessagesOnChannel":1,"lastReceivedMessageTimestamp":"2022-01-20T04:30:02.319Z","lastForwardedMessageTimestamp":"2022-01-20T04:30:03.27Z","channelErrorMessage":"no monitoring permission: numOutstandingMessagesOnChannel is not accurate","lastErrorRecordTimestamp":"2022-01-20T04:44:08.461Z","lastPulledFromChannelTimestamp":"2022-01-20T04:39:58.494Z","lastForwardedFilePath":"mypath/myfile.csv"}
La valeur
executionState
et le message d’erreur indiquent que Snowflake n’a pas reçu les autorisations minimales relatives à l’emplacement de stockage (c’est-à-dire un compartiment Amazon S3 ou Google Cloud Storage ou un conteneur Microsoft Azure) pour accéder aux fichiers de données dans l’emplacement de stockage.Erreur de compilation de l’instruction COPY INTO <table> dans la définition du canal :
{"executionState":"STALLED_COMPILATION_ERROR","pendingFileCount":0,"error":"SQL compilation error: error line 1 at position 29\ninvalid identifier 'LAST_NAME'",", "lastPipeErrorTimestamp":"2022-01-20T17:54:30.4Z", "lastIngestedTimestamp":"2022-01-20T17:51:04.73Z","lastIngestedFilePath":"myfile.csv","notificationChannelName":"projects/myproject/subscriptions/mysubscription","numOutstandingMessagesOnChannel":1,"lastReceivedMessageTimestamp":"2022-01-20T17:51:03.336Z","lastForwardedMessageTimestamp":"2022-01-20T17:51:05.081Z","lastPulledFromChannelTimestamp":"2022-01-20T18:03:00.637Z","lastForwardedFilePath":"mypath/myfile.csv"}
La valeur
executionState
et le message d’erreur indiquent que Snowpipe n’a pas pu exécuter l’instruction COPY INTO <table> dans la définition du canal pour charger les fichiers de données récupérés dans l’emplacement de stockage.
Changements SQL — Vues d’utilisation et Information Schema¶
Vue FUNCTIONS : nouvelles colonnes¶
Les colonnes suivantes ont été ajoutées à la vue ACCOUNT_USAGE.FUNCTIONS pour la rendre cohérente avec la vue INFORMATION_SCHEMA.FUNCTIONS :
handler
imports
target_path
Pour aider à limiter l’impact de ce changement, les nouvelles colonnes ont été ajoutées en tant que dernières colonnes dans la vue.
Vue FUNCTIONS, DESCRIBE FUNCTION et fonction GET_DDL : nouvelles colonnes¶
Les colonnes suivantes ont été ajoutées à la vue INFORMATION_SCHEMA.FUNCTIONS, ainsi que la sortie de la commande DESCRIBE FUNCTION et de la fonction GET_DDL :
request_translator
: le nom de la fonction définie par l’utilisateur JavaScript du traducteur de requêtes, si elle existe.response_translator
: le nom de la fonction définie par l’utilisateur JavaScript du traducteur de réponse, si elle existe.
Les traducteurs de requêtes et de réponses vous permettent de modifier le format des données envoyées vers et depuis les services distants utilisés par des fonctions externes. Pour plus d’informations, voir Utilisation de traducteurs de requêtes et de réponses avec des données pour un service distant.
Fonction POLICY_REFERENCES : nouvelles colonnes¶
La colonne created_on
a été supprimée de la sortie de la fonction de table INFORMATION_SCHEMA.POLICY_REFERENCES.
Les colonnes suivantes ont été ajoutées à la sortie de la fonction de table INFORMATION_SCHEMA.POLICY_REFERENCES :
tag_name
tag_database
tag_schema
policy_status
Ces nouvelles colonnes peuvent être utilisées pour découvrir les associations de politiques sur une colonne par le nom de la balise.
Pour aider à limiter l’impact de ce changement, ces nouvelles colonnes ont été ajoutées en tant que dernières colonnes dans la sortie.
Fonction TASK_HISTORY : historique d’utilisation de la tâche renvoyé pour les 7 jours précédents par défaut¶
Le comportement de la fonction de table INFORMATION_SCHEMA.TASK_HISTORY a été modifié comme suit :
- Précédemment:
Par défaut, la fonction renvoyait des enregistrements pour les exécutions de tâches historiques dans une plage de temps qui n’a pas de date ou d’heure de début déterminée. En raison d’une activité interne de nettoyage des données, la période était généralement limitée aux 14 jours précédents ; cependant, dans de rares circonstances, la période pouvait s’étendre plus loin dans le passé.
Si l’argument SCHEDULED_TIME_RANGE_START était spécifié dans une requête, la période était limitée aux enregistrements historiques des 7 jours précédents ou moins.
- Actuellement:
La fonction renvoie les enregistrements des tâches historiques qui ont commencé au cours des 7 jours précédents.
Notez que, comme pour le comportement précédent, si l’argument SCHEDULED_TIME_RANGE_START est spécifié dans une requête, la période continue à être limitée aux enregistrements historiques des 7 jours précédents ou moins.
Vue/fonction TASK_HISTORY : nouvelle colonne¶
La colonne suivante a été ajoutée à la sortie de la vue ACCOUNT_USAGE.TASK_HISTORY et de la fonction de table INFORMATION_SCHEMA.TASK_HISTORY :
scheduled_from
: spécifie le mécanisme qui a provoqué l’exécution de la tâche. La seule valeur renvoyée dans la colonne estSCHEDULE
. Cette valeur indique que l’exécution de la tâche a été lancée par la planification dans la définition de la tâche. Pour les exécutions de tâches enfants dans une arborescence de tâches, la colonne renvoie égalementSCHEDULE
.
Cette colonne a été introduite pour prendre en charge les fonctionnalités futures.
Vues d’entrepôt : sortie cohérente pour le nom de l’entrepôt¶
Le propriétaire d’un entrepôt (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur l’entrepôt) ou un rôle supérieur peut renommer l’entrepôt à l’aide de la nouvelle interface Web ou de la commande ALTER WAREHOUSE …. RENAME.
Le comportement lorsqu’un entrepôt est renommé a été modifié comme suit :
- Précédemment:
Le nom de l’entrepôt était affiché de manière incohérente dans les colonnes de vues suivantes :
ACCOUNT_USAGE, READER_ACCOUNT_USAGE et ORGANIZATION_USAGE
WAREHOUSE_METERING_HISTORY.WAREHOUSE_HAME
ACCOUNT_USAGE
METERING_HISTORY.NAME
Les enregistrements récents dans les vues (2-3 heures avant la modification du nom de l’entrepôt) affichaient le nouveau nom ; en revanche, les enregistrements plus anciens affichaient l’ancien nom.
- Actuellement:
Les colonnes WAREHOUSE_NAME et NAME de ces vues affichent le nouveau nom de l’entrepôt pour tous les enregistrements.
Note
Ce changement de comportement n’affecte pas les vues et fonctions de table suivantes, qui affichent déjà le nouveau nom de l’entrepôt pour tous les enregistrements de la colonne WAREHOUSE_NAME :
ACCOUNT_USAGE
Vue WAREHOUSE_EVENTS_HISTORY
Vue WAREHOUSE_LOAD_HISTORY
INFORMATION_SCHEMA
Fonction de table WAREHOUSE_LOAD_HISTORY
Fonction de table WAREHOUSE_METERING_HISTORY
Modifications de l’extensibilité¶
Procédures stockées JavaScript : changements dans la gestion des erreurs¶
La gestion des erreurs pour les procédures stockées écrites en JavaScript a été modifiée comme suit :
- Précédemment:
Toutes les erreurs levées par les procédures stockées JavaScript avaient le même code d’erreur et
SQLSTATE
(100183
etP0000
respectivement) et le même message d’erreur générique ("Execution error in stored procedure SP_NAME..."
).Le nom de la propriété pour accéder à la trace de pile était
stackTraceTxt
.Par exemple, si un objet de base de données n’existe pas, l’objet d’exception contient ce qui suit :
{ "stackTraceTxt":"At Statement.execute, line 12 position 19", "state":"P0000", "code":100183, "message":"SQL compilation error:\nObject 'X' does not exist or not authorized." }
Si votre procédure stockée n’avait pas capturé l’exception, l’appel de la procédure stockée produisait le résultat suivant :
100183 (P0000): Execution error in store procedure ...: SQL compilation error: Object 'X' does not exist or not authorized. At Statement.execute, line 12 position 19
- Actuellement:
Si la procédure stockée exécute des requêtes (comme le font la plupart des procédures stockées) et si l’erreur se produit pendant l’exécution de la requête enfant, le code d’erreur et
SQLSTATE
de la requête enfant sont utilisés.En outre, le nom de la propriété permettant d’accéder à la trace de pile a été remplacé par
stack
. Bien que la propriétéstackTraceTxt
soit toujours présente avec le changement de comportement activé,stackTraceTxt
sera supprimé dans une prochaine version.Par exemple, si un objet de base de données n’existe pas, l’objet d’exception contient ce qui suit :
{ "stack":"Statement.execute, line 12 position 19", "stackTraceTxt":"Statement.execute, line 12 position 19", // To be removed in a future release "state":"42S02", "code":2003, "message":"SQL compilation error:\nObject 'X' does not exist or not authorized." }
Si votre procédure stockée ne capture pas l’exception, l’appel de la procédure stockée produit le résultat suivant :
002003 (42S02): Execution error in store procedure ...: SQL compilation error: Object 'X' does not exist or not authorized. At Statement.execute, line 12 position 19