ADMIN_TASK_UPDATE プロシージャー - 既存のタスクの更新

ADMIN_TASK_UPDATE プロシージャーは、管理タスク、つまりプロシージャーの内部にカプセル化できる処理を更新します。

構文

構文図を読む構文図をスキップするADMIN_TASK_UPDATE(name,begin_timestamp,end_timestamp,max_invocations,schedule,options,remarks)

スキーマは SYSPROC です。

プロシージャー・パラメーター

name
既存のタスクの名前を指定する、タイプ VARCHAR (128) の入力引数。 この引数は NULL にできません。
begin_timestamp
タスクの実行を開始できる最も早い時刻を指定する、タイプ TIMESTAMP の入力引数。 この引数の値は、過去の日付にしたり、end_timestamp より後の日付にしたりすることはできません。
タスク実行が開始されるタイミングは、このパラメーターと schedule パラメーターが定義されている方法によって異なります。
  • begin_timestamp引数が NULL 以外の場合:
    • schedule 引数が NULL の場合、タスク実行は begin_timestamp に開始されます。
    • schedule 引数が NULL 以外の場合、タスク実行は、スケジュールされている次の時刻または begin_timestamp よりも後に開始されます。
  • begin_timestamp 引数が NULL の場合:
    • schedule 引数が NULL の場合、タスク実行は即時に開始されます。
    • schedule 引数が NULL 以外の場合、タスク実行は、スケジュールされている次の時刻に開始されます。
end_timestamp
タスクの実行を開始できる最後の時刻を指定する、タイプ TIMESTAMP の入力引数。 この引数の値は、過去の日付にしたり、begin_timestamp より前の日付にしたりすることはできません。引数が NULL の場合、タスクは、スケジュールされたとおりに無期限に実行されます。

実行中のタスクは、その end_timestamp で中断されることはありません。

max_invocations
タスクで許容される最大実行数を指定する、タイプ INTEGER の入力引数。 引数が NULL の場合、タスクを実行できる回数に制限はありません。 引数が 0 の場合、タスクは実行されません。

schedule が NULL 以外の場合、この値がスケジュールに適用されます。

end_timestamp と max_invocations の両方が指定されている場合、end_timestamp が優先されます。つまり、end_timestamp タイム・スタンプに達すると、タスクの回数がその時点で max_invocations の値に達していなくても、そのタスクが再び実行されることはありません。

schedule
特定の時間にタスクが実行されるようにスケジュールを指定する、タイプ VARCHAR(1024) の入力引数。 引数が NULL の場合、タスクは、特定の時間にスケジュールされません。

schedule ストリングは、UNIX cron 形式を使用して指定する必要があります。

複数のスケジュールはサポートされていません。

options
タイプ VARCHAR(512) の入力引数。 この引数は NULL でなければなりません。
remarks
タスクの説明を指定する、タイプ VARCHAR(254) の入力引数。 これは、NULL に設定できるオプションの引数です。

許可

以下のいずれかの権限が必要です。
  • ADMIN_TASK_UPDATE プロシージャーに対する EXECUTE 特権
  • DATAACCESS 権限
  • DBADM 権限
  • SQLADM 権限

ステートメント許可 ID を使用してプロシージャーを実行することが可能な場合でも、現行のセッション許可 ID がタスクの作成時に記録されたセッション許可 ID と一致しない限り、タスクを更新することはできません。 既存のタスクを更新できるのは、SYSADM、SYSCTRL、SYSMAINT、または DBADM の各権限を持ったユーザーです。別のユーザーによって追加されたタスクを更新しようとすると、SQL0551N が戻されます。

デフォルトの PUBLIC 特権

制限のないデータベースでは、このプロシージャーが自動的に作成されると、EXECUTE 特権が PUBLIC に付与されます。

使用上の注意

無効な引数がプロシージャーに渡されると、SQL0171N が戻されます。メッセージのトークンは、無効な引数およびプロシージャーの名前を示します。

タスクに対する変更は、作業単位がコミットされて、スケジューラーが更新されたタスク定義をフェッチするまでは有効になりません。 作業単位を非コミットのままにしておくと、既存のタスクの実行が遅延したり、実行されなかったりする場合があります。

スケジューラーは、更新されたタスクがないかどうか 5 分おきに調べます。 想定どおりにタスクが実行されるようにするには、begin_timestamp、end_timestamp、および schedule パラメーターで定義される最も早い開始時刻は、作業単位がコミットされてから少なくとも 5 分後でなければなりません。

タスクがスケジューラーによって実行できるようにするには、データベースはすべてのデータベース・パーティションでアクティブである必要があります。

begin_timestamp、end_timestamp、および schedule はデータベース・サーバーの時間帯に基づいています。 夏時間調整 (DST) の移行期間にタスクをスケジュールする場合には、特に注意が必要です。 タスクが午前 2 時 1 分に実行されるようスケジュールされている場合に、それが時間を早めるときに当たると、時間は午前 2 時から午前 3 時までスキップされるため、そのタスクは実行されません。 DST の変更がデータベースがアクティブな状態で行われ、DST の変更時間中にスケジュールされたタスクがない場合、DST の変更後にスケジュールされている最初のタスクは実行されません。2 番目以降のタスクは正常に実行されます。例えば、午前 2 時から午前 3 時の間にスケジュールされているタスクはなく、 午前 3 時 10 分にスケジュールされているタスクがあり、それが DST の変更後の最初のタスクである場合、このタスクは実行されません。これは、DST 変更のどれくらい後にタスクがスケジュールされているかとは関係がありません。例えば、DST より後の最初のタスクが DST の変更から 1 日後や 1 カ月後にスケジュールされていたとしても、そのタスクが DST 変更後の最初のタスクであり、データベースがその間ずっとアクティブな状態であった限り、そのタスクは実行されません。一方、時間が 1 時間戻されるときには、午前 2 時から 3 時の間にスケジュールされているタスクは 2 回実行されることになります。 必要な動作が実行されるように、夏時間調整時間の調整はユーザーの責任で行う必要があります。

タスクが更新されると、タスクの内部呼び出しカウンターはリセットされます。 一例として、max_invocations 値が 10 の循環タスクについて考えてみましょう。タスクが 3 回実行されると、ADMIN_TASK_STATUS 出力には 3 つの対応する状況レコードが存在することになります。エントリーの INVOCATION 値はそれぞれ、1、2、3 となります。次に、タスク作成者がこのタスクを更新するとします。 この更新によって、内部呼び出しカウンターはリセットされます。元の状況レコードはそのまま残されます。 時間の経過とともに、1、2、3 といった INVOCATION 値を持つ新しい状況レコードが作成されます。 BEGIN_TIME を使用して、元のタスク実行と更新されたタスク実行を区別することができます。