ALTER ALERT

Ändert die Eigenschaften eines bestehenden Alerts und unterbricht einen bestehenden Alert bzw. setzt diesen fort.

Siehe auch:

CREATE ALERT , DESCRIBE ALERT, DROP ALERT , SHOW ALERTS , EXECUTE ALERT

Syntax

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

Parameter

name

Bezeichner für den zu ändernden Alert. Wenn der Bezeichner Leerzeichen oder Sonderzeichen enthält, muss die gesamte Zeichenfolge in doppelte Anführungszeichen gesetzt werden. Bei Bezeichnern, die in doppelte Anführungszeichen eingeschlossen sind, ist auch die Groß-/Kleinschreibung zu beachten.

{ RESUME | SUSPEND }

Gibt die Aktion an, die für den Alert ausgeführt werden soll:

  • RESUME aktiviert einen unterbrochenen Alerts.

  • SUSPEND versetzt den Alert in den Status „Unterbrochen“.

Wenn der Alert-Zeitplan auf ein Intervall (d. h. num MINUTE) festgelegt ist, wird die Basisintervallzeit des Zeitplans zum Zeitpunkt der Aktivierung des Alerts auf die aktuelle Zeit zurückgesetzt, um Mehrdeutigkeiten zu vermeiden.

Die Basisintervallzeit startet den Intervallzähler ab der aktuellen Uhrzeit. Wenn ein Alert beispielsweise mit dem Wert 10 MINUTE erstellt wird und der Alert um 9:03 Uhr aktiviert wird, dann wird die Warnung um 9:13 Uhr, 9:23 Uhr usw. ausgeführt. Beachten Sie, dass wir uns nach besten Kräften bemühen, absolute Präzision sicherzustellen, aber nur garantieren, dass Alerts nicht vor ihrem festgelegten Intervall ausgeführt werden (im aktuellen Beispiel könnte es sein, dass der Alert erst 9:14 Uhr ausgeführt wird, aber definitiv nicht 9:12 Uhr).

SET ...

Gibt eine (oder mehrere) Eigenschaften an, die für den Alert festgelegt werden sollen (getrennt durch Leerzeichen, Kommas oder Neue-Zeile-Zeichen):

WAREHOUSE = warehouse_name

Gibt das virtuelle Warehouse an, das Computeressourcen für das Ausführen dieses Alerts bereitstellt.

Legen Sie diese Eigenschaft bei serverlosen Alerts nicht fest.

SCHEDULE ...

Gibt den Zeitplan für die periodische Auswertung der Alert-Bedingung an.

