タスクの紹介

タスクは、次に挙げる型の SQL コードのいずれかを実行できます。

  • 単一の SQL ステートメント

  • ストアドプロシージャへの呼び出し

  • Snowflakeスクリプト を使用した手続き型ロジック

タスクを テーブルストリーム と組み合わせて、連続して ELT ワークフローを実行し、最近変更されたテーブル行を処理できます。ストリームは、テーブル内の新しいデータまたは変更されたデータのセマンティクスを1回だけ保証します。

また、行のレポートテーブルへの挿入またはマージにより定期的なレポートを生成したり、他の定期的な作業を実行したりするために、タスクを独立して使用することもできます。

このトピックの内容:

コンピューティングリソース

タスクには、 SQL コードを実行するためのコンピューティングリソースが必要です。次のコンピューティングモデルのいずれかを個々のタスクに選択できます。

  • Snowflake管理(つまり、サーバーレスコンピューティングモデル)

  • ユーザー管理(つまり、仮想ウェアハウス)

サーバーレスタスク

注釈

プレビュー 機能としてサポートされています。

タスクにサーバーレスコンピューティングモデルを使用すると、ユーザーが管理する仮想ウェアハウスではなく、Snowflakeが管理するコンピューティングリソースに依存できるようになります。コンピューティングリソースは、各ワークロードの必要に応じて、Snowflakeによって自動的にサイズ変更、およびスケールアップまたはスケールダウンされます。Snowflakeは、同じタスクの最近の実行に対する統計の動的分析に基づいて、特定の実行に対する計算リソースの理想的なサイズを決定します。

サーバーレスコンピューティングモデルを有効にするオプションは、タスクの作成時に指定する必要があります。 CREATE TASK 構文は、ユーザー管理の仮想ウェアハウスに依存するタスクとほぼ同じです。Snowflakeがタスクのコンピューティングリソースを管理できるようにするには、 WAREHOUSE パラメーターを省略します。CREATE TASK コマンドを実行するロールには、 EXECUTE MANAGED TASK グローバル権限が必要であることに注意してください。タスクのアクセス制御要件の詳細については、 タスクセキュリティ をご参照ください。

サーバーレスタスクの実行に対する請求は、コンピューティングリソースをウェアハウスに依存するタスクの標準的なクレジット消費モデルとは多少異なります。詳細については、 タスク実行の請求 をご参照ください。

注釈

サーバーレスタスクは、次のオブジェクト型を呼び出すことはできません。

  • Javaコードを含む UDFs (ユーザー定義関数)。

  • Scalaで記述(Snowparkを使用)された、またはJavaコードを含む UDFs を呼び出すストアドプロシージャ。

ユーザー管理のタスク

必要に応じて、タスクの作成時に既存の仮想ウェアハウスを指定することで、個々のタスクのコンピューティングリソースを管理することもできます。このオプションでは、タスクによって実行される SQL アクションに適したサイズのウェアハウスを選択する必要があります。

ウェアハウスのサイズの選択

既存のウェアハウスを使用して個々のタスクにコンピューティングリソースを提供することを選択する場合は、 ウェアハウスに関する考慮事項 で説明されているベストプラクティスに従うことをお勧めします。ウェアハウスのサイズとクラスタリングに基づいて、特定のウェアハウスを使用して特定のタスクまたはタスクのツリーの平均実行時間を分析すること、およびウェアハウスが複数のプロセスで共有されているか、この単一のタスク(またはタスクのツリー)の実行専用であるかを分析するようにご提案します。

TASK_HISTORY Account Usageビュー (SNOWFLAKE 共有データベース内)をクエリします。タスクのスケジュールされた時間と完了した時間の平均差は、タスクがキューに入れられた期間を含む、タスクの予想される平均実行時間です。現在、他のプロセスがウェアハウス内のすべてのコンピューティングリソースを使用している場合、タスクはキューに入れられます。

タスクに定義された SQL ステートメントを(ステートメントの書き換え、またはストアドプロシージャの使用により)最適化できる場合を除き、これはタスク(またはタスクのツリー)の予想される平均実行時間になります。分析に基づいてウェアハウスの適切なサイズを選択し、タスク(またはタスクのツリー)がこのウィンドウ内で実行を完了することを確認します。

次の図は、20秒間キューに入れられた単一のタスクが40秒間実行された、1分間のウィンドウを示しています。

