29 Oracle Schedulerを使用したジョブのスケジューリング
Oracle Schedulerでジョブを作成、実行および管理できます。
ノート:
この章では、DBMS_SCHEDULER
パッケージを使用してスケジューラ・オブジェクトを処理する方法について説明します。Oracle Enterprise Manager Cloud Controlを使用して同じタスクを実行し、それらの作業の多くをOracle SQL Developerを使用して実行できます。
DBMS_SCHEDULER
の詳細は『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を、Oracle Schedulerの各ページの詳細はCloud Controlのオンライン・ヘルプを参照してください。
- スケジューラ・オブジェクトとそのネーミングについて
Oracle Schedulerは、一連のスケジューラ・オブジェクトを作成および管理することにより操作します。各スケジューラ・オブジェクトは、[schema.]name
の形式の完全なデータベース・スキーマ・オブジェクトです。スケジューラ・オブジェクトは、データベース・オブジェクトの命名規則に正確に従い、他のデータベース・オブジェクトとSQLネームスペースを共有します。 - ジョブの作成、実行および管理
ジョブとは、スケジュールとプログラムの組合せに、プログラムに必要な追加の引数が指定されたものです。 - ジョブを定義するためのプログラムの作成および管理
プログラムは、特定のタスクに関するメタデータの集まりです。必要に応じて、プログラムを使用してジョブの定義を支援できます。 - ジョブを定義するためのスケジュールの作成および管理
必要に応じて、スケジュール・オブジェクト(スケジュール)を使用してジョブの実行時期を定義できます。スケジュールは、データベースにオブジェクトとして作成および保存することによってユーザー間で共有できます。 - イベントを使用したジョブの開始
イベントが送信されたとき、Oracle Schedulerはジョブを開始できます。イベントは、アプリケーションまたはシステム・プロセス間で送信されるメッセージです。 - ジョブ・チェーンの作成と管理
ジョブ・チェーン(「チェーン」)は、結合した1つの目的のために互いにリンクされた一連の名前付きタスクです。 - 非互換性定義の使用
非互換性定義(または非互換性)は、互換性のないジョブまたはプログラムを指定し、該当する場合は一度に1つのグループのみを実行できるようにします。 - ジョブ・リソースの管理
ジョブが使用できるリソースを作成および変更したり、ジョブが使用できる指定されたリソースの量を制御できます。 - ジョブの優先度付け
3つのスケジューラ・ジョブ(ジョブ・クラス、ウィンドウおよびウィンドウ・グループ)を使用して、Oracle Schedulerジョブに優先度を付けます。これらのオブジェクトでは、ジョブをデータベース・リソース・マネージャのコンシューマ・グループに関連付けることによって、ジョブに優先度を付けます。これにより、これらのジョブに割り当てられるリソースの量が制御されます。また、ジョブ・クラスでは、グループ内のすべてのジョブに同一のリソース・レベルが割り当てられている場合に、ジョブのグループ間に相対的な優先度を設定できます。 - ジョブの監視
いくつかの異なる方法でジョブを監視できます。
親トピック: データベース・リソースの管理とタスクのスケジューリング
29.1 スケジューラ・オブジェクトとそのネーミングについて
Oracle Schedulerは、一連のスケジューラ・オブジェクトを作成および管理することにより操作します。各スケジューラ・オブジェクトは、[schema.]name
の形式の完全なデータベース・スキーマ・オブジェクトです。スケジューラ・オブジェクトは、データベース・オブジェクトの命名規則に正確に従い、他のデータベース・オブジェクトとSQLネームスペースを共有します。
SQLの命名規則に従ってDBMS_SCHEDULER
パッケージのスケジューラ・オブジェクトに名前を付けます。デフォルトでは、二重引用符で囲まれていないかぎり、スケジューラ・オブジェクトの名前は大文字になります。たとえば、ジョブを作成する際に、job_name => 'my_job'
はjob_name => 'My_Job'
およびjob_name => 'MY_JOB'
と同じですが、job_name => '"my_job"'
とは異なります。スケジューラ・オブジェクト名のカンマ区切リストがDBMS_SCHEDULER
パッケージ内で使用される場合も、これらの命名規則に従います。
関連項目:
-
オブジェクトのネーミングの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
29.2 ジョブの作成、実行および管理
ジョブとは、スケジュールとプログラムの組合せに、プログラムに必要な追加の引数が指定されたものです。
- ジョブのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なジョブ・タスクを管理します。 - ジョブの作成
ジョブを作成するには、DBMS_SCHEDULER
パッケージまたはCloud Controlを使用します。 - ジョブの変更
ジョブを変更するには、その属性を変更します。そのためには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
、SET_ATTRIBUTE_NULL
またはSET_JOB_ATTRIBUTES
プロシージャまたはCloud Controlを使用します。 - ジョブの実行
いくつかの異なる方法でジョブを実行できます。 - ジョブの停止
1つ以上の実行中のジョブを停止するには、DBMS_SCHEDULER
パッケージのSTOP_JOB
プロシージャまたはCloud Controlを使用します。 - 外部ジョブの停止
スケジューラを使用している場合、外部ジョブの実装者は、force
がFALSE
に設定されたSTOP_JOB
がコールされた場合に、その外部ジョブを正常にクリーン・アップするメカニズムを利用できます。 - チェーン・ジョブの停止
実行中のチェーンを指しているジョブが停止すると、実行中のチェーンのステップがすべて停止します。 - ジョブの削除
1つ以上のジョブを削除するには、DBMS_SCHEDULER
パッケージのDROP_JOB
プロシージャまたはCloud Controlを使用します。 - 実行中のジョブの削除
DROP_JOB
プロシージャが呼び出されたときにジョブが実行中である場合、ジョブを削除しようとすると失敗します。このデフォルトの動作は、force
またはdefer
オプションを設定することによって変更できます。 - 複数のジョブの削除
削除する複数のジョブを指定したとき、いずれかのジョブでエラーが発生した場合、その結果はDBMS_SCHEDULER.DROP_JOB
プロシージャのcommit_semantics
引数によって決定されます。 - ジョブの無効化
1つ以上のジョブを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャまたはCloud Controlを使用します。 - ジョブの有効化
1つ以上のジョブを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャまたはCloud Controlを使用します。 - ジョブのコピー
ジョブをコピーするには、DBMS_SCHEDULER
のCOPY_JOB
プロシージャまたはCloud Controlを使用します。
関連項目:
ジョブの概要については、「ジョブ」。
29.2.1 ジョブのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なジョブ・タスクを管理します。
表29-1に、ジョブの一般的なタスクとそれに対応するプロシージャおよび権限を示します。
表29-1 ジョブのタスクとそのプロシージャ
タスク | プロシージャ | 必要な権限 |
---|---|---|
ジョブの作成 |
|
|
ジョブの変更 |
|
|
ジョブの実行 |
|
|
ジョブのコピー |
|
|
ジョブの削除 |
|
|
ジョブの停止 |
|
|
ジョブの使用禁止 |
|
|
ジョブの使用可能化 |
|
|
権限の詳細は、「スケジューラ権限」を参照してください。
親トピック: ジョブの作成、実行および管理
29.2.2 ジョブの作成
ジョブを作成するには、DBMS_SCHEDULER
パッケージまたはCloud Controlを使用します。
- ジョブ作成の概要
1つ以上のジョブを作成するには、DBMS_SCHEDULER.CREATE_JOB
またはDBMS_SCHEDULER.CREATE_JOBS
プロシージャ、あるいはCloud Controlを使用します。 - ジョブの処理、スケジュール、プログラムおよびスタイルの指定
CREATE_JOB
プロシージャはオーバーロードになるため、複数の異なる使用方法があります。 - スケジューラ・ジョブの資格証明の指定
Oracle Schedulerには、実行前にOracle Databaseまたはオペレーティング・システムでの認証に使用するジョブの資格証明が必要です。 - 宛先の指定
リモート外部ジョブおよびリモート・データベース・ジョブの場合は、宛先オブジェクトを作成してdestination_name
ジョブ属性に割り当てることにより、ジョブの宛先を指定します。NULL
のdestination_name
属性が指定されたジョブは、ジョブが作成されたホストで実行されます。 - 複数の宛先のジョブの作成
複数の宛先で実行し、1箇所で管理するジョブを作成できます。 - ジョブ引数の設定
ジョブ引数を設定するには、SET_JOB_ARGUMENT_VALUE
またはSET_JOB_ANYDATA_VALUE
プロシージャ、あるいはCloud Controlを使用します。SET_JOB_ANYDATA_VALUE
は、VARCHAR2
文字列として表現できない複雑なデータ型に使用されます。 - ジョブ属性の追加設定
ジョブの作成後に、SET_ATTRIBUTE
またはSET_JOB_ATTRIBUTES
プロシージャを使用して、追加のジョブ属性を設定したり、属性値を変更できます。 - デタッチ済ジョブの作成
デタッチ済ジョブでは、detached
属性がTRUE
に設定されているプログラム・オブジェクト(プログラム)を指し示す必要があります。 - 単一トランザクションでの複数ジョブの作成
多数のジョブを作成する必要がある場合は、CREATE_JOBS
プロシージャを使用すると、トランザクションのオーバーヘッドを減らしてパフォーマンスを改善できる可能性があります。 - 外部ジョブの手法
この項では、次の例を通して、外部ジョブに関するいくつかの実践的手法を示します。
親トピック: ジョブの作成、実行および管理
29.2.2.1 ジョブ作成の概要
1つ以上のジョブを作成するには、DBMS_SCHEDULER.CREATE_JOB
またはDBMS_SCHEDULER.CREATE_JOBS
プロシージャ、あるいはCloud Controlを使用します。
単一のジョブを作成するには、CREATE_JOB
プロシージャを使用します。このプロシージャを使用して、異なるオブジェクトに基づく様々なタイプの複数のジョブを作成するとオーバーロードになります。単一トランザクションに複数のジョブを作成する場合は、CREATE_JOBS
プロシージャを使用してください。
自分のスキーマにジョブを作成するにはCREATE
JOB
権限が、SYS
以外のすべてのスキーマにジョブを作成するにはCREATE
ANY
JOB
権限が必要です。
作成される各ジョブに対して、ジョブ・タイプ、処理およびスケジュールを指定します。必要応じて、資格証明の名前、宛先や宛先グループ名、ジョブ・クラスおよび他の属性も指定できます。ジョブを有効にするとすぐに、スケジュールされた次の日付と時刻に、スケジューラによってジョブが自動的に実行されます。デフォルトでは、作成時にジョブは無効になっており、DBMS_SCHEDULER.ENABLE
で有効にして実行する必要があります。CREATE_JOB
プロシージャのenabled
引数をTRUE
に設定することもできます。その場合、ジョブを作成するとすぐに、スケジュールに従ってジョブを自動的に実行する準備が整います。
一部のジョブ属性はCREATE_JOB
では設定できないため、かわりにDBMS_SCHEDULER.SET_ATTRIBUTE
で設定する必要があります。たとえば、ジョブにlogging_level
属性を設定するには、CREATE_JOB
をコールした後、SET_ATTRIBUTE
をコールする必要があります。
schema.job_name
を指定すると、別のスキーマ内にジョブを作成できます。したがって、ジョブの作成者がジョブの所有者であるとはかぎりません。ジョブの所有者は、ジョブが作成されるスキーマを所有しているユーザーです。実行時のジョブのNLS環境は、そのジョブが作成された時点に存在していた環境です。
次の例では、売上集計表を更新するOPS
スキーマのパッケージ・プロシージャをコールする、update_sales
というデータベース・ジョブの作成について説明します。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'update_sales', job_type => 'STORED_PROCEDURE', job_action => 'OPS.SALES_PKG.UPDATE_SALES_SUMMARY', start_date => '28-APR-08 07.00.00 PM Australia/Sydney', repeat_interval => 'FREQ=DAILY;INTERVAL=2', /* every other day */ end_date => '20-NOV-08 07.00.00 PM Australia/Sydney', auto_drop => FALSE, job_class => 'batch_update_jobs', comments => 'My new job'); END; /
destination_name
属性は指定されていないため、ジョブは作成元の(ローカル)データベースで実行されます。ジョブは、ジョブを作成したユーザーとして実行されます。
repeat_interval
引数では、このジョブが終了日時に達するまで1日おきに実行されるように指定しています。繰返しジョブの実行回数を制限するもう1つの方法として、max_runs
属性を正の数に設定する方法があります。
ジョブの作成時、デフォルトではジョブは使用禁止になっています。ジョブは、スケジューラによって自動的に実行される前に、DBMS_SCHEDULER.ENABLE
で使用可能にする必要があります。
ジョブは、デフォルトでは完了後に自動的に削除されるように設定されています。auto_drop
属性をFALSE
に設定すると、ジョブは保持されます。繰返しジョブは、ジョブ終了日をすぎるか、最大実行回数(max_runs
)または最大失敗回数(max_failures
)に達するまでは自動削除されないことに注意してください。
作成したジョブは、*_SCHEDULER_JOBS
ビューを使用して問い合せることができます。
関連項目:
親トピック: ジョブの作成
29.2.2.2 ジョブの処理、スケジュール、プログラムおよびスタイルの指定
CREATE_JOB
プロシージャはオーバーロードになるため、複数の異なる使用方法があります。
「ジョブの作成の概要」の例で示しているように、ジョブの処理とジョブの繰返し間隔をジョブ属性として指定することに加えて(インラインでのジョブ処理とジョブ・スケジュールの指定とも呼ばれる)、ジョブの処理を指定するプログラム・オブジェクト(プログラム)、繰返し間隔を指定するスケジュール・オブジェクト(スケジュール)、またはプログラムとスケジュールの両方を指すジョブを作成できます。ジョブのプログラムとジョブ・スタイルを指定してジョブを作成することもできます。
- 名前付きプログラムを使用したジョブの作成
ジョブの処理をインラインで記述するかわりに、名前付きプログラムを指し示してジョブを作成することもできます。 - 名前付きプログラムとジョブ・スタイルを使用したジョブの作成
名前付きプログラムとジョブ・スタイルを使用してジョブを作成できます。使用できるジョブ・スタイルは、'REGULAR'
、'LIGHTWEIGHT
'、'IN_MEMORY_RUNTIME'
および'IN_MEMORY_FULL
'です。 - 名前付きスケジュールを使用したジョブの作成
ジョブのスケジュールをインラインにするかわりに、名前付きスケジュールを指すことにより、ジョブを作成することができます。 - 名前付きプログラムとスケジュールを使用したジョブの作成
名前付きプログラムと名前付きスケジュールの両方を指すことにより、ジョブを作成することができます。
親トピック: ジョブの作成
29.2.2.2.1 名前付きプログラムを使用したジョブの作成
ジョブの処理をインラインで記述するかわりに、名前付きプログラムを指し示してジョブを作成することもできます。
名前付きプログラムを使用してジョブを作成するには、ジョブの作成時にCREATE_JOB
プロシージャでprogram_name
の値を指定し、job_type
、job_action
およびnumber_of_arguments
の値は指定しません。
既存のプログラムを使用してジョブを作成するには、ジョブの所有者がプログラムの所有者であるか、プログラムに対するEXECUTE
権限を持っている必要があります。次のPL/SQLブロックは、my_new_job1
という標準ジョブを作成する名前付きプログラムが指定されたCREATE_JOB
プロシージャの例です。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'my_new_job1', program_name => 'my_saved_program', repeat_interval => 'FREQ=DAILY;BYHOUR=12', comments => 'Daily at noon'); END; /
29.2.2.2.2 名前付きプログラムとジョブ・スタイルを使用したジョブの作成
名前付きプログラムとジョブ・スタイルを使用してジョブを作成できます。使用できるジョブ・スタイルは、'REGULAR'
、'LIGHTWEIGHT
'、'IN_MEMORY_RUNTIME'
および'IN_MEMORY_FULL
'です。
デフォルトのジョブ・スタイルは'REGULAR'
で、ジョブ・スタイルが指定されない場合使用されます。他のジョブ・タイプの例を次に示します。
LIGHTWEIGHT
ジョブ
次のPL/SQLブロックでは、軽量ジョブが作成されます。軽量ジョブは1つのプログラムを参照する必要があり、プログラム・タイプは'PLSQL_BLOCK
'または'STORED_PROCEDURE
'であることが必要です。さらに、プログラムはジョブの作成時に使用可能になっている必要があります。
BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'my_lightweight_job1',
program_name => 'polling_prog_n2',
repeat_interval => 'FREQ=SECONDLY;INTERVAL=10',
end_date => '30-APR-09 04.00.00 AM Australia/Sydney',
job_style => 'LIGHTWEIGHT',
comments => 'Job that polls device n2 every 10 seconds');
END;
/
IN_MEMORY_RUNTIME
ジョブ
次のPL/SQLブロックはインメモリー・ランタイム・ジョブを作成します。インメモリー・ランタイム・ジョブの要件および制約は、ライトウェイト・ジョブと同じです。
BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'my_repeat_job',
program_name => 'repeat_prog',
start_date => systimestamp,
repeat_interval => 'freq=secondly;interval=10',
job_style => 'IN_MEMORY_RUNTIME',
enabled => true);
END;
/
IN_MEMORY_FULL
ジョブ
次のPL/SQLはインメモリー・フル・ジョブを作成します。インメモリー・フル・ジョブにはプログラムが必要であり、スケジュールまたは繰返し間隔は指定できません。ジョブが有効にされると自動的に実行され、実行後に破棄されます。
BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'my_immediate_job',
program_name => 'fast_op',
job_style => 'IN_MEMORY_FULL',
enabled => true);
END;
/
関連項目:
29.2.2.2.3 名前付きスケジュールを使用したジョブの作成
ジョブのスケジュールをインラインにするかわりに、名前付きスケジュールを指すことにより、ジョブを作成することができます。
名前付きスケジュールを使用してジョブを作成するには、ジョブの作成時にCREATE_JOB
プロシージャでschedule_name
の値を指定し、start_date
、repeat_interval
およびend_date
の値は指定しません。
すべてのスケジュールはPUBLIC
に対するアクセス権限付きで作成されるため、任意の名前付きスケジュールを使用してジョブを作成できます。次のCREATE_JOB
プロシージャには名前付きスケジュールがあり、my_new_job2
という標準ジョブを作成します。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'my_new_job2', job_type => 'PLSQL_BLOCK', job_action => 'BEGIN SALES_PKG.UPDATE_SALES_SUMMARY; END;', schedule_name => 'my_saved_schedule'); END; /
29.2.2.2.4 名前付きプログラムとスケジュールを使用したジョブの作成
名前付きプログラムと名前付きスケジュールの両方を指すことにより、ジョブを作成することができます。
たとえば、次のCREATE_JOB
プロシージャは、既存のプログラムmy_saved_program1
および既存のスケジュールmy_saved_schedule1
に基づいて、標準ジョブをmy_new_job3
という名前で作成します。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'my_new_job3', program_name => 'my_saved_program1', schedule_name => 'my_saved_schedule1'); END; /
29.2.2.3 スケジューラ・ジョブの資格証明の指定
Oracle Schedulerには、実行前にOracle Databaseまたはオペレーティング・システムでの認証に使用するジョブの資格証明が必要です。
ローカル外部ジョブ、リモート外部ジョブおよびリモート・データベース・ジョブの場合、ジョブを実行するための資格証明を指定する必要があります。そのためには、資格証明オブジェクトを作成して、それをcredential_name
ジョブ属性に割り当てます。
ノート:
ローカル・データベース・ジョブは常にジョブ所有者のユーザーとして実行され、名前付き資格証明は無視されます。
資格証明を作成するには、DBMS_CREDENTIAL.CREATE_CREDENTIAL
プロシージャをコールします。
自分のスキーマに資格証明を作成するにはCREATE
CREDENTIAL
権限が、SYS
以外のスキーマに資格証明を作成するにはCREATE
ANY
CREDENTIAL
権限が必要です。資格証明を使用できるのは、資格証明のEXECUTE
権限がジョブの所有者に付与されているジョブ、またはジョブの所有者が資格証明の所有者を兼ねているジョブのみです。資格証明は他のスキーマ・オブジェクトのようにスキーマに属しているため、資格証明に対する権限はGRANT
SQL文を使用して付与します。
例29-1 資格証明の作成
BEGIN DBMS_CREDENTIAL.CREATE_CREDENTIAL('DW_CREDENTIAL', 'dwuser', 'dW001515'); END; / GRANT EXECUTE ON DW_CREDENTIAL TO salesuser;
データベース内の資格証明のリストを表示するには、*_CREDENTIALS
ビューを問い合せます。資格証明パスワードは不明瞭化されて格納されるため、これらのビューには表示されません。
ノート:
*_SCHEDULER_CREDENTIALS
はOracle Database 12cでは非推奨ですが、下位互換性のために引き続き使用できます。
関連項目:
DBMS_CREDENTIAL.CREATE_CREDENTIAL
プロシージャを使用した資格証明の作成の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
親トピック: ジョブの作成
29.2.2.4 宛先の指定
リモート外部ジョブおよびリモート・データベース・ジョブの場合は、宛先オブジェクトを作成してdestination_name
ジョブ属性に割り当てることにより、ジョブの宛先を指定します。NULL
のdestination_name
属性が指定されたジョブは、ジョブが作成されたホストで実行されます。
- 宛先のタスクとそのプロシージャ
宛先のタスクは、DBMS_SCHEDULER
パッケージのプロシージャを使用して管理します。 - 宛先の作成
宛先とは、ジョブを実行する場所を定義したスケジューラ・オブジェクトです。 - 複数の宛先のジョブに対する宛先グループの作成
複数の宛先で実行するジョブを作成するには、宛先グループを作成して、そのグループをジョブのdestination_name
属性に割り当てる必要があります。 - 例: リモート・データベース・ジョブの作成
リモート・データベース・ジョブを作成する例を示します。
親トピック: ジョブの作成
29.2.2.4.1 宛先のタスクとそのプロシージャ
宛先のタスクは、DBMS_SCHEDULER
パッケージのプロシージャを使用して管理します。
表29-2に、宛先のタスクとそのプロシージャおよび権限を示します。
表29-2 宛先のタスクとそのプロシージャ
タスク | プロシージャ | 必要な権限 |
---|---|---|
外部宛先の作成 |
(なし) |
「宛先の作成」を参照 |
外部宛先の削除 |
|
|
データベース宛先の作成 |
|
|
データベース宛先の削除 |
|
|
宛先グループの作成 |
|
|
宛先グループの削除 |
|
|
宛先グループへのメンバーの追加 |
|
|
宛先グループからのメンバーの削除 |
|
|
親トピック: 宛先の指定
29.2.2.4.2 宛先の作成
宛先とは、ジョブを実行する場所を定義したスケジューラ・オブジェクトです。
ジョブが実行される場所を指定するには、ジョブのdestination_name
属性に単一の宛先または宛先グループを指定します。destination_name
属性をNULL
のままにすると、ジョブはローカル・ホスト(ジョブが作成されたホスト)で実行されます。
リモート外部ジョブが実行される場所を指定するには、外部宛先を使用します。リモート・データベース・ジョブが実行される場所を指定するには、データベース宛先を使用します。
別のユーザーが作成した宛先を使用するのにオブジェクト権限は必要ありません。
外部宛先を作成するには、リモート・スケジューラ・エージェントをデータベースに登録します。
手順は、「リモート・ホストでのスケジューラ・エージェントのインストールと構成」を参照してください。
ノート:
外部宛先を作成するためのDBMS_SCHEDULER
パッケージ・プロシージャはありません。外部宛先は、リモート・エージェントを登録することによって暗黙的に作成します。
リモート・ジョブのターゲットになるホストで他のデータベース・インスタンスを実行している場合は、ローカル・スケジューラ・エージェントも登録できます。この場合、ローカル・ホストを参照する外部宛先が作成されます。
外部宛先の名前は自動的にエージェント名に設定されます。外部宛先が作成されたかどうかを確認するには、DBA_SCHEDULER_EXTERNAL_DESTS
ビューまたはALL_SCHEDULER_EXTERNAL_DESTS
ビューを問い合せます。
データベース宛先を作成するには、DBMS_SCHEDULER.CREATE_DATABASE_DESTINATION
プロシージャをコールします。
プロシージャの引数として外部宛先の名前を指定する必要があります。これにより、データベース宛先が指し示すリモート・ホストが指定されます。また、ネット・サービス名を指定したり、接続先のデータベース・インスタンスを識別する接続記述子を入力します。ネット・サービス名を指定した場合、その名前はローカルのtnsnames.ora
ファイルで解決される必要があります。データベース・インスタンスを指定しなかった場合、リモート・スケジューラ・エージェントは、エージェント構成ファイルに指定されているデフォルトのデータベースに接続されます。
データベース宛先を作成するには、CREATE JOB
システム権限が必要です。自身のスキーマ以外のスキーマにデータベース接続先を作成するには、CREATE ANY JOB
権限が必要です。
例29-2 データベース宛先の作成
次の例では、DBHOST1_ORCLDW
という名前のデータベース宛先を作成しています。この例では、次のことを想定しています。
-
リモート・ホスト
dbhost1.example.com
にスケジューラ・エージェントをインストールし、そのエージェントをローカル・データベースに登録していること。 -
エージェント構成ファイル内のエージェント名の設定を変更していないこと。つまり、エージェント名および外部宛先の名前がデフォルトの
DBHOST1
に設定されていること。 -
ローカル・ホスト上のNet Configuration Assistantを使用して、リモート・ホスト
dbhost1.example.com
に存在するorcldw
という名前のOracle Databaseインスタンスに対してtnsnames.ora内に接続記述子を作成していること。また、ORCLDW
のネット・サービス名(別名)をこの接続記述子に割り当てていること。
BEGIN DBMS_SCHEDULER.CREATE_DATABASE_DESTINATION ( destination_name => 'DBHOST1_ORCLDW', agent => 'DBHOST1', tns_name => 'ORCLDW', comments => 'Instance named orcldw on host dbhost1.example.com'); END; /
データベース宛先が作成されたかどうかを確認するには、*_SCHEDULER_DB_DESTS
ビューを問い合せます。
29.2.2.4.3 複数の宛先のジョブに対する宛先グループの作成
複数の宛先で実行するジョブを作成するには、宛先グループを作成して、そのグループをジョブのdestination_name
属性に割り当てる必要があります。
グループの作成時にグループ・メンバー(宛先)を指定することも、後でグループ・メンバーを追加することもできます。
宛先グループを作成するには、DBMS_SCHEDULER.CREATE_GROUP
プロシージャをコールします。
リモート外部ジョブの場合、EXTERNAL_DEST
タイプのグループを指定し、すべてのグループ・メンバーを外部宛先にする必要があります。リモート・データベース・ジョブの場合、DB_DEST
タイプのグループを指定し、すべてのメンバーをデータベース宛先にする必要があります。
宛先グループのメンバーは、次の形式で指定する必要があります。
[[schema.]credential@][schema.]destination
ここで:
-
credential
は、既存の資格証明の名前です。 -
destination
は、既存のデータベース宛先または外部宛先の名前です。
接続先メンバーの資格証明部分はオプションです。省略すると、この接続先メンバーを使用するジョブはデフォルトの資格証明を使用します。
同じタイプの別のグループを宛先グループのメンバーとして含めることができます。グループの作成時に別のグループを含めた場合、その中に含まれるメンバーはスケジューラによって自動的に展開されます。
ジョブを実行する多数の宛先の1つとしてローカル・ホストを使用する場合、どちらのタイプの宛先グループのグループ・メンバーとしてもLOCAL
キーワードを指定できます。外部宛先グループの場合にかぎり、LOCAL
の前に資格証明の接頭辞を付けることができます。
グループの所有者は、そのグループを作成したユーザーです。自分のスキーマにグループを作成するにはCREATE
JOB
システム権限が必要になり、別のスキーマにグループを作成するにはCREATE
ANY
JOB
システム権限が必要になります。SELECT
をグループに付与することによって、グループのオブジェクト権限を他のユーザーに付与できます。
関連項目:
グループの概要については、「グループ」を参照してください。
例29-3 データベース宛先グループの作成
次の例では、データベース宛先グループを作成しています。一部のメンバーには資格証明がないため、この宛先グループを使用するジョブではデフォルトの資格証明を使用する必要があります。
BEGIN DBMS_SCHEDULER.CREATE_GROUP( GROUP_NAME => 'all_dbs', GROUP_TYPE => 'DB_DEST', MEMBER => 'oltp_admin@orcl, orcldw1, LOCAL', COMMENTS => 'All databases managed by me'); END; /
次のコードでは、グループに別のメンバーを追加しています。
BEGIN DBMS_SCHEDULER.ADD_GROUP_MEMBER( GROUP_NAME => 'all_dbs', MEMBER => 'dw_admin@orcldw2'); END; /
親トピック: 宛先の指定
29.2.2.4.4 例: リモート・データベース・ジョブの作成
リモート・データベース・ジョブを作成する例を示します。
次の例では、ジョブのdestination_name
オブジェクトにデータベース宛先オブジェクトを指定することで、リモート・データベース・ジョブを作成しています。リモート・データベースでジョブを認証できるように、資格証明も指定する必要があります。この例では、例29-1で作成した資格証明および例29-2で作成したデータベース宛先を使用しています。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'SALES_SUMMARY1', job_type => 'STORED_PROCEDURE', job_action => 'SALES.SALES_REPORT1', start_date => '15-JUL-09 11.00.00 PM Europe/Warsaw', repeat_interval => 'FREQ=DAILY', credential_name => 'DW_CREDENTIAL', destination_name => 'DBHOST1_ORCLDW'); END; /
親トピック: 宛先の指定
29.2.2.5 複数の宛先のジョブの作成
複数の宛先で実行し、1箇所で管理するジョブを作成できます。
このようにする代表的な理由としては、管理対象のすべてのデータベースでデータベース・メンテナンス・ジョブを実行することがあげられます。各データベースでジョブを作成するのではなく、ジョブを1つ作成し、そのジョブに対して複数の宛先を指定します。ジョブを作成したデータベース(local database)から、すべての場所のジョブのすべてのインスタンスの状態と結果を監視できます。
複数の宛先のジョブを作成するには:
-
DBMS_SCHEDULER.CREATE_JOB
プロシージャをコールして、ジョブのdestination_name
属性にデータベース宛先グループまたは外部宛先グループの名前を設定します。一部の宛先グループ・メンバーに資格証明の接頭辞(スキーマ)が付いていない場合、ジョブにデフォルトの資格証明を割り当てます。
ジョブを実行する宛先の1つとしてローカル・ホストまたはローカル・データベースを使用するには、
LOCAL
キーワードを宛先グループのメンバーの1つにする必要があります。
宛先グループのリストを取得するには、次の問合せを発行します。
SELECT owner, group_name, group_type, number_of_members FROM all_scheduler_groups WHERE group_type = 'DB_DEST' or group_type = 'EXTERNAL_DEST'; OWNER GROUP_NAME GROUP_TYPE NUMBER_OF_MEMBERS --------------- --------------- ------------- ----------------- DBA1 ALL_DBS DB_DEST 4 DBA1 ALL_HOSTS EXTERNAL_DEST 4
次の例では、例29-3で作成したデータベース宛先グループを使用して、複数の宛先のデータベース・ジョブを作成しています。資格証明に指定したユーザーには、ジョブ・アクションを実行する十分な権限が必要です。
BEGIN DBMS_CREDENTIAL.CREATE_CREDENTIAL('DBA_CREDENTIAL', 'dba1', 'sYs040533'); DBMS_SCHEDULER.CREATE_JOB ( job_name => 'MAINT_SET1', job_type => 'STORED_PROCEDURE', job_action => 'MAINT_PROC1', start_date => '15-JUL-09 11.00.00 PM Europe/Warsaw', repeat_interval => 'FREQ=DAILY', credential_name => 'DBA_CREDENTIAL', destination_name => 'ALL_DBS'); END; /
関連項目:
親トピック: ジョブの作成
29.2.2.6 ジョブ引数の設定
ジョブ引数を設定するには、SET_JOB_ARGUMENT_VALUE
またはSET_JOB_ANYDATA_VALUE
プロシージャ、あるいはCloud Controlを使用します。SET_JOB_ANYDATA_VALUE
は、VARCHAR2
文字列として表現できない複雑なデータ型に使用されます。
ジョブの作成後、次の場合にジョブ引数の設定が必要な場合があります。
-
インラインのジョブ処理が、引数を必要とするストアド・プロシージャまたはその他の実行可能ファイルの場合
-
ジョブが名前付きプログラム・オブジェクトを参照していて、そのデフォルト・プログラム引数の1つ以上を上書きする場合
-
ジョブが名前付きプログラム・オブジェクトを参照していて、そのプログラム引数の1つ以上にデフォルト値が割り当てられていない場合
引数を必要とする場合があるジョブの例の1つに、開始日と終了日が必要なレポート作成プログラムを開始するジョブがあります。次のコード例では、レポート作成プログラムの2番目の引数である終了日のジョブ引数が設定されます。
BEGIN
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE (
job_name => 'ops_reports',
argument_position => 2,
argument_value => '12-DEC-03');
END;
/
値がすでに設定されている引数についてこのプロシージャを使用すると、その引数は上書きされます。引数値を設定するには、引数名または引数の位置を使用します。引数名を使用するには、ジョブが名前付きプログラム・オブジェクトを参照し、そのプログラム・オブジェクト内で引数に名前が割り当てられている必要があります。プログラムがインラインで記述されている場合にサポートされるのは、位置による設定のみです。引数は、タイプがPLSQL_BLOCK
のジョブに対してはサポートされません。
設定されている値を削除するには、RESET_JOB_ARGUMENT
プロシージャを使用します。このプロシージャは、通常の引数およびANYDATA
引数の両方に使用できます。
SET_JOB_ARGUMENT_VALUE
では、SQLタイプの引数のみがサポートされます。したがって、SQLタイプではない引数の値(ブール値など)は、プログラムまたはジョブ引数としてサポートされません。
関連項目:
親トピック: ジョブの作成
29.2.2.7 ジョブ属性の追加設定
ジョブの作成後に、SET_ATTRIBUTE
またはSET_JOB_ATTRIBUTES
プロシージャを使用して、追加のジョブ属性を設定したり、属性値を変更できます。
また、Cloud Controlを使用してジョブ属性を設定することもできます。ジョブ属性の多くはCREATE_JOB
のコールを使用して設定できますが、destination
やcredential_name
などの一部の属性は、ジョブの作成後にSET_ATTRIBUTE
またはSET_JOB_ATTRIBUTES
を使用することによってのみ設定できます。
親トピック: ジョブの作成
29.2.2.8 デタッチ済ジョブの作成
デタッチ済ジョブでは、detached
属性がTRUE
に設定されているプログラム・オブジェクト(プログラム)を指し示す必要があります。
次のLinuxとUNIXの例では、データベースのコールド・バックアップを実行する夜間ジョブを作成しています。これには、3つのステップが含まれています。
ステップ1: RMAN起動スクリプトの作成
コールド・バックアップを実行するRMANスクリプトを呼び出すシェル・スクリプトを作成します。このシェル・スクリプトは$ORACLE_HOME/scripts/coldbackup.shに置かれます。これは、Oracle Databaseをインストールしたユーザー(通常はユーザーoracle
)が実行できる必要があります。
#!/bin/sh export ORACLE_HOME=/u01/app/oracle/product/18.0.0/db_1 export ORACLE_SID=orcl export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib $ORACLE_HOME/bin/rman TARGET / @$ORACLE_HOME/scripts/coldbackup.rman trace /u01/app/oracle/backup/coldbackup.out & exit 0
ステップ2: RMANスクリプトの作成
コールド・バックアップを実行してからジョブを終了する、RMANスクリプトを作成します。このスクリプトは$ORACLE_HOME/scripts/coldbackup.rmanに置かれます。
run { # Shut down database for backups and put into MOUNT mode shutdown immediate startup mount # Perform full database backup backup full format "/u01/app/oracle/backup/%d_FULL_%U" (database) ; # Open database after backup alter database open; # Call notification routine to indicate job completed successfully sql " BEGIN DBMS_SCHEDULER.END_DETACHED_JOB_RUN(''sys.backup_job'', 0, null); END; "; }
ステップ3: ジョブの作成とデタッチ済プログラムの使用
次のPL/SQLブロックを発行します。
BEGIN
DBMS_SCHEDULER.CREATE_PROGRAM(
program_name => 'sys.backup_program',
program_type => 'executable',
program_action => '?/scripts/coldbackup.sh',
enabled => TRUE);
DBMS_SCHEDULER.SET_ATTRIBUTE('sys.backup_program', 'detached', TRUE);
DBMS_SCHEDULER.CREATE_JOB(
job_name => 'sys.backup_job',
program_name => 'sys.backup_program',
repeat_interval => 'FREQ=DAILY;BYHOUR=1;BYMINUTE=0');
DBMS_SCHEDULER.ENABLE('sys.backup_job');
END;
/
関連項目:
親トピック: ジョブの作成
29.2.2.9 単一トランザクションでの複数ジョブの作成
多数のジョブを作成する必要がある場合は、CREATE_JOBS
プロシージャを使用すると、トランザクションのオーバーヘッドを減らしてパフォーマンスを改善できる可能性があります。
例29-4に、このプロシージャを使用して単一トランザクションで複数のジョブを作成する方法を示します。
例29-4 単一トランザクションでの複数ジョブの作成
DECLARE
newjob sys.job_definition;
newjobarr sys.job_definition_array;
BEGIN
-- Create an array of JOB_DEFINITION object types
newjobarr := sys.job_definition_array();
-- Allocate sufficient space in the array
newjobarr.extend(5);
-- Add definitions for 5 jobs
FOR i IN 1..5 LOOP
-- Create a JOB_DEFINITION object type
newjob := sys.job_definition(job_name => 'TESTJOB' || to_char(i),
job_style => 'REGULAR',
program_name => 'PROG1',
repeat_interval => 'FREQ=HOURLY',
start_date => systimestamp + interval '600' second,
max_runs => 2,
auto_drop => FALSE,
enabled => TRUE
);
-- Add it to the array
newjobarr(i) := newjob;
END LOOP;
-- Call CREATE_JOBS to create jobs in one transaction
DBMS_SCHEDULER.CREATE_JOBS(newjobarr, 'TRANSACTIONAL');
END;
/
PL/SQL procedure successfully completed.
SELECT JOB_NAME FROM USER_SCHEDULER_JOBS;
JOB_NAME
------------------------------
TESTJOB1
TESTJOB2
TESTJOB3
TESTJOB4
TESTJOB5
5 rows selected.
29.2.2.10 外部ジョブの手法
この項では、次の例を通して、外部ジョブに関するいくつかの実践的手法を示します。
例29-5 コマンド・インタプリタを実行するローカル外部ジョブの作成
次の例に、Windows上でインタプリタ・コマンド(この例ではmkdir
)を実行するローカル外部ジョブの作成方法を示します。このジョブでは、/c
オプションを指定してcmd.exe
が実行されます。
BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name => 'MKDIR_JOB', job_type => 'EXECUTABLE', number_of_arguments => 3, job_action => '\windows\system32\cmd.exe', auto_drop => FALSE, credential_name => 'TESTCRED'); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('mkdir_job',1,'/c'); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('mkdir_job',2,'mkdir'); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('mkdir_job',3,'\temp\extjob_test_dir'); DBMS_SCHEDULER.ENABLE('MKDIR_JOB'); END; /
例29-6 ローカル外部ジョブの作成とジョブ出力の表示
LinuxおよびUNIX用のこの例では、ローカル外部ジョブを作成および実行してから、ジョブ出力を表示する方法を示します。外部ジョブが実行されると、スケジューラはジョブから出力を自動的に取得し、データベース内に格納します。
結果を確認するには、 *_SCHEDULER_JOB_RUN_DETAILS
ビューを問い合せます。
-- User scott must have CREATE JOB, CREATE CREDENTIAL, and CREATE EXTERNAL JOB
-- privileges
GRANT CREATE JOB, CREATE EXTERNAL JOB TO scott ;
CONNECT scott/password
SET SERVEROUTPUT ON
-- Create a credential for the job to use
exec DBMS_CREDENTIAL.CREATE_CREDENTIAL('my_cred','host_username','host_passwd')
-- Create a job that lists a directory. After running, the job is dropped.
BEGIN
DBMS_SCHEDULER.CREATE_JOB(
job_name => 'lsdir',
job_type => 'EXECUTABLE',
job_action => '/bin/ls',
number_of_arguments => 1,
enabled => false,
auto_drop => true,
credential_name => 'my_cred');
DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('lsdir',1,'/tmp');
DBMS_SCHEDULER.ENABLE('lsdir');
END;
/
-- Wait a bit for the job to run, and then check the job results.
SELECT job_name, status, error#, actual_start_date, additional_info
FROM user_scheduler_job_run_details WHERE job_name='LSDIR';
-- Now use the external log id from the additional_info column to
-- formulate the log file name and retrieve the output
DECLARE
my_clob clob;
log_id varchar2(50);
BEGIN
SELECT regexp_substr(additional_info,'job[_0-9]*') INTO log_id
FROM user_scheduler_job_run_details WHERE job_name='LSDIR';
DBMS_LOB.CREATETEMPORARY(my_clob, false);
SELECT job_name, status, error#, errors, output FROM user_scheduler_job_run_details WHERE job_name = 'LSDIR';
END;
/
関連項目:
-
外部認証の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
親トピック: ジョブの作成
29.2.3 ジョブの変更
ジョブを変更するには、その属性を変更します。そのためには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
、SET_ATTRIBUTE_NULL
またはSET_JOB_ATTRIBUTES
プロシージャまたはCloud Controlを使用します。
ジョブ属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のCREATE_JOB
プロシージャに関する項を参照してください。
すべてのジョブは変更可能で、ジョブ名以外のすべてのジョブ属性を変更できます。変更する際に実行中のジョブ・インスタンスがある場合、そのインスタンスはこのコールによる影響を受けません。このプロシージャによる変更は、今後実行されるジョブに対してのみ反映されます。
通常、データベースによって自動的に作成されたジョブは変更しないでください。データベースによって作成されたジョブには、ジョブのビューでTRUE
に設定された列SYSTEM
があります。ジョブの属性は、*_SCHEDULER_JOBS
ビューで使用可能です。
実行中のジョブのジョブ属性も変更できます。ただし、その変更は、スケジュールされている次回のジョブ実行時まで反映されません。
SET_ATTRIBUTE
、SET_ATTRIBUTE_NULL
およびSET_JOB_ATTRIBUTES
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
次の例では、ジョブupdate_sales
のrepeat_interval
を毎週水曜日の1回に変更しています。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'update_sales', attribute => 'repeat_interval', value => 'freq=weekly; byday=wed'); END; /
親トピック: ジョブの作成、実行および管理
29.2.4 ジョブの実行
いくつかの異なる方法でジョブを実行できます。
ジョブを実行するには、次の3つの方法があります。
-
ジョブ・スケジュールに従って実行する方法: この場合、ジョブが有効であれば、スケジューラ・ジョブ・コーディネータによって自動的にジョブが取り出され、ジョブ・スレーブの制御下で実行されます。ジョブは、ジョブ所有者のユーザーとして、または資格証明のあるローカル外部ジョブの場合は、資格証明で指定したユーザーとして実行されます。ジョブが成功したかどうかを確認するには、ジョブ・ビュー(
*_SCHEDULER_JOBS
)またはジョブ・ログ(*_SCHEDULER_JOB_LOG
および*_SCHEDULER_JOB_RUN_DETAILS
)で問い合せる必要があります。ジョブ・スレーブおよびスケジューラ・アーキテクチャの詳細は、「ジョブの実行方法」を参照してください。 -
イベントの発生時に実行する方法: イベント・キューで特定のイベントが受信されるか、File Watcherでファイル到着イベントが呼び出されると、使用可能になっているイベントベースのジョブが開始されます ( 「イベントを使用したジョブの開始」 を参照)。(「イベントを使用したジョブの開始」 を参照してください。)または、資格証明を使用するローカル外部ジョブの場合は、資格証明内に指定されているユーザーとして実行されます。ジョブが成功したかどうかを確認するには、ジョブ・ビューまたはジョブ・ログを問い合せる必要があります。
-
DBMS_SCHEDULER.RUN_JOB
を呼び出して実行する方法:RUN_JOB
プロシージャを使用して、ジョブをテストしたり、指定したスケジュール以外で実行できます。ジョブは非同期に実行できますが、これは前の2つのジョブ実行方法、つまり同期して実行する方法に類似しており、この方法ではRUN_JOB
を呼び出したセッションにユーザーがログインするとジョブが実行されます。RUN_JOB
のuse_current_session
引数によって、ジョブが同期または非同期のどちらで実行されるかが決まります。RUN_JOB
では、ジョブ名のカンマ区切りのリストを使用できます。次の例では、2つのジョブを非同期で実行しています。
BEGIN DBMS_SCHEDULER.RUN_JOB( JOB_NAME => 'DSS.ETLJOB1, DSS.ETLJOB2', USE_CURRENT_SESSION => FALSE); END; /
ノート:
スケジュールに従ってジョブを実行する場合は、
RUN_JOB
をコールする必要はありません。ジョブが使用可能であれば、スケジューラによって自動的に実行されます。
親トピック: ジョブの作成、実行および管理
29.2.5 ジョブの停止
1つ以上の実行中のジョブを停止するには、DBMS_SCHEDULER
パッケージのSTOP_JOB
プロシージャまたはCloud Controlを使用します。
STOP_JOB
では、ジョブ、ジョブ・クラスおよびジョブ宛先IDのカンマ区切リストを使用できます。ジョブ宛先IDは、スケジューラによって割り当てられる番号で、ジョブ、資格証明および宛先の一意の組合せを表します。これは、複数宛先のジョブの特定の子ジョブを識別して、その子のみを停止するのに便利な方法です。子ジョブのジョブ宛先IDは*_SCHEDULER_JOB_DESTS
のビューから取得します。
ジョブ・クラスが指定されている場合、そのジョブ・クラス内の実行中のジョブはすべて停止されます。たとえば、次の文では、ジョブjob1
、ジョブ・クラスdw_jobs
内のすべてのジョブ、および複数の宛先のジョブに含まれる2つの子ジョブが停止されます。
BEGIN
DBMS_SCHEDULER.STOP_JOB('job1, sys.dw_jobs, 984, 1223');
END;
/
指定したジョブのインスタンスはすべて停止されます。ジョブの停止後、1回かぎりのジョブの状態はSTOPPED
に設定され、繰返しジョブの状態は、(次回のジョブ実行がスケジュールされているため)SCHEDULED
に設定されます。また、ジョブ・ログには、OPERATION
がSTOPPED
に設定され、ADDITIONAL_INFO
がREASON="Stop job called by user:
username"
に設定されたエントリが作成されます。
デフォルトでは、スケジューラは割込みメカニズムを使用してジョブを正常に停止しようとします。この方法では、制御がスレーブ・プロセスに戻され、スレーブ・プロセスはジョブ実行の統計を収集できます。force
オプションがTRUE
に設定されている場合、ジョブは即時に停止するため、そのジョブ実行について特定の実行時間の統計が使用できない場合があります。
チェーンを実行中のジョブを停止すると、実行中のすべてのステップが(各ステップでforce
オプションをTRUE
に設定してSTOP_JOB
をコールすることによって)自動的に停止されます。
STOP_JOB
のcommit_semantics
引数を使用すると、複数のジョブが指定されている場合の結果および1つ以上のジョブを停止しようとしたときに発生するエラーを制御できます。この引数をABSORB_ERRORS
に設定すると、エラーが発生した後もプロシージャを続行して、残りのジョブの停止試行を実行できる場合があります。エラーが発生したことがプロシージャによって示された場合は、エラーの内容を判断するために、ビューSCHEDULER_BATCH_ERRORS
を問い合せることができます。コミット・セマンティクスの詳細は、「ジョブの削除」を参照してください。
STOP_JOB
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
ノート:
ジョブが停止したときにロールバックされるのは、現行トランザクションのみです。これは、データの一貫性を損なう原因になる場合があります。
親トピック: ジョブの作成、実行および管理
29.2.6 外部ジョブの停止
スケジューラを使用している場合、外部ジョブの実装者は、force
がFALSE
に設定されたSTOP_JOB
がコールされた場合に、その外部ジョブを正常にクリーン・アップするメカニズムを利用できます。
この項で説明するメカニズムは、UNIXおよびLinuxプラットフォーム上のリモート外部ジョブにのみ適用されます。
UNIXおよびLinuxでは、スケジューラによって起動されたプロセスにSIGTERM
シグナルが送信されます。外部ジョブの実装者は、割込みハンドラにSIGTERM
をトラップし、ジョブの実装内容をすべてクリーン・アップして終了する必要があります。
Windowsでは、force
がFALSE
に設定されたSTOP_JOB
がサポートされます。スケジューラによって起動されるプロセスがコンソール・プロセスです。このプロセスを停止するために、スケジューラはCTRL+BREAK
をプロセスに送信します。CTRL+BREAK
は、SetConsoleCtrlHandler()
ルーチンにハンドラを登録することによって処理できます。
親トピック: ジョブの作成、実行および管理
29.2.7 チェーン・ジョブの停止
実行中のチェーンを指しているジョブが停止すると、実行中のチェーンのステップがすべて停止します。
個々のチェーン・ステップの停止の詳細は、「個々のチェーン・ステップの停止」を参照してください。
親トピック: ジョブの作成、実行および管理
29.2.8 ジョブの削除
1つ以上のジョブを削除するには、DBMS_SCHEDULER
パッケージのDROP_JOB
プロシージャまたはCloud Controlを使用します。
DROP_JOB
では、ジョブおよびジョブ・クラスのカンマ区切りリストを使用できます。ジョブ・クラスを指定すると、そのジョブ・クラスのすべてのジョブは削除されますが、ジョブ・クラス自体は削除されません。DROP_JOB
でジョブ宛先IDを使用して複数宛先ジョブの子を削除することはできません。
ジョブ・クラスを削除するには、DROP_JOB_CLASS
プロシージャを使用します(「ジョブ・クラスの削除」を参照)。
次の文では、ジョブjob1
とjob3
、およびジョブ・クラスjobclass1
とjobclass2
内のすべてのジョブが削除されます。
BEGIN
DBMS_SCHEDULER.DROP_JOB ('job1, job3, sys.jobclass1, sys.jobclass2');
END;
/
親トピック: ジョブの作成、実行および管理
29.2.9 実行中のジョブの削除
DROP_JOB
プロシージャが呼び出されたときにジョブが実行中である場合、ジョブを削除しようとすると失敗します。このデフォルトの動作は、force
またはdefer
オプションを設定することによって変更できます。
force
オプションをTRUE
に設定すると、最初に、実行中のジョブの停止試行がスケジューラの割込みメカニズム(force
オプションをFALSE
に設定してSTOP_JOB
をコール)によって行われます。ジョブが正常に停止されると、次にそのジョブが削除されます。または、STOP_JOB
を最初にコールしてジョブを停止してから、DROP_JOB
をコールすることもできます。STOP_JOB
が失敗した場合は、force
オプションを設定してSTOP_JOB
をコールできます(この場合、MANAGE SCHEDULER
権限が必要です)。その後、そのジョブを削除できます。デフォルトでは、STOP_JOB
およびDROP_JOB
プロシージャの両方で、force
はFALSE
に設定されています。
defer
オプションをTRUE
に設定すると、実行中のジョブは完了してから削除されます。force
とdefer
オプションは相互に排他的で、両方を設定するとエラーになります。
親トピック: ジョブの作成、実行および管理
29.2.10 複数のジョブの削除
削除する複数のジョブを指定したとき、いずれかのジョブでエラーが発生した場合、その結果はDBMS_SCHEDULER.DROP_JOB
プロシージャのcommit_semantics
引数によって決定されます。
この引数には、次の値を指定できます。
-
STOP_ON_FIRST_ERROR
(デフォルト): 最初のエラーでコールが戻り、エラー発生前に正常終了した削除操作がディスクにコミットされます。 -
TRANSACTIONAL
: 最初のエラーでコールが戻り、エラー発生前の削除操作がロールバックされます。force
がFALSE
に設定されている必要があります。 -
ABSORB_ERRORS
: エラーへの対応が取り組まれ、残りのジョブの削除が試行されて、正常終了したすべての削除操作がコミットされます。
commit_semantics
を設定できるのは、job_name
リストにジョブ・クラスが含まれていない場合のみです。ジョブ・クラスを指定している場合は、デフォルトのコミット・セマンティクス(STOP_ON_FIRST_ERROR
)が適用されます。
次の例では、defer
オプションとTRANSACTIONALコミット・セマンティクスを使用して、ジョブmyjob1
およびmyjob2
を削除しています。
BEGIN
DBMS_SCHEDULER.DROP_JOB(
job_name => 'myjob1, myjob2',
defer => TRUE,
commit_semantics => 'TRANSACTIONAL');
END;
/
次の例では、ABSORB_ERRORS
コミット・セマンティクスを示しています。プロシージャのコール時にmyjob1
が実行されており、myjob2
は実行されていないことを想定しています。
BEGIN
DBMS_SCHEDULER.DROP_JOB(
job_name => 'myjob1, myjob2',
commit_semantics => 'ABSORB_ERRORS');
END;
/
Error report:
ORA-27362: batch API call completed with errors
SCHEDULER_BATCH_ERRORS
ビューを問い合せて、エラーの内容を判断できます。
SELECT object_name, error_code, error_message FROM scheduler_batch_errors; OBJECT_NAME ERROR CODE ERROR_MESSAGE -------------- ---------- --------------------------------------------------- STEVE.MYJOB1 27478 "ORA-27478: job "STEVE.MYJOB1" is running
USER_SCHEDULER_JOBS
を確認すると、myjob2
は正常に削除され、myjob1
は残っていることがわかります。
DROP_JOB
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブの作成、実行および管理
29.2.11 ジョブの無効化
1つ以上のジョブを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャまたはCloud Controlを使用します。
ジョブは他の方法で使用禁止にすることもできます。たとえば、ジョブ・クラスを削除すると、そのクラスのジョブが使用禁止になります。ジョブが指し示しているプログラムまたはスケジュールのいずれかを削除した場合も、使用禁止になります。ただし、ジョブが指し示しているプログラムまたはスケジュールを使用禁止にしてもジョブは使用禁止にならないため、スケジューラがジョブを実行しようとしたときにエラーが発生します。
ジョブを使用禁止にすると、そのジョブのメタデータはそのまま存在しますが、ジョブ自体は実行対象ではないため、ジョブ・コーディネータがこれらのジョブを取り出して処理することはありません。ジョブが使用禁止になると、ジョブ表内のそのstate
はdisabled
に変更されます。
force
オプションをFALSE
に設定して現在実行中のジョブを使用禁止にすると、エラーが返されます。force
がTRUE
に設定されているときは、ジョブは使用禁止になりますが、現在実行中のインスタンスは完了できます。
commit_semantics
がSTOP_ON_FIRST_ERROR
に設定されている場合は、最初のエラーでコールが戻り、エラー発生前に正常終了した使用禁止操作がディスクにコミットされます。commit_semantics
がTRANSACTIONAL
に、force
がFALSE
に設定されている場合は、最初のエラーでコールが戻り、エラー発生前の使用禁止操作がロールバックされます。commit_semantics
がABSORB_ERRORS
に設定されている場合は、エラーへの対応が取り組まれ、残りのジョブの使用禁止が試行されて、正常に終了したすべての使用禁止操作がコミットされます。エラーが発生したことがプロシージャによって示された場合は、エラーの内容を判断するために、ビューSCHEDULER_BATCH_ERRORS
を問い合せることができます。
デフォルトでは、commit_semantics
はSTOP_ON_FIRST_ERROR
に設定されています。
DISABLE
プロシージャ・コールにジョブ名またはジョブ・クラス名のカンマ区切りのリストを指定することで、1回のコールで複数のジョブを使用禁止にすることもできます。たとえば、次の文では、ジョブとジョブ・クラスを組み合せて指定しています。
BEGIN DBMS_SCHEDULER.DISABLE('job1, job2, job3, sys.jobclass1, sys.jobclass2'); END; /
DISABLE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブの作成、実行および管理
29.2.12 ジョブの有効化
1つ以上のジョブを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャまたはCloud Controlを使用します。
このプロシージャを使用すると、ジョブは、ジョブ・コーディネータによって取り出され、処理されるようになります。ジョブは、デフォルトで使用禁止で作成されるため、実行するには使用可能にする必要があります。ジョブを使用可能にすると、妥当性チェックが実行されます。チェックに失敗すると、ジョブは使用可能になりません。
使用禁止のジョブを使用可能にすると、ジョブはスケジュールに従って実行を即時開始します。また、使用禁止のジョブを使用可能にすると、ジョブのRUN_COUNT
、FAILURE_COUNT
およびRETRY_COUNT
属性が再設定されます。
commit_semantics
がSTOP_ON_FIRST_ERROR
に設定されている場合は、最初のエラーでコールが戻り、エラー発生前に正常終了した使用可能にする操作がディスクにコミットされます。commit_semantics
がTRANSACTIONAL
に設定されている場合は、最初のエラーでコールが戻り、エラー発生前の使用可能にする操作がロールバックされます。commit_semantics
がABSORB_ERRORS
に設定されている場合は、エラーへの対応が取り組まれ、残りのジョブを使用可能にする操作が試行されて、正常に終了した使用可能にする操作がすべてコミットされます。エラーが発生したことがプロシージャによって示された場合は、エラーの内容を判断するために、ビューSCHEDULER_BATCH_ERRORS
を問い合せることができます。
デフォルトでは、commit_semantics
はSTOP_ON_FIRST_ERROR
に設定されています。
ENABLE
プロシージャ・コールにジョブ名またはジョブ・クラス名のカンマ区切りのリストを指定することで、1回のコールで複数のジョブを使用可能にすることもできます。たとえば、次の文では、ジョブとジョブ・クラスを組み合せて指定しています。
BEGIN DBMS_SCHEDULER.ENABLE ('job1, job2, job3, sys.jobclass1, sys.jobclass2, sys.jobclass3'); END; /
ENABLE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブの作成、実行および管理
29.2.13 ジョブのコピー
ジョブをコピーするには、DBMS_SCHEDULER
のCOPY_JOB
プロシージャまたはCloud Controlを使用します。
このコールによって、旧ジョブのすべての属性(ジョブ名以外)が新規ジョブにコピーされます。新規ジョブは使用禁止の状態で作成されます。
COPY_JOB
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブの作成、実行および管理
29.3 ジョブを定義するためのプログラムの作成および管理
プログラムは、特定のタスクに関するメタデータの集まりです。必要に応じて、プログラムを使用してジョブの定義を支援できます。
- プログラムのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なプログラム・タスクを管理します。 - スケジューラを使用するプログラムの作成
プログラムでは、スケジューラによって実行される内容が記述されます。 - プログラムの変更
プログラムを変更するには、その属性を変更します。プログラムを変更するには、Cloud ControlまたはDBMS_SCHEDULER.SET_ATTRIBUTE
およびDBMS_SCHEDULER.SET_ATTRIBUTE_NULL
パッケージ・プロシージャを使用します。 - プログラムの削除
1つ以上のプログラムを削除するには、DBMS_SCHEDULER
パッケージのDROP_PROGRAM
プロシージャまたはCloud Controlを使用します。 - プログラムの無効化
1つ以上のプログラムを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャまたはCloud Controlを使用します。 - プログラムの有効化
1つ以上のプログラムを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャまたはCloud Controlを使用します。
関連項目:
プログラムの概要については、「プログラム」を参照してください。
29.3.1 プログラムのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なプログラム・タスクを管理します。
表29-3に、プログラムの一般的なタスクとそれに対応するプロシージャおよび権限を示します。
表29-3 プログラムのタスクとそのプロシージャ
タスク | プロシージャ | 必要な権限 |
---|---|---|
プログラムの作成 |
|
|
プログラムの変更 |
|
|
プログラムの削除 |
|
|
プログラムの使用禁止 |
|
|
プログラムの使用可能化 |
|
|
権限の詳細は、「スケジューラ権限」を参照してください。
親トピック: ジョブを定義するためのプログラムの作成および管理
29.3.2 スケジューラを使用するプログラムの作成
プログラムでは、スケジューラによって実行される内容が記述されます。
- プログラムの作成
プログラムを作成するには、CREATE_PROGRAM
プロシージャまたはCloud Controlを使用します。 - プログラム引数の定義
プログラムを作成した後、プログラムの引数を定義できます。
親トピック: ジョブを定義するためのプログラムの作成および管理
29.3.2.1 プログラムの作成
プログラムを作成するには、CREATE_PROGRAM
プロシージャまたはCloud Controlを使用します。
デフォルトでは、プログラムは作成者のスキーマに作成されます。別のユーザーのスキーマにプログラムを作成するには、スキーマ名でプログラム名を修飾する必要があります。他のユーザーがこのプログラムを使用するには、プログラムに対するEXECUTE
権限が必要であるため、プログラムを作成したら、EXECUTE
権限を付与する必要があります。
次の例では、my_program1
というプログラムを作成しています。
BEGIN DBMS_SCHEDULER.CREATE_PROGRAM ( program_name => 'my_program1', program_action => '/usr/local/bin/date', program_type => 'EXECUTABLE', comments => 'My comments here'); END; /
プログラムは、デフォルトで使用禁止状態で作成されるため、そのプログラムを指し示すジョブを使用可能にするには、プログラムを使用可能にする必要があります。
「プログラム引数の定義」に説明されているDEFINE_
XXX
_ARGUMENT
プロシージャを使用してプログラムのすべての引数を指定する前に、引数が必要なプログラムを使用可能にしないでください。
親トピック: スケジューラを使用するプログラムの作成
29.3.2.2 プログラム引数の定義
プログラムを作成した後、プログラムの引数を定義できます。
引数は、コーリング順序内の位置によって定義し、オプションで引数名とデフォルト値を指定できます。プログラム引数のデフォルト値が定義されていない場合は、そのプログラムを参照するジョブで引数の値を指定する必要があります。(ジョブで、デフォルト値を上書きすることもできます。)すべての引数値を指定しないと、ジョブを有効にできません。
プログラム引数値を設定するには、DEFINE_PROGRAM_ARGUMENT
またはDEFINE_ANYDATA_ARGUMENT
プロシージャを使用します。DEFINE_ANYDATA_ARGUMENT
は、ANYDATA
オブジェクト内にカプセル化する必要がある複雑な型に使用します。引数を必要とする場合があるプログラムの例の1つに、開始日と終了日が必要なレポート作成プログラムを開始するジョブがあります。次のコード例では、レポート作成プログラムの2番目の引数である終了日の引数が設定されます。この例では、SET_JOB_ANYDATA_VALUE
やSET_JOB_ARGUMENT_VALUE
などの他のパッケージ・プロシージャから(位置ではなく)名前で引数を参照できるように、引数に名前が割り当てられています。
BEGIN DBMS_SCHEDULER.DEFINE_PROGRAM_ARGUMENT ( program_name => 'operations_reporting', argument_position => 2, argument_name => 'end_date', argument_type => 'VARCHAR2', default_value => '12-DEC-03'); END; /
argument_type
引数の有効な値はSQLデータ型である必要があるため、ブールはサポートされていません。外部実行可能ファイルの場合、CHAR
やVARCHAR2
などの文字列型のみを使用できます。
プログラム引数は、名前または位置で削除できます。次に例を示します。
BEGIN DBMS_SCHEDULER.DROP_PROGRAM_ARGUMENT ( program_name => 'operations_reporting', argument_position => 2); DBMS_SCHEDULER.DROP_PROGRAM_ARGUMENT ( program_name => 'operations_reporting', argument_name => 'end_date'); END; /
一部の特殊なケースでは、プログラムのロジックがスケジューラの環境によって異なる場合があります。この目的のために、スケジューラには、プログラムに引数として渡すことができる事前定義のメタデータ引数がいくつかあります。たとえば、スケジュールがウィンドウ名である一部のジョブについては、ジョブの開始時にウィンドウがオープンしている時間の長さを認識していると便利です。これは、ウィンドウ終了時間をプログラムに対するメタデータ引数として定義すると可能です。
特定ジョブのメタデータに対するアクセス権限がプログラムに必要な場合は、プログラムの実行時にスケジューラによって値が指定されるように、DEFINE_METADATA_ARGUMENT
プロシージャを使用して特別なメタデータ引数を定義できます。
関連項目:
親トピック: スケジューラを使用するプログラムの作成
29.3.3 プログラムの変更
プログラムを変更するには、その属性を変更します。プログラムを変更するには、Cloud ControlまたはDBMS_SCHEDULER.SET_ATTRIBUTE
およびDBMS_SCHEDULER.SET_ATTRIBUTE_NULL
パッケージ・プロシージャを使用します。
プログラム属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_SCHEDULER.CREATE_PROGRAM
プロシージャに関する項を参照してください。
変更したプログラムが、現在実行中のジョブで使用されている場合、そのジョブは変更操作前に定義されたプログラムで引き続き実行されます。
次の例では、プログラムmy_program1
で実行される実行可能ファイルを変更しています。
BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE (
name => 'my_program1',
attribute => 'program_action',
value => '/usr/local/bin/salesreports1');
END;
/
親トピック: ジョブを定義するためのプログラムの作成および管理
29.3.4 プログラムの削除
1つ以上のプログラムを削除するには、DBMS_SCHEDULER
パッケージのDROP_PROGRAM
プロシージャまたはCloud Controlを使用します。
プログラムが削除されると、そのプログラムに関係する引数もすべて削除されます。プログラム名のカンマ区切りのリストを指定することで、1回のコールで複数のプログラムを削除できます。たとえば、次の文では3つのプログラムが削除されます。
BEGIN DBMS_SCHEDULER.DROP_PROGRAM('program1, program2, program3'); END; /
このプログラムを指定した実行中のジョブは、DROP_PROGRAM
コールの影響を受けずに続行できます。
force
引数をTRUE
に設定すると、このプログラムを指し示しているジョブは使用禁止になり、プログラムは削除されます。force
引数をデフォルトのFALSE
に設定すると、プログラムを指し示すジョブがある場合はコールが失敗します。
DROP_PROGRAM
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブを定義するためのプログラムの作成および管理
29.3.5 プログラムの無効化
1つ以上のプログラムを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャまたはCloud Controlを使用します。
プログラムが使用禁止になると、ステータスがdisabled
に変更されます。使用禁止プログラムとは、メタデータが存在しても、このプログラムを指定したジョブを実行できないことを意味します。
このプログラムを指し示す実行中のジョブはDISABLE
コールの影響を受けず、実行を継続できます。また、プログラムが使用禁止になった場合にも、そのプログラムに関係する引数は影響を受けません。
プログラムは、プログラム引数が削除された場合やnumber_of_arguments
の変更で引数を定義できなくなった場合など、他の理由で使用禁止になる場合もあります。
DISABLE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブを定義するためのプログラムの作成および管理
29.3.6 プログラムの有効化
1つ以上のプログラムを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャまたはCloud Controlを使用します。
プログラムが使用可能になると、使用可能フラグがTRUE
に設定されます。プログラムは、デフォルトで使用禁止で作成されるため、そのプログラムを指し示すジョブを使用可能にするには、プログラムを使用可能にする必要があります。プログラムが使用可能になる前に、処理が有効であること、およびすべての引数が定義されていることを確認するために妥当性チェックが実行されます。
ENABLE
プロシージャ・コールにプログラム名のカンマ区切りのリストを指定することで、1回のコールで複数のプログラムを使用可能にできます。たとえば、次の文では3つのプログラムが使用可能になります。
BEGIN DBMS_SCHEDULER.ENABLE('program1, program2, program3'); END; /
ENABLE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブを定義するためのプログラムの作成および管理
29.4 ジョブを定義するためのスケジュールの作成および管理
必要に応じて、スケジュール・オブジェクト(スケジュール)を使用してジョブの実行時期を定義できます。スケジュールは、データベースにオブジェクトとして作成および保存することによってユーザー間で共有できます。
- スケジュールのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なスケジュール・タスクを管理します。 - スケジュールの作成
スケジュールを作成するには、DBMS_SCHEDULER
パッケージのCREATE_SCHEDULE
プロシージャまたはCloud Controlを使用します。 - スケジュールの変更
スケジュールを変更するには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
およびSET_ATTRIBUTE_NULL
プロシージャまたはCloud Controlを使用します。 - スケジュールの削除
スケジュールを削除するには、DBMS_SCHEDULER
パッケージのDROP_SCHEDULE
プロシージャまたはCloud Controlを使用します。 - 繰返し間隔の設定
ジョブの繰返し時期および頻度を制御できます。
関連項目:
-
スケジュールの概要については、「スケジュール」を参照してください。
-
ジョブ・リソース使用率を管理しながらジョブをスケジュールする方法は、「ウィンドウを使用したジョブ・スケジューリングとジョブ優先度の管理」および「ウィンドウ・グループを使用したジョブ・スケジューリングとジョブ優先度の管理」
29.4.1 スケジュールのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なスケジュール・タスクを管理します。
表29-4に、スケジュールの一般的なタスクとその処理に使用するプロシージャを示します。
表29-4 スケジュールのタスクとそのプロシージャ
タスク | プロシージャ | 必要な権限 |
---|---|---|
スケジュールの作成 |
|
|
スケジュールの変更 |
|
|
スケジュールの削除 |
|
|
詳細は、「スケジューラ権限」を参照してください。
親トピック: ジョブを定義するためのスケジュールの作成および管理
29.4.2 スケジュールの作成
スケジュールを作成するには、DBMS_SCHEDULER
パッケージのCREATE_SCHEDULE
プロシージャまたはCloud Controlを使用します。
スケジュールは、そのスケジュールを作成するユーザーのスキーマ内に作成され、最初に作成した時点で使用可能です。また、別のユーザーのスキーマ内に作成できます。スケジュールが作成されると、他のユーザーもそのスケジュールを使用できます。スケジュールは、PUBLIC
へのアクセス権を伴って作成されます。このため、スケジュールへのアクセス権限を明示的に付与する必要はありません。次の例では、スケジュールを作成しています。
BEGIN DBMS_SCHEDULER.CREATE_SCHEDULE ( schedule_name => 'my_stats_schedule', start_date => SYSTIMESTAMP, end_date => SYSTIMESTAMP + INTERVAL '30' day, repeat_interval => 'FREQ=HOURLY; INTERVAL=4', comments => 'Every 4 hours'); END; /
関連項目:
-
CREATE_SCHEDULE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブを定義するためのスケジュールの作成および管理
29.4.3 スケジュールの変更
スケジュールを変更するには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
およびSET_ATTRIBUTE_NULL
プロシージャまたはCloud Controlを使用します。
スケジュールを変更すると、スケジュールの定義が変更されます。スケジュール名以外のすべての属性を変更できます。スケジュールの属性は、*_SCHEDULER_SCHEDULES
ビューで使用可能です。
スケジュールを変更した場合、この変更は実行中のジョブおよびこのスケジュールを使用するオープン中のウィンドウには影響しません。この変更は、次回ジョブを実行するときまたはウィンドウをオープンするときから有効になります。
SET_ATTRIBUTE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブを定義するためのスケジュールの作成および管理
29.4.4 スケジュールの削除
スケジュールを削除するには、DBMS_SCHEDULER
パッケージのDROP_SCHEDULE
プロシージャまたはCloud Controlを使用します。
このプロシージャ・コールによって、スケジュール・オブジェクトがデータベースから削除されます。
DROP_SCHEDULE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブを定義するためのスケジュールの作成および管理
29.4.5 繰返し間隔の設定
ジョブの繰返し時期および頻度を制御できます。
- 繰返し間隔の設定について
ジョブの繰返し時期および間隔を制御するには、ジョブ自体またはジョブが参照する名前付きスケジュールのrepeat_interval
属性を設定します。repeat_interval
は、DBMS_SCHEDULER
パッケージ・プロシージャまたはCloud Controlで設定できます。 - スケジューラのカレンダ指定構文の使用方法
ジョブの繰返し間隔を設定する主要な方法は、スケジューラのカレンダ指定式を使用してrepeat_interval
属性を設定する方法です。 - PL/SQL式の使用方法
カレンダ指定構文より複雑な機能が必要な場合は、PL/SQL式を使用できます。ただし、PL/SQL式はウィンドウまたは名前付きスケジュールでは使用できません。PL/SQL式は、日付またはタイムスタンプに評価される必要があります。 - PL/SQL式とカレンダ指定構文の動作の相違点
カレンダ指定式とPL/SQLの繰返し間隔では、動作に重要な相違点があります。 - 繰返し間隔と夏時間
ジョブの繰返しでは、次回のジョブ実行時間のスケジュールは、タイム・ゾーン列のあるタイムスタンプに格納されます。
親トピック: ジョブを定義するためのスケジュールの作成および管理
29.4.5.1 繰返し間隔の設定について
ジョブの繰返し時期および間隔を制御するには、ジョブ自体またはジョブが参照する名前付きスケジュールのrepeat_interval
属性を設定します。repeat_interval
は、DBMS_SCHEDULER
パッケージ・プロシージャまたはCloud Controlで設定できます。
repeat_interval
を評価すると、一連のタイムスタンプが返されます。各タイムスタンプの時点で、スケジューラがジョブを実行します。ジョブまたはスケジュールの開始日も、タイムスタンプの結果セットの決定に役立つことに注意してください。repeat_interval
に値を指定しないと、指定した開始日に1回のみジョブが実行されます。
ジョブが開始されるとすぐに、repeat_interval
が評価されて、次にスケジュールされるジョブの実行時刻が決定されます。ジョブがまだ実行されている間に次の実行時刻になることがありますが、ジョブの新しいインスタンスは現在のジョブが完了するまで開始されません。
関連項目:
repeat_interval
の評価の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: 繰返し間隔の設定
29.4.5.2 スケジューラのカレンダ指定構文の使用方法
ジョブの繰返し間隔を設定する主要な方法は、スケジューラのカレンダ指定式を使用してrepeat_interval
属性を設定する方法です。
関連項目:
repeat_interval
のカレンダ指定構文およびCREATE_SCHEDULE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
カレンダ指定式の例
次に、簡単な繰返し間隔の例を示します。わかりやすくするために、開始日は評価結果に影響を与えないと仮定します。
毎週金曜日に実行(3つの例はすべて同等です。)
FREQ=DAILY; BYDAY=FRI; FREQ=WEEKLY; BYDAY=FRI; FREQ=YEARLY; BYDAY=FRI;
隔週金曜日に実行。
FREQ=WEEKLY; INTERVAL=2; BYDAY=FRI;
毎月末に実行。
FREQ=MONTHLY; BYMONTHDAY=-1;
毎月末の翌日に実行。
FREQ=MONTHLY; BYMONTHDAY=-2;
3月10日に実行(両方の例は同等です。)
FREQ=YEARLY; BYMONTH=MAR; BYMONTHDAY=10; FREQ=YEARLY; BYDATE=0310;
10日おきに実行。
FREQ=DAILY; INTERVAL=10;
毎日午後4時、5時および6時に実行。
FREQ=DAILY; BYHOUR=16,17,18;
隔月15日に実行。
FREQ=MONTHLY; INTERVAL=2; BYMONTHDAY=15;
毎月29日に実行。
FREQ=MONTHLY; BYMONTHDAY=29;
毎月第2水曜日に実行。
FREQ=MONTHLY; BYDAY=2WED;
毎年最終金曜日に実行。
FREQ=YEARLY; BYDAY=-1FRI;
50時間おきに実行。
FREQ=HOURLY; INTERVAL=50;
隔月末に実行。
FREQ=MONTHLY; INTERVAL=2; BYMONTHDAY=-1;
毎月初めの3日間1時間おきに実行。
FREQ=HOURLY; BYMONTHDAY=1,2,3;
以降は、多少複雑な繰返し間隔の例です。
毎月最後の稼働日に実行(稼働日は月曜日から金曜日と仮定)。
FREQ=MONTHLY; BYDAY=MON,TUE,WED,THU,FRI; BYSETPOS=-1
会社の祝日を除く、毎月の最後の稼働日に実行(この例では、Company_Holidays
という既存の名前付きスケジュールを参照しています。)
FREQ=MONTHLY; BYDAY=MON,TUE,WED,THU,FRI; EXCLUDE=Company_Holidays; BYSETPOS=-1
毎週金曜日および会社の休業日の正午に実行。
FREQ=YEARLY;BYDAY=FRI;BYHOUR=12;INCLUDE=Company_Holidays
7月4日、メモリアル・デーおよびレイバー・デーの3つの祝日に実行(この例では、それぞれの祝日に対応する1日を定義したJUL4
、MEM
およびLAB
の既存の3つの名前付きスケジュールを参照しています。)
JUL4,MEM,LAB
カレンダ指定式評価の例
繰返し間隔を"FREQ=MINUTELY;INTERVAL=2;BYHOUR=17; BYMINUTE=2,4,5,50,51,7;
"に、開始日を28-FEB-2004 23:00:00に設定すると、次のスケジュールが生成されます。
SUN 29-FEB-2004 17:02:00 SUN 29-FEB-2004 17:04:00 SUN 29-FEB-2004 17:50:00 MON 01-MAR-2004 17:02:00 MON 01-MAR-2004 17:04:00 MON 01-MAR-2004 17:50:00 ...
繰返し間隔を"FREQ=MONTHLY;BYMONTHDAY=15, -1
"に、開始日を29-DEC-2003 9:00:00に設定すると、次のスケジュールが生成されます。
WED 31-DEC-2003 09:00:00 THU 15-JAN-2004 09:00:00 SAT 31-JAN-2004 09:00:00 SUN 15-FEB-2004 09:00:00 SUN 29-FEB-2004 09:00:00 MON 15-MAR-2004 09:00:00 WED 31-MAR-2004 09:00:00 ...
繰返し間隔を"FREQ=MONTHLY;
"に、開始日を29-DEC-2003 9:00:00に設定すると、次のスケジュールが生成されます。(BYMONTHDAY
句がないため、開始日から日付が取得されることに注意してください。)
MON 29-DEC-2003 09:00:00 THU 29-JAN-2004 09:00:00 SUN 29-FEB-2004 09:00:00 MON 29-MAR-2004 09:00:00 ...
カレンダ指定式の使用例
カレンダ指定構文を使用した次の例について考えてみます。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'scott.my_job1', start_date => '15-JUL-04 01.00.00 AM Europe/Warsaw', repeat_interval => 'FREQ=MINUTELY; INTERVAL=30;', end_date => '15-SEP-04 01.00.00 AM Europe/Warsaw', comments => 'My comments here'); END; /
これにより、my_job1
がscott
に作成されます。7月15日に始めて実行されて、9月15日まで実行されます。このジョブの開始日は7月15日、終了日は9月15日で、30分おきに実行されます。
親トピック: 繰返し間隔の設定
29.4.5.3 PL/SQL式の使用方法
カレンダ指定構文より複雑な機能が必要な場合は、PL/SQL式を使用できます。ただし、PL/SQL式はウィンドウまたは名前付きスケジュールでは使用できません。PL/SQL式は、日付またはタイムスタンプに評価される必要があります。
これ以外に制限はないため、適切なプログラミングによって、あらゆる繰返し間隔を作成できます。例として、次の文を考えてみます。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'scott.my_job2', start_date => '15-JUL-04 01.00.00 AM Europe/Warsaw', repeat_interval => 'SYSTIMESTAMP + INTERVAL '30' MINUTE', end_date => '15-SEP-04 01.00.00 AM Europe/Warsaw', comments => 'My comments here'); END; /
これにより、my_job1
がscott
に作成されます。7月15日に始めて実行されて、9月15日まで30分ごとに実行されます。repeat_interval
が、30分後の日付を返すSYSTIMESTAMP + INTERVAL '30' MINUTE
に設定されているため、30分ごとにジョブが実行されます。
親トピック: 繰返し間隔の設定
29.4.5.4 PL/SQL式とカレンダ指定構文の動作の相違点
カレンダ指定式とPL/SQL繰返し間隔では、動作に重要な相違点があります。
相違点は、次のとおりです。
-
開始日
-
カレンダ指定構文を使用する場合、開始日は参照専用の日になります。そのため、スケジュールはこの日に有効になります。開始日にジョブが開始されるという意味ではありません。
-
PL/SQL式を使用した場合、開始日はジョブが最初に実行を開始した実際の時間を表します。
-
-
次回の実行時期
-
カレンダ指定構文を使用した場合、次回のジョブ実行時期は固定されています。
-
PL/SQL式を使用する場合、次にジョブが実行される時期は、現在のジョブ実行の実際の開始時刻によって異なります。
違いの例として、ジョブが午後2時に開始して、2時間ごとに繰り返されるようにスケジュールされているにもかかわらず、実際は2時10分に開始されたとします。
-
カレンダ指定構文で繰返し間隔が指定されている場合、ジョブは4時、6時などに繰返し実行されます。
-
PL/SQLを使用した場合、ジョブは4時10分に繰り返されますが、実際には次のジョブが4時11分に開始した場合は、後続の実行が6時11分になります。
-
これら2つの点を例で示すために、15-July-2003 1:45:00という開始日付が設定されていて、2時間ごとに繰り返す必要がある場合を考えます。"FREQ=HOURLY; INTERVAL=2; BYMINUTE=0;
"というカレンダ指定構文では、次のスケジュールが生成されます。
TUE 15-JUL-2003 03:00:00 TUE 15-JUL-2003 05:00:00 TUE 15-JUL-2003 07:00:00 TUE 15-JUL-2003 09:00:00 TUE 15-JUL-2003 11:00:00 ...
カレンダ式では、2時間おきの毎正時に繰返しを実行します。
一方、PL/SQL式"SYSTIMESTAMP + interval '2' hour
"では、実行時間は次のようになります。
TUE 15-JUL-2003 01:45:00 TUE 15-JUL-2003 03:45:05 TUE 15-JUL-2003 05:45:09 TUE 15-JUL-2003 07:45:14 TUE 15-JUL-2003 09:45:20 ...
親トピック: 繰返し間隔の設定
29.4.5.5 繰返し間隔と夏時間
ジョブの繰返しでは、次回のジョブ実行時間のスケジュールは、タイム・ゾーン列のあるタイムスタンプに格納されます。
-
カレンダ指定構文を使用する場合、タイム・ゾーンは
start_date
から取り出されます。start_date
が指定されていない場合の動作の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
PL/SQL繰返し間隔を使用する場合、タイム・ゾーンはPL/SQL式が返すタイムスタンプの一部になっています。
いずれの場合も、リージョン名を使用することが重要です。たとえば、"+2:00"
のような絶対タイム・ゾーン・オフセットではなく、"Europe/Istanbul"
を使用します。タイム・ゾーンがリージョン名で指定されている場合のみ、スケジューラはそのリージョンに適用される夏時間調整に従います。
親トピック: 繰返し間隔の設定
29.5 イベントを使用したジョブの開始
イベントが送信されたとき、Oracle Schedulerはジョブを開始できます。イベントは、アプリケーションまたはシステム・プロセス間で送信されるメッセージです。
- イベントについて
イベントは、なんらかの処理または発生が検出されたことを、アプリケーションまたはシステム・プロセスが別のアプリケーションまたはシステム・プロセスに示すために送信するメッセージです。イベントは、1つのアプリケーションまたはプロセスによって呼び出され(送信)、1つ以上のアプリケーションまたはプロセスによって使用されます(受信)。 - アプリケーションによって呼び出されたイベントによるジョブの開始
Oracle Schedulerは、アプリケーションによるイベントの発生時にジョブを開始できます。 - ファイルがシステムに到着したことによるジョブの開始
ファイルがローカル・システムまたはリモート・システムに到着したときにジョブを開始するようにスケジューラを構成できます。ジョブはイベントベースのジョブであり、ファイル到着イベントはFile Watcher(Oracle Database 11g リリース2 (11.2)で導入されたスケジューラ・オブジェクト)によって呼び出されます。
関連項目:
-
プロセス・フローを正確に制御するためにチェーンでのイベントの使用については、「ジョブ・チェーンの作成と管理」
29.5.1 イベントについて
イベントは、なんらかの処理または発生が検出されたことを、アプリケーションまたはシステム・プロセスが別のアプリケーションまたはシステム・プロセスに示すために送信するメッセージです。イベントは、1つのアプリケーションまたはプロセスによって呼び出され(送信)、1つ以上のアプリケーションまたはプロセスによって使用されます(受信)。
スケジューラでは、次の2種類のイベントが使用されます。
-
アプリケーションによって呼び出されるイベント
アプリケーションは、スケジューラが使用するイベントを呼び出すことができます。スケジューラは、ジョブを開始することでこのイベントを処理します。たとえば、在庫が一定のしきい値を下回ったことを感知した在庫追跡システムでは、在庫の補充ジョブを開始するイベントを呼び出すことができます。
「アプリケーションによって呼び出されたイベントによるジョブの開始」を参照してください。
-
File Watcherによって呼び出されるファイル到着イベント
File Watcher (Oracle Database 11gリリース2 (11.2)で導入されたスケジューラ・オブジェクト)を作成して、システムへのファイルの到着を監視できます。その後、File Watcherでファイルの存在が検出されたときに開始するジョブを構成できます。たとえば、チェーン店用のデータ・ウェアハウスでは、店舗からアップロードされた日次売上レポートからデータがロードされます。データ・ウェアハウスのロード・ジョブは、新しい日次レポートが到着するたびに開始されます。
関連項目:
スケジューラによって呼び出されるジョブ状態変化イベントがアプリケーションで使用される仕組みの詳細は、「スケジューラによって呼び出されるイベントによるジョブ状態の監視」
親トピック: イベントを使用したジョブの開始
29.5.2 アプリケーションによって呼び出されたイベントによるジョブの開始
Oracle Schedulerは、アプリケーションによるイベントの発生時にジョブを開始できます。
- アプリケーションによって呼び出されるイベントについて
アプリケーションでは、ジョブを開始するためにスケジューラに通知するイベントを発生できます。この方法で開始されるジョブは、イベントベースのジョブと呼ばれます。 - イベントベースのジョブの作成
イベントベースのジョブを作成するには、CREATE_JOB
プロシージャまたはCloud Controlを使用します。ジョブには、ジョブ属性としてイベント情報をインラインで組み込むか、またはイベント・スケジュールを指し示してイベント情報を指定できます。時間スケジュールに基づくジョブと同様に、イベントベースのジョブは、ジョブ終了日をすぎるか、max_runs
または最大失敗回数(max_failures
)に達するまでは自動削除されません。 - イベントベースのジョブの変更
イベントベースのジョブを変更するには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
プロシージャを使用します。 - イベント・スケジュールの作成
イベントに基づいたスケジュールを作成できます。作成したスケジュールは、複数のジョブに再利用できます。そのためには、CREATE_EVENT_SCHEDULE
プロシージャまたはCloud Controlを使用します。 - イベント・スケジュールの変更
イベント・スケジュールのイベント情報を変更する方法は、ジョブのイベント情報を変更する方法と同じです。 - イベントベースのジョブにイベント・メッセージを渡す方法
メタデータの引数を介して、スケジューラは、イベントベースのジョブに対して、ジョブを開始したイベントのメッセージ内容を渡すことができます。
親トピック: イベントを使用したジョブの開始
29.5.2.1 アプリケーションによって呼び出されるイベントについて
アプリケーションで、ジョブを開始するようにスケジューラに通知するイベントを呼び出すことができます。この方法で開始されるジョブは、イベントベースのジョブと呼ばれます。
日付、時間、繰り返し発生する情報を定義するかわりに、イベントを参照する名前付きスケジュールを作成できます。このようなスケジュール(イベント・スケジュール)が割り当てられたジョブは、イベントが呼び出されると実行されます。
ジョブの開始をスケジューラに通知するイベントを呼び出すために、アプリケーションは、このジョブの設定時に指定したOracle Databaseアドバンスト・キューイングのキューにメッセージをエンキューします。ジョブが開始されると、ジョブはオプションでイベントのメッセージ内容を取得できます。
イベントベースのジョブを作成するには、次の2つの追加属性を設定する必要があります。
-
queue_spec
キュー仕様。アプリケーションがジョブ開始イベントを呼び出すためのメッセージをエンキューするキューの名前が含まれます。または、セキュアなキューの場合はキュー名の後にカンマとエージェント名が記述されます。
-
event_condition
メッセージでジョブを開始するために
TRUE
と評価される必要のあるメッセージ・プロパティに基づく条件式。式には、Oracle Databaseアドバンスト・キューイングのルールの構文が必要です。したがって、メッセージ・ペイロードがオブジェクト・タイプで、式のオブジェクト属性の前にtab.user_data
を付加した場合は、ユーザー・データ・プロパティを式に含めることができます。関連項目:
-
キューイング・ルールの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』の
DBMS_AQADM
.ADD_SUBSCRIBER
プロシージャを参照してください。 -
キューの作成方法の詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください
-
メッセージのエンキュー方法の詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください
次の例では、
event_condition
が、午前0時から午前9時の間に発生する在庫不足イベントのみを選択するように設定されます。メッセージ・ペイロードはevent_type
とevent_timestamp
の2つの属性を持つオブジェクトであるとします。event_condition = 'tab.user_data.event_type = ''LOW_INVENTORY'' and extract hour from tab.user_data.event_timestamp < 9'
-
queue_spec
およびevent_condition
は、インラインのジョブ属性として指定するか、またはこれらの属性を指定したイベント・スケジュールを作成し、ジョブからこのスケジュールを指し示すことができます。
ノート:
スケジューラは、event_condition
に一致するイベントが発生するたびにイベントベースのジョブを実行します。ただし、デフォルトでは、ジョブがすでに実行されている間に発生したイベントは無視され、イベントは消費されますが別のジョブの実行がトリガーされることはありません。Oracle Database 11g リリース1 (11.1)以降では、ジョブ属性PARALLEL_INSTANCES
をTRUE
に設定することで、このデフォルト動作を変更できます。この場合、ジョブのインスタンスがイベントのすべてのインスタンスに対して起動され、すべてのジョブ・インスタンスが軽量ジョブになります。詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のSET_ATTRIBUTE
プロシージャに関する項を参照してください。
表29-5に、アプリケーションによって呼び出される(スケジューラによって使用される)イベントに関する一般的な管理タスクとそれに対応するプロシージャを示します。
表29-5 アプリケーションによって呼び出されるイベントに対するイベント・タスクとそのプロシージャ
タスク | プロシージャ | 必要な権限 |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
29.5.2.2 イベントベースのジョブの作成
イベントベースのジョブを作成するには、CREATE_JOB
プロシージャまたはCloud Controlを使用します。ジョブには、ジョブ属性としてイベント情報をインラインで組み込むか、またはイベント・スケジュールを指し示してイベント情報を指定できます。時間スケジュールに基づくジョブと同様に、イベントベースのジョブは、ジョブ終了日をすぎるか、max_runs
または最大失敗回数(max_failures
)に達するまでは自動削除されません。
- イベント情報をジョブ属性として指定する方法
イベント情報をジョブ属性として指定するには、CREATE_JOB
の代替構文を使用して、queue_spec
およびevent_condition
属性を組み込みます。 - イベント情報をイベント・スケジュールで指定する方法
イベント・スケジュールでイベント情報を指定するには、ジョブのschedule_name
属性にイベント・スケジュールの名前を設定します。
29.5.2.2.1 イベント情報をジョブ属性として指定する方法
イベント情報をジョブ属性として指定するには、CREATE_JOB
の代替構文を使用して、queue_spec
およびevent_condition
属性を組み込みます。
次の例では、項目の在庫レベルが低しきい値レベルを下回ったことがアプリケーションからスケジューラに伝達されるときに開始されるジョブを作成しています。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'process_lowinv_j1', program_name => 'process_lowinv_p1', event_condition => 'tab.user_data.event_type = ''LOW_INVENTORY''', queue_spec => 'inv_events_q, inv_agent1', enabled => TRUE, comments => 'Start an inventory replenishment job'); END; /
CREATE_JOB
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: イベント・ベースのジョブの作成
29.5.2.2.2 イベント情報をイベント・スケジュールで指定する方法
イベント情報をイベント・スケジュールで指定するには、ジョブのschedule_name
属性にイベント・スケジュールの名前を設定します。
次の例では、イベント・スケジュールでイベント情報を指定します。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'process_lowinv_j1', program_name => 'process_lowinv_p1', schedule_name => 'inventory_events_schedule', enabled => TRUE, comments => 'Start an inventory replenishment job'); END; /
詳細は、「イベント・スケジュールの作成」を参照してください。
親トピック: イベント・ベースのジョブの作成
29.5.2.3 イベントベースのジョブの変更
イベントベースのジョブを変更するには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
プロシージャを使用します。
イベントをインラインで指定するジョブの場合、SET_ATTRIBUTE
を使用してqueue_spec
属性とevent_condition
属性を別々に設定することはできません。かわりに、event_spec
と呼ばれる属性を設定し、イベント条件とキュー仕様を3番目と4番目の引数としてSET_ATTRIBUTE
に渡す必要があります。
次の例では、event_spec
属性を使用しています。
BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE ('my_job', 'event_spec',
'tab.user_data.event_type = ''LOW_INVENTORY''', 'inv_events_q, inv_agent1');
END;
/
SET_ATTRIBUTE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.5.2.4 イベント・スケジュールの作成
イベントに基づいたスケジュールを作成できます。作成したスケジュールは、複数のジョブに再利用できます。そのためには、CREATE_EVENT_SCHEDULE
プロシージャまたはCloud Controlを使用します。
次の例では、イベント・スケジュールを作成しています。
BEGIN DBMS_SCHEDULER.CREATE_EVENT_SCHEDULE ( schedule_name => 'inventory_events_schedule', start_date => SYSTIMESTAMP, event_condition => 'tab.user_data.event_type = ''LOW_INVENTORY''', queue_spec => 'inv_events_q, inv_agent1'); END; /
イベント・スケジュールを削除するには、DROP_SCHEDULE
プロシージャを使用します。CREATE_EVENT_SCHEDULE
の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.5.2.5 イベント・スケジュールの変更
イベント・スケジュールのイベント情報を変更する方法は、ジョブのイベント情報を変更する方法と同じです。
詳細は、「イベントベースのジョブの変更」を参照してください。
次の例は、イベント・スケジュールのイベント情報を変更するためのSET_ATTRIBUTE
プロシージャおよびevent_spec
属性の使用方法を示しています。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ('inventory_events_schedule', 'event_spec', 'tab.user_data.event_type = ''LOW_INVENTORY''', 'inv_events_q, inv_agent1'); END; /
SET_ATTRIBUTE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.5.2.6 イベントベースのジョブにイベント・メッセージを渡す方法
メタデータの引数を介して、スケジューラは、イベントベースのジョブに対して、ジョブを開始したイベントのメッセージ内容を渡すことができます。
以下のルールが適用されます。
-
ジョブは、タイプ
STORED_PROCEDURE
の名前付きプログラムを使用する必要があります。 -
名前付きプログラムの引数の1つがメタデータ引数であり、その
metadata_attribute
がEVENT_MESSAGE
に設定されている必要があります。 -
プログラムを実装するストアド・プロシージャには、名前付きプログラムのメタデータ引数に対応する位置に引数が必要です。引数の型は、アプリケーションがジョブ開始イベントをエンキューするキューのデータ型であることが必要です。
EVENT_MESSAGE
メタデータ引数があるジョブをRUN_JOB
プロシージャを使用して手動で実行した場合、その引数に渡される値はNULL
です。
次の例は、イベント・メッセージの内容を受け取ることができるイベントベースのジョブを作成する方法を示しています。
CREATE OR REPLACE PROCEDURE my_stored_proc (event_msg IN event_queue_type) AS BEGIN -- retrieve and process message body END; / BEGIN DBMS_SCHEDULER.CREATE_PROGRAM ( program_name => 'my_prog', program_action=> 'my_stored_proc', program_type => 'STORED_PROCEDURE', number_of_arguments => 1, enabled => FALSE) ; DBMS_SCHEDULER.DEFINE_METADATA_ARGUMENT ( program_name => 'my_prog', argument_position => 1 , metadata_attribute => 'EVENT_MESSAGE') ; DBMS_SCHEDULER.ENABLE ('my_prog'); EXCEPTION WHEN others THEN RAISE ; END ; / BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'my_evt_job' , program_name => 'my_prog', schedule_name => 'my_evt_sch', enabled => true, auto_Drop => false) ; EXCEPTION WHEN others THEN RAISE ; END ; /
29.5.3 ファイルがシステムに到着したことによるジョブの開始
ファイルがローカル・システムまたはリモート・システムに到着したときにジョブを開始するようにスケジューラを構成できます。ジョブはイベントベースのジョブであり、ファイル到着イベントはFile Watcher(Oracle Database 11g リリース2 (11.2)で導入されたスケジューラ・オブジェクト)によって呼び出されます。
- File Watcherについて
File Watcherは、ファイルがシステムに到着したことによってスケジューラでジョブが開始される場合の対象ファイルの場所、名前などのプロパティを定義したスケジューラ・オブジェクトです。 - リモート・システムからのファイルの到着イベントの有効化
リモート・システムからファイル到着イベントを受け取るには、そのシステムにスケジューラ・エージェントをインストールし、そのエージェントをデータベースに登録する必要があります。 - File WatcherおよびFile Watcherジョブの作成
File WatcherおよびFile Watcherジョブを作成するには、いくつかのステップを実行します。 - ファイルの到着の例
File Watcherジョブのファイル到着の例を示します。 - File Watcherの管理
DBMS_SCHEDULER
PL/SQLパッケージには、File Watcherの属性を有効化、無効化、削除および設定するためのプロシージャが用意されています。 - File Watcherの情報の表示
*_SCHEDULER_FILE_WATCHERS
ビューを問い合せることによって、File Watcherに関する情報を表示できます。
親トピック: イベントを使用したジョブの開始
29.5.3.1 File Watcherについて
File Watcherは、ファイルがシステムに到着したことによってスケジューラでジョブが開始される場合の対象ファイルの場所、名前などのプロパティを定義したスケジューラ・オブジェクトです。
ファイル・ウォッチャを作成し、次に、そのファイル・ウォッチャを参照する任意の数のイベントベースのジョブまたはイベント・スケジュールを作成します。File Watcherでは、指定されたファイルの到着、新たに到着したファイルを検出すると、到着イベントを呼び出します。
新たに到着したファイルとは、変更されているため、最新の実行またはFile Watcherジョブがターゲット・ファイル・ディレクトリの監視を開始した時間よりタイムスタンプが遅いファイルです。
File Watcherがファイルが新たに到着したものか否かを判断する方法は、UNIXコマンドls -lrt
またはWindows DOSコマンドdir /od
を繰り返し実行してディレクトリ内の新しいファイルを監視するのと同じです。この両方のコマンドでは必ず、最近に変更されたファイルが最後にリストされます。つまり最も古いものが最初で最も新しいものが最後になります。
ノート:
動作は次のとおりです。
UNIX mv
コマンドはファイルの変更時間を変更しませんが、cp
コマンドは変更します。
Windows move
/paste
およびcopy
/paste
コマンドは、ファイルの変更時間を変更しません。そうするには、move
またはcopy
コマンドの後にDOSコマンドcopy /b file_name +,,
を実行します。
CREATE_FILE_WATCHER
プロシージャのsteady_state_duration
パラメータ(『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照)は、File Watcherがファイルを検出したと判断するまでに、ファイルが未変更のままであることが必要な最小時間間隔を指定します。これは1時間を超えることはできません。パラメータがNULL
の場合、内部値が使用されます。
ファイルの到着イベントによって開始されたジョブでは、新しく到着したファイルを示すイベント・メッセージを取得できます。このメッセージには、ファイルの検索、オープンおよび処理に必要な情報が含まれます。
File Watcherでは、ローカル・システム(Oracle Databaseを実行しているホスト・コンピュータ)またはリモート・システムでファイルを監視できます。リモート・システムではスケジューラ・エージェントが実行され、そのエージェントがデータベースに登録されている必要があります。
File Watcherでは、10分間隔でファイルの到着がチェックされます。この間隔は調整可能です。詳細は、「ファイルの到着を検出する間隔の変更」を参照してください。
File Watcherを使用するには、データベースのJava仮想マシン(JVM)コンポーネントをインストールする必要があります。
スキーマにFile Watcherを作成するには、CREATE
JOB
システム権限が必要です。自分のスキーマと異なるスキーマ(許可されないSYS
スキーマ以外)にFile Watcherを作成するには、CREATE
ANY
JOB
システム権限が必要です。別のスキーマ内のジョブでFile Watcherを参照できるように、File Watcherに対するEXECUTE
オブジェクト権限を付与できます。また、別のユーザーがFile Watcherを変更できるように、File Watcherに対するALTER
オブジェクト権限を付与できます。
親トピック: ファイルがシステムに到着したことによるジョブの開始
29.5.3.2 リモート・システムからのファイルの到着イベントの有効化
リモート・システムからファイル到着イベントを受け取るには、そのシステムにスケジューラ・エージェントをインストールし、そのエージェントをデータベースに登録する必要があります。
リモート・システムでファイル到着イベントを生成するのに、Oracle Databaseインスタンスが実行されている必要はありません。
リモート・システムでのファイル到着イベントの呼出しを有効にするには:
-
リモート外部ジョブを実行するようにローカル・データベースを設定します。
手順は、「リモート・ジョブを実行するためのデータベースの設定の有効化と無効化」を参照してください。
-
最初のリモート・システムでスケジューラ・エージェントをインストール、構成、登録および起動します。
手順は、「リモート・ホストでのスケジューラ・エージェントのインストールと構成」を参照してください。
これにより、ローカル・データベースで管理されている外部宛先のリストにリモート・ホストが追加されます。
-
追加の各リモート・システムに対して前述のステップを繰り返します。
親トピック: ファイルがシステムに到着したことによるジョブの開始
29.5.3.3 File WatcherおよびFile Watcherジョブの作成
File WatcherおよびFile Watcherジョブを作成するには、いくつかのステップを実行します。
File Watcherを作成し、指定したファイルが到着したときに開始されるイベントベースのジョブを作成するには、次のタスクを実行します。
- タスク1: 資格証明の作成
-
File Watcherでは、ホスト・オペレーティング・システムでファイルへのアクセスを認証するために使用される資格証明オブジェクト(資格証明)が必要になります。資格証明を作成するために必要な権限の詳細は、「資格証明」を参照してください。
次のステップを実行します。
-
監視対象ファイルにアクセスする必要があるオペレーティング・システム・ユーザーの資格証明を作成します。
BEGIN DBMS_CREDENTIAL.CREATE_CREDENTIAL('WATCH_CREDENTIAL', 'salesapps', 'sa324w1'); END; /
-
File Watcherによって開始されるイベントベースのジョブを所有するスキーマに、資格証明に対する
EXECUTE
オブジェクト権限を付与します。GRANT EXECUTE ON WATCH_CREDENTIAL to DSSUSER;
-
- タスク2: File Watcherの作成
-
次のステップを実行します。
-
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』の
DBMS_SCHEDULER.CREATE_FILE_WATCHER
プロシージャに関する項の説明に従って属性を割り当て、File Watcherを作成します。ファイル名にワイルドカード・パラメータを指定できます。DIRECTORY_PATH
属性の「?」接頭辞は、Oracleホーム・ディレクトリへのパスを示します。NULL
のdestination
はローカル・ホストを示します。リモート・ホストのファイルを監視するには、ビューALL_SCHEDULER_EXTERNAL_DESTS
から取得できる有効な外部宛先名を指定します。BEGIN DBMS_SCHEDULER.CREATE_FILE_WATCHER( file_watcher_name => 'EOD_FILE_WATCHER', directory_path => '?/eod_reports', file_name => 'eod*.txt', credential_name => 'watch_credential', destination => NULL, enabled => FALSE); END; /
-
File Watcherを参照するイベントベースのジョブを所有するスキーマに、File Watcherに対する
EXECUTE
を付与します。GRANT EXECUTE ON EOD_FILE_WATCHER to dssuser;
-
- タスク3: プログラム・オブジェクトの作成とメタデータ引数の指定
-
アプリケーションでファイル到着イベント・メッセージの内容(ファイル名、ファイル・サイズなど)を取得できるように、スケジューラ・プログラム・オブジェクトを作成し、イベント・メッセージを参照するメタデータ引数を指定します。
次のステップを実行します。
-
プログラムを作成します。
BEGIN DBMS_SCHEDULER.CREATE_PROGRAM( program_name => 'dssuser.eod_program', program_type => 'stored_procedure', program_action => 'eod_processor', number_of_arguments => 1, enabled => FALSE); END; /
-
event_message
属性を使用してメタデータ引数を定義します。BEGIN DBMS_SCHEDULER.DEFINE_METADATA_ARGUMENT( program_name => 'DSSUSER.EOD_PROGRAM', metadata_attribute => 'event_message', argument_position => 1); END; /
-
プログラムで呼び出すストアド・プロシージャを作成します。
ファイル到着イベントを処理するストアド・プロシージャには、
SYS.SCHEDULER_FILEWATCHER_RESULT
タイプの引数(イベント・メッセージのデータ型)を指定する必要があります。この引数の位置は、定義済のメタデータ引数の位置と一致させる必要があります。これにより、プロシージャでこの抽象データ型の属性にアクセスして、到着したファイルに関する情報を把握できるようになります。
関連項目:
-
DEFINE_METADATA_ARGUMENT
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
SYS.SCHEDULER_FILEWATCHER_RESULT
型の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
-
- タスク4: File Watcherを参照するイベントベースのジョブの作成
-
「イベントベースのジョブの作成」の説明に従ってイベントベースのジョブを作成します。ただし、
queue_spec
属性にキューの仕様を指定するかわりに、File Watcherの名前を指定してください。通常は、event_condition
ジョブ属性をnullのままにしますが、必要に応じて条件を指定できます。ジョブに対して
queue_spec
属性を設定するかわりに、イベント・スケジュールを作成し、そのイベント・スケジュールのqueue_spec
属性でFile Watcherを参照し、ジョブのschedule_name
属性でそのイベント・スケジュールを参照できます。次のステップを実行して、イベントベースのジョブを準備します。
-
ジョブを作成します。
BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name => 'dssuser.eod_job', program_name => 'dssuser.eod_program', event_condition => NULL, queue_spec => 'eod_file_watcher', auto_drop => FALSE, enabled => FALSE); END; /
-
ジョブによって前のイベントがすでに処理されていても、ファイル到着イベントの各インスタンスに対してジョブを実行する場合は、
parallel_instances
属性をTRUE
に設定します。この設定を使用すると、ジョブは軽量ジョブとして実行され、ジョブの複数のインスタンスを迅速に開始できるようになります。イベントベースのジョブで別のイベントがすでに処理されている間に発生するFile Watcherイベントを破棄するには、parallel_instances
属性をFALSE
(デフォルト)のままにします。BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE('dssuser.eod_job','parallel_instances',TRUE); END; /
この属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』の
SET_ATTRIBUTE
に関する項を参照してください。
-
- タスク5: すべてのオブジェクトの有効化
-
File Watcher、プログラムおよびジョブを有効にします。
BEGIN DBMS_SCHEDULER.ENABLE('DSSUSER.EOD_PROGRAM,DSSUSER.EOD_JOB,EOD_FILE_WATCHER'); END; /
親トピック: ファイルがシステムに到着したことによるジョブの開始
29.5.3.4 ファイルの到着の例
File Watcherジョブのファイル到着の例を示します。
この例では、イベントベースのジョブによって、各地からの日次売上レポートがローカル・ホストに到着するのを監視しています。各レポート・ファイルが到着すると、ストアド・プロシージャによりファイルに関する情報が取得され、eod_reports
という表に格納されます。その後、定期レポート集計ジョブにより、この表を問い合せて、すべての未処理ファイルを処理し、新たに処理したファイルを処理済としてマークできます。
ここでは、次のコードを実行するデータベース・ユーザーにSYS.SCHEDULER_FILEWATCHER_RESULT
データ型に対するEXECUTE
が付与されていることを想定しています。
BEGIN DBMS_CREDENTIAL.CREATE_CREDENTIAL( credential_name => 'watch_credential', username => 'pos1', password => 'jk4545st'); END; / CREATE TABLE eod_reports (WHEN timestamp, file_name varchar2(100), file_size number, processed char(1)); CREATE OR REPLACE PROCEDURE q_eod_report (payload IN sys.scheduler_filewatcher_result) AS BEGIN INSERT INTO eod_reports VALUES (payload.file_timestamp, payload.directory_path || '/' || payload.actual_file_name, payload.file_size, 'N'); END; / BEGIN DBMS_SCHEDULER.CREATE_PROGRAM( program_name => 'eod_prog', program_type => 'stored_procedure', program_action => 'q_eod_report', number_of_arguments => 1, enabled => FALSE); DBMS_SCHEDULER.DEFINE_METADATA_ARGUMENT( program_name => 'eod_prog', metadata_attribute => 'event_message', argument_position => 1); DBMS_SCHEDULER.ENABLE('eod_prog'); END; / BEGIN DBMS_SCHEDULER.CREATE_FILE_WATCHER( file_watcher_name => 'eod_reports_watcher', directory_path => '?/eod_reports', file_name => 'eod*.txt', credential_name => 'watch_credential', destination => NULL, enabled => FALSE); END; / BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name => 'eod_job', program_name => 'eod_prog', event_condition => 'tab.user_data.file_size > 10', queue_spec => 'eod_reports_watcher', auto_drop => FALSE, enabled => FALSE); DBMS_SCHEDULER.SET_ATTRIBUTE('EOD_JOB','PARALLEL_INSTANCES',TRUE); END; / EXEC DBMS_SCHEDULER.ENABLE('eod_reports_watcher,eod_job');
親トピック: ファイルがシステムに到着したことによるジョブの開始
29.5.3.5 File Watcherの管理
DBMS_SCHEDULER
PL/SQLパッケージには、File Watcherの属性を有効化、無効化、削除および設定するためのプロシージャが用意されています。
- File Watcherの有効化
File Watcherが無効になっている場合、それを有効にするにはDBMS_SCHEDULER.ENABLE
を使用します。 - File Watcherの変更
File Watcherの属性を変更するには、DBMS_SCHEDULER.SET_ATTRIBUTE
およびDBMS_SCHEDULER.SET_ATTRIBUTE_NULL
パッケージ・プロシージャを使用します。 - File Watcherの無効化および削除
File Watcherを無効にするにはDBMS_SCHEDULER.DISABLE
プロシージャ、File Watcherを削除するにはDBMS_SCHEDULER.DROP_FILE_WATCHER
プロシージャを使用します。 - ファイルの到着を検出する間隔の変更
File Watcherでは、デフォルトでは10分間隔でファイルの到着がチェックされます。この間隔は変更可能です。
関連項目:
DBMS_SCHEDULER
PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ファイルがシステムに到着したことによるジョブの開始
29.5.3.5.1 File Watcherの有効化
File Watcherが無効になっている場合、それを有効にするにはDBMS_SCHEDULER.ENABLE
を使用します。
これは、「タスク5: すべてのオブジェクトの有効化」で示しています。
File Watcherを有効にできるのは、そのすべての属性が有効な値に設定され、File Watcherの所有者に指定の資格証明に対するEXECUTE
権限が付与されている場合のみです。
親トピック: File Watcherの管理
29.5.3.5.2 File Watcherの変更
File Watcherの属性を変更するには、DBMS_SCHEDULER.SET_ATTRIBUTE
およびDBMS_SCHEDULER.SET_ATTRIBUTE_NULL
パッケージ・プロシージャを使用します。
File Watcherの属性の詳細は、CREATE_FILE_WATCHER
プロシージャの説明を参照してください。
親トピック: File Watcherの管理
29.5.3.5.3 File Watcherの無効化および削除
File Watcherを無効にするにはDBMS_SCHEDULER.DISABLE
プロシージャ、File Watcherを削除するにはDBMS_SCHEDULER.DROP_FILE_WATCHER
プロシージャを使用します。
File Watcherに依存するジョブが存在する場合、File Watcherを無効にしたり、削除することはできません。このような場合に無効化または削除操作を強制するには、FORCE
属性をTRUE
に設定します。File Watcherの無効化または削除を強制すると、File Watcherに依存するジョブは無効になります。
親トピック: File Watcherの管理
29.5.3.5.4 ファイルの到着を検出する間隔の変更
File Watcherでは、デフォルトでは10分間隔でファイルの到着がチェックされます。この間隔は変更可能です。
ファイルの到着を検出する間隔を変更するには:
-
SYS
ユーザーとしてデータベースに接続します。 -
事前定義のスケジュール
SYS.FILE_WATCHER_SCHEDULE
のREPEAT_INTERVAL
属性を変更します。有効なカレンダ指定構文を使用してください。File Watcherの
REPEAT_INTERVAL
をいずれかのSTEADY_STATE_DURATION
属性値よりも小さい値に設定することはお薦めしません。関連項目:
-
File Watcherの属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
-
CREATE_FILE_WATCHER
パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
次の例では、ファイルの到着を検出する頻度を2分間隔に変更しています。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE('FILE_WATCHER_SCHEDULE', 'REPEAT_INTERVAL', 'FREQ=MINUTELY;INTERVAL=2'); END; /
-
親トピック: File Watcherの管理
29.5.3.6 File Watcherの情報の表示
*_SCHEDULER_FILE_WATCHERS
ビューを問い合せることによって、File Watcherに関する情報を表示できます。
たとえば、次の問合せを実行します。
SELECT file_watcher_name, destination, directory_path, file_name, credential_name FROM dba_scheduler_file_watchers; FILE_WATCHER_NAME DESTINATION DIRECTORY_PATH FILE_NAME CREDENTIAL_NAME -------------------- -------------------- -------------------- ---------- ---------------- MYFW dsshost.example.com /tmp abc MYFW_CRED EOD_FILE_WATCHER ?/eod_reports eod*.txt WATCH_CREDENTIAL
関連項目:
*_SCHEDULER_FILE_WATCHERS
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
親トピック: ファイルがシステムに到着したことによるジョブの開始
29.6 ジョブ・チェーンの作成と管理
ジョブ・チェーンは、結合した1つの目的のために互いにリンクされた一連の名前付きタスクです。
- ジョブ・チェーンの作成と管理について
ジョブ・チェーンを使用して、前の1つ以上のジョブの結果に応じて異なるジョブが開始される依存性ベースのスケジューリングを実装できます。 - チェーンのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なチェーン・タスクを管理します。 - チェーンの作成
チェーンを作成するには、DBMS_SCHEDULER
パッケージのCREATE_CHAIN
プロシージャを使用します。 - チェーン・ステップの定義
チェーン・オブジェクトの作成後、1つ以上のチェーン・ステップを定義します。 - チェーンへのルールの追加
チェーンにルールを追加するには、DBMS_SCHEDULER
パッケージのDEFINE_CHAIN_RULE
プロシージャを使用します。このプロシージャは、チェーンに追加する各ルールに対して1回ずつコールします。 - チェーン・ルールの評価間隔の設定
スケジューラでは、チェーン・ジョブの開始時と各チェーン・ステップの終了時に、すべてのチェーン・ルールが評価されます。 - チェーンの有効化
チェーンを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャを使用します。ジョブでチェーンを実行するには、チェーンを使用可能にする必要があります。すでに使用可能なチェーンを使用可能にしてもエラーは戻りません。 - チェーン用のジョブの作成
チェーンを実行するには、DBMS_SCHEDULER
パッケージのRUN_CHAIN
プロシージャを使用するか、CHAIN
タイプのジョブ(チェーン・ジョブ)を作成およびスケジュールする必要があります。 - チェーンの削除
ステップおよびルールを含むチェーンを削除するには、DBMS_SCHEDULER
パッケージのDROP_CHAIN
プロシージャを使用します。 - チェーンの実行
チェーンを即時に実行するには、DBMS_SCHEDULER
パッケージのRUN_JOB
またはRUN_CHAIN
プロシージャを使用します。 - チェーン・ルールの削除
チェーンからルールを削除するには、DBMS_SCHEDULER
パッケージのDROP_CHAIN_RULE
プロシージャを使用します。 - チェーンの無効化
チェーンを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャを使用します。 - チェーン・ステップの削除
チェーンからステップを削除するには、DBMS_SCHEDULER
パッケージのDROP_CHAIN_STEP
プロシージャを使用します。 - チェーンの停止
実行中のチェーンを停止するには、DBMS_SCHEDULER.STOP_JOB
プロシージャをコールして、チェーン・ジョブ(チェーンを開始したジョブ)の名前を渡します。 - 個々のチェーン・ステップの停止
ルールの条件が満たされたときに1つ以上のステップが停止するチェーン・ルールを作成するか、STOP_JOB
プロシージャを呼び出すことにより、個々のチェーン・ステップを停止できます。 - チェーンの一時停止
チェーン全体、またはチェーンの個別ブランチを一時停止できます。そのためには、DBMS_SCHEDULER.ALTER_CHAIN
またはALTER_RUNNING_CHAIN
プロシージャで、1つ以上のステップのPAUSE
属性をTRUE
に設定します。 - チェーン・ステップのスキップ
チェーンの1つ以上のステップをスキップできます。そのためには、DBMS_SCHEDULER.ALTER_CHAIN
またはALTER_RUNNING_CHAIN
プロシージャで、1つ以上のステップのSKIP
属性をTRUE
に設定します。 - チェーンの一部実行
チェーンの一部のみを実行することができます。 - 実行中のチェーンの監視
実行中のチェーンの状態は、*_SCHEDULER_RUNNING_JOBS
および*_SCHEDULER_RUNNING_CHAINS
の2つのビューで参照できます。 - ストールしたチェーンの処理
ステップの完了時には、常にチェーン・ルールが評価され、次に実行するステップが判別されます。いずれのルールでも別のステップが開始されず、チェーンが終了せず、チェーンのevaluation_interval
がNULL
の場合は、チェーンがstalled状態になります。
関連項目:
-
チェーンの概要については、「チェーン」
29.6.1 ジョブ・チェーンの作成と管理について
ジョブ・チェーンを使用して、前の1つ以上のジョブの結果に応じて異なるジョブが開始される依存性ベースのスケジューリングを実装できます。
チェーンを作成して使用するには、次のタスクを実行します。
タスク | 参照 |
---|---|
1. チェーン・オブジェクトを作成します。 |
|
2. チェーン内のステップを定義します。 |
|
3. ルールを追加します。 |
|
4. チェーンを使用可能にします。 |
|
5. チェーンを指し示すジョブ(チェーン・ジョブ)を作成します。 |
親トピック: ジョブ・チェーンの作成と管理
29.6.2 チェーンのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なチェーン・タスクを管理します。
表29-6に、チェーンに関する一般的なタスクとそれに対応するプロシージャを示します。
表29-6 チェーンのタスクとそのプロシージャ
タスク | プロシージャ | 必要な権限 |
---|---|---|
チェーンの作成 |
|
所有者の場合、 |
チェーンの削除 |
|
チェーンの所有権、あるいはチェーンに対する |
チェーンの変更 |
|
チェーンの所有権、あるいはチェーンに対する |
実行中チェーンの変更 |
|
ジョブの所有権、あるいはジョブに対する |
チェーンの実行 |
|
|
チェーンへのルールの追加 |
|
チェーンの所有権、あるいはチェーンに対する |
チェーン内のルールの変更 |
|
チェーンの所有権、あるいはチェーンに対する |
チェーンからのルールの削除 |
|
チェーンの所有権、あるいはチェーンに対する |
チェーンの有効化 |
|
チェーンの所有権、あるいはチェーンに対する |
チェーンの無効化 |
|
チェーンの所有権、あるいはチェーンに対する |
ステップの作成 |
|
チェーンの所有権、あるいはチェーンに対する |
ステップの削除 |
|
チェーンの所有権、あるいはチェーンに対する |
ステップの変更(ステップへの追加の属性値の割当てを含む) |
|
チェーンの所有権、あるいはチェーンに対する |
親トピック: ジョブ・チェーンの作成と管理
29.6.3 チェーンの作成
チェーンを作成するには、DBMS_SCHEDULER
パッケージのCREATE_CHAIN
プロシージャを使用します。
最初に、必要な権限があることを確認してください。詳細は、「チェーンの各権限の設定」を参照してください。
CREATE_CHAIN
を使用してチェーン・オブジェクトを作成した後、チェーン・ステップおよびチェーン・ルールを別々に定義します。
次の例では、チェーンを作成しています。
BEGIN DBMS_SCHEDULER.CREATE_CHAIN ( chain_name => 'my_chain1', rule_set_name => NULL, evaluation_interval => NULL, comments => 'My first chain'); END; /
rule_set_name
およびevaluation_interval
引数は通常NULL
のままです。evaluation_interval
では、チェーン・ルールが評価される繰返し間隔を定義できます。rule_set_name
は、Oracle Streams内で定義されたルール・セットです。
関連項目:
-
evaluation_interval
属性の詳細は、「チェーンへのルールの追加」 -
CREATE_CHAIN
の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
ルールおよびルール・セットの詳細は、『Oracle Streams概要および管理』を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.4 チェーン・ステップの定義
チェーン・オブジェクトの作成後、1つ以上のチェーン・ステップを定義します。
各ステップは、次のいずれかを指し示します。
-
スケジューラ・プログラム・オブジェクト(プログラム)
-
別のチェーン(ネストしたチェーン)
-
イベント・スケジュール、インライン・イベントまたはFile Watcher
プログラムまたはネストしたチェーンを指し示すステップを定義するには、DEFINE_CHAIN_STEP
プロシージャを使用します。次の例では、my_chain1
に2つのステップを追加しています。
BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_STEP ( chain_name => 'my_chain1', step_name => 'my_step1', program_name => 'my_program1'); DBMS_SCHEDULER.DEFINE_CHAIN_STEP ( chain_name => 'my_chain1', step_name => 'my_step2', program_name => 'my_chain2'); END; /
ステップを定義する際に、名前付きプログラムまたはチェーンが存在している必要はありません。ただし、チェーンの実行時には存在して有効になっている必要があり、そうでないとエラーが発生します。
イベントの発生を待機するステップを定義するには、DEFINE_CHAIN_EVENT_STEP
プロシージャを使用します。プロシージャの引数を使用して、イベント・スケジュールを指し示すか、インラインのキュー仕様およびイベント条件を組み込むか、またはFile Watcherの名前を指定できます。この例では、名前付きイベント・スケジュール内に指定されているイベントを待機する、3番目のチェーン・ステップが作成されます。
BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_EVENT_STEP ( chain_name => 'my_chain1', step_name => 'my_step3', event_schedule_name => 'my_event_schedule'); END; /
イベント・ステップでは、ステップが開始されるまでそのイベントを待機することはありません。
ローカルの外部実行可能ファイルを実行するステップ
ローカルの外部実行可能ファイルを実行するステップを定義した後、次の例に示すように、ALTER_CHAIN
プロシージャを使用して、ステップに資格証明を割り当てる必要があります。
BEGIN DBMS_SCHEDULER.ALTER_CHAIN('chain1','step1','credential_name','MY_CREDENTIAL'); END; /
リモートの宛先で実行するステップ
リモート・ホストまたはリモート・データベース上のデータベース・プログラム・ユニットで外部実行可能ファイルを実行するステップを定義した後、次の例に示すように、ALTER_CHAIN
プロシージャを使用して、ステップに資格証明と宛先の両方を割り当てる必要があります。
BEGIN DBMS_SCHEDULER.ALTER_CHAIN('chain1','step2','credential_name','DW_CREDENTIAL'); DBMS_SCHEDULER.ALTER_CHAIN('chain1','step2','destination_name','DBHOST1_ORCLDW'); END; /
ステップを再開可能にする方法
データベース・リカバリ後、デフォルトでは、実行中だったステップがSTOPPED
としてマークされ、チェーンが続行されます。ALTER_CHAIN
を使用してチェーン・ステップのrestart_on_recovery
属性をTRUE
に設定すると、これらのステップをデータベース・リカバリ後に自動的に再開するように指定できます。
DEFINE_CHAIN_STEP
、DEFINE_CHAIN_EVENT_STEP
およびALTER_CHAIN
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.5 チェーンへのルールの追加
チェーンにルールを追加するには、DBMS_SCHEDULER
パッケージのDEFINE_CHAIN_RULE
プロシージャを使用します。このプロシージャは、チェーンに追加する各ルールに対して1回ずつコールします。
チェーン・ルールでは、ステップの実行時期、およびステップ間の依存関係が定義されます。各ルールには条件と処理があります。ルールが評価されるときに、ルールの条件がTRUE
に評価されると、その処理が実行されます。条件では、スケジューラ・チェーン条件の構文、またはSQLのWHERE
句で有効な構文を使用できます。この構文には、ステップの完了ステータスなど、チェーン・ステップの属性への参照を組み込むことができます。標準な処理は、指定したステップを実行すること、またはステップのリストを実行することです。
チェーン・ルールはすべてまとまって機能し、チェーン全体の処理を定義します。チェーン・ジョブの開始時および各ステップの終了時に、次に実行される処理を判断するためにすべてのルールが評価されます。複数のルールにTRUE
条件がある場合は、複数の処理を発生させることができます。チェーンのevaluation_interval
属性を設定して、ルールを一定間隔で評価させることもできます。
条件は通常、1つ以上の先行するステップの結果に基づきます。たとえば、先行する2つのステップが成功した場合はあるステップを実行し、2つのステップのいずれかが失敗した場合には別のステップを実行する場合があります。
スケジューラのチェーン条件構文には、次の2つの書式があります。
stepname [NOT] {SUCCEEDED|FAILED|STOPPED|COMPLETED} stepname ERROR_CODE {comparision_operator|[NOT] IN} {integer|list_of_integers}
条件をブール演算子AND
、OR
およびNOT()
と組み合せて条件式を作成できます。式にカッコを使用すると、評価順序を指定できます。
ステップに割り当てたプログラム内でRAISE_APPLICATION_ERROR
PL/SQL文を使用して、ERROR_CODE
を設定できます。この方法でプログラムにより設定されるエラー・コードは負の数値ですが、チェーン・ルール内でERROR_CODE
をテストするときには正の数値をテストします。たとえば、プログラムに次の文が含まれている場合を考えます。
RAISE_APPLICATION_ERROR(-20100, errmsg);
チェーン・ルールの条件を次のように指定する必要があります。
stepname ERROR_CODE=20100
ステップ属性
次のリストに、SQL WHERE
句の構文を使用する際に条件に含めることのできるステップ属性を示します。
completed
state
start_date
end_date
error_code
duration
completed
属性はブール値で、state
属性がSUCCEEDED
、FAILED
またはSTOPPED
のときにはTRUE
です。
表29-7に、state
属性に使用される値を示します。これらの値は、*_SCHEDULER_RUNNING_CHAINS
ビューのSTATE
列で参照可能です。
表29-7 チェーン・ステップのstate属性の値
state属性の値 | 意味 |
---|---|
|
ステップのチェーンは実行中ですが、ステップはまだ開始されていません。 |
|
ルールによって |
|
ステップは実行中です。イベント・ステップの場合、ステップは開始されており、イベントを待機中です。 |
|
ステップの |
|
ステップは正常に完了しています。ステップの |
|
ステップはエラーで完了しました。 |
|
ステップは |
|
ステップはネストしたチェーンであり、停止されています。 |
SQL WHERE
句の構文のルールと例は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDEFINE_CHAIN_RULE
プロシージャに関する項を参照してください。
スケジューラ・チェーン条件の構文を使用した条件の例
次の例では、スケジューラ・チェーン条件の構文を使用しています。
次の条件を含んだルールによって開始されたステップは、form_validation_step
というステップが完了(SUCCEEDED
、FAILED
またはSTOPPED
)すると開始されます。
form_validation_step COMPLETED
次の条件も同様ですが、条件が満たされるにはステップが成功する必要があることを示しています。
form_validation_step SUCCEEDED
次の条件では、エラーがあるかどうかをテストしています。ステップform_validation_step
が失敗して20001以外のエラー・コードが戻された場合は、TRUE
になります。
form_validation_step FAILED AND form_validation_step ERROR_CODE != 20001
他の例は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDEFINE_CHAIN_RULE
プロシージャに関する項を参照してください。
SQL WHERE構文を使用した条件の例
':step1.state=''SUCCEEDED'''
チェーンの開始
チェーン・ジョブの開始時にチェーンを開始できるように、少なくとも1つのルールに、常にTRUE
に評価される条件が必要です。このための最も簡単な方法は、スケジュール・チェーン条件の構文を使用している場合は条件を'TRUE
'に設定すること、またはSQL構文を使用している場合は条件を'1=1
'に設定することです。
チェーンの終了
少なくとも1つのチェーン・ルールに、'END
'のaction
が含まれている必要があります。チェーン・ジョブは、END
処理が含まれているルールの1つがTRUE
に評価されるまでは完了しません。通常は、異なるEND
処理が設定された別々のルールがあり、エラー・コードを伴う場合と伴わない場合があります。
チェーンに実行するステップがなくなり、イベントの発生の待機中ではなく、END
処理が含まれているルールでTRUE
に評価されるルールがない(またはEND
処理が設定されているルールがない)場合、チェーン・ジョブの状態はCHAIN_STALLED
になります。詳細は、「ストールしたチェーンの処理」を参照してください。
ルールの定義例
次の例では、step1
でチェーンを開始するルールおよびstep1
の完了時にstep2
を開始するルールを定義しています。rule_name
およびcomments
はオプションですが、デフォルトでNULL
になります。rule_name
を使用する場合は、DEFINE_CHAIN_RULE
に対する別の呼出しで、そのルールを後で再定義できます。新しい定義で、以前の定義が上書きされます。
BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( chain_name => 'my_chain1', condition => 'TRUE', action => 'START step1', rule_name => 'my_rule1', comments => 'start the chain'); DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( chain_name => 'my_chain1', condition => 'step1 completed', action => 'START step2', rule_name => 'my_rule2'); END; /
関連項目:
-
DEFINE_CHAIN_RULE
プロシージャおよびスケジューラのチェーン条件構文の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.6 チェーン・ルールの評価間隔の設定
スケジューラでは、チェーン・ジョブの開始時と各チェーン・ステップの終了時に、すべてのチェーン・ルールが評価されます。
1時間に1回など、一定の時間間隔でスケジューラによってルールが評価されるようにチェーンを構成することもできます。この機能は、時間に基づいて、またはチェーン外部での発生に基づいてチェーン・ステップを開始するのに役立ちます。いくつか例を挙げます。
-
チェーン・ステップがリソース集中型であるため、オフピーク時に実行する必要があるとします。ステップの条件として、別のステップの完了と午後6時から午前0時までの時間の両方を設定できます。スケジューラでは、この条件が
TRUE
になる時期を判別するために、ルールをその都度評価する必要があります。 -
ステップが、チェーン外部にある他のプロセスから表にデータが到着するまで待機する必要があるとします。このステップの条件として、別のステップの完了と行を含む特定の表の両方を設定できます。スケジューラでは、この条件が
TRUE
になる時期を判別するために、ルールをその都度評価する必要があります。この条件はSQLWHERE
句構文を使用し、次のようになります。':step1.state=''SUCCEEDED'' AND select count(*) from oe.sync_table > 0'
チェーンの評価間隔を設定するには、チェーンの作成時にevaluation_interval
属性を設定します。この属性のデータ型はINTERVAL
DAY
TO
SECOND
です。
BEGIN DBMS_SCHEDULER.CREATE_CHAIN ( chain_name => 'my_chain1', rule_set_name => NULL, evaluation_interval => INTERVAL '30' MINUTE, comments => 'Chain with 30 minute evaluation interval'); END; /
親トピック: ジョブ・チェーンの作成と管理
29.6.7 チェーンの有効化
チェーンを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャを使用します。ジョブでチェーンを実行するには、チェーンを使用可能にする必要があります。すでに使用可能なチェーンを使用可能にしてもエラーは戻りません。
この例では、チェーンmy_chain1
が使用可能になります。
BEGIN DBMS_SCHEDULER.ENABLE ('my_chain1'); END; /
ENABLE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
ノート:
チェーンは、次のいずれかが削除された場合にスケジューラによって自動的に使用禁止にされます。
-
いずれかのチェーン・ステップが指し示しているプログラム
-
いずれかのチェーン・ステップが指し示しているネストしたチェーン
-
いずれかのチェーン・イベント・ステップが指し示しているイベント・スケジュール
親トピック: ジョブ・チェーンの作成と管理
29.6.8 チェーン用のジョブの作成
チェーンを実行するには、DBMS_SCHEDULER
パッケージのRUN_CHAIN
プロシージャを使用するか、CHAIN
タイプのジョブ(チェーン・ジョブ)を作成およびスケジュールする必要があります。
ジョブの処理では、次の例に示すように、以前に作成されたチェーン名を参照する必要があります。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'chain_job_1', job_type => 'CHAIN', job_action => 'my_chain1', repeat_interval => 'freq=daily;byhour=13;byminute=0;bysecond=0', enabled => TRUE); END; /
実行中のチェーン・ジョブの各ステップには、スケジューラによって、チェーン・ジョブと同じジョブ名と所有者を設定したステップ・ジョブが作成されます。各ステップ・ジョブにはさらに、そのジョブを一意に識別するためのサブ名があります。ジョブのサブ名は、ビュー*_SCHEDULER_RUNNING_JOBS
、*_SCHEDULER_JOB_LOG
および*_SCHEDULER_JOB_RUN_DETAILS
に列として表示できます。また、次の場合を除いて、ジョブのサブ名は通常はステップ名と同じです。
-
ネストされたチェーンの場合、現在のステップ名がすでにジョブのサブ名として使用されている場合があります。この場合、スケジューラは、'
_N
'をステップ名の最後に追加しますが、ここで、N
はジョブのサブ名を一意にするための整数を表します。 -
ステップ・ジョブの作成時にエラーが発生した場合、スケジューラは、ジョブ・サブ名を'
step_name_
0
'に設定して、ジョブ・ログ・ビュー(*_SCHEDULER_JOB_LOG
および*_SCHEDULER_JOB_RUN_DETAILS
)にFAILED
エントリを記録します。
関連項目:
-
CREATE_JOB
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
チェーン・ジョブを作成せずにチェーンを実行する別の方法は、「チェーンの実行」
親トピック: ジョブ・チェーンの作成と管理
29.6.9 チェーンの削除
ステップおよびルールを含むチェーンを削除するには、DBMS_SCHEDULER
パッケージのDROP_CHAIN
プロシージャを使用します。
次の例では、my_chain1
という名前のチェーンを削除しています。
BEGIN DBMS_SCHEDULER.DROP_CHAIN ( chain_name => 'my_chain1', force => TRUE); END; /
DROP_CHAIN
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.10 チェーンの実行
チェーンを即時に実行するには、DBMS_SCHEDULER
パッケージのRUN_JOB
またはRUN_CHAIN
プロシージャを使用します。
すでにチェーン用のチェーン・ジョブを作成している場合は、RUN_JOB
プロシージャを使用してそのジョブを実行(したがってチェーンを実行)できますが、RUN_JOB
のuse_current_session
引数をFALSE
に設定する必要があります。
RUN_CHAIN
プロシージャを使用すると、チェーンに対するチェーン・ジョブをあらかじめ作成することなく、チェーンを実行できます。また、RUN_CHAIN
を使用してチェーンの一部のみを実行することもできます。
RUN_CHAIN
は、指定したチェーンを実行する一時ジョブを作成します。ジョブ名を指定すると、その名前のジョブが作成されますが、それ以外の場合はデフォルトのジョブ名が割り当てられます。
開始ステップ・リストを指定すると、チェーンの実行開始時にそれらのステップのみが開始されます (通常開始されるステップは、それらがリスト内にない場合は実行されません)。開始ステップのリストが提供されない場合は、チェーンが通常どおり開始されます。つまり、初期評価が行われ、実行を開始するステップが判断されます。次の例では、my_chain1
を即時に実行します。
BEGIN
DBMS_SCHEDULER.RUN_CHAIN (
chain_name => 'my_chain1',
job_name => 'partial_chain_job',
start_steps => 'my_step2, my_step4');
END;
/
関連項目:
-
RUN_CHAIN
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.11 チェーン・ルールの削除
チェーンからルールを削除するには、DBMS_SCHEDULER
パッケージのDROP_CHAIN_RULE
プロシージャを使用します。
次の例では、my_rule1
を削除しています。
BEGIN DBMS_SCHEDULER.DROP_CHAIN_RULE ( chain_name => 'my_chain1', rule_name => 'my_rule1', force => TRUE); END; /
DROP_CHAIN_RULE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.12 チェーンの無効化
チェーンを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャを使用します。
次の例では、my_chain1
を使用禁止にしています。
BEGIN DBMS_SCHEDULER.DISABLE ('my_chain1'); END; /
DISABLE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
ノート:
チェーンは、次のいずれかが削除された場合にスケジューラによって自動的に使用禁止にされます。
-
いずれかのチェーン・ステップが指し示しているプログラム
-
いずれかのチェーン・ステップが指し示しているネストしたチェーン
-
いずれかのチェーン・イベント・ステップが指し示しているイベント・スケジュール
親トピック: ジョブ・チェーンの作成と管理
29.6.13 チェーン・ステップの削除
チェーンからステップを削除するには、DBMS_SCHEDULER
パッケージのDROP_CHAIN_STEP
プロシージャを使用します。
次の例では、my_chain2
からmy_step2
を削除しています。
BEGIN DBMS_SCHEDULER.DROP_CHAIN_STEP ( chain_name => 'my_chain2', step_name => 'my_step2', force => TRUE); END; /
DROP_CHAIN_STEP
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.14 チェーンの停止
実行中のチェーンを停止するには、DBMS_SCHEDULER.STOP_JOB
プロシージャをコールして、チェーン・ジョブ(チェーンを開始したジョブ)の名前を渡します。
チェーン・ジョブを停止すると、実行中のチェーンの全ステップが停止され、チェーンが終了します。
STOP_JOB
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.15 個々のチェーン・ステップの停止
ルールの条件が満たされたときに1つ以上のステップが停止するチェーン・ルールを作成するか、STOP_JOB
プロシージャを呼び出すことにより、個々のチェーン・ステップを停止できます。
停止するステップごとに、スキーマ名、チェーン・ジョブ名およびステップ・ジョブ・サブ名を指定する必要があります。
BEGIN DBMS_SCHEDULER.STOP_JOB('oe.chainrunjob.stepa'); END; /
この例では、chainrunjob
はチェーン・ジョブ名で、stepa
はステップ・ジョブ・サブ名です。通常、ステップ・ジョブ・サブ名はステップ名と同じですが、異なる場合もあります。ステップ・ジョブ・サブ名は、*_SCHEDULER_RUNNING_CHAINS
ビューのSTEP_JOB_SUBNAME
列から取得できます。
チェーン・ステップを停止すると、state
がSTOPPED
に設定され、チェーン・ルールが評価されて次に実行するステップが判別されます。
STOP_JOB
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.16 チェーンの一時停止
チェーン全体、またはチェーンの個別ブランチを一時停止できます。そのためには、DBMS_SCHEDULER.ALTER_CHAIN
またはALTER_RUNNING_CHAIN
プロシージャで、1つ以上のステップのPAUSE
属性をTRUE
に設定します。
チェーン・ステップを一時停止すると、チェーンの実行をそのステップの実行後に一時停止できます。
ステップを一時停止すると、そのステップの実行後にstate
属性がPAUSED
に変わりますが、completed
属性はFALSE
のままです。そのため、一時停止したステップの完了に依存しているステップは実行されません。一時停止したステップのPAUSE
属性をFALSE
にリセットすると、state
属性が完了状態(SUCCEEDED
、FAILED
またはSTOPPED
)に設定され、一時停止したステップの完了を待機しているステップを実行できるようになります。
図29-1では、ステップ3が一時停止されています。ステップ3の一時停止が解除されるまで、ステップ5は実行されません。ステップ2のみを一時停止した場合、ステップ4、6および7は実行されません。ただし、ステップ1、3および5は実行できます。いずれの場合も、チェーンのブランチを1つのみ一時停止することになります。
チェーン全体を一時停止するには、チェーンのステップをすべて一時停止します。チェーンの一時停止を解除するには、チェーン・ステップの1つ、多数またはすべての一時停止を解除します。図29-1のチェーンでは、ステップ1を一時停止すると、ステップ1の実行後にチェーン全体も一時停止します。
関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_SCHEDULER.ALTER_CHAIN
およびDBMS_SCHEDULER.ALTER_RUNNING_CHAIN
プロシージャに関する項を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.17 チェーン・ステップのスキップ
チェーンの1つ以上のステップをスキップできます。そのためには、DBMS_SCHEDULER.ALTER_CHAIN
またはALTER_RUNNING_CHAIN
プロシージャで、1つ以上のステップのSKIP
属性をTRUE
に設定します。
ステップのSKIP
属性がTRUE
の場合、そのステップを実行するためのチェーン条件を満たすと、そのステップは実行されるかわりに、即時に成功した場合と同様に処理されます。SKIP
をTRUE
に設定しても、実行中のステップ、遅延後に実行するようにスケジュールされているステップまたは実行済のステップには影響しません。
ステップのスキップが特に役立つのは、チェーンのテスト時です。たとえば、図29-1に示したチェーンをテストする際に、ステップ7をスキップすると、このステップはネストしたチェーンであるため、テスト時間を大幅に短縮できます。
関連項目:
親トピック: ジョブ・チェーンの作成と管理
29.6.18 チェーンの一部実行
チェーンの一部のみを実行することができます。
チェーンの一部のみを実行するには2つの方法があります。
-
ALTER_CHAIN
プロシージャを使用して、1つ以上のステップに対してPAUSE
属性をTRUE
に設定してから、RUN_JOB
でチェーン・ジョブを起動するか、RUN_CHAIN
でチェーンを起動します。一時停止しているステップに依存するステップは実行されませんが、一時停止しているステップは実行されます。この方法のデメリットは、チェーンを将来実行する場合に備えて、影響を受けるステップの
PAUSE
属性の設定をFALSE
に戻す必要があることです。 -
RUN_CHAIN
プロシージャを使用して、実行しないステップをスキップし、チェーンの特定ステップのみを開始します。この方法の方が簡単であり、ステップの開始前に初期状態を設定することもできます。
この2つの方法の両方を使用して、チェーンの開始時と終了時の両方でステップをスキップすることが必要な場合もあります。
詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のRUN_CHAIN
プロシージャに関する項を参照してください。
親トピック: ジョブ・チェーンの作成と管理
29.6.19 実行中のチェーンの監視
実行中のチェーンの状態は、*_SCHEDULER_RUNNING_JOBS
および*_SCHEDULER_RUNNING_CHAINS
の2つのビューで参照できます。
*_SCHEDULER_RUNNING_JOBS
ビューには、チェーン・ジョブに関する1行と実行中の各ステップに関する1行が含まれています。*_SCHEDULER_RUNNING_CHAINS
ビューには、各チェーン・ステップ(ネストしたチェーンを含む)に関する1行と、各ステップの実行ステータス(NOT_STARTED
、RUNNING
、STOPPED
、SUCCEEDED
など)が含まれています。
関連項目:
-
*_SCHEDULER_RUNNING_JOBS
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください -
*_SCHEDULER_RUNNING_CHAINS
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください
親トピック: ジョブ・チェーンの作成と管理
29.6.20 ストールしたチェーンの処理
ステップの完了時には、常にチェーン・ルールが評価され、次に実行するステップが判別されます。いずれのルールでも別のステップが開始されず、チェーンが終了せず、チェーンのevaluation_interval
がNULL
の場合は、チェーンがstalled状態になります。
チェーンが停止状態になっている場合、実行中のステップはありません。また、(指定の時間間隔だけ待機した後に)実行するようにスケジュールされているステップや、イベントを待機中のイベント・ステップもありません。この場合、チェーンを実行しているジョブの状態はCHAIN_STALLED
に設定されます。ただし、ジョブは*_SCHEDULER_RUNNING_JOBS
ビューにリストされたままです。
停止状態のチェーンの問題を解決するには、ビューALL_SCHEDULER_RUNNING_CHAINS
(チェーン(ネストしたチェーンを含む)内のすべてのステップの状態が示されます)とビューALL_SCHEDULER_CHAIN_RULES
(すべてのチェーン・ルールが含まれます)が使用されます。
ALTER_RUNNING_CHAIN
プロシージャを使用していずれかのステップのstate
を変更すると、チェーンの実行を継続できます。たとえば、ステップ11がステップ9の正常終了まで待機してから開始するようになっており、状態の変更がこれに関係する場合、ステップ9のstate
を'SUCCEEDED
'に設定することもできます。
あるいは、1つ以上のルールが正しくない場合は、DEFINE_CHAIN_RULE
プロシージャを使用して、(同じルール名を使用して)それらのルールを置換するか、または新規ルールを作成できます。新規および更新したルールは、実行中のチェーンと次回以降のすべてのチェーン実行に適用されます。ルールの追加または更新後は、停止状態のチェーン・ジョブでEVALUATE_RUNNING_CHAIN
を実行し、必要な処理をトリガーする必要があります。
親トピック: ジョブ・チェーンの作成と管理
29.7 非互換性定義の使用
非互換性定義(または非互換性)は、互換性のないジョブまたはプログラムを指定し、該当する場合は一度に1つのグループのみを実行できるようにします。
- ジョブまたはプログラムの非互換性の作成
ジョブ・レベルまたはプログラム・レベルの非互換性を指定するには、DBMS_SCHEDULER
パッケージのCREATE_INCOMPATIBILITY
プロシージャを使用します。 - 非互換性へのジョブまたはプログラムの追加
既存の非互換性定義にジョブまたはプログラムを追加するには、DBMS_SCHEDULER
パッケージのADD_TO_INCOMPATIBILITY
プロシージャを使用します。 - 非互換性からのジョブまたはプログラムの削除
既存の非互換性定義からジョブまたはプログラムを削除するには、DBMS_SCHEDULER
パッケージのREMOVE_FROM_INCOMPATIBILITY
プロシージャを使用します。 - 非互換性の削除
既存の非互換性定義を削除するには、DBMS_SCHEDULER
パッケージのDROP_INCOMPATIBILITY
プロシージャを使用します。
関連項目:
-
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_SCHEDULERに関する項
29.7.1 ジョブまたはプログラムの非互換性の作成
ジョブ・レベルまたはプログラム・レベルの非互換性を指定するには、DBMS_SCHEDULER
パッケージのCREATE_INCOMPATIBILITY
プロシージャを使用します。
たとえば、次の文はjob1
、job2
またはjob3
というジョブのいずれかのみが一度に実行できることを指定するincompat1
という非互換性を作成します。
BEGIN dbms_scheduler.create_incompatibility( incompatibility_name => 'icompat1', object_name => 'job1,job2,job3', enabled => true ); END; /
object_name
には、相互に互換性がない(つまり、一度に実行できない)すべてのプログラムまたはすべてのジョブのカンマ区切りのリストを指定します。ジョブの場合、リストは複数のジョブで構成され、constraint_level
は'JOB_LEVEL'
(デフォルト。例には含まれていません)である必要があります。プログラムの場合、constraint_level
には'JOB_LEVEL'
または'PROGRAM_LEVEL'
を指定できます。デフォルト値の'JOB_LEVEL'
を設定した場合、object_name
に指定されているプログラム(複数も可)に基づく単一ジョブのみを同時に実行できます。PROGRAM_LEVEL
を設定した場合、プログラムに互換性はないが、同じプログラムに基づくジョブには互換性があります。
たとえば、object_name
の値が'P1,P2,P3'
で、constraint_level
が'PROGRAM_LEVEL'
である場合、P1に基づく多数のジョブを同時に実行できますが、P1ベースのジョブが実行されている場合、P2またはP3に基づくジョブは実行できません。同様に、P3に基づく多数のジョブを同時に実行できますが、P1またはP2に基づくジョブは実行できません。constraint_level
に'JOB_LEVEL'
が設定されている場合、特定の時点で実行できるのは、プログラムP1、P2およびP3に基づくすべてのジョブのうちの単一のジョブのみです。
関連項目:
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のCREATE INCOMPATIBILITYプロシージャに関する項
親トピック: 非互換性定義の使用
29.7.2 非互換性へのジョブまたはプログラムの追加
既存の非互換性定義にジョブまたはプログラムを追加するには、DBMS_SCHEDULER
パッケージのADD_TO_INCOMPATIBILITY
プロシージャを使用します。
たとえば、次の文はicomp1234
という非互換性にジョブjob1
を追加します。
BEGIN dbms_scheduler.add_to_incompatibility( incompatibility_name => 'icomp1234', object_name => 'job1'); END; /
incompatibility_name
は既存の非互換性定義の名前です。
object_name
には、ジョブまたはプログラムのカンマ区切りのリストが含まれています。
指定した追加するジョブまたはプログラムが指定した非互換性定義にすでに含まれていても、このプロシージャはエラーを生成しません。
関連項目:
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のADD_TO_INCOMPATIBILITYプロシージャに関する項
親トピック: 非互換性定義の使用
29.7.3 非互換性からのジョブまたはプログラムの削除
既存の非互換性定義からジョブまたはプログラムを削除するには、DBMS_SCHEDULER
パッケージのREMOVE_FROM_INCOMPATIBILITY
プロシージャを使用します。
たとえば、次の文はicomp1234
という非互換性からジョブjob1
を削除します。
BEGIN dbms_scheduler.remove_from_incompatibility( incompatibility_name => 'icomp1234', object_name => 'job1'); END; /
incompatibility_name
は既存の非互換性定義の名前です。
object_name
には、ジョブまたはプログラムのカンマ区切りのリストが含まれています。
指定した削除するジョブまたはプログラムが指定した非互換性定義に存在しない場合、このプロシージャはエラーを生成しません。
関連項目:
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のREMOVE_FROM_INCOMPATIBILITYプロシージャに関する項
親トピック: 非互換性定義の使用
29.7.4 非互換性の削除
既存の非互換性定義を削除するには、DBMS_SCHEDULER
パッケージのDROP_INCOMPATIBILITY
プロシージャを使用します。
たとえば、次の文は非互換性icomp1234
を削除します。
BEGIN dbms_scheduler.drop_incompatibility( incompatibility_name => 'icomp1234'; END; /
incompatibility_name
は既存の非互換性定義の名前です。
関連項目:
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDROP_INCOMPATIBILITYプロシージャに関する項
親トピック: 非互換性定義の使用
29.8 ジョブ・リソースの管理
ジョブが使用できるリソースを作成および変更したり、ジョブが使用できる指定されたリソースの量を制御したりできます。
お客様にはリソースにアクセスする必要があるジョブがあります。使用できるそのようなリソースの数は限られているため、スケジュール・システムは各リソースおよびそれを使用しているジョブを追跡し、必要なリソースが使用可能になるまでジョブをスケジュールしないでおく必要があります。
- リソースの作成または削除
リソースを作成するには、DBMS_SCHEDULER
パッケージのCREATE_RESOURCE
プロシージャを使用します。 - リソースの変更
リソースを変更するには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
およびSET_ATTRIBUTE_NULL
プロシージャを使用します。 - ジョブのリソース制約の設定
ジョブまたはプログラムが使用するリソースを指定するには、DBMS_SCHEDULER
パッケージのSET_RESOURCE_CONSTRAINT
プロシージャを使用します。
関連項目:
-
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_SCHEDULERに関する項
29.8.1 リソースの作成または削除
リソースを作成するには、DBMS_SCHEDULER
パッケージのCREATE_RESOURCE
プロシージャを使用します。
リソースは、リソースを作成しているユーザーのスキーマに作成されます。
たとえば、次の文はmy_resource
という名前のリソースを作成して、3ユニットのリソースが内部的に使用可能になるように指定し、スケジューラは3ユニットを超えるリソースがジョブによって同時に使用されないように制約を管理します。
BEGIN DBMS_SCHEDULER.CREATE_RESOURCE( resource_name => 'my_resource', units => 3, state => 'ENFORCE_CONSTRAINTS', comments => 'Resource1' ) END; /
リソースが必要なくなった場合は、DBMS_SCHEDULER
パッケージのDROP_RESOURCE
プロシージャを使用して削除できます。例:
BEGIN DBMS_SCHEDULER.DROP_RESOURCE( resource_name => 'my_resource', force => true ) END; /
関連項目:
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のCREATE_RESOURCEプロシージャに関する項
親トピック: ジョブ・リソースの管理
29.8.2 リソースの変更
リソースを変更するには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
およびSET_ATTRIBUTE_NULL
プロシージャを使用します。
リソースを変更した場合、その変更はこのリソースを使用する現在実行されているジョブには影響しません。変更はそのリソースを使用する後続のジョブで有効になります。
関連項目:
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のSET_ATTRIBUTEプロシージャおよびSET_ATTRIBUTE_NULLプロシージャに関する項
親トピック: ジョブ・リソースの管理
29.8.3 ジョブのリソース制約の設定
ジョブまたはプログラムが使用するリソースを指定するには、DBMS_SCHEDULER
パッケージのSET_RESOURCE_CONSTRAINT
プロシージャを使用します。
指定したジョブやプログラムが使用できるリソースのユニット数を指定できます。
たとえば、次の文はjob1
というオブジェクトがresource1
というリソースの1ユニットを使用できることを指定します。
BEGIN DBME_SCHEDULER.SET_RESOURCE_CONSTRAINT( OBJECT_NAME => 'job1', RESOURCE_NAME => 'resource1', UNITS =>1); END; /
object_name
パラメータには、プログラムまたはジョブの名前、あるいは名前のカンマ区切りのリストを指定できます。
units
パラメータは、このプログラムまたはジョブが使用できるリソースのユニット数を指定します。units
に0を設定した場合、プログラムやジョブはこのリソースを使用しなくなり、制約が削除されることを意味します。以前は制約がなかったリソースでunits
に0を設定すると、エラーが生成されます。
同一のリソースに複数の制約を定義する場合、オブジェクト・タイプ(ジョブまたはプログラム)が一致している必要があります。たとえば、リソースの1つ以上の制約がジョブに基づいている場合、同じリソースにプログラムに対する新しい制約を追加すると、エラーが生成されます。
関連項目:
『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のSET_RESOURCE_CONSTRAINTプロシージャに関する項
親トピック: ジョブ・リソースの管理
29.9 ジョブの優先度付け
3つのスケジューラ・ジョブ(ジョブ・クラス、ウィンドウおよびウィンドウ・グループ)を使用して、Oracle Schedulerジョブに優先度を付けます。これらのオブジェクトでは、ジョブをデータベース・リソース・マネージャのコンシューマ・グループに関連付けることによって、ジョブに優先度を付けます。これにより、これらのジョブに割り当てられるリソースの量が制御されます。また、ジョブ・クラスでは、グループ内のすべてのジョブに同一のリソース・レベルが割り当てられている場合に、ジョブのグループ間に相対的な優先度を設定できます。
- ジョブ・クラスのジョブ優先度の管理
ジョブ・クラスでは、ジョブをグループ化して優先度を付けることができます。また、メンバー・ジョブに一連の属性値を簡単に割り当てることができます。ジョブ・クラスは、データベース・リソース・マネージャに関連するジョブ・クラス属性を通して各メンバー・ジョブの優先度に影響します。 - ジョブ・クラス内でのジョブの相対的な優先度の設定
DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
プロシージャを使用して、同じジョブ・クラス内のジョブの相対的な優先度を変更できます。ジョブの優先度は、1を最も高い優先度として1から5の範囲で設定する必要があります。 - ウィンドウを使用したジョブ・スケジューリングとジョブ優先度の管理
日または週などの様々な期間中に、ジョブを自動的に開始したり、複数のジョブ間のリソース割当てを変更するには、ウィンドウを作成します。ウィンドウは、時間間隔で表現されます。 - ウィンドウ・グループを使用したジョブ・スケジューリングとジョブ優先度の管理
ウィンドウ・グループを使用すると、1日あるいは1週間などの間に複数期間実行するジョブを簡単にスケジュールできます。ウィンドウ・グループを作成してウィンドウをグループに加え、ウィンドウ・グループ名をジョブのschedule_name
属性に設定すると、ジョブがウィンドウ・グループ内のすべてのウィンドウの指定期間に実行されます。ウィンドウ・グループはSYS
スキーマにあります。 - リソース・マネージャを使用したジョブ間のリソース割当て
データベース・リソース・マネージャ(リソース・マネージャ)は、データベース・セッション間のリソースの割当て方法を制御します。スケジューラ・ジョブのような非同期セッションだけでなく、ユーザー・セッションのような同期セッションも制御します。 - ジョブに対するリソース割当ての例
ジョブのリソースの割当て方法の例を示します。
29.9.1 ジョブ・クラスのジョブ優先度の管理
ジョブ・クラスでは、ジョブをグループ化して優先度を付けることができます。また、メンバー・ジョブに一連の属性値を簡単に割り当てることができます。ジョブ・クラスは、データベース・リソース・マネージャに関連するジョブ・クラス属性を通して各メンバー・ジョブの優先度に影響します。
データベースとともにデフォルトのジョブ・クラスが作成されます。ジョブ・クラスを指定せずにジョブを作成すると、ジョブはこのデフォルトのジョブ・クラス(DEFAULT_JOB_CLASS
)に割り当てられます。デフォルトのジョブ・クラスでは、EXECUTE
権限がPUBLIC
に付与されているため、ジョブの作成権限を持つすべてのデータベース・ユーザーは、デフォルトのジョブ・クラスにジョブを作成できます。
- ジョブ・クラスのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なジョブ・クラスのタスクを管理します。 - ジョブ・クラスの作成
ジョブ・クラスを作成するには、DBMS_SCHEDULER
パッケージのCREATE_JOB_CLASS
プロシージャまたはCloud Controlを使用します。ジョブ・クラスは、常にSYS
スキーマに作成されます。 - ジョブ・クラスの変更
ジョブ・クラスを変更するには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
プロシージャまたはCloud Controlを使用します。 - ジョブ・クラスの削除
1つ以上のジョブ・クラスを削除するには、DBMS_SCHEDULER
パッケージのDROP_JOB_CLASS
プロシージャまたはCloud Controlを使用します。
関連項目:
-
ジョブ・クラスを表示するには、『Oracle Databaseリファレンス』
-
ジョブ・クラスの概要については、「ジョブ・クラス」
親トピック: ジョブの優先度付け
29.9.1.1 ジョブ・クラスのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なジョブ・クラスのタスクを管理します。
表29-8に、ジョブ・クラスの一般的なタスクとそれに対応するプロシージャおよび権限を示します。
表29-8 ジョブ・クラスのタスクとそのプロシージャ
タスク | プロシージャ | 必要な権限 |
---|---|---|
ジョブ・クラスの作成 |
|
|
ジョブ・クラスの変更 |
|
|
ジョブ・クラスの削除 |
|
|
権限の詳細は、「スケジューラ権限」を参照してください。
親トピック: ジョブ・クラスのジョブ優先度の管理
29.9.1.2 ジョブ・クラスの作成
ジョブ・クラスを作成するには、DBMS_SCHEDULER
パッケージのCREATE_JOB_CLASS
プロシージャまたはCloud Controlを使用します。ジョブ・クラスは、常にSYS
スキーマに作成されます。
次の文では、すべての財務ジョブ用のジョブ・クラスが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_JOB_CLASS ( job_class_name => 'finance_jobs', resource_consumer_group => 'finance_group'); END; /
このジョブ・クラス内のすべてのジョブは、finance_group
リソース・コンシューマ・グループに割り当てられます。
ジョブ・クラスを問い合せるには、*_SCHEDULER_JOB_CLASSES
ビューを使用します。
関連項目:
親トピック: ジョブ・クラスのジョブ優先度の管理
29.9.1.3 ジョブ・クラスの変更
ジョブ・クラスを変更するには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
プロシージャまたはCloud Controlを使用します。
また、ジョブ・クラス名以外のすべての属性を変更できます。ジョブ・クラスの属性は、*_SCHEDULER_JOB_CLASSES
ビューで使用可能です。
ジョブ・クラスを変更した場合、そのクラスに属する実行中のジョブには影響しません。この変更は、今後実行されるジョブに対してのみ有効です。
親トピック: ジョブ・クラスのジョブ優先度の管理
29.9.1.4 ジョブ・クラスの削除
1つ以上のジョブ・クラスを削除するには、DBMS_SCHEDULER
パッケージのDROP_JOB_CLASS
プロシージャまたはCloud Controlを使用します。
ジョブ・クラスの削除とは、そのジョブ・クラスのすべてのメタデータをデータベースから削除することです。
DROP_JOB_CLASS
プロシージャ・コールにジョブ・クラス名のカンマ区切りのリストを指定することで、1回のコールで複数のジョブ・クラスを削除できます。たとえば、次の文では3つのジョブ・クラスが削除されます。
BEGIN DBMS_SCHEDULER.DROP_JOB_CLASS('jobclass1, jobclass2, jobclass3'); END; /
親トピック: ジョブ・クラスのジョブ優先度の管理
29.9.2 ジョブ・クラス内でのジョブの相対的な優先度の設定
DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
プロシージャを使用して、同じジョブ・クラス内のジョブの相対的な優先度を変更できます。ジョブの優先度は、1を最も高い優先度として1から5の範囲で設定する必要があります。
たとえば、次の文では、my_job1
のジョブ優先度の設定が1
に変更されます。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'my_emp_job1', attribute => 'job_priority', value => 1); END; /
属性が変更されたことを確認するには、次の文を発行します。
SELECT JOB_NAME, JOB_PRIORITY FROM DBA_SCHEDULER_JOBS; JOB_NAME JOB_PRIORITY ------------------------------ ------------ MY_EMP_JOB 3 MY_EMP_JOB1 1 MY_NEW_JOB1 3 MY_NEW_JOB2 3 MY_NEW_JOB3 3
システムにおけるジョブの全体的な優先度は、最初に、そのジョブのジョブ・クラスが割り当てられているリソース・コンシューマ・グループと現行のリソース・プランの組合せによって決定され、次に、ジョブ・クラス内の相対的な優先度によって決定されます。
関連項目:
-
SET_ATTRIBUTE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
親トピック: ジョブの優先度付け
29.9.3 ウィンドウを使用したジョブ・スケジューリングとジョブ優先度の管理
日または週などの様々な期間中に、ジョブを自動的に開始したり、複数のジョブ間のリソース割当てを変更するには、ウィンドウを作成します。ウィンドウは、時間間隔で表現されます。
- ウィンドウでのジョブ・スケジューリングとジョブ優先度について
ウィンドウを使用すると、異なる時間帯で別々のリソース・プランを自動的にアクティブにできます。ジョブを実行すると、そのジョブに割り当てられているリソースが、リソース・プランの変更時に変わることがわかります。 - ウィンドウのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なウィンドウのタスクを管理します。 - ウィンドウの作成
ウィンドウを作成するには、Cloud ControlまたはDBMS_SCHEDULER.CREATE_WINDOW
プロシージャを使用できます。 - ウィンドウの変更
ウィンドウを変更するには、その属性を変更します。そのためには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
およびSET_ATTRIBUTE_NULL
プロシージャまたはCloud Controlを使用します。 - ウィンドウのオープン
ウィンドウがオープンすると、スケジューラは、ウィンドウの作成時に関連付けられたリソース・プランに切り替えます。ウィンドウのオープン時に実行中のジョブがある場合、そのジョブに割り当てられているリソースはリソース・プランの切替えによって変更される場合があります。 - ウィンドウのクローズ
ウィンドウはスケジュールに基づいてクローズするか、手動でクローズできます。 - ウィンドウの削除
1つ以上のウィンドウを削除するには、DBMS_SCHEDULER
パッケージのDROP_WINDOW
プロシージャまたはCloud Controlを使用します。 - ウィンドウの無効化
1つ以上のウィンドウを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャまたはCloud Controlを使用します。 - ウィンドウの有効化
1つ以上のウィンドウを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャまたはCloud Controlを使用します。
親トピック: ジョブの優先度付け
29.9.3.1 ウィンドウでのジョブ・スケジューリングとジョブ優先度について
ウィンドウを使用すると、異なる時間帯で別々のリソース・プランを自動的にアクティブにできます。ジョブを実行すると、そのジョブに割り当てられているリソースが、リソース・プランの変更時に変わることがわかります。
ジョブは、そのschedule_name
属性でウィンドウを指定できます。スケジューラは、このウィンドウがオープンしているジョブを開始します。ウィンドウには、ワークロード・サイクル中の様々な時間にオープンできるように、スケジュールが関連付けられます。
ウィンドウの主な属性は次のとおりです。
-
スケジュール
ウィンドウが有効である時期を制御します。
-
期間
ウィンドウがオープンしている長さを制御します。
-
リソース・プラン
ウィンドウのオープン時にアクティブ化されるリソース・プランの名前を設定します。
特定の時間に有効にできるウィンドウは1つのみです。ウィンドウはSYS
スキーマに属します。
すべてのウィンドウ・アクティビティは、*_SCHEDULER_WINDOW_LOG
ビューに記録されます(ウィンドウ・ログとも呼ばれる)。ウィンドウ・ログの例は、「ウィンドウ・ログ」を参照してください。
関連項目:
ウィンドウの概要については、「ウィンドウ」を参照してください。
29.9.3.2 ウィンドウのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なウィンドウ・タスクを管理します。
表29-9に、ウィンドウの一般的なタスクとその処理に使用するプロシージャを示します。
表29-9 ウィンドウのタスクとそのプロシージャ
タスク | プロシージャ | 必要な権限 |
---|---|---|
ウィンドウの作成 |
|
|
ウィンドウのオープン |
|
|
ウィンドウのクローズ |
|
|
ウィンドウの変更 |
|
|
ウィンドウの削除 |
|
|
ウィンドウの使用禁止 |
|
|
ウィンドウの使用可能化 |
|
|
権限の詳細は、「スケジューラ権限」を参照してください。
29.9.3.3 ウィンドウの作成
ウィンドウを作成するには、Cloud ControlまたはDBMS_SCHEDULER.CREATE_WINDOW
プロシージャを使用します。
パッケージ・プロシージャを使用すると、resource_plan
パラメータをNULL
のままにできます。この場合は、ウィンドウのオープン時に現行のプランが有効のままになります。
ウィンドウを作成するには、MANAGE
SCHEDULER
権限が必要です。
ウィンドウにスケジュールを指定する場合、スケジューラではそのスケジュールにウィンドウがすでに定義されているかどうかはチェックされません。したがって、複数のウィンドウが重複する場合があります。また、繰返し間隔としてPL/SQL式が設定されている名前付きスケジュールの使用は、ウィンドウに対してはサポートされていません。
ウィンドウ属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のCREATE_WINDOW
プロシージャに関する項を参照してください。
次の例では、営業時間中にmixed_workload_plan
リソース・プランを有効にするdaytime
というウィンドウを作成しています。
BEGIN DBMS_SCHEDULER.CREATE_WINDOW ( window_name => 'daytime', resource_plan => 'mixed_workload_plan', start_date => '28-APR-09 08.00.00 AM', repeat_interval => 'freq=daily; byday=mon,tue,wed,thu,fri', duration => interval '9' hour, window_priority => 'low', comments => 'OLTP transactions have priority'); END; /
ウィンドウが正しく作成されたことを検証するには、DBA_SCHEDULER_WINDOWS
ビューを問い合せます。たとえば、次の文を発行します。
SELECT WINDOW_NAME, RESOURCE_PLAN, DURATION, REPEAT_INTERVAL FROM DBA_SCHEDULER_WINDOWS; WINDOW_NAME RESOURCE_PLAN DURATION REPEAT_INTERVAL ----------- ------------------- ------------- --------------- DAYTIME MIXED_WORKLOAD_PLAN +000 09:00:00 freq=daily; byday=mon,tue,wed,thu,fri
29.9.3.4 ウィンドウの変更
ウィンドウを変更するには、その属性を変更します。そのためには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
およびSET_ATTRIBUTE_NULL
プロシージャまたはCloud Controlを使用します。
変更するときは、WINDOW_NAME
以外のすべてのウィンドウ属性を変更できます。ウィンドウ属性の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のCREATE_WINDOW
プロシージャに関する項を参照してください。
ウィンドウを変更した場合、アクティブ・ウィンドウには影響しません。この変更は、次回ウィンドウをオープンするときからのみ有効になります。
すべてのウィンドウを変更できます。使用禁止のウィンドウを変更した場合は、変更した後も使用禁止のままです。使用可能なウィンドウは自動的に使用禁止になり、変更後、使用可能化プロセスで実行される妥当性チェックが成功した場合は再び使用可能になります。
SET_ATTRIBUTE
およびSET_ATTRIBUTE_NULL
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.9.3.5 ウィンドウのオープン
ウィンドウがオープンすると、スケジューラは、ウィンドウの作成時に関連付けられたリソース・プランに切り替えます。ウィンドウのオープン時に実行中のジョブがある場合、そのジョブに割り当てられているリソースはリソース・プランの切替えによって変更される場合があります。
ウィンドウをオープンする方法は、次の2通りあります。
-
ウィンドウのスケジュールに基づいたオープン
-
OPEN_WINDOW
プロシージャを使用した手動オープンこのプロシージャは、スケジュールとは関係なくウィンドウをオープンします。ウィンドウがオープンし、関連付けられたリソース・プランが即時に有効になります。手動でオープンできるのは、使用可能なウィンドウのみです。
OPEN_WINDOW
プロシージャで、duration
属性を使用して、ウィンドウがオープンしている時間の長さを指定できます。継続時間の型はINTERVAL DAY TO SECONDです。継続時間の指定がない場合、ウィンドウはそのウィンドウに保存されている通常の継続時間の間オープン状態です。手動によるウィンドウのオープンは、通常のスケジュール・ウィンドウの実行には影響しません。
手動でオープンしたウィンドウをクローズする場合で、クローズするときに他のウィンドウもある場合、どのウィンドウをオープンするかを決定するために、オーバーラップ・ウィンドウのルールが適用されます。
すでにオープンしているウィンドウがある場合でも、
OPEN_WINDOW
コールまたはCloud Controlでforce
オプションをTRUE
に設定すると、ウィンドウを強制的にオープンできます。force
オプションがTRUE
に設定されているときは、その時点でオープンしているウィンドウの優先度の方が高い場合でも、スケジューラはウィンドウを自動的にクローズします。この手動でオープンしたウィンドウの継続時間中は、Schedulerにより他のスケジュール・ウィンドウはオープンされません(より優先順位の高いウィンドウもオープンされません)。すでにオープンしているウィンドウをオープンできます。この場合、ウィンドウは、OPEN_WINDOW
コマンドが発行された時点から、コールで指定された継続時間の間オープンしたままになります。これを示す例を考えます。
window1
は、4時間の期間という設定で作成されました。もう2時間オープンしています。この時点でOPEN_WINDOW
呼出しを使用してwindow1
を再びオープンし、期間を指定しないと、window1
には4時間という期間が設定されるため、もう4時間オープンすることになります。30分という期間を指定すると、ウィンドウは30分でクローズします。
ウィンドウがオープンすると、ウィンドウ・ログにエントリが作成されます。
現在のリソース・プランが、ALTER
SYSTEM
文FORCE
オプションあるいはDBMS_RESOURCE_MANAGER.SWITCH_PLAN
パッケージ・プロシージャのallow_scheduler_plan_switches
引数FALSE
を使用して、手動で切り替えられたものである場合、ウィンドウでリソース・プランの切替えに失敗する可能性があります。この場合、リソース・プランの切替え失敗がウィンドウ・ログに書き込まれます。
関連項目:
-
DBMS_SCHEDULER.OPEN_WINDOW
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 -
DBMS_RESOURCE_MANAGER.SWITCH_PLAN
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.9.3.6 ウィンドウのクローズ
ウィンドウはスケジュールに基づいてクローズするか、手動でクローズできます。
ウィンドウをクローズする方法は、次の2通りあります。
-
スケジュールに基づいたクローズ
ウィンドウは作成時に定義されたスケジュールに基づいてクローズします。
-
CLOSE_WINDOW
プロシージャを使用した手動クローズCLOSE_WINDOW
プロシージャは、オープン中のウィンドウを期間終了前にクローズします。
ウィンドウはクローズすると無効になります。ウィンドウがクローズすると、スケジューラは、リソース・プランをそのウィンドウ期間外で有効だったリソース・プランに切り替えるか、またはウィンドウの重複がある場合は別のウィンドウに切り替えます。存在しないウィンドウ、またはオープンしていないウィンドウをクローズしようとすると、エラーが発生します。
実行中のジョブは、そのジョブが実行されているウィンドウがクローズした場合でも、stop_on_window_close
属性がジョブの作成時にTRUE
に設定されていないかぎり停止しません。ただし、リソース・プランが変更される場合があるため、ジョブに割り当てられているリソースは変更される可能性があります。
実行中のジョブにスケジュールとしてウィンドウ・グループが設定されていると、そのジョブは、同じウィンドウ・グループのメンバーである別のウィンドウが元のウィンドウのクローズ時にアクティブになった場合、停止しません。これは、stop_on_window_close
属性がTRUE
に設定された状態でジョブが作成されている場合でも同じです。
ウィンドウがクローズ状態になると、ウィンドウ・ログDBA_SCHEDULER_WINDOW_LOG
にエントリが追加されます。
CLOSE_WINDOW
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.9.3.7 ウィンドウの削除
1つ以上のウィンドウを削除するには、DBMS_SCHEDULER
パッケージのDROP_WINDOW
プロシージャまたはCloud Controlを使用します。
ウィンドウが削除されると、そのウィンドウに関するすべてのメタデータが*_SCHEDULER_WINDOWS
ビューから削除されます。また、ウィンドウに対するすべての参照がウィンドウ・グループから削除されます。
DROP_WINDOW
プロシージャにウィンドウ名またはウィンドウ・グループ名のカンマ区切りのリストを指定すると、1回のコールで複数のウィンドウを削除できます。たとえば、次の文ではウィンドウとウィンドウ・グループの両方が削除されます。
BEGIN DBMS_SCHEDULER.DROP_WINDOW ('window1, window2, window3, windowgroup1, windowgroup2'); END; /
ウィンドウ・グループ名を指定した場合、ウィンドウ・グループ内のウィンドウは削除されますが、ウィンドウ・グループは削除されません。ウィンドウ・グループを削除するには、DROP_GROUP
プロシージャを使用する必要があります。
DROP_GROUP
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.9.3.8 ウィンドウの無効化
1つ以上のウィンドウを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャまたはCloud Controlを使用します。
そのため、ウィンドウはオープンしません。ただし、ウィンドウのメタデータは依然存在するため、再び使用可能に設定できます。DISABLE
プロシージャは複数のスケジューラ・オブジェクトに対して使用されるため、ウィンドウを使用禁止にするときは、先頭にSYS
を付ける必要があります。
ウィンドウは他の理由で使用禁止になる場合もあります。たとえば、ウィンドウはそのスケジュールの終了時に使用禁止になります。また、存在しないスケジュールをウィンドウが指し示している場合も使用禁止になります。
スケジュールとしてウィンドウが設定されているジョブがある場合、そのウィンドウは、プロシージャ・コールでforce
をTRUE
に設定しないかぎり、使用禁止にできません。デフォルトでは、force
はFALSE
に設定されます。ウィンドウが使用禁止の場合、このウィンドウがスケジュールとして設定されているジョブを使用禁止にすることはできません。
DISABLE
プロシージャ・コールにウィンドウ名またはウィンドウ・グループ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウを使用禁止にすることもできます。たとえば、次の文ではウィンドウとウィンドウ・グループの両方が使用禁止になります。
BEGIN DBMS_SCHEDULER.DISABLE ('sys.window1, sys.window2, sys.window3, sys.windowgroup1, sys.windowgroup2'); END; /
DISABLE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.9.3.9 ウィンドウの有効化
1つ以上のウィンドウを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャまたはCloud Controlを使用します。
使用可能なウィンドウとは、オープン可能なウィンドウのことです。ウィンドウは、デフォルトでenabled
で作成されます。ENABLE
プロシージャを使用してウィンドウを使用可能にすると、妥当性チェックが実行され、このチェックが成功した場合のみウィンドウは使用可能になります。ウィンドウが使用可能になると、ウィンドウ・ログ表にログが記録されます。ENABLE
プロシージャは複数のスケジューラ・オブジェクトに対して使用されるため、ウィンドウを使用可能にするときは、先頭にSYS
を付ける必要があります。
ウィンドウ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウを使用可能にできます。たとえば、次の文では3つのウィンドウが使用可能になります。
BEGIN DBMS_SCHEDULER.ENABLE ('sys.window1, sys.window2, sys.window3'); END; /
ENABLE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.9.4 ウィンドウ・グループを使用したジョブ・スケジューリングとジョブ優先度の管理
ウィンドウ・グループを使用すると、1日あるいは1週間などの間に複数期間実行するジョブを簡単にスケジュールできます。ウィンドウ・グループを作成してウィンドウをグループに加え、ウィンドウ・グループ名をジョブのschedule_name
属性に設定すると、ジョブがウィンドウ・グループ内のすべてのウィンドウの指定期間に実行されます。ウィンドウ・グループはSYS
スキーマにあります。
- ウィンドウ・グループのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なグループ・タスクを管理します。 - ウィンドウ・グループの作成
ウィンドウ・グループを作成するには、DBMS_SCHEDULER.CREATE_GROUP
プロシージャを使用して、グループ・タイプとしてWINDOW
を指定します。 - ウィンドウ・グループの削除
1つ以上のウィンドウ・グループを削除するには、DBMS_SCHEDULER
パッケージのDROP_GROUP
プロシージャを使用します。 - ウィンドウ・グループへのメンバーの追加
ウィンドウ・グループにウィンドウを追加するには、DBMS_SCHEDULER
パッケージのADD_GROUP_MEMBER
プロシージャを使用します。 - ウィンドウ・グループからのメンバーの削除
ウィンドウ・グループから1つ以上のウィンドウを削除するには、DBMS_SCHEDULER
パッケージのREMOVE_GROUP_MEMBER
プロシージャを使用します。 - ウィンドウ・グループの有効化
1つ以上のウィンドウ・グループを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャを使用します。 - ウィンドウ・グループの無効化
ウィンドウ・グループを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャを使用します。
関連項目:
ウィンドウ・グループの概要については、「ウィンドウ・グループ」を参照してください。
親トピック: ジョブの優先度付け
29.9.4.1 ウィンドウ・グループのタスクとそのプロシージャ
DBMS_SCHEDULER
パッケージのプロシージャを使用して、一般的なウィンドウ・グループのタスクを管理します。
表29-10に、ウィンドウ・グループの一般的なタスクとその処理に使用するプロシージャを示します。
表29-10 ウィンドウ・グループのタスクとそのプロシージャ
タスク | プロシージャ | 必要な権限 |
---|---|---|
ウィンドウ・グループの作成 |
|
|
ウィンドウ・グループの削除 |
|
|
ウィンドウ・グループへのメンバーの追加 |
|
|
ウィンドウ・グループからのメンバーの削除 |
|
|
ウィンドウ・グループの有効化 |
|
|
ウィンドウ・グループの無効化 |
|
|
権限の詳細は、「スケジューラ権限」を参照してください。
29.9.4.2 ウィンドウ・グループの作成
ウィンドウ・グループを作成するには、DBMS_SCHEDULER.CREATE_GROUP
プロシージャを使用して、グループ・タイプとしてWINDOW
を指定します。
グループのメンバー・ウィンドウは、グループの作成時に指定するか、または後でADD_GROUP_MEMBER
プロシージャを使用して追加できます。ウィンドウ・グループは、他のウィンドウ・グループのメンバーになれません。ただし、メンバーを設定しないウィンドウ・グループは作成できます。
ウィンドウ・グループを作成し、存在しないメンバー・ウィンドウを指定すると、エラーが生成され、ウィンドウ・グループは作成されません。ウィンドウがすでにウィンドウ・グループのメンバーである場合、再度追加されることはありません。
ウィンドウ・グループはSYS
スキーマで作成します。ウィンドウ・グループは、ウィンドウと同様に、PUBLIC
へのアクセス権を伴って作成されるため、ウィンドウ・グループへのアクセス権限は必要ありません。
次の文では、downtime
というウィンドウ・グループが作成され、2つのウィンドウ(weeknights
とweekends
)が追加されます。
BEGIN DBMS_SCHEDULER.CREATE_GROUP ( group_name => 'downtime', group_type => 'WINDOW', member => 'weeknights, weekends'); END; /
ウィンドウ・グループの内容を確認するには、MANAGE
SCHEDULER
権限を持つユーザーとして次の問合せを発行します。
SELECT group_name, enabled, number_of_members FROM dba_scheduler_groups WHERE group_type = 'WINDOW'; GROUP_NAME ENABLED NUMBER_OF_MEMBERS -------------- -------- ----------------- DOWNTIME TRUE 2 SELECT group_name, member_name FROM dba_scheduler_group_members; GROUP_NAME MEMBER_NAME --------------- -------------------- DOWNTIME "SYS"."WEEKENDS" DOWNTIME "SYS"."WEEKNIGHTS"
29.9.4.3 ウィンドウ・グループの削除
1つ以上のウィンドウ・グループを削除するには、DBMS_SCHEDULER
パッケージのDROP_GROUP
プロシージャを使用します。
このプロシージャをコールすると、ウィンドウ・グループは削除されますが、ウィンドウ・グループのメンバーであるウィンドウは削除されません。ウィンドウ・グループ自体は削除せずに、ウィンドウ・グループのメンバーであるウィンドウをすべて削除するには、DROP_WINDOW
プロシージャを使用し、そのコールにウィンドウ・グループ名を指定します。
DROP_GROUP
プロシージャ・コールにウィンドウ・グループ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウ・グループを削除できます。各ウィンドウ・グループ名の前にSYS
スキーマの接頭辞を付ける必要があります。たとえば、次の文では3つのウィンドウ・グループが削除されます。
BEGIN DBMS_SCHEDULER.DROP_GROUP('sys.windowgroup1, sys.windowgroup2, sys.windowgroup3'); END; /
29.9.4.4 ウィンドウ・グループへのメンバーの追加
ウィンドウ・グループにウィンドウを追加するには、DBMS_SCHEDULER
パッケージのADD_GROUP_MEMBER
プロシージャを使用します。
ウィンドウのカンマ区切りのリストを指定すると、1回のコールで複数のメンバーをウィンドウ・グループに追加できます。たとえば、次の文ではウィンドウ・グループwindow_group1
に2つのウィンドウが追加されます。
BEGIN DBMS_SCHEDULER.ADD_GROUP_MEMBER ('sys.windowgroup1','window2, window3'); END; /
すでにオープンしているウィンドウがウィンドウ・グループに追加された場合、スケジューラは、ウィンドウ・グループ内の次のウィンドウがオープンするまで、このウィンドウ・グループを指し示すジョブを開始しません。
29.9.4.5 ウィンドウ・グループからのメンバーの削除
ウィンドウ・グループから1つ以上のウィンドウを削除するには、DBMS_SCHEDULER
パッケージのREMOVE_GROUP_MEMBER
プロシージャを使用します。
stop_on_window_close
フラグが設定されているジョブが停止するのは、ウィンドウがクローズするときのみです。オープン中のウィンドウをウィンドウ・グループから削除しても、この処理への影響はありません。
ウィンドウのカンマ区切りのリストを指定すると、1回のコールで複数のメンバーをウィンドウ・グループから削除できます。たとえば、次の文では2つのウィンドウが削除されます。
BEGIN DBMS_SCHEDULER.REMOVE_GROUP_MEMBER('sys.window_group1', 'window2, window3'); END; /
29.9.4.6 ウィンドウ・グループの有効化
1つ以上のウィンドウ・グループを有効にするには、DBMS_SCHEDULER
パッケージのENABLE
プロシージャを使用します。
デフォルトでは、ウィンドウ・グループはENABLED
で作成されます。例:
BEGIN DBMS_SCHEDULER.ENABLE('sys.windowgroup1, sys.windowgroup2, sys.windowgroup3'); END; /
29.9.4.7 ウィンドウ・グループの無効化
ウィンドウ・グループを無効にするには、DBMS_SCHEDULER
パッケージのDISABLE
プロシージャを使用します。
ウィンドウ・グループがスケジュールとして使用禁止になっているジョブは、メンバー・ウィンドウがオープンしても実行されません。ウィンドウ・グループを使用禁止にしても、そのメンバー・ウィンドウは使用禁止になりません。
また、ウィンドウ・グループ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウ・グループを使用禁止にすることもできます。たとえば、次の文では3つのウィンドウ・グループが使用禁止になります。
BEGIN DBMS_SCHEDULER.DISABLE('sys.windowgroup1, sys.windowgroup2, sys.windowgroup3'); END; /
29.9.5 リソース・マネージャを使用したジョブ間のリソース割当て
データベース・リソース・マネージャ(リソース・マネージャ)は、データベース・セッション間のリソースの割当て方法を制御します。スケジューラ・ジョブのような非同期セッションだけでなく、ユーザー・セッションのような同期セッションも制御します。
データベースのすべての「作業単位」をリソース・コンシューマ・グループにグループ化し、リソース・プランを使用して、様々なコンシューマ・グループ間のリソースの割当て方法を指定します。リソース・マネージャが割り当てる主なシステム・リソースはCPUです。
スケジューラ・ジョブの場合、最初に各ジョブをジョブ・クラスに割り当てて、次にジョブ・クラスをコンシューマ・グループに関連付けることによって、リソースが割り当てられます。その後、リソースは、コンシューマ・グループ内のスケジューラ・ジョブと他のセッションとの間で分配されます。また、ジョブ・クラス内のジョブに相対的な優先度を割り当てて、それに従ってそれらのジョブにリソースが分配されるようにすることもできます。
現行のリソース・プランはいつでも手動で変更できます。かわりに、スケジューラ・ウィンドウを作成することで現行のリソース・プランを変更することもできます。ウィンドウには、リソース・プラン属性があります。ウィンドウがオープンすると、現行のプランがウィンドウのリソース・プランに切り替えられます。
スケジューラは、完了に必要なリソースを確保できないまま同時に多数のジョブを実行するかわりに、少なくとも一部のジョブを完了できるように、同時に実行するジョブの数を制限しようとします。
スケジューラとリソース・マネージャは緊密に統合されています。ジョブ・コーディネータは、リソース・マネージャからデータベース・リソースの可用性を取得します。その情報に基づいて、コーディネータは、開始するジョブの数を決定します。実行するために十分なリソースがあるジョブ・クラスのジョブのみを起動します。コンシューマ・グループに割り当てられた最大リソースに到達したとリソース・マネージャが判断するまで、そのコンシューマ・グループにマップされた特定のジョブ・クラスのジョブをコーディネータが起動し続けます。そのため、実行準備が完了したジョブがジョブ表にあっても、ジョブを実行するリソースがないため、ジョブ・コーディネータに取り出されない場合があります。そのため、スケジュールされた正確な時刻にジョブが実行される保証はありません。コーディネータは、どのコンシューマ・グループにまだ使用可能なリソースがあるかに基づいて、ジョブ表からジョブを取り出します。
リソース・マネージャでは、実行中の各ジョブに割り当てられているリソースを指定のリソース・プランに基づいて継続的に管理します。リソース・マネージャが管理できるのはデータベースのプロセスのみであることに注意してください。リソースのアクティブな管理は、外部ジョブには適用されません。
親トピック: ジョブの優先度付け
29.9.6 ジョブに対するリソース割当ての例
ジョブのリソースの割当て方法の例を示します。
アクティブなリソース・プランの名前が「Night Plan」で、コンシューマ・グループDW
にマップするJC1
、コンシューマ・グループOLTP
にマップするJC2
およびデフォルト・コンシューマ・グループにマップするJC3
の3つのジョブ・クラスがあるとします。図29-2は、このシナリオを簡単な図で表したものです。
このリソース・プランでは、ジョブ・クラスJC1
に属するジョブが明らかに優先されます。コンシューマ・グループDW
はリソースを60%取得するため、ジョブ・クラスJC1
に属するジョブはリソースを60%取得します。コンシューマ・グループOLTP
はリソースを30%取得するため、ジョブ・クラスJC2
内のジョブはリソースを30%取得します。コンシューマ・グループOther
では、他のすべてのコンシューマ・グループがリソースを10%取得することが指定されます。そのため、ジョブ・クラスJC3
に属するすべてのジョブが、10%のリソースを共有し、リソースを最大10%取得できます。
あるコンシューマ・グループで未使用のリソースは、他のコンシューマ・グループで使用できます。したがって、ジョブ・クラスJC1のジョブが割当ての60%を完全に使用していない場合、その未使用部分はクラスJC2とJC3のジョブが使用できます。リソース・マネージャは、CPU使用が100%に達するまで、リソース使用の制限を開始しません。詳細は、「Oracle Database Resource Managerを使用したリソースの管理」を参照してください。
親トピック: ジョブの優先度付け
29.10 ジョブの監視
いくつかの異なる方法でジョブを監視できます。
- ジョブの監視について
スケジューラのジョブを監視するには、いくつかの方法があります。 - ジョブ・ログ
ジョブ・ログでローカルおよびリモート・ジョブの結果を参照できます。 - 複数の宛先のジョブの監視
複数の宛先のジョブの場合、親ジョブの全体的な状態は子ジョブの結果に依存します。 - スケジューラによって呼び出されるイベントによるジョブ状態の監視
スケジューラでは、ジョブの状態が変化したとき、イベントを発生することができます。 - 電子メール通知によるジョブ状態の監視
スケジューラは、ジョブの状態が変化したときに電子メールを送信できます。
29.10.1 ジョブの監視について
スケジューラ・ジョブは、いくつかの方法で監視できます。
次の方法でスケジューラ・ジョブを監視できます:
-
ジョブ・ログの表示
ジョブ・ログには、
*_SCHEDULER_JOB_LOG
および*_SCHEDULER_JOB_RUN_DETAILS
データ・ディクショナリ・ビューが含まれます。* = {
DBA
|ALL
|USER
}「ジョブ・ログの表示」を参照してください。
-
追加のデータ・ディクショナリ・ビューの問合せ
DBA_SCHEDULER_RUNNING_JOBS
やDBA_SCHEDULER_RUNNING_CHAINS
などのビューを問い合せて、実行中のジョブとチェーンのステータスおよび詳細を表示します。 -
スケジューラからジョブ状態イベントを受け取るアプリケーションの作成
-
状態変化に応じて電子メール通知を送信するジョブの構成
親トピック: ジョブの監視
29.10.2 ジョブ・ログ
ジョブ・ログでローカルおよびリモート・ジョブの結果を参照できます。
- ジョブ・ログの表示
ジョブの実行、状態変化および失敗について、ジョブ・ログ内の情報を表示できます。ジョブ・ログには、ローカル・ジョブとリモート・ジョブの両方の結果が示されます。 - 実行詳細
RUN
、RETRY_RUN
またはRECOVERY_RUN
操作に関する*_SCHEDULER_JOB_LOG
内の行ごとに、*_SCHEDULER_JOB_RUN_DETAILS
ビューには対応する行があります。 - ジョブおよびジョブ・クラスのロギング・レベルの優先度
ジョブおよびジョブ・クラスには、logging_level
属性があります。
親トピック: ジョブの監視
29.10.2.1 ジョブ・ログの表示
ジョブの実行、状態変化および失敗について、ジョブ・ログ内の情報を表示できます。ジョブ・ログには、ローカル・ジョブとリモート・ジョブの両方の結果が示されます。
ジョブ・ログは、次の2つのデータ・ディクショナリ・ビューとして実装されます。
-
*_SCHEDULER_JOB_LOG
-
*_SCHEDULER_JOB_RUN_DETAILS
スケジューラは、有効なロギング・レベルに応じて、ジョブの実行時、作成時、削除時、有効化時などにジョブ・ログ・エントリを作成できます。繰返しスケジュールが設定されたジョブの場合、スケジューラではジョブ・ログ(ジョブ・インスタンスごとに1つ)に複数のエントリが作成されます。各ログ・エントリは、ジョブの完了ステータスなど、特定の実行に関する情報を提供します。
次の例では、max_runs
属性の値が4に設定されている繰返しジョブのジョブ・ログ・エントリを示しています。
SELECT job_name, job_class, operation, status FROM USER_SCHEDULER_JOB_LOG; JOB_NAME JOB_CLASS OPERATION STATUS ---------------- -------------------- --------------- ---------- JOB1 CLASS1 RUN SUCCEEDED JOB1 CLASS1 RUN SUCCEEDED JOB1 CLASS1 RUN SUCCEEDED JOB1 CLASS1 RUN SUCCEEDED JOB1 CLASS1 COMPLETED
ジョブまたはジョブ・クラスのlogging_level
属性を設定することによって、ジョブ・ログに情報を書き込む頻度を制御できます。表29-11に、logging_level
に指定可能な値を示します。
表29-11 ジョブのロギング・レベル
ロギング・レベル | 説明 |
---|---|
|
ロギングは実行されません。 |
|
ジョブが失敗した場合にのみログ・エントリが作成されます。 |
|
ジョブが実行されるたびにログ・エントリが作成されます。 |
|
ジョブが実行されるたびに、および作成、有効化、無効化、更新( |
ジョブの実行に関するログ・エントリは、ジョブの実行が正常に完了するか、失敗するかまたは停止するまで作成されません。
次の例は、完全なジョブ・ライフサイクルのジョブ・ログ・エントリを示しています。この場合、ジョブ・クラスのロギング・レベルはLOGGING_FULL
で、ジョブは非繰返しジョブです。最初に正常に実行された後、もう一度実行されるようにジョブが有効化されています。次に、停止され、削除されています。
SELECT to_char(log_date, 'DD-MON-YY HH24:MI:SS') TIMESTAMP, job_name, job_class, operation, status FROM USER_SCHEDULER_JOB_LOG WHERE job_name = 'JOB2' ORDER BY log_date; TIMESTAMP JOB_NAME JOB_CLASS OPERATION STATUS -------------------- --------- ---------- ---------- --------- 18-DEC-07 23:10:56 JOB2 CLASS1 CREATE 18-DEC-07 23:12:01 JOB2 CLASS1 UPDATE 18-DEC-07 23:12:31 JOB2 CLASS1 ENABLE 18-DEC-07 23:12:41 JOB2 CLASS1 RUN SUCCEEDED 18-DEC-07 23:13:12 JOB2 CLASS1 ENABLE 18-DEC-07 23:13:18 JOB2 RUN STOPPED 18-DEC-07 23:19:36 JOB2 CLASS1 DROP
親トピック: ジョブ・ログ
29.10.2.2 実行詳細
RUN
、RETRY_RUN
またはRECOVERY_RUN
操作に関する*_SCHEDULER_JOB_LOG
内の行ごとに、*_SCHEDULER_JOB_RUN_DETAILS
ビューには対応する行があります。
2つの異なるビューの行は、それぞれのLOG_ID
列で関係付けられています。実行詳細ビューを参照して、ジョブが失敗した理由や停止された理由を判断できます。
SELECT to_char(log_date, 'DD-MON-YY HH24:MI:SS') TIMESTAMP, job_name, status, SUBSTR(additional_info, 1, 40) ADDITIONAL_INFO FROM user_scheduler_job_run_details ORDER BY log_date; TIMESTAMP JOB_NAME STATUS ADDITIONAL_INFO -------------------- ---------- --------- ---------------------------------------- 18-DEC-07 23:12:41 JOB2 SUCCEEDED 18-DEC-07 23:12:18 JOB2 STOPPED REASON="Stop job called by user:'SYSTEM' 19-DEC-07 14:12:20 REMOTE_16 FAILED ORA-29273: HTTP request failed ORA-06512
実行詳細ビューには、実際のジョブ開始時刻と継続時間も含まれています。
属性STORE_OUTPUT
を使用して、外部ジョブの場合はstdout
またはデータベース・ジョブの場合はDBMS_OUTPUT
に送信された出力を*_SCHEDULER_JOB_RUN_DETAILS
ビューで保存するように指定することもできます。STORE_OUTPUT
がTRUE
に設定され、LOGGING_LEVEL
がジョブの実行をログに記録する必要があることを示している場合は、すべての出力が収集され、このビューのBINARY_OUTPUT
出力列に挿入されます。char
表現はOUTPUT
列から問い合せることができます。
親トピック: ジョブ・ログ
29.10.2.3 ジョブおよびジョブ・クラスのロギング・レベルの優先度
ジョブおよびジョブ・クラスには、logging_level
属性があります。
表29-11に、この属性に指定できる値を示します。ジョブ・クラスのデフォルト・ロギング・レベルはLOGGING_RUNS
で、個々のジョブのデフォルト・レベルはLOGGING_OFF
です。ジョブ・クラスのロギング・レベルが、クラス内のジョブのロギング・レベルよりも高い場合は、ジョブ・クラスのロギング・レベルが優先されます。そのため、デフォルトでは、すべてのジョブの実行がジョブ・ログに記録されます。
非常に短くて頻度の高いジョブの場合は、個々の実行をすべて記録すると負荷が非常に高くなるため、ロギングをオフに設定して、ジョブが失敗した場合にのみロギングが行われるように設定する場合もあります。ただし、特定のクラスのジョブで発生したすべての事象の完全なロギングを取得する必要がある場合には、そのクラスの完全なロギングを有効にします。
すべてのジョブのロギングが確実に作成されるようにするには、個々のジョブ作成者がロギングをオフにできないようにする必要があります。これをサポートするために、スケジューラではクラス別のレベルがジョブの情報を記録する最低レベルとなっています。ジョブ作成者は、個々のジョブに対するロギング・レベルを上げることはできますが、下げることはできません。したがって、個々のジョブのロギング・レベルをすべてLOGGING_OFF
に設定すると、クラス内のすべてのジョブがクラスでの指定に従って記録されます。
この機能は、デバッグの目的で提供されています。たとえば、クラス別のレベルでジョブ実行を記録するように設定されているときに、ジョブ・レベルでロギングがオフにされた場合でも、スケジューラはジョブの実行を記録します。ただし、ジョブ作成者が完全ロギングをオンにしているときに、クラス別のレベルでは実行のみを記録するように設定されている場合は、ジョブの上位のロギング・レベルが優先され、この個別ジョブのすべての操作がログに記録されます。このように、エンド・ユーザーは、完全ロギングをオンにして自分のジョブをテストできます。
個々のジョブのロギング・レベルを設定するには、そのジョブについてSET_ATTRIBUTE
プロシージャを使用する必要があります。たとえば、mytestjob
というジョブの完全ロギングをオンにするには、次の文を発行します。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ( 'mytestjob', 'logging_level', DBMS_SCHEDULER.LOGGING_FULL); END; /
ジョブ・クラスのロギング・レベルを設定できるのは、MANAGE
SCHEDULER
権限を付与されているユーザーのみです。
関連項目:
ジョブ・クラスのロギング・レベルの設定の詳細は、「ウィンドウ・ログおよびジョブ・ログの監視と管理」
親トピック: ジョブ・ログ
29.10.3 複数の宛先のジョブの監視
複数の宛先のジョブの場合、親ジョブの全体的な状態は子ジョブの結果に依存します。
たとえば、すべての子ジョブが成功した場合、親ジョブの状態はSUCCEEDED
に設定されます。すべてが失敗した場合、親ジョブの状態はFAILED
に設定されます。一部が失敗し、一部が成功した場合、親ジョブの状態はSOME
FAILED
に設定されます。
一部の宛先で子ジョブの開始が遅延するような状況では、親ジョブの状態がファイナライズされるまでに大幅な遅延が生じる可能性があります。複数の宛先のジョブが繰返しジョブの場合は、スケジュールされている次回の実行に進むジョブもあれば、前回の実行がまだ終了しないジョブが生じることもあります。この場合、親ジョブの状態はINCOMPLETE
に設定されます。ただし、最終的には、遅延しているジョブも他の兄弟ジョブに追いつき、親ジョブの最終的な状態を決定できるようになります。
表29-12に、複数の宛先のジョブを対象としたジョブ監視ビューの内容を示します。
表29-12 複数の宛先のジョブを対象としたスケジューラ・データ・ディクショナリ・ビューの内容
ビュー名 | 目次 |
---|---|
|
親ジョブの1つのエントリ |
|
親ジョブの1つのエントリ(親ジョブが開始された場合)および実行中の子ジョブごとに1つのエントリ |
|
親ジョブの1つのエントリ(親ジョブが開始された場合)(operation = ' |
|
子ジョブごとに1つのエントリ(子ジョブが完了した場合)および親ジョブの1つのエントリ(最後の子ジョブが完了し、親が完了した場合) |
|
親ジョブの宛先ごとに1つのエントリ |
*_SCHEDULER_JOB_DESTS
ビューでは、各子ジョブに割り当てられている一意のジョブ宛先ID(job_dest_id
)を調べることができます。このIDは、ジョブ、資格証明および宛先の一意の組合せを表します。このIDは、STOP_JOB
プロシージャで使用できます。また、*_SCHEDULER_JOB_DESTS
ビューで各子ジョブのジョブ状態を監視できます。
親トピック: ジョブの監視
29.10.4 スケジューラによって呼び出されるイベントによるジョブ状態の監視
スケジューラでは、ジョブの状態が変化したとき、イベントを発生することができます。
- ジョブ状態イベントについて
ジョブの状態が変化したときに、スケジューラがイベントを呼び出すようにジョブを構成できます。 - イベントを呼び出すようにジョブを変更する方法
ジョブのジョブ状態イベントの発生を可能にするには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
プロシージャを使用してraise_events
ジョブ属性のビット・フラグをオンにします。 - ジョブの状態イベントのアプリケーションでの使用
ジョブ状態イベントを使用するには、アプリケーションがスケジューラ・イベント・キューSYS.SCHEDULER$_EVENT_QUEUE
をサブスクライブする必要があります。このキューはセキュアなキューであり、所有者はSYS
です。
親トピック: ジョブの監視
29.10.4.1 ジョブ状態イベントについて
ジョブの状態が変化したときに、スケジューラがイベントを呼び出すようにジョブを構成できます。
スケジューラは、ジョブの開始時、ジョブの完了時、ジョブがその割当ての実行時間を超えたときなどにイベントを呼び出します。イベントのコンシューマは、そのイベントに対応して処理を実行するアプリケーションです。たとえば、システムの負荷が高いために、スケジュールされた開始時間から30分を経過してもジョブが開始されない場合、スケジューラは、ハンドラのアプリケーションによって低優先度のジョブを停止させてシステム・リソースを解放するイベントを呼び出すことができます。スケジューラでは、ローカル(標準)・ジョブ、リモート・データベース・ジョブ、ローカル外部ジョブおよびリモート外部ジョブに対してジョブ状態イベントを呼び出すことができます。
表29-13に、スケジューラによって呼び出されるジョブ状態イベントのタイプを示します。
表29-13 スケジューラによって呼び出されるジョブ状態イベントのタイプ
イベント・タイプ | 説明 |
---|---|
|
イベントではなく、すべてのイベントを簡単に有効にするための定数です。 |
|
ジョブ属性 |
|
チェーンを実行するジョブが |
|
|
|
Schedulerまたは |
|
エラーが発生したか、異常終了したため、ジョブが失敗しました。 |
|
ジョブは、 |
|
ジョブの実行が、失敗、成功または停止しました。 |
|
ジョブのスケジュール制限に達しました。ジョブ開始の遅延時間がジョブ属性 |
|
ジョブが開始されました |
|
|
|
ジョブが正常に完了しました。 |
ジョブ状態イベントの呼出しを有効にするには、raise_events
ジョブ属性を設定します。デフォルトでは、ジョブはジョブ状態イベントを呼び出しません。
スケジューラは、イベントを呼び出すためにOracle Databaseアドバンスト・キューイングを使用します。ジョブの状態の変更に関するイベントが発生すると、スケジューラは、メッセージをデフォルトのイベント・キューにエンキューします。アプリケーションは、このキューをサブスクライブし、イベント・メッセージをデキューして、適切な処理を行います。
ジョブに対するジョブの状態変化イベントを有効(使用可能)にすると、スケジューラは、メッセージをスケジューラ・イベント・キューSYS.SCHEDULER$_EVENT_QUEUE
にエンキューすることによってこれらのイベントを呼び出します。このキューはセキュアなキューであるため、アプリケーションによっては、特定のユーザーがキューの操作を実行できるようにキューを構成する必要があります。セキュアなキューの詳細は、『Oracle Streams概要および管理』を参照してください。
スケジューラのイベント・キューが無制限に大きくなるのを防ぐために、デフォルトでは、スケジューラが呼び出したイベントは24時間で失効します。(失効したイベントはキューから削除されます。)SET_SCHEDULER_ATTRIBUTE
プロシージャを使用して、event_expiry_time
スケジューラ属性を設定することで、この有効期間を変更できます。詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.10.4.2 イベントを呼び出すようにジョブを変更する方法
ジョブのジョブ状態イベントの発生を可能にするには、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
プロシージャを使用してraise_events
ジョブ属性のビット・フラグをオンにします。
各ビット・フラグは、イベントの呼出しの対象になる様々なジョブ状態を表します。たとえば、最下位ビットをオンにすることで、job
started
イベントを呼び出すことができます。複数の状態変化イベント・タイプを1回のコールで使用可能にするには、必要なビット・フラグの値を加算し、その結果を引数としてSET_ATTRIBUTE
に提供します。
次の例では、ジョブdw_reports
に対して複数の状態変更イベントを有効にしています。次のイベント・タイプが有効になっていますが、両方ともなんらかのエラーを示しています。
-
JOB_FAILED
-
JOB_SCH_LIM_REACHED
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE('dw_reports', 'raise_events', DBMS_SCHEDULER.JOB_FAILED + DBMS_SCHEDULER.JOB_SCH_LIM_REACHED); END; /
ノート:
raise_events
ジョブ属性を指定してJOB_OVER_MAX_DUR
イベントを使用可能にする必要はありません。このイベントは常に使用可能になっています。
関連項目:
ジョブ状態ビット・フラグの名前と値は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_SCHEDULER
.SET_ATTRIBUTE
に関する項を参照してください。
29.10.4.3 ジョブの状態イベントのアプリケーションでの使用
ジョブ状態イベントを使用するには、アプリケーションがスケジューラ・イベント・キューSYS.SCHEDULER$_EVENT_QUEUE
をサブスクライブする必要があります。このキューはセキュアなキューであり、所有者はSYS
です。
あるユーザーについてこのキューのサブスクリプションを作成するには、次の処理を実行します。
ユーザーにデキュー権限を付与する必要はありません。スケジューラ・イベント・キューに関するデキュー権限は、PUBLIC
に付与されます。
または、次の例に示すように、ユーザーがADD_EVENT_QUEUE_SUBSCRIBER
プロシージャを使用してスケジューラ・イベント・キューをサブスクライブすることもできます。
DBMS_SCHEDULER.ADD_EVENT_QUEUE_SUBSCRIBER(subscriber_name);
この例のsubscriber_name
は、スケジューラ・イベント・キューのサブスクライブに使用されるOracle Databaseアドバンスト・キューイング(AQ)のエージェント名です。(NULL
の場合は、呼出しユーザーのユーザー名でエージェントが作成されます。)このコールによって、スケジューラ・イベント・キューのサブスクリプションが作成され、指定エージェントを使用してデキューする許可がユーザーに付与されます。サブスクリプションはルールベースです。ルールによって、ユーザーが許可されるのは、所有するジョブが呼び出したイベントの参照のみで、その他のメッセージはすべて除外されます。サブスクリプションが使用可能になると、ユーザーは一定の間隔でメッセージをポーリングするか、またはメッセージが通知されるようにAQに登録できます。
詳細は、Oracle Databaseアドバンスド・キューイング・ユーザーズ・ガイドを参照してください。
29.10.4.3.1 スケジューラ・イベント・キュー
SYS.SCHEDULER$_EVENT_QUEUE
のタイプはscheduler$_event_info
です。このタイプの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
29.10.5 電子メール通知によるジョブ状態の監視
スケジューラでは、ジョブの状態が変化したとき、イベントを発生することができます。
- 電メール通知について
ジョブの状態が変化したときに電子メール通知を送信するようにジョブを構成できます。 - ジョブに対する電子メール通知の追加
ジョブに対する電子メール通知を追加するには、DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION
パッケージ・プロシージャを使用します。 - ジョブに対する電子メール通知の削除
ジョブに対する電子メール通知を削除するには、DBMS_SCHEDULER.REMOVE_JOB_EMAIL_NOTIFICATION
パッケージ・プロシージャを使用します。 - 電子メール通知情報の表示
*_SCHEDULER_NOTIFICATIONS
ビューを問い合せることによって、現在の電子メール通知に関する情報を表示できます。
親トピック: ジョブの監視
29.10.5.1 電子メール通知について
ジョブの状態が変化したときに電子メール通知を送信するようにジョブを構成できます。
表29-13に、電子メールを送信できるジョブ状態イベントを示します。電子メール通知は、指定したジョブ状態イベントのリストに含まれる任意のイベントをトリガーとして、複数の受信者に送信できます。また、フィルタ条件を指定して、その条件に一致する通知ジョブ状態イベントのみを生成することもできます。メッセージの件名と本文の両方に、ジョブ所有者、ジョブ名、イベント・タイプ、エラー・コード、エラー・メッセージなどの変数を含めることができます。これらの変数の値は、電子メール通知が送信される前に、スケジューラによって自動的に設定されます。
単一のジョブに対して複数のジョブ状態電子メール通知を構成できます。これらの通知は、ジョブ状態イベント・リスト、受信者およびフィルタ条件によって区別できます。
たとえば、ジョブがエラー・コード600または700で失敗した場合は常に主任DBAとシニアDBAの1人に電子メールを送信するようにジョブを構成できます。また、同じジョブに対して、ジョブがスケジュールどおり開始されなかった場合は主任DBAのみに通知を送信するように構成することもできます。
電子メール通知を送信するようにジョブを構成するには、スケジューラ属性email_server
に、電子メールの送信に使用するSMTPサーバーのアドレスを設定する必要があります。また、必要に応じて、送信者未指定のジョブに対しては、スケジューラ属性email_sender
に、デフォルトの送信者電子メール・アドレスを設定できます。
スケジューラでは、SMTPサーバーとの通信におけるSSLプロトコルおよびTLSプロトコルがサポートされています。また、認証を必要とするSMTPサーバーもサポートされています。
関連項目:
電子メール通知関連の属性の設定の詳細は、「スケジューラのプリファレンスの設定」
親トピック: 電子メール通知によるジョブ状態の監視
29.10.5.2 ジョブに対する電子メール通知の追加
ジョブに対する電子メール通知を追加するには、DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION
パッケージ・プロシージャを使用します。
たとえば、次のプロシージャは、OED_JOB
ジョブの電子メール通知を追加します。
BEGIN DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION ( job_name => 'EOD_JOB', recipients => 'jsmith@example.com, rjones@example.com', sender => 'do_not_reply@example.com', subject => 'Scheduler Job Notification-%job_owner%.%job_name%-%event_type%', body => '%event_type% occurred at %event_timestamp%. %error_message%', events => 'JOB_FAILED, JOB_BROKEN, JOB_DISABLED, JOB_SCH_LIM_REACHED'); END; /
subject
およびbody
引数では、%文字で囲まれた変数が使用されています。複数の受信者および複数のイベントを指定した場合、指定したイベントのいずれかが呼び出されると各受信者に通知されます。これを確認するには、USER_SCHEDULER_NOTIFICATIONS
ビューを問い合せます。
SELECT JOB_NAME, RECIPIENT, EVENT FROM USER_SCHEDULER_NOTIFICATIONS; JOB_NAME RECIPIENT EVENT ----------- -------------------- ------------------- EOD_JOB jsmith@example.com JOB_FAILED EOD_JOB jsmith@example.com JOB_BROKEN EOD_JOB jsmith@example.com JOB_SCH_LIM_REACHED EOD_JOB jsmith@example.com JOB_DISABLED EOD_JOB rjones@example.com JOB_FAILED EOD_JOB rjones@example.com JOB_BROKEN EOD_JOB rjones@example.com JOB_SCH_LIM_REACHED EOD_JOB rjones@example.com JOB_DISABLED
ジョブに対して異なる通知を構成するたびに、ADD_JOB_EMAIL_NOTIFICATION
をコールします。job_name
とrecipients
の指定は必須です。他のすべての引数には、デフォルト値があります。デフォルトのsender
は、前の項で説明したように、スケジューラ属性によって定義されます。subject
、body
およびevents
引数のデフォルト値は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のADD_JOB_EMAIL_NOTIFICATION
プロシージャに関する項を参照してください。
次の例では、同じジョブに対して、異なるイベントに関する追加の電子メール通知を構成しています。この例では、sender
、subject
およびbody
引数のデフォルト値をそのまま使用しています。
BEGIN DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION ( job_name => 'EOD_JOB', recipients => 'jsmith@example.com', events => 'JOB_OVER_MAX_DUR'); END; /
この例では、events
引数も省略して、イベントのデフォルト値をそのまま使用しています。
次の例は最初の例と類似していますが、この場合、フィルタ条件を使用して、エラー番号が600または700でジョブが失敗した場合にのみ電子メール通知を送信するように指定しています。
BEGIN DBMS_SCHEDULER.ADD_JOB_EMAIL_NOTIFICATION ( job_name => 'EOD_JOB', recipients => 'jsmith@example.com, rjones@example.com', sender => 'do_not_reply@example.com', subject => 'Job Notification-%job_owner%.%job_name%-%event_type%', body => '%event_type% at %event_timestamp%. %error_message%', events => 'JOB_FAILED', filter_condition => ':event.error_code=600 or :event.error_code=700'); END; /
関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のADD_JOB_EMAIL_NOTIFICATION
プロシージャに関する項を参照してください。
親トピック: 電子メール通知によるジョブ状態の監視
29.10.5.3 ジョブに対する電子メール通知の削除
ジョブに対する電子メール通知を削除するには、DBMS_SCHEDULER.REMOVE_JOB_EMAIL_NOTIFICATION
パッケージ・プロシージャを使用します。
たとえば、次のプロシージャは、OED_JOB
ジョブの電子メール通知を削除します。
BEGIN DBMS_SCHEDULER.REMOVE_JOB_EMAIL_NOTIFICATION ( job_name => 'EOD_JOB', recipients => 'jsmith@example.com, rjones@example.com', events => 'JOB_DISABLED, JOB_SCH_LIM_REACHED'); END; /
複数の受信者および複数のイベントを指定した場合、指定した各イベントの通知が各受信者に対して削除されます。前の項で説明したものと同じ問合せを実行した場合、結果は次のようになります。
SELECT JOB_NAME, RECIPIENT, EVENT FROM USER_SCHEDULER_NOTIFICATIONS; JOB_NAME RECIPIENT EVENT ----------- -------------------- ------------------- EOD_JOB jsmith@example.com JOB_FAILED EOD_JOB jsmith@example.com JOB_BROKEN EOD_JOB rjones@example.com JOB_FAILED EOD_JOB rjones@example.com JOB_BROKEN
REMOVE_JOB_EMAIL_NOTIFICATION
引数を指定する場合、次のルールが別途適用されます。
-
events
引数をNULL
のままにすると、指定した受信者に対して、すべてのイベントの通知が削除されます。 -
recipients
引数をNULL
のままにすると、すべての受信者に対して、指定したイベントの通知が削除されます。 -
recipients
とevents
の両方をNULL
のままにすると、該当ジョブのすべての通知が削除されます。 -
今まで通知を作成したことのない受信者とイベントを指定した場合、エラーは生成されません。
関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のREMOVE_JOB_EMAIL_NOTIFICATION
プロシージャに関する項を参照してください。
親トピック: 電子メール通知によるジョブ状態の監視
29.10.5.4 電子メール通知情報の表示
*_SCHEDULER_NOTIFICATIONS
ビューを問い合せることによって、現在の電子メール通知に関する情報を表示できます。
関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
親トピック: 電子メール通知によるジョブ状態の監視