EXECUTE TASK¶

構文¶

EXECUTE TASK <name>
  [ USING CONFIG = <configuration_string> ]

EXECUTE TASK <name> RETRY LAST

パラメーター¶

name

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

USING CONFIG = configuration_string

この1回の実行のための有効なJSON形式の構成文字列を指定します。このパラメーターは、動的に指定された構成で新しい実行を作成しますが、タスク定義は変更しません。

Snowflakeは、動的構成を デフォルト 構成とマージします。これは、CREATEまたはALTERを使用してタスク定義で設定したCONFIGパラメーターです。フィールドの照合のために、Snowflakeは動的に指定された値を使用します。一致しないフィールドの場合、Snowflakeはデフォルト構成の値を使用します。例については、 動的CONFIGを使用する をご参照ください。

構成文字列は、 CREATE TASK または ALTER TASK のCONFIGパラメーターと同じ形式に従います。

CopyExpand

CONFIG = $${"string1": value1 [, "string2": value2, ...] }$$

Show lessSee more

Scroll to top

例:

CopyExpand

CONFIG = $${"learning_rate": 0.2, "environment": "testing"}$$

Show lessSee more

Scroll to top

RETRY LAST

失敗した name の タスクグラフ の最終タスクを失敗したタスクから再実行します。

タスクを再実行するには、以下の条件を満たす必要があります。

• 最後のタスクグラフ実行は状態が FAILED か CANCELED であること。

• タスクグラフは最後に実行されてから変更されていないこと。

• 最後に失敗したグラフ実行の最初の試行が、過去14日以内に実行されていること。

タスク履歴を表示するには、 TASK_HISTORY テーブル関数または Snowsightのタスクのページ をご参照ください。

注釈

RETRY LAST は、最後に失敗したタスクから実行を開始する新しいグラフ実行を作成します。

具体的には、 FAILED または CANCELED タスクの実行はすべて直ちに再実行され、関連する子タスクは、それらの先行タスクがすべて正常に実行された場合にスケジュールされます。

さらに、再試行によって生成される新しいタスクグラフ実行は、前回失敗したグラフ実行よりも1つ大きい ATTEMPT NUMBER を持ち、再試行された、つまり元のタスクグラフ実行と同じ GRAPH_RUN_GROUP_ID を共有します。

使用上の注意¶

• タスクを実行するには、タスクの OWNERSHIP または OPERATE 権限が必要です。

  EXECUTE TASK コマンドがタスク実行をトリガーすると、Snowflakeは、タスクに対する OWNERSHIP 権限を持つロールが、タスクに割り当てられたウェアハウスに対する USAGE 権限、およびグローバル EXECUTE TASK 権限を持っていることを確認します。それ以外の場合は、エラーが生成されます。

  OPERATE 権限を持つ別のロールが EXECUTE TASK を使用してタスクを実行する場合でも、タスクは常に元の所有者ロールの権限で実行されます。

• デフォルトでは、Snowflakeはタスク所有者ロールの権限を持つシステムユーザーを使用してタスクを実行します。特定のユーザーとしてタスクを実行するには、 EXECUTE AS USER でタスクを設定します。詳細については、 ユーザー権限でタスクを実行する をご参照ください。

• USING CONFIGオプションの場合:

  • タスクグラフが現在実行中で、このコマンドを実行すると、Snowflakeは現在の実行が完了するのを待ってから、動的構成で新しい実行を開始します。

  • タスクの実行中にこのコマンドを複数回実行すると、Snowflakeは次の実行で最新のコマンドの構成を使用します。以前の構成は置換され、実行されません。

  • 動的構成は、このコマンドによってトリガーされた単一の実行にのみ適用されます。それ以降のスケジュールされた実行では、タスク定義からのデフォルトのCONFIGパラメーターが使用されます。

• SQL コマンドは、スタンドアロンタスクまたはタスクグラフ内のルートタスクのみを実行できます。子タスクが入力された場合、コマンドはユーザーエラーを返します。

• スタンドアロンまたはルートタスクを手動で実行すると、タスクのバージョンが確立されます。スタンドアロンタスクまたはタスクグラフ全体が、このバージョンで実行を完了します。タスクバージョンの詳細については、 タスク実行のバージョニング をご参照ください。

• 中断されたルートタスクは、タスクを再開 することなく 実行されます。この SQL コマンドを実行する前に、ルートタスクを明示的に再開する必要はありません。ただし、 EXECUTE TASK は、タスクグラフ内の子タスクを自動的に再開 しません。このコマンドは、中断されている子タスクをスキップします。

  タスクグラフでルートタスクに関連付けられたすべての依存タスクを再帰的に再開するには、各タスクを個別に有効にするのではなく、 SYSTEM$TASK_DEPENDENTS_ENABLE 関数をクエリします（ALTER TASK ... RESUME を使用）。

  新規または変更されたタスクグラフをテストする際のベストプラクティスとしては、ルートタスクを目的の運用スケジュールで実行するように設定しますが、 中断状態のままにします。タスクグラフのテストに成功した後、ルートタスクを再開します。テストのために、タスクグラフ内で中断された子タスクを再開する必要があることに注意してください。そうしないと、タスクグラフの実行中にスキップされます。

• タスクのインスタンスが実行されていない場合、新しい実行が直ちに開始されます。

• 別のインスタンスがスケジュールされている場合（つまり、タスクが TASK_HISTORY 出力で SCHEDULED 状態を示している場合）、リクエストされた実行はスケジュールされた実行に置き換わります。リクエストされた実行は、現在のタイムスタンプをスケジュール時刻として、直ちに開始されます。

• タスクまたはタスクグラフが現在キュー中または実行中である場合（すなわち、 TASK_HISTORY 出力でタスクが EXECUTING 状態を示している場合）、コマンドが実行されたときに現在であった タスクバージョン を使って現在の実行が継続されます。その後、タスクタイプに応じた時間に、新しい実行がスケジュールされます。

  • スタンドアロンタスクの場合、現在の実行が完了した後、新しい実行がスケジュールされます。

  • タスクグラフの場合、動作はOVERLAP_POLICY設定によって異なります。詳細については、CREATE TASKドキュメントの:ref:`OVERLAP_POLICY<label-create_task_optional_parameters>`をご参照ください。

  次のスケジュール実行が開始される前に EXECUTE TASK コマンドが再度実行されると、リクエストされた実行はスケジュールされた実行に置き換わります。

• タスクが予期しないエラーで失敗した場合、エラーに関する通知を受け取ることができます。タスクエラー通知の構成の詳細については、 タスクのエラー通知をセットアップする をご参照ください。

• タスク情報を表示するには、以下のいずれかを実行します。

  • Snowsight のナビゲーションメニューで、Transformation » Tasks を選択します。

  • COMPLETE_TASK_GRAPHS テーブル関数を呼び出し、結果を調べます。

例¶

次の例は、タスクの実行を手動でトリガーする方法と、動的CONFIGの使用方法を示しています。

EXECUTE TASK mytask;

CREATE OR REPLACE TASK my_root_task
  WAREHOUSE = regress
  SCHEDULE = '10 m'
  CONFIG = $${
    "environment": "production",
    "output_paths": {
      "logs": "/prod/logs",
      "results": "/prod/results"
    }
  }$$
  AS ...;

EXECUTE TASK my_root_task
  USING CONFIG=$${
    "output_paths": {
      "results": "/temp/testing"
    }
  }$$;

{
  "environment": "production",
  "output_paths": {
    "logs": "/prod/logs",
    "results": "/temp/testing"
  }
}