ALTER ALERT

既存のアラートのプロパティを変更し、既存の アラート を中断または再開します。

こちらもご参照ください。

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

構文

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 <name> UNSET TAG <tag_name> [ , <tag_name> ... ]

ALTER ALERT [ IF EXISTS ] <name> UNSET COMMENT

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

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

パラメーター

name

変更するアラートの識別子。識別子にスペースまたは特殊文字が含まれる場合は、文字列全体を二重引用符で囲む必要があります。二重引用符で囲まれた識別子も大文字と小文字が区別されます。

{ RESUME | SUSPEND }

アラートで実行するアクションを指定します。

  • RESUME は、中断しているアラートをアクティブにします。

  • SUSPEND は、アラートを「中断」状態にします。

アラートスケジュールが間隔（つまり、 num MINUTE）に設定されている場合は、あいまいさを避けるため、アラート再開時にスケジュールの 基本間隔時間 が現在の時刻にリセットされます。

基本間隔時間は、現在のクロックタイムから間隔カウンターを開始します。たとえば、アラートが 10 MINUTE で作成され、アラートが9:03 AM に再開される場合、アラートは9:13 AM、9:23 AM というように実行されます。絶対精度を確保するために最善を尽くしますが、保証されるのは、設定間隔の 前に アラートが実行されないようにすることのみです（たとえば、現在の例では、アラートは最初に9:14 AM に実行されることはあっても、9:12 AM に実行されることは決してありません）。

SET ...

アラートに設定する1つ（または複数）のプロパティを指定します（空白、コンマ、または改行で区切り）。

WAREHOUSE = warehouse_name

このアラートを実行するためのコンピューティングリソースを提供する仮想ウェアハウスを指定します。

SCHEDULE ...

アラートの条件を定期的に評価するスケジュールを指定します。

次のいずれかの方法でスケジュールを指定できます。

  • USING CRON expr time_zone

    アラートの条件を定期的に評価するためのcron式とタイムゾーンを指定します。標準のcronユーティリティ構文のサブセットをサポートします。

    cron式は、次のフィールドで構成されます。

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

    次の特殊文字がサポートされています。

    特殊文字

    説明

    *

    ワイルドカード。特定のフィールドに指定された場合、アラートはそのフィールドの単位時間で実行されます。

    たとえば、月フィールドの * は、アラートが毎月実行されることを指定します。

    L

    「最後」の略。曜日フィールドで使用すると、特定の月の「最後の金曜日」（「5L」）などの構造を指定できます。月の日フィールドでは、月の最後の日を指定します。

    /n

    特定の時間単位における n 番目のインスタンスを示します。時間の各クォンタムは独立して計算されます。

    たとえば、月フィールドに 4/3 が指定されている場合、条件の評価は4月、7月、および10月（つまり、年の4番目の月から始まる3か月ごと）にスケジュールされます。

    その後も同じスケジュールが維持されます。つまり、条件は1月（10月の実行から3か月後）に評価されるようにスケジュールされてはいません。

    注釈

    • cron式は現在、指定されたタイムゾーンに対してのみ評価します。アカウントの TIMEZONE パラメーター値を変更（またはユーザーレベルまたはセッションレベルで値を設定）しても、アラートのタイムゾーンは変更 されません。

    • cron式は、アラートの条件を評価するためのすべての 有効な 時間を定義します。Snowflakeは、このスケジュールに基づいて条件を評価しようとします。ただし、次の有効な実行時間が始まる前に前の実行が完了していない場合、有効な実行時間はスキップされます。

    • cron式に特定の月の日と曜日の両方が含まれている場合、条件の評価は月の日または曜日の いずれか を満たす日にスケジュールされます。たとえば、 SCHEDULE = 'USING CRON 0 0 10-20 * TUE,THU UTC' は、月の10日から20日、およびそれらの日付以外の火曜日または木曜日の 0AM に評価をスケジュールします。

  • num MINUTE

    アラートの評価間に挿入される待機時間の間隔（分単位）を指定します。正の整数のみを受け入れます。

    num M 構文もサポートしています。

    あいまいさを避けるために、アラートの再開時（ALTER ALERT RESUME を使用）には 基本間隔時間 が設定されます。

    基本間隔時間は、現在のクロックタイムから間隔カウンターを開始します。たとえば、アラートが 10 MINUTE で作成され、アラートが9:03 AM に再開される場合、アラートの条件は9:13 AM、9:23 AM というように評価されます。絶対精度を確保するために最善を尽くしますが、保証されるのは、設定間隔の 前に 条件が評価されないようにすることのみです（たとえば、現在の例では、条件は最初に9:14 AM に評価されることはあっても、9:12 AM に評価されることは決してありません）。

    注釈

    サポートされる最大値は 11520 （8日間）です。 num MINUTE の値がこれよりも大きいアラートの条件が評価されることはありません。