Sie können den Zeitplan auf eine der folgenden Arten festlegen:

  • USING CRON expr time_zone

    Gibt einen Cron-Ausdruck und eine Zeitzone für die regelmäßige Auswertung der Alert-Bedingung an. Unterstützt eine Teilmenge der Standardsyntax des Cron-Dienstprogramms.

    Der Cron-Ausdruck besteht aus folgenden Feldern:

    # __________ 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

    Folgende Sonderzeichen werden unterstützt:

    Sonderzeichen

    Beschreibung

    *

    Platzhalter. Wenn Sie diesen in einem bestimmten Feld angeben, wird der Alert immer zu der Zeiteinheit dieses Feldes ausgeführt.

    Beispielweise wird durch Angabe von * im Feld „Monat“ festgelegt, dass der Alert jeden Monat ausgeführt wird.

    L

    Steht für „last“ (letzte). Bei Verwendung im Feld Wochentag können Sie Konstrukte wie „den letzten Freitag“ („5L“) eines bestimmten Monats angeben. Im Feld Tag des Monats wird der letzte Tag des Monats angegeben.

    /n

    Gibt die n-te Instanz einer bestimmten Zeiteinheit an. Jeder Zeitanteil wird unabhängig berechnet.

    Wenn beispielsweise im Monatsfeld 4/3 angegeben ist, ist die Auswertung der Bedingung für April, Juli und Oktober geplant (d. h. alle 3 Monate, beginnend mit dem 4. Monat des Jahres).

    In den Folgejahren wird derselbe Zeitplan beibehalten. Das heißt, die Bedingung ist nicht für eine Auswertung im Januar (3 Monate nach der Oktober-Ausführung) geplant.

    Bemerkung

    • Der Cron-Ausdruck wird derzeit nur für die angegebene Zeitzone ausgewertet. Das Ändern des TIMEZONE-Parameterwerts für das Konto (oder das Festlegen des Werts auf Benutzer- oder Sitzungsebene) führt nicht zur Änderung der Zeitzone des Alerts.

    • Der Cron-Ausdruck definiert alle gültigen Zeitpunkte für die Auswertung der Alert-Bedingung. Snowflake versucht, die Bedingung auf Basis dieses Zeitplans auszuwerten. Jede gültige Ausführungszeit wird jedoch übersprungen, wenn eine vorherige Ausführung nicht vor dem Start der nächsten gültigen Ausführung abgeschlossen wurde.

    • Wenn sowohl ein bestimmter Tag des Monats als auch ein bestimmter Wochentag im Cron-Ausdruck enthalten sind, wird die Aktualisierung an Tagen geplant, die entweder dem Tag des Monats oder dem Wochentag entsprechen. Beispielsweise plant SCHEDULE = 'USING CRON 0 0 10-20 * TUE,THU UTC' eine Auswertung um 0:00 Uhr an jedem 10. bis 20. Tag des Monats und auch an jedem Dienstag oder Donnerstag außerhalb dieser Tage.

  • num MINUTE

    Gibt ein Intervall (in Minuten) für die Wartezeit an, die zwischen Auswertungen der Alert-Bedingung eingefügt wird. Akzeptiert nur positive ganze Zahlen.

    Unterstützt auch die Syntax num M.

    Zur Vermeidung von Mehrdeutigkeiten wird eine Basisintervallzeit festgelegt, wenn der Alert aktiviert wird (mit ALTER ALERT … RESUME).

    Die Basisintervallzeit startet den Intervallzähler ab der aktuellen Uhrzeit. Wenn beispielsweise ein Alert mit dem Wert 10 MINUTE erstellt wird und der Alert um 9:03 Uhr aktiviert wird, dann wird die Bedingung des Alerts um 9:13 Uhr, 9:23 Uhr usw. ausgewertet. Beachten Sie, dass wir uns nach besten Kräften bemühen, absolute Präzision sicherzustellen, aber nur garantieren, dass die Bedingungen nicht vor ihrem festgelegten Intervall ausgewertet werden (im aktuellen Beispiel könnte es sein, dass die Auswertung erst 9:14 Uhr ausgeführt wird, aber definitiv nicht 9:12 Uhr).

    Bemerkung

    Der maximal unterstützte Wert ist 11520 (8 Tage). Bei Alerts mit einem größeren num MINUTE-Wert werden die Bedingungen nie ausgewertet.

COMMENT = 'string_literal'

Gibt einen Kommentar zu dem Alert an.

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

Gibt den Namen des Tags und den Wert der Tag-Zeichenfolge an.

Der Tag-Wert ist immer eine Zeichenfolge, die maximale 256 Zeichen lang sein kann.

Weitere Informationen zur Angabe von Tags in einer Anweisung finden Sie unter Tag-Kontingente für Objekte und Spalten.

UNSET ...

Gibt eine oder mehrere Eigenschaften/Parameter an, die für den Alert nicht festgelegt werden sollen, wodurch sie auf ihre Standardwerte zurückgesetzt werden:

  • WAREHOUSE

  • COMMENT

  • TAG tag_key [ , tag_key ... ]

MODIFY CONDITION EXISTS (condition)

Gibt die SQL-Anweisung an, die die Alert-Bedingung angeben soll. Sie können die folgenden Befehle verwenden:

Wenn die Anweisung eine oder mehrere Zeilen zurückgibt, wird die Aktion des Alerts ausgeführt.

MODIFY ACTION action

Gibt die SQL-Anweisung an, die ausgeführt werden soll, wenn die Bedingung eine oder mehrere Zeilen zurückgibt.

Um eine Benachrichtigung zu senden, können Sie die gespeicherte Prozedur SYSTEM$SEND_EMAIL oder SYSTEM$SEND_SNOWFLAKE_NOTIFICATION aufrufen.

Anforderungen an die Zugriffssteuerung