Example task batch window

次の図は、実行ごとに平均で5分かかるタスクのツリーを示しています。この図は、タスクツリーを2回実行して完了するウィンドウを示しています。このウィンドウでは、ルートタスクの開始がスケジュールされている時間から、ツリー内の最後の子タスクの実行が完了するまでが計算されます。この例では、タスクのツリーは、ツリー内の各3タスクの実行中にキューに入れられる他の並行操作と共有されます。これらの同時操作は、ツリー内の各タスクの実行が終了し、次のタスクの実行が開始される前に、使用可能なすべてのリソースを消費します。その結果、各タスクのウィンドウには、他の操作が終了してコンピューティングリソースを放棄するのを待つ間、ある程度のキューイングが含まれます。

このタスクのツリーが専用のウェアハウスで実行された場合でも、先行タスクの実行が完了して子タスクが実行された後、わずかな遅れが予想されることに注意してください。ただし、他の操作と共有したリソースのキューは発生しません。選択するウェアハウスのサイズは、先行タスクによって同時にトリガーされる複数の子タスクに対応できる大きさでなければなりません。

Example tree of tasks batch window

タスクのスケジュール

タスクをトリガーできるイベントソースはありません。代わりにタスクは、タスク作成時(CREATETASK を使用)または後(ALTER TASK を使用)に定義できるスケジュールに従って実行されます。

Snowflakeは、スケジュールのあるタスクのインスタンス(つまり、スタンドアロンタスクまたはタスクツリー内のルートタスク)が特定の時間に1つだけ実行されるようにします。次のスケジュールされた実行時間が発生したときにタスクがまだ実行されている場合、そのスケジュールされた時間はスキップされます。

Snowflakeは、サーバーレスタスクのコンピューティングリソースのサイズを自動的に変更およびスケールします。ウェアハウスに依存してコンピューティングリソースを提供するタスクの場合は、特定のタスクに適切なウェアハウスサイズを選択して、定義されたスケジュール内でワークロードを完了します。詳細については、 ウェアハウスのサイズの選択 (このトピック内)をご参照ください。

タスクのスケジューリングと夏時間

タスク定義のcron式は、タイムゾーンの指定をサポートしています。スケジュールされたタスクは、指定されたタイムゾーンのローカル時間で指定されたcron式に従って実行されます。夏時間を認識するタイムゾーンのタスクのスケジュールに関しては、特別な注意が必要です。標準時間から夏時間への移行(またはその逆)が発生する日の特定の時間にスケジュールされたタスクは、予期しない動作をする可能性があります。

例:

  • 夏時間から標準時間への秋の変更中に、米国/ロサンゼルスタイムゾーンの1 AM (つまり 0 1 * * * America/Los_Angeles)で開始するようにスケジュールされたタスクは、 2回 実行されます。1 AM そして、1:59:59 AM が現地時間の1:00:00 AM にシフトしたときに再び実行されます。つまり、現地時間が1 AMである時点は2つあります。

  • 春から標準時間への夏時間の変更中、米国/ロサンゼルスタイムゾーンの2 AM (つまり 0 2 * * * America/Los_Angeles)で開始するようにスケジュールされたタスクは、ローカル時間が1:59:59 AM から3:00:00 AMへシフトするため まったく実行されません 。つまり、その日のローカル時間が2 AMであるポイントはありません。

夏時間による予期しないタスクの実行を避けるため、次の どちらか を実行します:

  • 次のタイミングでに実行するようにタスクをスケジュールしないでください:1 AM と3 AM の間の特定の時間(毎日、または日曜日を含む曜日)、 または

  • 毎年2回、これらの時間帯にスケジュールされたタスクのcron式を手動で調整して、夏時間による時間の変更を補正します。

タスクの単純なツリー

ユーザーはルートタスクで始まり、タスクの依存関係によってリンクされている単純なツリーのようなタスク構造を定義できます。現在の実装では、2つのノード間の単一パスがサポートされています。つまり、個々のタスクは単一の先行タスク(親)のみを持つことができます。これは、1つのノードが複数の先行を持つことができる有向非巡回グラフ(DAG)構造とは異なります。

Tree of tasks

