CREATE ALERT

Crée une nouvelle alerte dans le schéma actuel.

Cette commande prend également en charge la variante suivante :

  • CREATE ALERT … CLONE (crée un clone d’une alerte existante)

Voir aussi :

ALTER ALERT , DESCRIBE ALERT, DROP ALERT , SHOW ALERTS , EXECUTE ALERT

Important

Les alertes nouvellement créées ou clonées sont suspendues dès leur création. Pour plus d’informations sur la reprise des alertes suspendues, consultez Suspension et reprise d’une alerte.

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>
Copy

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.

Note

Lorsque vous clonez une alerte en utilisant CREATE ALERT <nom> CLONE ou en clonant un schéma ou une base de données contenant l’alerte, la nouvelle alerte possède toutes les propriétés de l’alerte d’origine, à l’exception de celles que vous remplacez explicitement.

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.

WAREHOUSE = warehouse_name

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

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 de détails 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 :

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 par e-mail, vous pouvez appeler la procédure stockée SYSTEM$SEND_EMAIL().

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

Un rôle utilisé pour exécuter cette commande SQL doit avoir les privilèges suivants définis au minimum ainsi :

Privilège

Objet

Remarques

EXECUTE ALERT

Compte

CREATE ALERT

Schéma

USAGE

Entrepôt

Requis sur l’entrepôt utilisé pour l’alerte.

Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.

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.