Das Ausführen dieses SQL-Befehls erfordert mindestens Rollen mit den folgenden Berechtigungen:

  • So setzen Sie einen Alert fort:

    • Die Rolle, die ALTER ALERT ausführt, muss entweder die Berechtigung OPERATE oder OWNERSHIP für den Alert haben.

    • Die Rolle mit der Berechtigung OWNERSHIP für den Alert muss auch folgende Berechtigungen haben:

      • Die globale Berechtigung EXECUTE ALERT

      • Die globale Berechtigung EXECUTE MANAGED ALERT, wenn es sich bei dem Alert um einen serverlosen Alert handelt.

      • Die Berechtigung USAGE für das Warehouse, wenn der Alert ein bestimmtes Warehouse verwendet.

  • Um einen Alert zu unterbrechen, muss die Rolle, die ALTER ALERT ausführt, entweder die Berechtigung OPERATE oder OWNERSHIP für den Alert haben.

  • Um die Eigenschaften des Alerts ändern zu können, muss die Rolle, die ALTER ALERT ausführt, die Berechtigung OWNERSHIP für den Alert haben.

Beachten Sie, dass für die Bearbeitung eines Objekts in einem Schema auch die Berechtigung USAGE für die übergeordnete Datenbank und das Schema erforderlich ist.

Eine Anleitung zum Erstellen einer kundenspezifischen Rolle mit einer bestimmten Gruppe von Berechtigungen finden Sie unter Erstellen von kundenspezifischen Rollen.

Allgemeine Informationen zu Rollen und Berechtigungen zur Durchführung von SQL-Aktionen auf sicherungsfähigen Objekten finden Sie unter Übersicht zur Zugriffssteuerung.

Nutzungshinweise

  • Wenn ein Alert fortgesetzt wird, überprüft Snowflake, ob die Rolle mit der Berechtigung OWNERSHIP für den Alert auch die Berechtigung USAGE für das dem Alert zugewiesene Warehouse sowie die globale Berechtigung EXECUTE ALERT hat. Wenn nicht, wird ein Fehler erzeugt.

  • Nur Kontoadministratoren (d. h. Benutzer mit der Rolle ACCOUNTADMIN) können einer Rolle die Berechtigung EXECUTE ALERT erteilen. Zur Vereinfachung der Verwendung empfehlen wir das Erstellen einer kundenspezifischen Rolle (z. B. „alert_admin“) und das Zuweisen der Berechtigung EXECUTE ALERT zu dieser Rolle. Jede Rolle, die Berechtigungen erteilen kann (z. B. SECURITYADMIN oder jede Rolle mit der Berechtigung MANAGE GRANTS) kann diese kundenspezifische Rolle dann jeder Alert-Eigentümerrolle zuweisen, um das Ändern der eigenen Alerts zuzulassen. Eine Anleitung zum Erstellen von kundenspezifischen Rollen und Rollenhierarchien finden Sie unter Konfigurieren der Zugriffssteuerung.

  • Wenn Sie CREATE ALERT oder ALTER ALERT ausführen, werden einige Validierungsprüfungen für die Anweisungen in der Bedingung und der Aktion nicht durchgeführt, einschließlich:

    • Auflösung der Bezeichner für Objekte

    • Auflösung der Datentypen von Ausdrücken

    • Überprüfung von Anzahl und Typen der Argumente eines Funktionsaufrufs

    Die Befehle CREATE ALERT und ALTER ALERT schlagen nicht fehl, wenn die SQL-Anweisung für eine Bedingung oder Aktion einen ungültigen Bezeichner, einen falschen Datentyp, eine falsche Anzahl und Art von Funktionsargumenten usw. angibt. Stattdessen tritt der Fehler auf, wenn der Alert ausgeführt wird.

    Um den Alert auf Fehler zu überprüfen, verwenden Sie die Tabellenfunktion ALERT_HISTORY.

    Um diese Art von Fehlern zu vermeiden, sollten Sie, bevor Sie die Bedingungen und Aktionen für Alerts festlegen, die SQL-Ausdrücke und -Anweisungen für diese Bedingungen und Aktionen überprüfen.

  • Metadaten:

    Achtung

    Kunden müssen sicherstellen, dass bei der Nutzung des Snowflake-Dienstes keine personenbezogenen Daten (außer für ein Objekt „Benutzer“), sensible Daten, exportkontrollierte Daten oder andere regulierte Daten als Metadaten eingegeben werden. Weitere Informationen dazu finden Sie unter Metadatenfelder in Snowflake.

Beispiele

Siehe Unterbrechen und Fortsetzen eines Alerts.

Sprache: Deutsch