タスクの作成時に( CREATE TASK ... AFTER を使用)、または後で( ALTER TASK ... ADD AFTER を使用)、先行タスクを定義できます。ツリーのルートタスクにはスケジュールが定義されている必要があります。ツリー内の他の各タスクには、それらを相互にリンクするための定義済みの先行があります。先行タスクの実行が正常に完了すると、このタスクを定義で先行タスクとして識別される子タスクの実行がトリガーされます。

単純なタスクのツリーは、合計で最大1000タスク(ルートタスクを含む)に制限されます。ツリー内の個々のタスクは、単一の先行タスクに限られます。ただし、タスクには最大100個の タスク(つまり、タスクを先行タスクとして識別する他のタスク)を含めることができます。

注釈

先行タスクの実行が完了し、子タスクが実行された後、短いラグが発生します。

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

タスクとタスク所有権の単純なツリー

単純なツリーのすべてのタスクには、同じタスク所有者が必要で(つまり、単一のロールにはツリー内のすべてのタスクに対する OWNERSHIP 権限が必要)、同一のデータベースとスキーマに保存されていなければなりません。

タスクのツリー内のすべてのタスクの所有権が、次のアクティビティのいずれかを介して一度に転送されると、ツリー内のすべてのタスク間のリンクが保持されます。

  • タスクのツリーを構成するすべてのタスクの現在の所有者を削除する( DROP ROLE を使用)。ドロップされたロールが所有するオブジェクトの所有権は、 DROP ROLE コマンドを実行するロールに転送されます。

  • タスクのツリーを構成するすべてのタスクの所有権は、明示的に別のロールに譲渡されます(たとえば、スキーマ内のすべてのタスクで GRANT OWNERSHIP を実行することにより)。

タスク実行の重複ツリー

デフォルトでは、Snowflakeは、タスクの特定のツリーの1つのインスタンスのみが一度に実行できるようにします。ルートタスクの次の実行は、ツリー内のすべての子タスクの実行が終了した後にのみスケジュールされます。これは、ツリー内のすべてのタスクを実行するために必要な累積時間がルートタスクの定義で設定された明示的なスケジュールされた時間を超える場合、タスクツリーの少なくとも1つの実行がスキップされることを意味します。

動作は、ルートタスクのALLOW_OVERLAPPING_EXECUTIONパラメータによって制御されます。デフォルト値はFALSEです。

次の例では、タスクツリーの実行は、前の実行がまだ完了していないときに開始するようにスケジュールされています。重複期間、つまり並行性は赤色で示されます。この図は、各タスクがユーザー管理のウェアハウスで実行される前にキューに入れられた期間も示しています。Snowflake管理のコンピューティングリソースが使用されている場合は、キュー期間がないことに注意してください。

Overlapping task tree runs

タスクツリーの重複実行によって実行される読み取り/書き込み SQL 操作が誤ったデータまたは重複するデータを生成しない場合、重複する実行は許容される(または望ましい)場合があります。ただし、他のツリーの場合、タスク所有者(つまり、ツリー内のすべてのタスクに対して OWNERSHIP 権限を持つロール)は、ルートタスクに適切なスケジュールを設定して、適切なウェアハウス(または、Snowflake管理のコンピューティングリソース)サイズを選択し、ルートタスクの次回の実行予定前に、タスクツリーのインスタンスが完了するようにする必要があります。

ルートタスクで定義されたスケジュールに合わせてタスクツリーを適切に調整するには、

  1. 可能であれば、ルートタスクの実行間のスケジュール時間を増やします。

  2. コンピューティングの負荷が大きいタスクは、Snowflake管理のコンピューティングリソースを使用するように変更することを検討します。タスクがユーザー管理のコンピューティングリソースに依存している場合は、タスクツリーで大規模または複雑な SQL ステートメントやストアドプロシージャを実行するためのウェアハウスサイズを拡大することを検討します。

  3. 各タスクによって実行される SQL ステートメントまたはストアドプロシージャを分析します。並列処理を活用するようにコードを書き直すことができるかどうかを判断します。

上記の解決策のいずれも役に立たない場合は、ルートタスクでALLOW_OVERLAPPING_EXECUTION = TRUEを設定して、ツリーの同時実行を許可する必要があるかどうかを検討してください。タスクの作成時に(CREATE TASKを使用)、または後で(ALTER TASKを使用)、このパラメーターを定義できます。

実行のバージョニング

