ALTER ALERT¶

Modifie les propriétés d’une alerte existante et suspend ou reprend une alerte existante.

Voir aussi :: CREATE ALERT , DESCRIBE ALERT, DROP ALERT , SHOW ALERTS , EXECUTE ALERT

Syntaxe¶

ALTER ALERT [ IF EXISTS ] <name> { RESUME | SUSPEND };

ALTER ALERT [ IF EXISTS ] <name> SET
  [ WAREHOUSE = <string> ]
  [ SCHEDULE = '{ <number> MINUTE | USING CRON <expr> <time_zone> }' ]
  [ COMMENT = '<string_literal>' ]

ALTER ALERT [ IF EXISTS ] <name> SET TAG <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' ... ]

ALTER ALERT [ IF EXISTS ] <name> UNSET
  [ WAREHOUSE ]
  [ COMMENT ]

ALTER ALERT <name> UNSET TAG <tag_name> [ , <tag_name> ... ]

ALTER ALERT [ IF EXISTS ] <name> MODIFY CONDITION EXISTS (<condition>)

ALTER ALERT [ IF EXISTS ] <name> MODIFY ACTION <action>

Copy

Paramètres¶

name

Identificateur de l’alerte à modifier. Si l’identificateur contient des espaces ou des caractères spéciaux, toute la chaîne doit être délimitée par des guillemets doubles. Les identificateurs entre guillemets doubles sont également sensibles à la casse.

{ RESUME | SUSPEND }

Spécifie l’action à effectuer sur l’alerte :

RESUME rend active une alerte suspendue.
SUSPEND met l’alerte dans un état « suspendu ».

Si la planification de la tâche est définie sur un intervalle (c’est-à-dire num MINUTE), pour éviter toute ambiguïté, l’intervalle de base de la planification est réinitialisé à l’heure actuelle lorsque la tâche est reprise.

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 l’alerte s’exécute à 9:13 AM, 9:23 AM, et ainsi de suite. Notez que nous faisons de notre mieux pour assurer une précision absolue, mais nous garantissons uniquement que les alertes ne s’exécutent pas avant leur intervalle défini (par exemple, dans cet exemple, l’alerte pourrait d’abord être exécutée à 9:14 AM, mais ne fonctionnera certainement pas à 9:12 AM).

SET ...

Spécifie une ou plusieurs propriétés à définir pour l’alerte (séparées par des espaces, des virgules ou des sauts de ligne).

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é.

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).

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.

UNSET ...

Spécifie un(e) ou plusieurs propriétés/paramètres à désactiver pour l’alerte, ce qui les réinitialise à leurs valeurs par défaut :

WAREHOUSE
COMMENT
TAG tag_key [ , tag_key ... ]

MODIFY CONDITION EXISTS (condition)

Spécifie l’instruction SQL qui doit représenter 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.

MODIFY ACTION action

Spécifie 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.

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

L’exécution de cette commande SQL nécessite les rôles avec au minimum les privilèges suivants :

Pour reprendre une alerte :
- Le rôle qui exécute ALTER ALERT doit avoir le privilège OPERATE ou OWNERSHIP sur l’alerte.
- Le rôle doté du privilège OWNERSHIP sur l’alerte doit également disposer des privilèges suivants :
  - Le privilège EXECUTE ALERT global.
  - Le privilège EXECUTE MANAGED ALERT global, si l’alerte est une alerte sans serveur.
  - Le privilège USAGE sur l’entrepôt, si l”alerte utilise un entrepôt spécifié.
Pour suspendre une alerte, le rôle qui exécute ALTER ALERT doit avoir le privilège OPERATE ou OWNERSHIP sur l’alerte.
Pour modifier les propriétés de l’alerte, le rôle qui exécute ALTER ALERT doit avoir le privilège OWNERSHIP sur l’alerte.

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¶

Lorsqu’une alerte est reprise, Snowflake vérifie que le rôle avec le privilège OWNERSHIP sur l’alerte possède également le privilège USAGE sur l’entrepôt affecté à l’alerte, ainsi que le privilège global EXECUTE ALERT ; sinon, une erreur se produit.
Seuls les administrateurs de compte (utilisateurs dotés du rôle ACCOUNTADMIN) peuvent accorder le privilège EXECUTE ALERT à un rôle. Pour faciliter l’utilisation, nous vous recommandons de créer un rôle personnalisé (par exemple, alert_admin) et d’attribuer le privilège EXECUTE ALERT à ce rôle. Tout rôle pouvant octroyer des privilèges (par exemple, SECURITYADMIN ou n’importe quel rôle disposant du privilège MANAGE GRANTS) peut ensuite attribuer ce rôle personnalisé à tout rôle de propriétaire d’alerte afin de permettre la modification de ses propres alertes. Pour obtenir des instructions sur la création de rôles personnalisés et de hiérarchies de rôles, voir Configuration du contrôle d’accès.

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.

Exemples¶

Voir Suspension et reprise d’une alerte.