CREATE ALERT¶

Syntaxe¶

CREATE [ OR REPLACE ] ALERT [ IF NOT EXISTS ] <name>
  [ WAREHOUSE = <warehouse_name> ]
  SCHEDULE = '{ <num> MINUTE | USING CRON <expr> <time_zone> }'
  COMMENT = '<string_literal>'
  [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' , ... ] ) ]
  IF( EXISTS(
    <condition>
  ))
  THEN
    <action>

Syntaxe des variantes¶

CREATE ALERT … CLONE

Crée une nouvelle alerte avec les mêmes valeurs de paramètre :

CREATE [ OR REPLACE ] ALERT <name> CLONE <source_alert>
  [ ... ]

Copy

Pour plus de détails, voir CREATE <objet> … CLONE.

Paramètres requis¶

name

Chaîne qui indique l’identificateur (c’est-à-dire le nom) de l’alerte ; doit être unique pour le schéma dans lequel l’alerte est créée.

De plus, l’identificateur doit commencer par un caractère alphabétique et ne peut pas contenir d’espaces ou de caractères spéciaux à moins que toute la chaîne d’identificateur soit délimitée par des guillemets doubles (p. ex. "My object"). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

Pour plus de détails, voir Exigences relatives à l’identificateur.

SCHEDULE ...

Spécifie la planification de l’évaluation périodique de la condition de l’alerte.

Vous pouvez spécifier la planification de l’une des manières suivantes :

• USING CRON expr time_zone

  Spécifie une expression cron et un fuseau horaire pour évaluer périodiquement la condition de l’alerte. Prend en charge un sous-ensemble de la syntaxe standard de l’utilitaire cron.

  L’expression cron comprend les champs suivants :

  # __________ minute (0-59)
  # | ________ hour (0-23)
  # | | ______ day of month (1-31, or L)
  # | | | ____ month (1-12, JAN-DEC)
  # | | | | _ day of week (0-6, SUN-SAT, or L)
  # | | | | |
  # | | | | |
    * * * * *
  

  Copy

  Les caractères spéciaux suivants sont acceptés :

  Caractère spécial	Description
  *	Caractère générique. Lorsqu’elle est spécifiée pour un champ donné, l’alerte s’exécute à chaque unité de temps pour ce champ. Par exemple, * dans le champ mois spécifie que l’alerte est lancée tous les mois.
  L	Signifie « dernier ». Lorsqu’il est utilisé dans le champ du jour de la semaine, il vous permet de spécifier des constructions telles que « le dernier vendredi » (« 5L ») d’un mois donné. Dans le champ du mois, il spécifie le dernier jour du mois.
  /n	Indique la n ième instance d’une unité de temps donnée. Chaque quanta de temps est calculé indépendamment. Par exemple, si 4/3 est spécifié dans le champ du mois, l’évaluation est planifiée pour avril, juillet et octobre (c’est-à-dire tous les 3 mois, à partir du 4e mois de l’année). Le même calendrier est maintenu les années suivantes. En d’autres termes, la réévaluation n’est pas prévue en janvier (3 mois après l’exécution d’octobre).

  Note

  • L’expression cron est actuellement évaluée par rapport au fuseau horaire spécifié. La modification de la valeur du paramètre TIMEZONE pour le compte (ou la définition de la valeur au niveau de l’utilisateur ou de la session) ne modifie pas le fuseau horaire de l’alerte.

  • L’expression cron définit tous les moments valides pour l’évaluation de la condition de l’alerte. Snowflake tente d’évaluer la condition en fonction de cette planification. Toutefois, toute heure d’exécution valide est ignorée si une exécution précédente n’a pas été terminée avant le début de la prochaine heure d’exécution valide.

  • Lorsqu’un jour de mois et un jour de semaine spécifiques sont inclus dans l’expression cron, l’évaluation de la condition est planifiée les jours satisfaisant le jour du mois ou le jour de la semaine. Par exemple, SCHEDULE = 'USING CRON 0 0 10-20 * TUE,THU UTC' planifie une évaluation à 0AM entre le 10e et le 20e jour du mois ainsi que le mardi ou le jeudi en dehors de ces dates.

• num MINUTE

  Spécifie un intervalle (en minutes) de temps d’attente inséré entre les évaluations de l’alerte Accepte uniquement les entiers positifs.

  Prend également en charge la syntaxe num M.

  Pour éviter toute ambiguïté, un intervalle de base est défini lorsque l’alerte est reprise (à l’aide de ALTER ALERT … RESUME).

  L’intervalle de base démarre le compteur d’intervalle à partir de l’heure actuelle. Par exemple, si une alerte est créée avec 10 MINUTE et que l’alerte est reprise à 9:03 AM, alors la condition de l’alerte est évaluée à 9:13 AM, 9:23 AM, et ainsi de suite. Notez que nous nous efforçons d’assurer une précision absolue, mais que nous garantissons uniquement que les conditions ne sont pas évaluées avant leur intervalle de consigne (par exemple, dans l’exemple actuel, la condition pourrait être évaluée d’abord à 9:14 AM mais certainement pas à 9:12 AM).

  Note

  La valeur maximale prise en charge est 11520 (8 jours). Les conditions des alertes dont la valeur num MINUTE est supérieure ne sont jamais évaluées.

COMMENT = 'string_literal'

Spécifie un commentaire pour l’alerte.

TAG ( tag_name = 'tag_value' [ , tag_name = 'tag_value' , ... ] )

Spécifie le nom de la balise et la valeur de la chaîne de la balise.

La valeur de la balise est toujours une chaîne de caractères et le nombre maximum de caractères pour la valeur de la balise est 256.

Pour plus d’informations sur la spécification des balises dans une instruction, voir Quotas de balises pour les objets et les colonnes.

IF( EXISTS( condition ))

L’instruction SQL qui représente la condition de l’alerte. Vous pouvez utiliser les commandes suivantes :

• SELECT

• SHOW <objets>

• CALL

Si l’instruction renvoie une ou plusieurs lignes, l’action relative à l’alerte est exécutée.

THEN action

L’instruction SQL qui doit être exécutée si la condition renvoie une ou plusieurs lignes.

Pour envoyer une notification, vous pouvez appeler la procédure stockée SYSTEM$SEND_EMAIL ou SYSTEM$SEND_SNOWFLAKE_NOTIFICATION.

Paramètres facultatifs¶

WAREHOUSE = warehouse_name

Spécifie l’entrepôt virtuel qui fournit les ressources de calcul pour l’exécution de cette alerte.

Pour les alertes sans serveur, ne définissez pas cette propriété.

Exigences en matière de contrôle d’accès¶

Un rôle utilisé pour exécuter cette opération doit au minimum disposer des privilèges suivants :

Le privilège USAGE relatif à la base de données et au schéma parents est exigé pour effectuer des opérations sur tout objet d’un schéma.

Pour obtenir des instructions sur la création d’un rôle personnalisé avec un ensemble spécifique de privilèges, voir Création de rôles personnalisés.

Pour des informations générales sur les rôles et les privilèges accordés pour effectuer des actions SQL sur des objets sécurisables, voir Aperçu du contrôle d’accès.

Notes sur l’utilisation¶

• Les tâches s’exécutent en utilisant les privilèges accordés au propriétaire de l’alerte (c’est-à-dire le rôle qui possède le privilège OWNERSHIP sur l’alerte). Pour obtenir la liste des privilèges minimums requis pour exécuter les alertes, voir Attribution de privilèges pour créer des alertes.

  Pour vérifier que le rôle de propriétaire d’alerte dispose des privilèges requis pour exécuter les instructions SQL pour la condition et l’action, nous vous recommandons d’exécuter ces instructions en utilisant le rôle de propriétaire d’alerte avant de les spécifier dans CREATE ALERT.

• Lorsque vous créez une alerte, celle-ci est suspendue par défaut.

  Pour rendre l’alerte active, vous devez exécuter ALTER ALERT … RESUME.

• Lorsque vous exécutez CREATE ALERT ou ALTER ALERT, certains contrôles de validation ne sont pas effectués sur les instructions de la condition et de l’action, notamment :

  • La résolution des identificateurs d’objets.

  • La résolution des types de données des expressions.

  • La vérification du nombre et des types d’arguments dans un appel de fonction.

  Les commandes CREATE ALERT et ALTER ALERT n’échouent pas si l’instruction SQL d’une condition ou d’une action spécifie un identificateur non valide, un type de données incorrect, un nombre et des types d’arguments de fonction incorrects, etc. Au lieu de cela, l’échec se produit lorsque l’alerte s’exécute.

  Pour vérifier les échecs d’une alerte existante, utilisez la fonction de table ALERT_HISTORY.

  Pour éviter ce type d’échec, avant de spécifier les conditions et les actions pour les alertes, vérifiez les expressions et les instructions SQL pour ces conditions et ces actions.

• Concernant les métadonnées :

  Attention

  Les clients doivent s’assurer qu’aucune donnée personnelle (autre que pour un objet utilisateur), donnée sensible, donnée à exportation contrôlée ou autre donnée réglementée n’est saisie comme métadonnée lors de l’utilisation du service Snowflake. Pour plus d’informations, voir Champs de métadonnées dans Snowflake.

• Les instructions CREATE OR REPLACE <objet> sont atomiques. En d’autres termes, lorsqu’un objet est remplacé, l’ancien objet est supprimé et le nouvel objet est créé dans une seule transaction.

Exemples¶

Voir Création d’une alerte.

Interfaces alternatives¶

• Snowflake REST APIs

  • Créer un point de terminaison d’alerte

• Snowflake Python APIs

  • Méthode alert.AlertCollection.create

• Snowflake CLI

  • Non pris en charge