ツリー内のスタンドアロンタスクまたはルートタスクが最初に再開される(または、 EXECUTE TASK を使用して手動で実行される)と、タスクの初期バージョンが設定されます。タスクがルートタスクの場合は、ツリー内にあるタスクすべてのプロパティすべてを含む、タスクツリー全体のバージョンが設定されます。スタンドアロンタスクまたはタスクツリーは、このバージョンを使用して実行されます。タスクが一時停止および変更された後、スタンドアロンまたはルートタスクが再開されるか、手動で実行されると、新しいバージョンが設定されます。

タスクツリー内にある任意のタスクを変更または再作成するには、最初にルートタスクを一時停止する必要があります(ALTERTASK ... SUSPEND を使用)。ルートタスクが一時停止されると、将来のスケジュールされたルートタスクの実行はすべてキャンセルされます。ただし、現在実行中のタスク(つまり、 EXECUTING 状態のタスク)がある場合、これらのタスクと子孫タスクは、現在のバージョンを使用して引き続き実行されます。

注釈

タスクのツリーの実行中にタスクによって呼び出されるストアドプロシージャの定義が変更された場合、現在実行中のタスクによってストアドプロシージャが呼び出されたときに、新しいプログラミングを実行できます。

たとえば、タスクツリーのルートタスクが一時停止されているが、このタスクのスケジュールされた実行がすでに開始されているとします。ツリーの所有者は、ルートタスクの実行中に子タスクによって呼び出される SQL コードを変更します。子タスクは、ルートタスクが実行を開始したときに最新だったタスクツリーのバージョンを使用して、定義内の SQL コードを実行します。ルートタスクが再開されるか、手動で実行されると、タスクツリーの新しいバージョンが設定されます。この新しいバージョンには、子タスクへの変更が含まれています。

タスクのセッションパラメーターの設定

タスクを実行するセッションのセッションパラメーターを設定できます。これを行うには、既存のタスクを変更し、目的のパラメーター値を設定します( ALTER TASK ... SET セッションパラメーター = [, セッションパラメーター = ... ] を使用)。

タスクは、すべてのセッションパラメーターをサポートします。完全なリストについては、 パラメーター をご参照ください。

タスクは、アカウントまたはユーザーのパラメーターを サポートしない ことに注意してください。

手動によるタスクの実行

EXECUTE TASK コマンドは、タスクに定義されたスケジュールとは関係なく、スケジュールされたタスク(スタンドアロンタスクまたはタスクツリーのルートタスクのいずれか)の単一の実行を手動でトリガーします。先行タスクが完了するにつれて、ルートタスクが正常に実行されると、ルートタスクが定義されたスケジュールで実行されたかのように、ツリー内にある子タスクのカスケード実行がトリガーされます。

この SQL コマンドは、運用環境で SQL コードを実行できるようにする前に、新規または変更されたスタンドアロンタスクとタスクツリーをテストするのに役立ちます。

この SQL コマンドは、スクリプトまたはストアドプロシージャで直接呼び出します。さらに、このコマンドは、外部データパイプライン内でタスクの統合をサポートします。Snowflakeアカウントへの認証と SQL アクションの承認が可能なサードパーティのサービスは、 EXECUTE TASK コマンドを実行してタスクを実行できます。

注釈

プレビュー 機能としてサポートされています。

アカウントのタスク履歴を表示する

次のロール(または指定された権限を持つロール)は、 SQL を使用して、指定された日付範囲内のタスク履歴を表示できます。

  • アカウント管理者(つまり、 ACCOUNTADMIN ロールを持つユーザー)。

  • タスク所有者(つまり、タスクに対する OWNERSHIP 権限を持つロール)。

  • グローバル MONITOR EXECUTION 権限を持つ任意のロール。

タスク履歴を表示するには:

SQL

TASK_HISTORY テーブル関数( Snowflake Information Schema 内)をクエリします。

タスク実行の請求

SQL コードを実行するためのタスク実行に関連するコストは、タスクのコンピューティングリソースのソースによって異なります。

ユーザー管理のウェアハウス

Snowflakeは、タスク実行中のウェアハウスの使用量に基づいて、アカウントに クレジット使用状況 を請求します。これは、クライアントまたはSnowflakeウェブインターフェイスで、同じ SQL ステートメントを実行する際のウェアハウスの使用量と類似しています。秒あたりのクレジット請求と自動一時停止により、より大きなウェアハウスサイズから始めて、ワークロードに合わせてサイズを調整する柔軟性が得られます。