COMMENT = 'string_literal'

アラートのコメントを指定します。

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

タグ の名前とタグ文字列の値を指定します。

タグ値は常に文字列であり、タグ値の最大文字数は256です。

ステートメントでのタグの指定に関する情報については、 オブジェクトおよび列のタグクォータ をご参照ください。

UNSET ...

アラートの設定を解除する1つ以上のプロパティ/パラメーターを指定し、それらをデフォルトにリセットします。

  • TAG tag_key [ , tag_key ... ]

  • COMMENT

MODIFY CONDITION EXISTS (condition)

アラートの条件を表す SQL ステートメントを指定します。次のコマンドを使用できます。

ステートメントが1つ以上の行を返す場合にアラートのアクションが実行されます。

MODIFY ACTION action

条件が1つ以上の行を返す場合に実行する SQL ステートメントを指定します。

メール通知を送信するには、 SYSTEM$SEND_EMAIL() ストアドプロシージャを呼び出します。

アクセス制御の要件

この SQL コマンドを実行するには、少なくとも次の 権限 を持つ ロール が必要です。

  • アラートを再開するには、

    • アラートに対する OWNERSHIP 権限を持つロールには、 EXECUTE ALERT グローバル権限も必要です。

    • ALTER ALERT を実行するロールには、アラートに対する OPERATE または OWNERSHIP 権限が必要です。

  • アラートを中断するには、 ALTER ALERT を実行するロールにアラートに対する OPERATE または OWNERSHIP 権限が必要です。

  • アラートのプロパティを変更するには、 ALTER ALERT を実行するロールにアラートに対する OWNERSHIP 権限が必要です。

スキーマ内の任意のオブジェクトを操作するには、親データベースとスキーマに対する USAGE 権限も必要であることに注意してください。

指定された権限のセットを使用してカスタムロールを作成する手順については、 カスタムロールの作成 をご参照ください。

セキュリティ保護可能なオブジェクト に対して SQL アクションを実行するためのロールと権限付与に関する一般的な情報については、 アクセス制御の概要 をご参照ください。

使用上の注意

  • アラートが再開されると、Snowflakeは、アラートに対する OWNERSHIP 権限を持つロールが、アラートに割り当てられたウェアハウスに対する USAGE 権限、および EXECUTE ALERT グローバル権限を持っていることを確認します。権限がない場合は、エラーが生成されます。

  • アカウント管理者（ ACCOUNTADMIN ロールを持つユーザー）のみが、ロールに EXECUTE ALERT 権限を付与できます。使いやすくするために、カスタムロール（例: alert_admin）を作成し、このロールに EXECUTE ALERT 権限を割り当てることをお勧めします。権限を付与できるロール（例: SECURITYADMIN または MANAGE GRANTS 権限を持つ任意のロール）は、このカスタムロールを任意のアラート所有者ロールに付与して、自身のアラートの変更を許可できます。カスタムロールとロール階層を作成する手順については、 アクセス制御の構成 をご参照ください。

  • CREATE ALERT または ALTER ALERT を実行すると、条件とアクションのステートメントに対して、以下のようないくつかの検証チェックが実行されません。

    • オブジェクトの識別子の解決。

    • 式のデータ型の解決。

    • 関数呼び出しの引数の数と型の検証。

    CREATE ALERT コマンドと ALTER ALERT コマンドは、条件またはアクションの SQL ステートメントで無効な識別子、不正なデータ型、関数引数の不正な数と型などが指定されていても失敗しません。その代わり、アラートが実行されると失敗します。

    既存アラートの失敗を確認するには、 ALERT_HISTORY テーブル関数を使用します。

    このような失敗を避けるために、アラートの条件とアクションを指定する前に、それらの条件とアクションの SQL 式とステートメントを検証します。

  • メタデータについて:

    注意

    Snowflakeサービスを使用する場合、お客様は、個人データ（ユーザーオブジェクト向け以外）、機密データ、輸出管理データ、またはその他の規制されたデータがメタデータとして入力されていないことを確認する必要があります。詳細については、 Snowflakeのメタデータフィールド をご参照ください。

例

アラートの中断と再開 をご参照ください。

言語: 日本語