ALTER ALERT

Snowflake logo in black (no text) Fonctionnalité en avant-première — En accès libre

Disponible pour tous les comptes.

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

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

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

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). Pour plus de détails sur les propriétés que vous pouvez définir, voir CREATE ALERT.

UNSET ...

Spécifie une ou plusieurs propriétés et/ou paramètres de session à désactiver pour l’alerte, ce qui les réinitialise aux valeurs par défaut.

Vous pouvez réinitialiser plusieurs propriétés/paramètres avec une seule instruction ALTER ; cependant, chaque propriété/paramètre doit être séparé(e) par une virgule. Lors de la réinitialisation d’une propriété ou d’un paramètre, spécifiez seulement le nom ; si vous spécifiez une valeur pour la propriété/le paramètre, vous obtiendrez une erreur.

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

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 doté du privilège OWNERSHIP sur l’alerte doit également disposer du privilège global EXECUTE ALERT.

    • Le rôle qui exécute ALTER ALERT doit avoir le privilège OPERATE ou OWNERSHIP sur l’alerte.

  • Pour suspendre une alerte, le rôle qui exécute ALTER ALERT doit avoir le privilège OPERATOR 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.

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

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

Langage: Français