Snowflake管理のリソース(つまり、サーバーレスコンピューティングモデル)

Snowflakeは、実際のコンピューティングリソースの使用量に基づいてアカウントに請求します。アクティブなときにクレジットを消費し、待機状態や過剰使用の可能性がある、顧客管理の仮想ウェアハウスとは対照的です。料金は、 コンピューティング時間 のクレジット使用状況で測定されたリソースの合計使用状況(クラウドサービスの使用状況を含む)に基づいて計算されます。

Snowflakeは、タスク履歴内のタスク実行を動的に分析して、コンピューティングリソースの理想的なサイズを決定し、これらのコンピューティングリソースを一時停止して、コストを節約します。Snowflakeはロード容量を管理し、需要を満たす最適なコンピューティングリソースを確保します。Snowflakeが提供するコンピューティングリソースの管理コストを回収するため、リソースの消費に 1.5x乗数 を適用します。ただし、サーバーレスコンピューティングモデルでも、ユーザー管理のウェアハウスよりもコンピューティングコストを大幅に削減できる場合があります。

計算時間ごとに請求されるSnowflakeクレジット:

  • Snowflake管理のコンピューティングリソース: 1.5

  • クラウドサービス: 1

請求 は、テーブルの自動クラスタリング、データベース複製とフェールオーバー/フェールバック、Snowpipeなどの他のSnowflake機能と同様です。

特定のタスクに対する現在のクレジット使用状況を取得するには、 SERVERLESS_TASK_HISTORY テーブル関数をクエリします。タスク所有者(つまり、タスクに対して OWNERSHIP 権限を持つロール)として、次のステートメントを実行します。

SET num_credits = (SELECT SUM(credits_used)
  FROM TABLE(<database_name>.information_schema.serverless_task_history(
    date_range_start=>dateadd(D, -1, current_timestamp()),
    date_range_end=>dateadd(D, 1, current_timestamp()),
    task_name => '<task_name>')
    )
  );

条件:

<データベース名>

タスクを含むデータベースの名前です。

<タスク名>

タスクの名前。

すべてのサーバーレスタスクに対する現在のクレジット使用状況を取得するには、 SERVERLESS_TASK_HISTORY ビューをクエリします。アカウント管理者(つまり、 ACCOUNTADMIN ロールを持つユーザー)として、次のステートメントを実行します。

SELECT START_TIME, END_TIME, TASK_ID, TASK_NAME, CREDITS_USED, SCHEMA_ID, SCHEMA_NAME, DATABASE_ID, DATABASE_NAME
  FROM snowflake.account_usage.serverless_task_history
  ORDER BY start_time, task_id;

システムサービスの理解

Snowflakeは、タスク所有者の権限(つまり、タスクに対する OWNERSHIP 権限を持つロール)でタスクを実行しますが、タスクの実行はユーザーに関連付けられていません。代わりに、各実行はシステムサービスによって実行されます。タスクは特定のユーザーから切り離され、ユーザーのドロップ、認証の問題が原因によるロック、ロールの削除などにより発生する可能性のある複雑さを回避します。

タスクの実行はユーザーから切り離されているため、タスクの実行のクエリ履歴はシステムサービスに関連付けられています。SYSTEM はアカウントのユーザーではなく、バックグラウンドのサービスです。そのため、このサービスにはユーザー認証情報がなく、いかなる個人(Snowflakeまたはアカウント内)もそのIDを引き受けることはできません。システムサービスのアクティビティはアカウントに制限されています。他の操作に適用されるのと同じ暗号化保護および他のセキュリティプロトコルがこのサービスに組み込まれています。

タスク DDL

タスクの作成と管理をサポートするために、Snowflakeは次の一連の特別な DDL コマンドを提供します:

さらに、プロバイダーは、次の標準アクセス制御 DDLを使用して、 ELT に必要なデータベースオブジェクトへのアクセスを表示、許可、または取り消すことができます:

タスク関数

タスクに関する情報の取得をサポートするために、Snowflakeは次の SQL 関数のセットを提供します:

タスクセキュリティ

アクセス制御権限

タスクの作成

タスクを作成するには、少なくとも次の権限を持つロールが必要です。

オブジェクト

権限

注意

アカウント

EXECUTE MANAGED TASK

Snowflakeが管理するコンピューティングリソース(サーバーレスコンピューティングタスク)に依存するタスクにのみ必要です。

データベース

USAGE

スキーマ

USAGE, CREATE TASK

ウェアハウス

USAGE

コンピューティングリソースをユーザー管理のウェアハウスに依存するタスクにのみ必要です。

タスクの所有

タスクが作成された後、タスクの所有者(つまり、タスクに対する OWNERSHIP 権限を持つロール)には、次の権限が必要です。

オブジェクト

権限

注意

アカウント

EXECUTE TASK

ロールが所有するタスクを実行するために必要です。ロールの EXECUTE TASK 権限を取り消すと、それ以降、すべてのタスクの実行はそのロールで開始できなくなります。

アカウント

EXECUTE MANAGED TASK

Snowflake管理のコンピューティングリソースに依存するタスクにのみ必要です。

データベース

USAGE

スキーマ

USAGE

タスク

OWNERSHIP

ウェアハウス

USAGE

またロールは、タスクによって実行される SQL ステートメントの実行に必要な権限を持っている必要があります。

タスクの再開または一時停止

タスクの所有者に加えて、タスクに対するOPERATE権限を持つロールは、タスクを一時停止または再開できます。このロールには、タスクを含むデータベースとスキーマに対するUSAGE権限が必要です。他の権限は必要ありません。

タスクが再開されると、Snowflakeは、タスクの所有者のロールが 所有タスク (このトピック内)にリストされている権限を持っていることを確認します。

タスク管理者ロールの作成

使いやすくするために、カスタムロール(例: taskadmin)を作成し、このロールに EXECUTE TASK 権限を割り当てることをお勧めします。権限を付与できるロール(例: SECURITYADMIN または MANAGE GRANTS 権限を持つ任意のロール)は、このカスタムロールを任意のタスク所有者ロールに付与して、自身のタスクの変更を許可できます。タスク所有者ロールがタスクを実行する機能を削除するには、このカスタムロールをタスク所有者ロールから取り消すだけです。このカスタムロールを作成しないことを選択した場合、アカウント管理者はタスク所有者ロールから EXECUTE TASK 権限を取り消す必要があることに注意してください。

たとえば、カスタムロール名 taskadmin を作成し、そのロールに EXECUTE TASK 権限を付与します。 myrole という名前のタスク所有者ロールに taskadmin ロールを割り当てます。

USE ROLE securityadmin;

CREATE ROLE taskadmin;

-- set the active role to ACCOUNTADMIN before granting the account-level privileges to the new role
USE ROLE accountadmin;

GRANT EXECUTE TASK, EXECUTE MANAGED TASK ON ACCOUNT TO ROLE taskadmin;

-- set the active role to SECURITYADMIN to show that this role can grant a role to another role
USE ROLE securityadmin;

GRANT ROLE taskadmin TO ROLE myrole;

カスタムロールとロール階層の作成の詳細については、 アクセス制御の構成 をご参照ください。

タスク所有者ロールの削除

特定のタスクの所有者のロール(つまり、タスクに対する OWNERSHIP 権限を持つロール)が削除されると、所有者のロールをドロップしたロールによってタスクが「再所有」されます。これにより、所有権がロール階層のルートにより近いロールに移動します。タスクが再所有されると、タスクは自動的に一時停止します。つまり、現在実行中のすべての実行は処理を完了しますが、新しい所有者によってタスクが明示的に再開されるまで、新しい実行はスケジュールされません。これの理由は、特定のロールへのアクセス権限を持つユーザーが、ロールが削除されたときに、高いアクセス許可で突然実行されるタスクを残さないようにすることです。

実行中のタスクが実行されているロールがタスクの実行中に削除された場合、タスクは削除されたロールの下で処理を完了します。

ワークフロー

このセクションでは、タスク設定のワークフローの概要を説明します。

  1. タスク管理者ロールの作成 (このトピック)のステップを完了して、次のステップのコマンドの実行に使用できるロールを作成します。

  2. CREATE TASK を使用してタスクを作成します。タスクはデフォルトで一時停止されています。

    注釈

    タスクを作成する 前に 、タスクで参照する SQL ステートメントが期待どおりに実行されることを確認します。タスクは、すでに徹底的にテストされている SQL ステートメントまたはストアドプロシージャを自動化することを目的としています。

  3. ALTER TASK ... RESUME を実行して、タスク定義で指定されたパラメーターに基づいてタスクを実行できるようにします。

最上部に戻る