11gリリース1（11.1）
E05760-03
 目次 |
 索引 |
| Oracle Database 管理者ガイド 11gリリース1（11.1） E05760-03 |
|
この章の内容は次のとおりです。
各スケジューラ・オブジェクトは、[schema.]nameという形式の完全なデータベース・スキーマ・オブジェクトです。スケジューラ・オブジェクトは、データベース・オブジェクトのネーミング規則に厳密に従っています。また、他のデータベース・オブジェクトとSQLネームスペースを共有しています。
スケジューラ・オブジェクトの名前がDBMS_SCHEDULERパッケージで使用されるときも、SQLネーミング規則に従います。スケジューラ・オブジェクト名は、デフォルトでは大文字です。大文字にしない場合は二重引用符で囲みます。たとえば、ジョブの作成時には、job_name => 'my_job'は、job_name => 'My_Job'およびjob_name => 'MY_JOB'と同じですが、job_name => '"my_job"'とは同じではありません。DBMS_SCHEDULERパッケージ内でスケジューラ・オブジェクト名のカンマ区切りのリストが使用される場合も、これらのネーミング規則に従います。
オブジェクトのネーミングの詳細は、『Oracle Database SQLリファレンス』を参照してください。
ジョブは、スケジュールとプログラムの組合せで、他にプログラムに必要な引数が含まれます。この項では、ジョブの基本的なタスクについて説明します。この項の内容は、次のとおりです。
表27-1に、ジョブの一般的なタスクとそれに対応するプロシージャおよび権限を示します。
権限の詳細は、「スケジューラ権限」を参照してください。
この項の内容は次のとおりです。
1つ以上のジョブを作成するには、CREATE_JOBまたはCREATE_JOBSプロシージャ、あるいはEnterprise Managerを使用します。単一のジョブを作成するには、CREATE_JOBプロシージャを使用します。このプロシージャを使用して、異なるオブジェクトに基づく様々なタイプの複数のジョブを作成するとオーバーロードになります。 単一トランザクションに複数のジョブを作成する場合は、CREATE_JOBSプロシージャを使用してください。
各ジョブの作成時には、ジョブ・タイプ、処理、スケジュール、オプションのジョブ・クラスおよび他の属性を指定します。 ジョブはデフォルトでは使用禁止で作成されるため、実行するにはDBMS_SCHEDULER.ENABLEを使用して使用可能にする必要があります。 ジョブを使用可能にすると、次にスケジュールされている日時にスケジューラによって自動的に実行されます。 CREATE_JOBプロシージャのenabled引数をTRUEに設定することもできます。この場合、ジョブは作成直後にスケジュールに従って自動的に実行できるようになります。
例27-1に、update_salesという単一ジョブを作成する例を示します。このジョブは、売上集計表を更新する、OPSスキーマ内のストアド・プロシージャをコールします。
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', job_class => 'batch_update_jobs', comments => 'My new job'); END; /
schema.job_nameを指定すると、別のスキーマ内にジョブを作成できます。したがって、ジョブの作成者がジョブの所有者であるとはかぎりません。 ジョブの所有者は、ジョブが作成されるスキーマを所有しているユーザーです。ジョブは、そのジョブが作成されるスキーマの権限で実行されます。実行時のジョブのNLS環境は、そのジョブが作成された時点に存在していた環境です。
作成したジョブは、*_SCHEDULER_JOBSビューを使用して問い合せることができます。
ジョブは、デフォルトでは完了後に自動的に削除されるように設定されています。auto_drop属性をFALSEに設定すると、ジョブは保持されます。繰返しジョブは、ジョブ終了日を過ぎるか、最大実行回数（max_runs）または最大失敗回数（max_failures）に達するまでは自動削除されないことに注意してください。
CREATE_JOBプロシージャはオーバーロードになるため、複数の異なる使用方法があります。 例27-1に示すように、ジョブの処理と繰返し間隔をジョブ属性として指定する方法（ジョブの処理とジョブ・スケジュールのインライン指定）に加えて、プログラム・オブジェクト（プログラム）を指し示すジョブを作成してジョブの処理を指定する方法、スケジュール・オブジェクト（スケジュール）を指し示すジョブを作成して繰返し間隔を指定する方法、またはプログラムとスケジュールの両方を指し示すジョブを作成する方法があります。この操作については、次の項を参照してください。
ジョブの処理をインラインで記述するかわりに、名前付きプログラムを指し示してジョブを作成することもできます。名前付きプログラムを使用してジョブを作成するには、ジョブの作成時にCREATE_JOBプロシージャでprogram_nameの値を指定し、job_type、job_actionおよびnumber_of_argumentsの値は指定しません。
ジョブの作成時に既存のプログラムを使用するには、ジョブの所有者がプログラムの所有者であるか、またはそのプログラムに対するEXECUTE権限を持っている必要があります。 次のPL/SQLブロックは、名前付きプログラムを指定したCREATE_JOBプロシージャの使用例です。このPL/SQLブロックでは、my_new_job1という標準ジョブが作成されます。
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; /
次の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; /
ジョブのスケジュールをインラインで記述するかわりに、名前付きスケジュールを指し示してジョブを作成することもできます。名前付きスケジュールを使用してジョブを作成するには、ジョブの作成時に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; /
ジョブは、名前付きプログラムとスケジュールの両方を指し示して作成することもできます。次の文は、名前付きプログラムとスケジュールを指定した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; /
ジョブの作成後、次の場合にジョブ引数の設定が必要な場合があります。
ジョブ引数を設定するには、SET_JOB_ARGUMENT_VALUEまたはSET_JOB_ANYDATA_VALUEプロシージャ、あるいはEnterprise Managerを使用します。 SET_JOB_ANYDATA_VALUEは、VARCHAR2文字列として表現できない複雑なデータ型に使用されます。
引数を必要とする場合があるジョブの例の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およびSET_JOB_ANYDATA_VALUEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ジョブの作成後に、SET_ATTRIBUTEプロシージャ、SET_JOB_ATTRIBUTESプロシージャまたはEnterprise Managerを使用してジョブ属性を設定できます。 CREATE_JOBのコール中に多数のジョブ属性を設定できますが、ジョブの作成後にSET_ATTRIBUTEまたはSET_JOB_ATTRIBUTESでのみ設定可能な属性もあります。
SET_ATTRIBUTEプロシージャ、SET_JOB_ATTRIBUTESプロシージャおよび様々なジョブ属性の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ローカル外部ジョブまたはリモート外部ジョブを作成するには、CREATE JOB権限とCREATE EXTERNAL JOB権限の両方が必要です。
ローカル外部ジョブまたはリモート外部ジョブを作成する手順は、次のとおりです。
DBMS_SCHEDULERパッケージのCREATE_JOBプロシージャを使用してジョブを作成します。enabled属性を省略するか、またはFALSEに設定します。
CREATE_CREDENTIALプロシージャを使用して資格証明を作成します。詳細は、「資格証明の概要」を参照してください。
SET_ATTRIBUTEプロシージャを使用して、ジョブのcredential_name属性を設定します。ジョブの所有者は、資格証明のEXECUTE権限を持っているか、または資格証明の所有者であることが必要です。 リモート外部ジョブの場合、credential_name属性が必須です。 ローカル外部ジョブの場合、この属性が設定されていなければデフォルトの資格証明が使用されます。 詳細は、表26-1を参照してください。
SET_ATTRIBUTEプロシージャを使用して、ジョブのdestination属性を設定します。属性は、host:portの形式で指定する必要があります。hostにはリモート・ホストのホスト名またはIPアドレス、portにはホストがリスニングするスケジューラ・エージェントのポートが入ります。このポート番号を判断するには、ファイルschagent.confを表示します。このファイルは、リモート・ホストのスケジューラ・エージェントのホーム・ディレクトリに格納されています。
nslookupなどのユーティリティを使用して、リモート・ホスト名が有効であることとホストにアクセス可能であることを確認します。
ENABLEプロシージャを使用してジョブを有効化します。次の例では、LOGOWNERという名前の資格証明を使用してCLEANLOGSというローカル外部ジョブが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name => 'CLEANLOGS', job_type => 'EXECUTABLE', job_action => '/home/logowner/cleanlogs', repeat_interval => 'FREQ=DAILY; BYHOUR=23', enabled => FALSE); DBMS_SCHEDULER.SET_ATTRIBUTE('CLEANLOGS', 'credential_name', 'LOGOWNER'); DBMS_SCHEDULER.ENABLE('CLEANLOGS'); END; /
ジョブの作成時には資格証明を指定できず、かわりにSET_ATTRIBUTEを使用して指定する必要があるため、資格証明を設定する機会を設けるためにジョブは使用禁止の状態で作成されます。 資格証明の設定後、ジョブが使用可能になります。
次の例に、Windows上でDOS組込みコマンド（この例では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); 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.SET_ATTRIBUTE('MKDIR_JOB', 'credential_name', 'STEVE'); DBMS_SCHEDULER.ENABLE('MKDIR_JOB'); END; /例 27-4 複数のリモート・ホストに対するリモート外部ジョブの作成
次の例では、複数のリモート・ホストに対して同じリモート外部ジョブが作成されます。PL/SQLコードには、ホスト名を繰り返すループが組み込まれています。remote_credはすべてのホストに有効な資格証明の名前です。作成先のリストは、ホスト名とスケジューラ・エージェントのポートのリストです。すべてのホストで実行される実行可能ファイルは、/u01/app/ext_backupというアプリケーションです。
このコードを実行するユーザーには、CREATE JOB権限とCREATE EXTERNAL JOB権限の両方が必要です。
declare job_prefix varchar2(30) := 'remote_'; job_name varchar2(30); destinations dbms_utility.lname_array; begin destinations(1) := 'host1:1234'; destinations(2) := 'host2:1234'; destinations(3) := 'host3:1234'; destinations(4) := 'host4:1234'; for i in 1..destinations.LAST loop job_name := dbms_scheduler.generate_job_name(job_prefix); dbms_scheduler.create_job(job_name, job_type=>'executable', job_action=>'/u01/app/ext_backup', number_of_arguments=>0, enabled=>false); dbms_scheduler.set_attribute(job_name,'destination',destinations(i)); dbms_scheduler.set_attribute(job_name,'credential_name','remote_cred'); dbms_scheduler.enable(job_name); end loop; end; /
次に、この例について説明します。
次の例では、リモート外部ジョブでSQL文をリモートのOracleデータベースに発行する方法を示しています。ジョブの処理では、SQL*Plusを使用して文を発行するシェル・スクリプトが実行されます。このスクリプトは、リモート・ホストに存在している必要があります。次のスクリプトは、Linux上でSQL*Plusを実行するために必要な環境変数すべてを設定することから開始しています。
データベース・パスワードをスクリプトにハードコードしないように、外部認証が使用されています。
#!/bin/sh export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1 export ORACLE_SID=orcl export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib # The following command assumes external authentication $ORACLE_HOME/bin/sqlplus / << EOF set serveroutput on; select * from dual; EXIT; EOF例 27-6 ローカル外部ジョブの作成とstdoutの取得
LinuxとUNIXに関する次の例では、ローカル外部ジョブを作成して実行してから、GET_FILEプロシージャを使用してジョブのstdoutの出力を取得する方法を示しています。 ローカル外部ジョブの場合、stdoutの出力はORACLE_HOME/scheduler/log内のログ・ファイルに格納されます。 このパスをGET_FILEに指定する必要はなく、ファイル名のみを指定します。ファイル名を生成するには、ジョブの外部ログIDについてログ・ビューを問い合せて_stdoutを追加します。
-- User scott must have CREATE JOB and CREATE EXTERNAL JOB privileges grant create job, create external job to scott ; connect scott/tiger set serveroutput on -- Create a credential for the job to use exec dbms_scheduler.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 ); dbms_scheduler.set_job_argument_value('lsdir',1,'/tmp'); dbms_scheduler.set_attribute('lsdir','credential_name','my_cred'); 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); dbms_scheduler.get_file( source_file => log_id ||'_stdout', credential_name => 'my_cred', file_contents => my_clob, source_host => null); dbms_output.put_line(my_clob); end; /
デタッチ済ジョブでは、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/11.1.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; /
多数のジョブを作成する必要がある場合は、CREATE_JOBSプロシージャを使用すると、トランザクションのオーバーヘッドを減らしてパフォーマンスを改善できる可能性があります。例27-8に、このプロシージャを使用して単一トランザクションで複数のジョブを作成する方法を示します。 詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
DECLARE newjob sys.job; newjobarr sys.job_array; BEGIN -- Create an array of JOB object types newjobarr := sys.job_array(); -- Allocate sufficient space in the array newjobarr.extend(5); -- Add definitions for 5 jobs FOR i IN 1..5 LOOP -- Create a JOB object type newjob := sys.job(job_name => 'TESTJOB' || to_char(i), job_style => 'REGULAR', job_template => '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.
ジョブを変更するには、SET_ATTRIBUTEまたはSET_JOB_ATTRIBUTESプロシージャ、あるいはEnterprise Managerを使用します。ジョブはすべて変更できます。また、ジョブ名以外のすべてのジョブ属性を変更できます。変更の際に実行中のジョブ・インスタンスがあった場合、そのジョブはコールの影響を受けません。変更は、次回のジョブ実行時から反映されます。
通常、データベースによって自動的に作成されたジョブは変更しないでください。データベースによって作成されたジョブの場合、ジョブ・ビューでSYSTEM列がTRUEに設定されます。ジョブの属性は、*_SCHEDULER_JOBSビューで使用可能です。
実行中のジョブに対してそのジョブ属性を変更することは有効ですが、変更した属性は、スケジュールされている次回のジョブ実行時まで反映されません。
SET_ATTRIBUTEおよびSET_JOB_ATTRIBUTESプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』と「Oracle Schedulerの構成」を参照してください。
ジョブを実行するには、次の3つの方法があります。
*_SCHEDULER_JOBS）またはジョブ・ログを問い合せる必要があります。 ジョブ・スレーブとスケジューラのアーキテクチャの詳細は、「ジョブ・スレーブ」を参照してください。
DBMS_SCHEDULER.RUN_JOBをコールして実行する方法: RUN_JOBプロシージャを使用すると、ジョブをテストしたり、指定したスケジュール外で実行できます。 ジョブは、前の2つのジョブ実行方法と同様に非同期で実行するか、同期で実行できます。後者の場合、ジョブはRUN_JOBをコールしたセッションで実行されます。ジョブを非同期で実行するには、use_current_session引数をFALSEに設定してRUN_JOBを使用します。 この場合、ジョブはスケジュールに従って開始される場合やイベントにより開始される場合と同様に実行されます。 つまり、ジョブ・スレーブの制御下でジョブ所有者として実行されます。 RUN_JOBをコールするセッションは即時に戻り、ジョブの完了を待機する間にブロックされることはありません。 ジョブが成功したかどうかを確認するには、ジョブ・ビューまたはジョブ・ログを問い合せる必要があります。
use_current_session引数をTRUEに設定してRUN_JOBを使用すると、ジョブを同期で実行できます。 この場合、ジョブはジョブ・スレーブによって実行されるかわりに、RUN_JOBを起動するユーザー・セッション内で実行されます。 RUN_JOBをコールするセッションは、ジョブの完了までブロックされます。
RUN_JOBを使用してジョブを同期で実行すると、ジョブのfailure_countおよびrun_countは変更されません。 ただし、ジョブ・ログにはジョブの実行が反映されます。ジョブによって生成されたランタイム・エラーは、RUN_JOBの実行者に返送されます。
RUN_JOBを使用してリモート外部ジョブまたはチェーンを指し示すジョブを実行する場合は、use_current_sessionをFALSEに設定する必要があります。
ジョブは、ジョブの所有者に直接付与された権限、またはデフォルトのログイン・ロールによって間接的に付与された権限で実行されます。 外部オペレーティング・システムのロールはサポートされていません。適切な権限が付与されている場合、ユーザーは他のユーザーのスキーマ内にジョブを作成できます。したがって、ジョブの作成者と所有者は異なる場合があります。たとえば、ユーザーjimにCREATE ANY JOB権限があり、scottのスキーマ内にジョブを作成した場合、そのジョブはscottの権限で実行されます。
ジョブが作成されたセッションのNLS環境が保存され、ジョブの実行時に使用されます。ジョブが実行されるNLS環境を変更するには、別のNLS設定のセッション内にジョブを作成する必要があります。
実行中の1つ以上のジョブを停止するには、STOP_JOBプロシージャまたはEnterprise Managerを使用します。STOP_JOBは、ジョブおよびジョブ・クラスのカンマ区切りのリストを受け入れます。ジョブ・クラスが指定されている場合、そのジョブ・クラス内の実行中のジョブはすべて停止されます。たとえば、次の文では、ジョブjob1とジョブ・クラスdw_jobs内のすべてのジョブが停止されます。
BEGIN DBMS_SCHEDULER.STOP_JOB('job1, sys.dw_jobs'); END; /
指定したジョブのインスタンスはすべて停止されます。ジョブの停止後、1回かぎりのジョブの状態はSTOPPEDに設定され、繰返しジョブの状態は、（次回のジョブ実行がスケジュールされているため）SCHEDULEDに設定されます。また、ジョブ・ログには、OPERATIONが'STOPPED'に設定され、ADDITIONAL_INFOが'REASON="Stop job called by user: username"'に設定されたエントリが作成されます。
デフォルトでは、スケジューラは割込みメカニズムを使用してジョブを正常に停止しようとします。この方法では、制御がスレーブ・プロセスに戻され、スレーブ・プロセスはジョブ実行の統計を収集できます。forceオプションがTRUEに設定されている場合、ジョブは即時に停止するため、そのジョブ実行について特定の実行時間の統計が使用できない場合があります。
チェーンを実行中のジョブを停止すると、実行中のすべてのステップが（各ステップでforceオプションをTRUEに設定してSTOP_JOBをコールすることによって）自動的に停止されます。
STOP_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
スケジューラを使用している場合、外部ジョブの実装者は、forceがFALSEに設定されたSTOP_JOBがコールされた場合に、その外部ジョブを正常にクリーン・アップするメカニズムを利用できます。 次の説明は、すべてのプラットフォーム上で資格証明を使用せずに作成されたローカル外部ジョブと、UNIXおよびLinuxプラットフォーム上のリモート外部ジョブにのみ該当します。
UNIXおよびLinuxでは、スケジューラによって起動されたプロセスにSIGTERMシグナルが送信されます。外部ジョブの実装者は、割込みハンドラにSIGTERMをトラップし、ジョブの実装内容をすべてクリーン・アップして終了する必要があります。Windowsでは、forceがFALSEに設定されたSTOP_JOBは、Windows XP、Windows 2003およびそれ以降のオペレーティング・システムでのみサポートされます。 これらのプラットフォームでは、スケジューラによって起動されるプロセスがコンソール・プロセスです。このプロセスを停止するために、スケジューラはCTRL-BREAKをプロセスに送信します。CTRL_BREAKは、SetConsoleCtrlHandler()ルーチンにハンドラを登録することによって処理できます。
チェーンを指し示すジョブが停止すると、実行中のチェーンのステップがすべて停止します。
個々のチェーン・ステップの停止の詳細は、「個々のチェーン・ステップの停止」を参照してください。
1つ以上のジョブを削除するには、DROP_JOBプロシージャまたはEnterprise Managerを使用します。DROP_JOBは、ジョブおよびジョブ・クラスのカンマ区切りのリストを受け入れます。ジョブ・クラスが指定されている場合、そのジョブ・クラス内のジョブはすべて削除されます。ただし、そのジョブ・クラス自体は削除されません。
たとえば、次の文では、ジョブjob1とjob3、およびジョブ・クラスjobclass1とjobclass2内のすべてのジョブが削除されます。
BEGIN DBMS_SCHEDULER.DROP_JOB ('job1, job3, sys.jobclass1, sys.jobclass2'); END; /
ジョブを削除すると、そのジョブはジョブ表から削除され、そのメタデータも削除され、*_SCHEDULER_JOBSビューに表示されなくなります。したがって、これ以降ジョブは実行されません。
DROP_JOBのコール時にジョブのインスタンスが実行中の場合、そのコールはエラーになります。この場合でも、コールでforceオプションをTRUEに設定すると、ジョブを削除できます。forceオプションをTRUEに設定すると、最初に、実行中のジョブ・インスタンスが割込みメカニズムによって停止（forceオプションをFALSEに設定してSTOP_JOBをコール）され、次にジョブが削除されます。
または、STOP_JOBをコールして最初にジョブを停止してから、DROP_JOBをコールしてジョブを削除することもできます。MANAGE SCHEDULER権限が付与されている場合は、通常のSTOP_JOBコールがジョブの停止に失敗したときにforce付きでSTOP_JOBをコールし、その後でDROP_JOBをコールできます。
デフォルトでは、forceはFALSEに設定されます。
commit_semanticsがSTOP_ON_FIRST_ERRORに設定されている場合は、最初のエラーでコールが戻り、エラー発生前に正常終了した削除操作がディスクにコミットされます。commit_semanticsがTRANSACTIONALに、forceがFALSEに設定されている場合は、最初のエラーでコールが戻り、エラー発生前の削除操作がロールバックされます。commit_semanticsがABSORB_ERRORSに設定されている場合は、エラーへの対応が取り組まれ、残りのジョブの削除が試行されて、正常に終了したすべての削除操作がコミットされます。デフォルトでは、commit_semanticsはSTOP_ON_FIRST_ERRORに設定されています。
ジョブ・クラスを削除するには、DROP_JOB_CLASSプロシージャを使用してください。 ジョブ・クラスの削除方法は、「ジョブ・クラスの削除」を参照してください。
DROP_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
1つ以上のジョブを無効（使用禁止）にするには、DISABLEプロシージャまたはEnterprise Managerを使用します。ジョブは他の理由で使用禁止になる場合もあります。たとえば、ジョブが属しているジョブ・クラスが削除されると、ジョブは使用禁止になります。また、ジョブが指し示しているプログラムまたはスケジュールのいずれかが削除された場合も使用禁止になります。ジョブが指し示しているプログラムまたはスケジュールが使用禁止の場合は、そのジョブ自体は使用禁止にならないため、スケジューラがジョブを実行しようとしたときに、エラーとなることに注意してください。
ジョブを使用禁止にすると、そのジョブのメタデータはそのまま存在しますが、ジョブ自体は実行対象ではないため、ジョブ・コーディネータがこれらのジョブを取り出して処理することはありません。ジョブが使用禁止になると、ジョブ表内のそのstateはdisabledに変更されます。
forceオプションをFALSEに設定してジョブを使用禁止にすると、ジョブが現在実行中の場合はエラーが返されます。forceがTRUEに設定されているときは、ジョブは使用禁止になりますが、現在実行中のインスタンスは完了できます。
commit_semanticsがSTOP_ON_FIRST_ERRORに設定されている場合は、最初のエラーでコールが戻り、エラー発生前に正常終了した使用禁止操作がディスクにコミットされます。commit_semanticsがTRANSACTIONALに、forceがFALSEに設定されている場合は、最初のエラーでコールが戻り、エラー発生前の使用禁止操作がロールバックされます。commit_semanticsがABSORB_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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
1つ以上のジョブを有効（使用可能）にするには、ENABLEプロシージャまたはEnterprise Managerを使用します。このプロシージャを使用すると、ジョブは、ジョブ・コーディネータによって取り出され、処理されるようになります。ジョブは、デフォルトで使用禁止で作成されるため、実行するには使用可能にする必要があります。ジョブを使用可能にすると、妥当性チェックが実行されます。チェックに失敗すると、ジョブは使用可能になりません。
commit_semanticsがSTOP_ON_FIRST_ERRORに設定されている場合は、最初のエラーでコールが戻り、エラー発生前に正常終了した使用可能にする操作がディスクにコミットされます。commit_semanticsがTRANSACTIONALに設定されている場合は、最初のエラーでコールが戻り、エラー発生前の使用可能にする操作がロールバックされます。commit_semanticsがABSORB_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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ジョブをコピーするには、COPY_JOBプロシージャまたはEnterprise Managerを使用します。 このコールによって、旧ジョブのすべての属性（ジョブ名以外）が新規ジョブにコピーされます。 新規ジョブは使用禁止の状態で作成されます。
COPY_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ジョブの実行、状態変化および失敗について、ジョブ・ログ内の情報を表示できます。 ジョブ・ログは、次の2つのデータ・ディクショナリ・ビューとして実装されます。
スケジューラは、有効なロギング・レベルに応じて、ジョブの実行時、作成時、削除時、有効化時などにジョブ・ログ・エントリを作成できます。 繰返しスケジュールを持つジョブの場合、スケジューラではジョブ・ログにジョブ・インスタンスごとに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属性を設定すると、ジョブ・ログに情報が書き込まれる頻度を制御できます。表27-2に、logging_levelに可能な値を示します。
ジョブの実行に関するログ・エントリは、ジョブの実行が正常に完了するか、失敗するかまたは停止するまで作成されません。
次の例に、ジョブのライフサイクル全体に関するジョブ・ログ・エントリを示します。 この例では、ジョブ・クラスのロギング・レベルはLOGGING_FULLで、ジョブは非繰返しジョブです。 ジョブは最初に成功した実行の後で再び使用可能になるため、もう1回実行されます。 その後、停止され、削除されます。
SELECT to_char(log_date, 'DD-MON-YY HH24:MM: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
RUN、RETRY_RUNまたはRECOVERY_RUN操作に関する*_SCHEDULER_JOB_LOG内の行ごとに、*_SCHEDULER_JOB_RUN_DETAILSビューには対応する行があります。 2つの異なるビューの行は、それぞれのLOG_ID列で関係付けられています。 実行詳細ビューを参照して、ジョブが失敗した理由や停止された理由を判断できます。
SELECT to_char(log_date, 'DD-MON-YY HH24:MM: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
実行詳細ビューには、実際のジョブ開始時刻と継続時間も含まれています。
ジョブとジョブ・クラスの両方にlogging_level属性があります。この属性に可能な値については、表27-2を参照してください。 ジョブ・クラスのデフォルトのロギング・レベルはLOGGING_RUNSで、個別ジョブのデフォルトのレベルはLOGGING_OFFです。 ジョブ・クラスのロギング・レベルがクラス内のジョブのロギング・レベルよりも高い場合は、ジョブ・クラスのロギング・レベルが優先されます。 したがって、デフォルトでは、すべてのジョブの実行がジョブ・ログに記録されます。
極端に短く頻繁に実行されるジョブが含まれているジョブ・クラスの場合は、各実行ごとの記録のオーバーヘッドが大きすぎるため、ロギングをオフにするか、ジョブが失敗した場合にのみロギングが発生するように設定することもできます。 一方で、特定のクラス内のジョブについては発生したすべての操作の完全な監査証跡が必要な場合があります。この場合はそのクラスに対して完全ロギングを有効化する必要があります。
すべてのジョブの監査証跡が確実に作成されるようにする場合は、個々のジョブ作成者がロギングをオフにできないようにする必要があります。 これをサポートするために、スケジューラではクラス別のレベルがジョブの情報を記録する最低レベルとなっています。 ジョブ作成者は、個々のジョブに対するロギング・レベルを上げることはできますが、下げることはできません。 したがって、個々のジョブのロギング・レベルをすべてLOGGING_OFFに設定すると、クラス内のすべてのジョブがクラスでの指定に従って記録されます。
この機能は、デバッグの目的で提供されています。 たとえば、クラス別のレベルでジョブ実行を記録するように設定されているときに、ジョブ・レベルでロギングがオフにされた場合でも、スケジューラはジョブの実行を記録します。 一方、ジョブ作成者が完全ロギングをオンにしているときに、クラス別のレベルでは実行のみを記録するように設定されている場合は、ジョブの上位のロギング・レベルが優先され、この個別ジョブのすべての操作がログに記録されます。このように、エンド・ユーザーは、完全ロギングをオンにして自分のジョブをテストできます。
個々のジョブのロギング・レベルを設定するには、そのジョブについてSET_ATTRIBUTEプロシージャを使用する必要があります。たとえば、mytestjobというジョブの完全ロギングをオンにするには、次の文を発行します。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ( 'mytestjob', 'logging_level', DBMS_SCHEDULER.LOGGING_FULL); END;
ジョブ・クラスのロギング・レベルを設定できるのは、MANAGE SCHEDULER権限を付与されているユーザーのみです。
資格証明が割り当てられている外部ジョブでは、stdoutとstderrがログ・ファイルに書き込まれます。 ローカル外部ジョブでは、ディレクトリORACLE_HOME/scheduler/log内のログ・ファイルに書き込まれます。 リモート外部ジョブでは、ディレクトリAGENT_HOME/data/log内のログ・ファイルに書き込まれます。 これらのファイルの内容は、DBMS_SCHEDULER.GET_FILEで取得できます。 ファイル名は、ジョブ・ログIDとそれに続く文字列_stdoutまたは_stderrで構成されています。ジョブのジョブ・ログIDを取得するには、*_SCHEDULER_JOB_RUN_DETAILSビューのADDITIONAL_INFO列を問い合せて、次のような名前/値ペアを解析します。
EXTERNAL_LOG_ID="job_71035_3158"
たとえば、ファイル名はjob_71035_3158_stdoutのようになります。stdoutの出力の取得方法は、例27-6「ローカル外部ジョブの作成とstdoutの取得」を参照してください。 この例はローカル外部ジョブに関するものですが、メソッドはリモート外部ジョブの場合も同じです。
また、ローカル外部ジョブまたはリモート外部ジョブによってstderrに出力が書き込まれる際は、最初の200バイトが*_SCHEDULER_JOB_RUN_DETAILSビューのADDITIONAL_INFO列に記録されます。 この情報は、次のような名前/値ペアの形式で記録されます。
STANDARD_ERROR="text"
プログラムは、特定のタスクに関するメタデータの集合です。この項では、プログラムの基本的なタスクについて説明します。この項の内容は、次のとおりです。
表27-3に、プログラムの一般的なタスクとそれに対応するプロシージャおよび権限を示します。
権限の詳細は、「スケジューラ権限」を参照してください。
プログラムを作成するには、CREATE_PROGRAMプロシージャまたはEnterprise Managerを使用します。デフォルトでは、プログラムは作成者のスキーマ内に作成されます。別のユーザーのスキーマ内にプログラムを作成するには、プログラム名をスキーマ名で修飾する必要があります。他のユーザーがプログラムを使用する場合、そのユーザーにはそのプログラムに対する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_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; /
プログラム引数は、名前または位置で削除できます。次に例を示します。
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プロシージャを使用して特別なメタデータ引数を定義できます。
プログラムを変更するには、Enterprise ManagerまたはDBMS_SCHEDULER.SET_ATTRIBUTEおよびDBMS_SCHEDULER.SET_ATTRIBUTE_NULLパッケージ・プロシージャを使用します。 DBMS_SCHEDULERパッケージ・プロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
次に、Enterprise Managerを使用したプログラムの変更方法を示します。
「スケジューラのプログラム」ページが表示されます。このページには既存のプログラムが表示されます。
「プログラムの編集」ページが表示されます。
PLSQL_BLOCK「ソース」フィールドが表示されます。このフィールドでPL/SQLコードを入力または変更します。
STORED_PROCEDURE「プロシージャ名」フィールドが表示されます。フィールドにストアド・プロシージャ名が含まれている場合は、「プロシージャの表示」をクリックするとストアド・プロシージャを表示または編集できます。フィールドが空白の場合、またはストアド・プロシージャを変更する場合は、「プロシージャの選択」をクリックします。「プロシージャの選択」ページが表示されます。ストアド・プロシージャを選択して「選択」をクリックすると、「プログラムの編集」ページに戻ります（「プロシージャの選択」ページの使用方法に関するヘルプは、ページの上部にある「ヘルプ」をクリックしてください）。
プロシージャ名を選択すると、「プログラムの編集」ページの「引数」ヘッダーの下に、引数のリストが表示されます。必要に応じて、1つ以上の引数のデフォルト値を入力します。
EXECUTABLE「実行可能な名前」フィールドが表示されます。実行可能ファイルのフルパスを入力します。「引数」ヘッダーの下にある引数を編集または削除するか、「行の追加」をクリックして引数を追加します。
変更したプログラムが、現在実行中のジョブで使用されている場合、そのジョブは変更操作前に定義されたプログラムで引き続き実行されます。
1つ以上のプログラムを削除するには、DROP_PROGRAMプロシージャまたはEnterprise Managerを使用します。
削除されたプログラムを指し示している実行中のジョブはDROP_PROGRAMコールの影響を受けず、実行を継続できます。プログラムが削除されると、そのプログラムに関係する引数もすべて削除されます。プログラム名のカンマ区切りのリストを指定することで、1回のコールで複数のプログラムを削除できます。たとえば、次の文では3つのプログラムが削除されます。
BEGIN DBMS_SCHEDULER.DROP_PROGRAM('program1, program2, program3'); END; /
DROP_PROGRAMプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
1つ以上のプログラムを無効（使用禁止）にするには、DISABLEプロシージャまたはEnterprise Managerを使用します。プログラムが使用禁止になると、ステータスがdisabledに変更されます。使用禁止プログラムとは、メタデータは存在しているが、このプログラムを指し示すジョブは実行できないことを意味します。
使用禁止のプログラムを指し示している実行中のジョブはDISABLEコールの影響を受けず、実行を継続できます。プログラムが使用禁止になった場合でも、そのプログラムに関係する引数は影響を受けません。
プログラムは他の理由で使用禁止になる場合もあります。たとえば、プログラム引数が削除された場合やnumber_of_argumentsの変更ですべての引数を定義できなくなった場合などです。
DISABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
1つ以上のプログラムを有効（使用可能）にするには、ENABLEプロシージャまたはEnterprise Managerを使用します。プログラムを使用可能になると、使用可能フラグがTRUEに設定されます。プログラムは、デフォルトで使用禁止で作成されるため、そのプログラムを指し示すジョブを使用可能にするには、プログラムを使用可能にする必要があります。プログラムが使用可能になる前に、処理が有効であること、およびすべての引数が定義されていることを確認するために妥当性チェックが実行されます。
ENABLEプロシージャ・コールにプログラム名のカンマ区切りのリストを指定することで、1回のコールで複数のプログラムを使用可能にできます。たとえば、次の文では3つのプログラムが使用可能になります。
BEGIN DBMS_SCHEDULER.ENABLE('program1, program2, program3'); END; /
ENABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
スケジュールは、ジョブの実行時期またはウィンドウのオープン時期を定義します。スケジュールは、データベースにオブジェクトとして作成および保存することによってユーザー間で共有できます。
この項では、スケジュールの基本的なタスクについて説明します。この項の内容は、次のとおりです。
表27-4に、スケジュールの一般的なタスクとその処理に使用するプロシージャを示します。
| タスク | プロシージャ | 必要な権限 |
|---|---|---|
|
スケジュールの作成 |
|
|
|
スケジュールの変更 |
|
|
|
スケジュールの削除 |
|
|
権限の詳細は、「スケジューラ権限」を参照してください。
スケジュールを作成するには、CREATE_SCHEDULEプロシージャまたはEnterprise Managerを使用します。スケジュールは、そのスケジュールを作成するユーザーのスキーマ内に作成され、最初に作成した時点で使用可能です。また、別のユーザーのスキーマ内に作成できます。作成したスケジュールは、他のユーザーが使用できます。スケジュールは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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
スケジュールを変更するには、SET_ATTRIBUTEプロシージャまたはEnterprise Managerを使用します。スケジュールを変更すると、スケジュールの定義が変更されます。スケジュール名以外のすべての属性を変更できます。スケジュールの属性は、*_SCHEDULER_SCHEDULESビューで使用可能です。
スケジュールを変更しても、このスケジュールを使用している実行中のジョブとオープン中のウィンドウに影響を与えることはありません。変更が有効になるのは、次回のジョブ実行時またはウィンドウ・オープン時からです。
SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
スケジュールを削除するには、DROP_SCHEDULEプロシージャまたはEnterprise Managerを使用します。このプロシージャ・コールによって、スケジュール・オブジェクトがデータベースから削除されます。
DROP_SCHEDULEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ジョブの繰返し時期および間隔を制御するには、ジョブ自体またはジョブが参照する名前付きスケジュールのrepeat_interval属性を設定します。repeat_intervalは、DBMS_SCHEDULERパッケージまたはEnterprise Managerで設定できます。
repeat_intervalの評価結果は一連のタイムスタンプです。スケジューラは各タイムスタンプの日時にジョブを実行します。ジョブやスケジュールからの開始日も、タイムスタンプの結果セットを決定する要因となることに注意してください （repeat_intervalの評価の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください）。repeat_intervalに値が指定されていない場合、ジョブは指定した開始日に1回のみ実行されます。
ジョブの開始直後にrepeat_intervalが評価され、スケジュールされた次回のジョブ実行時間が判別されます。ジョブがまだ実行されている間に、スケジュールされた次回のジョブ実行時間に達する可能性があります。しかし、ジョブの新規インスタンスは、現在のジョブが完了するまでは開始されません。
繰返し間隔を指定する方法は、次の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日に実行（2つの例は等価です）
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
米国独立記念日、戦没将兵記念日、労働者の日の3つの休日に実行（この例では、それぞれ休日に対応する日を定義する既存の3つの名前付きスケジュールJUL4、MEMおよびLABを参照）
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; /
この文では、scott内にmy_job1が作成されます。このジョブの開始日は7月15日、終了日は9月15日で、30分おきに実行されます。
カレンダ指定構文より複雑な機能が必要な場合は、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; /
この文では、scott内にmy_job1が作成されます。このジョブの開始日は7月15日で、30分おきに実行され9月15日に終了します。ジョブが30分おきに実行されるのは、repeat_intervalがSYSTIMESTAMP + INTERVAL '30' MINUTEに設定されており、この式では30分後が戻されるためです。
カレンダ指定式とPL/SQL繰返し間隔の動作には、次のような重要な相違があります。
カレンダ指定構文を使用した場合、開始日は参照日のみです。つまり、スケジュールはこの日付から有効になります。これは、ジョブが開始日に開始されることを意味しません。
PL/SQL式を使用した場合、開始日はジョブが最初に実行を開始した実際の時間を表します。
カレンダ指定構文を使用した場合、次回のジョブ実行時期は固定されています。
PL/SQL式を使用した場合、次回のジョブ実行時期は現行ジョブ実行の実際の開始時間によって異なります。この違いを示す例を考えてみます。あるジョブを午後2時に開始し、2時間おきに繰り返すスケジュールの場合、繰返し間隔をカレンダ指定構文で指定すると、ジョブは4時、6時というように繰り返され、以降も同様に繰り返されます。PL/SQLを指定してジョブを午後2時10分に開始した場合、そのジョブは午後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 ...
ジョブの繰返しでは、次回のジョブ実行時間のスケジュールは、タイム・ゾーン列のあるタイムスタンプに格納されます。カレンダ指定構文を使用する場合、タイム・ゾーンはstart_dateから取り出されます。 start_dateが設定されていない場合の操作の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
PL/SQL式に基づいた繰返し間隔の場合、タイム・ゾーンはPL/SQL式が返すタイムスタンプの一部になっています。いずれの場合も、リージョン名を使用することが重要です。たとえば、"+2:00"のように絶対タイム・ゾーン・オフセットを指定するのではなく、"Europe/Istanbul"のように指定します。タイム・ゾーンがリージョン名で指定されている場合のみ、スケジューラはそのリージョンに適用される夏時間調整に従います。
ジョブ・クラスを使用すると、リソース割当ておよび優先度付けの目的でジョブをグループ化でき、一連の属性値をメンバーのジョブに簡単に割り当てることができます。
データベースとともに作成されるデフォルトのジョブ・クラスがあります。ジョブ・クラスを指定せずにジョブを作成すると、ジョブはこのデフォルトのジョブ・クラス（DEFAULT_JOB_CLASS）に割り当てられます。デフォルトのジョブ・クラスでは、EXECUTE権限がPUBLICに付与されているため、ジョブの作成権限を持つすべてのデータベース・ユーザーは、デフォルトのジョブ・クラスにジョブを作成できます。
この項では、ジョブ・クラスの基本的なタスクについて説明します。この項の内容は、次のとおりです。
表27-5に、ジョブ・クラスの一般的なタスクとそれに対応するプロシージャと権限を示します。
| タスク | プロシージャ | 必要な権限 |
|---|---|---|
|
ジョブ・クラスの作成 |
|
|
|
ジョブ・クラスの変更 |
|
|
|
ジョブ・クラスの削除 |
|
|
権限の詳細は、「スケジューラ権限」を参照してください。
ジョブ・クラスを作成するには、CREATE_JOB_CLASSプロシージャまたはEnterprise Managerを使用します。たとえば、次の文では、すべての財務ジョブ用のジョブ・クラスが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_JOB_CLASS ( job_class_name => 'finance_jobs', resource_consumer_group => 'finance_group'); END; /
ジョブ・クラスを問い合せるには、*_SCHEDULER_JOB_CLASSESビューを使用します。
SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。また、ジョブ・クラスの作成例は、「Oracle Schedulerの構成」を参照してください。
ジョブ・クラスを変更するには、SET_ATTRIBUTEプロシージャまたはEnterprise Managerを使用します。また、ジョブ・クラス名以外のすべての属性を変更できます。ジョブ・クラスの属性は、*_SCHEDULER_JOB_CLASSESビューで使用可能です。
ジョブ・クラスを変更しても、そのクラスに属する実行中のジョブは影響を受けません。変更は、まだ実行が開始されていないジョブに対してのみ有効です。
SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。また、「Oracle Schedulerの構成」を参照してください。
1つ以上のジョブ・クラスを削除するには、DROP_JOB_CLASSプロシージャまたはEnterprise Managerを使用します。ジョブ・クラスを削除すると、そのジョブ・クラスに関するすべてのメタデータがデータベースから削除されます。
DROP_JOB_CLASSプロシージャ・コールにジョブ・クラス名のカンマ区切りのリストを指定することで、1回のコールで複数のジョブ・クラスを削除できます。たとえば、次の文では3つのジョブ・クラスが削除されます。
BEGIN DBMS_SCHEDULER.DROP_JOB_CLASS('jobclass1, jobclass2, jobclass3'); END; /
DROP_JOB_CLASSプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ウィンドウを使用すると、異なる時間帯で別々のリソース・プランを自動的にアクティブにできます。ジョブを実行すると、そのジョブに割り当てられているリソースが、リソース・プランの変更時に変わることがわかります。
ウィンドウの主な属性は次のとおりです。
ウィンドウが有効である時期を制御します。
ウィンドウがオープンしている長さを制御します。
ウィンドウのオープン時にアクティブ化されるリソース・プランの名前を設定します。
特定の時間に有効にできるウィンドウは1つのみです。ウィンドウはSYSスキーマに属します。
すべてのウィンドウ・アクティビティは、*_SCHEDULER_WINDOW_LOGビュー（ウィンドウ・ログと呼ばれます）に記録されます。 ウィンドウ・ログの記録例は、「ウィンドウ・ログ」を参照してください。
この項では、ウィンドウの基本的なタスクについて説明します。この項の内容は、次のとおりです。
表27-6に、ウィンドウの一般的なタスクとその処理に使用するプロシージャを示します。
権限の詳細は、「スケジューラ権限」を参照してください。
ウィンドウを作成するには、Enterprise ManagerまたはDBMS_SCHEDULER.CREATE_WINDOWパッケージ・プロシージャを使用します。これらの作成方法には、一方はPL/SQLを使用し、もう一方はGUIを使用すること以外に、異なる点が1つあります。パッケージ・プロシージャを使用する場合は、resource_planパラメータをNULLのままにできることです。この場合は、ウィンドウのオープン時に現行のプランが有効のままになります。 詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』および「Oracle Schedulerの構成」を参照してください。
Enterprise Managerを使用してウィンドウを作成する手順は、次のとおりです。
「スケジューラのウィンドウ」ページが表示されます。このページには既存のウィンドウが表示されます。
「ウィンドウの作成」ページが表示されます。
デフォルトのINTERNAL_PLANを使用できます。 既存のリソース・プランの内容を表示するには、「リソース・プランの表示」をクリックします。 新規リソース・プランを作成するには、「リソース・プランの作成」をクリックしてその作成手順に従います。
「OK」をクリックし、残りの手順をスキップします。
ウィンドウを変更するには、SET_ATTRIBUTEプロシージャまたはEnterprise Managerを使用します。変更するときは、WINDOW_NAME以外のすべてのウィンドウ属性を変更できます。ウィンドウの属性は、*_SCHEDULER_WINDOWSビューで使用可能です。
ウィンドウを変更しても、アクティブなウィンドウには影響を与えません。変更は、次回ウィンドウがオープンしたときに有効になります。
すべてのウィンドウを変更できます。使用禁止のウィンドウを変更した場合は、変更した後も使用禁止のままです。使用可能なウィンドウは自動的に使用禁止になり、変更後、使用可能化プロセスで実行される妥当性チェックが成功した場合は再び使用可能になります。
SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。また、「Oracle Schedulerの構成」を参照してください。
ウィンドウがオープンすると、スケジューラは、ウィンドウの作成時に関連付けられたリソース・プランに切り替えます。ウィンドウのオープン時に実行中のジョブがある場合、そのジョブに割り当てられているリソースはリソース・プランの切替えによって変更される場合があります。
ウィンドウをオープンする方法は、次の2通りあります。
OPEN_WINDOWプロシージャを使用した手動オープンこのプロシージャは、スケジュールとは関係なくウィンドウをオープンします。ウィンドウがオープンし、関連付けられたリソース・プランが即時に有効になります。手動でオープンできるのは、使用可能なウィンドウのみです。
OPEN_WINDOWプロシージャで、duration属性を使用して、ウィンドウがオープンしている時間の長さを指定できます。継続時間の型はINTERVAL DAY TO SECONDです。継続時間の指定がない場合、ウィンドウはそのウィンドウに保存されている通常の継続時間の間オープン状態です。
ウィンドウを手動でオープンしても、スケジュールされた通常のウィンドウの実行には影響を与えません。
手動でオープンしたウィンドウがクローズすると、その時点でオープン対象のウィンドウが他にある場合は、重複ウィンドウのルールが適用され、オープンするウィンドウが判別されます。
すでにオープンしているウィンドウがある場合でも、OPEN_WINDOWコールまたはEnterprise ManagerでforceオプションをTRUEに設定すると、ウィンドウを強制的にオープンできます。
forceオプションがTRUEに設定されているときは、その時点でオープンしているウィンドウの優先度の方が高い場合でも、スケジューラはウィンドウを自動的にクローズします。手動でオープンしたウィンドウの継続時間中は、より優先度の高いウィンドウが他にスケジュールされていても、スケジューラはそのウィンドウをオープンしません。すでにオープンしているウィンドウもオープンできます。この場合、ウィンドウは、OPEN_WINDOWコマンドが発行された時点から、コールで指定された継続時間の間オープンしたままになります。
この状態を示す例について考えてみます。window1が継続時間4時間で作成されたとします。現在は、オープンから2時間が経過しています。この時点でOPEN_WINDOWコールを使用してwindow1を再オープンしても、継続時間を指定しない場合、window1は、さらに4時間オープンしたままになります。これは、以前からこの継続時間で作成されているためです。継続時間に30分を指定した場合、ウィンドウは30分後にクローズします。
ウィンドウがオープンすると、ウィンドウ・ログにエントリが作成されます。
現在のリソース・プランが、ALTER SYSTEM文FORCEオプションあるいはDBMS_RESOURCE_MANAGER.SWITCH_PLANパッケージ・プロシージャのallow_scheduler_plan_switches引数FALSEを使用して、手動で切り替えられたものである場合、ウィンドウでリソース・プランの切替えに失敗する可能性があります。この場合、リソース・プランの切替え失敗がウィンドウ・ログに書き込まれます。
OPEN_WINDOWプロシージャおよびDBMS_RESOURCE_MANAGER.SWITCH_PLANプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ウィンドウをクローズする方法は、次の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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
1つ以上のウィンドウを削除するには、DROP_WINDOWプロシージャまたはEnterprise Managerを使用します。ウィンドウが削除されると、そのウィンドウに関するすべてのメタデータが*_SCHEDULER_WINDOWSビューから削除されます。また、ウィンドウに対するすべての参照がウィンドウ・グループから削除されます。
DROP_WINDOWプロシージャにウィンドウ名またはウィンドウ・グループ名のカンマ区切りのリストを指定すると、1回のコールで複数のウィンドウを削除できます。たとえば、次の文ではウィンドウとウィンドウ・グループの両方が削除されます。
BEGIN DBMS_SCHEDULER.DROP_WINDOW ('window1, window2, window3, windowgroup1, windowgroup2'); END; /
ウィンドウ・グループ名を指定した場合、ウィンドウ・グループ内のウィンドウは削除されますが、ウィンドウ・グループは削除されません。ウィンドウ・グループを削除するには、DROP_WINDOW_GROUPプロシージャを使用する必要があります。
DROP_WINDOWプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
1つ以上のウィンドウを無効（使用禁止）にするには、DISABLEプロシージャまたはEnterprise Managerを使用します。使用禁止のウィンドウはオープンしませんが、ウィンドウのメタデータは存在しているため、再び使用可能にできます。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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
1つ以上のウィンドウを有効（使用可能）にするには、ENABLEプロシージャまたはEnterprise Managerを使用します。使用可能なウィンドウとは、オープン可能なウィンドウのことです。ウィンドウは、デフォルトでenabledで作成されます。ENABLEプロシージャを使用してウィンドウを使用可能にすると、妥当性チェックが実行され、このチェックが成功した場合のみウィンドウは使用可能になります。ウィンドウが使用可能になると、ウィンドウ・ログ表にログが記録されます。ENABLEプロシージャは複数のスケジューラ・オブジェクトに対して使用されるため、ウィンドウを使用可能にするときは、先頭にSYSを付ける必要があります。
ウィンドウ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウを使用可能にできます。たとえば、次の文では3つのウィンドウが使用可能になります。
BEGIN DBMS_SCHEDULER.ENABLE ('sys.window1, sys.window2, sys.window3'); END; /
ENABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
お薦めする方法ではありませんが、ウィンドウは重複して設定できます。1度にアクティブにできるウィンドウは1つのみであるため、ウィンドウが重複したときにどのウィンドウをアクティブにするかを判別するために、次のルールが使用されます。
2つのウィンドウが重複した場合は、スケジューラのログにエントリが必ず記録されます。
図27-1に、24時間スケジュールの場合のウィンドウ、リソース・プランおよび優先度の判別方法に関する一般的な例を示します。次の2つの例では、ウィンドウ1はリソース・プラン1に、ウィンドウ2はリソース・プラン2に関連付けられ、以下も同様に関連付けられているとします。
図27-1では、次の処理が発生します。
いずれのウィンドウもオープンしていないため、デフォルトのリソース・プランが有効です。
ウィンドウ1には低い優先度が割り当てられていますが、高い優先度のウィンドウが他に存在しないためウィンドウ1がオープンします。したがって、リソース・プラン1が有効です。
ウィンドウ1より優先度の高いウィンドウ3がオープンします。したがって、リソース・プラン3が有効です。
ウィンドウ1は、より優先度の高いウィンドウがオープンしたために午前6時にクローズしましたが、午前9時に、この優先度の高いウィンドウがクローズし、ウィンドウ1には当初のスケジュールの残り時間がまだ2時間あります。ウィンドウ1は残りの2時間再びオープン状態となり、リソース・プランが有効になります。
いずれのウィンドウもオープンしていないため、デフォルトのリソース・プランが有効です。
ウィンドウ2がオープンするため、リソース・プラン2が有効です。
ウィンドウ4の優先度はウィンドウ2と同じであるため、ウィンドウ2への割込みはありません。したがって、リソース・プラン2が有効です。
ウィンドウ4がオープンしているため、リソース・プラン4が有効です。
いずれのウィンドウもオープンしていないため、デフォルトのリソース・プランが有効です。
図27-2に、24時間スケジュールの場合のウィンドウ、リソース・プランおよび優先度の判別方法に関する別の例を示します。
図27-2では、次の処理が発生します。
デフォルトのリソース・プランが有効です。
ウィンドウ1には低い優先度が割り当てられていますが、高い優先度のウィンドウが他に存在しないためウィンドウ1がオープンします。したがって、リソース・プラン1が有効です。
ウィンドウ1より優先度の高いウィンドウ3がオープンします。ウィンドウ6は優先度の高い別のウィンドウがすでに有効であるためオープンしません。
午前9時の時点では、ウィンドウ5またはウィンドウ1の2つが選択対象です。両方とも優先度が低いため、残り継続時間の比率の大きさに基づいて選択されます。ウィンドウ1の総継続時間と比較して、ウィンドウ5の残り時間の比率の方が大きい状態です。たとえば、ウィンドウ1が午前11時30分まで延長された場合でも、ウィンドウ5の残り継続時間に対する比率が2/3×100%であるのに対して、ウィンドウ1は2.5/7×100%であるため比率が小さくなります。したがって、リソース・プラン5が有効になります。
ウィンドウ・グループを使用すると、1日あるいは1週間などの間に複数期間実行するジョブを簡単にスケジュールできます。ウィンドウ・グループを作成してウィンドウをグループに加え、ウィンドウ・グループ名をジョブのschedule_name属性に設定すると、ジョブがウィンドウ・グループ内のすべてのウィンドウの指定期間に実行されます。
ウィンドウ・グループはSYSスキーマに格納されます。この項では、ウィンドウ・グループの基本的なタスクについて説明します。この項の内容は、次のとおりです。
表27-7に、ウィンドウ・グループの一般的なタスクとその処理に使用するプロシージャを示します。
権限の詳細は、「スケジューラ権限」を参照してください。
ウィンドウ・グループを作成するには、CREATE_WINDOW_GROUPプロシージャまたはEnterprise Managerを使用します。グループのメンバー・ウィンドウは、グループの作成時に指定するか、または後でADD_WINDOW_GROUP_MEMBERプロシージャを使用して追加できます。ウィンドウ・グループは別のウィンドウ・グループのメンバーとして設定できません。ただし、メンバーを設定しないウィンドウ・グループは作成できます。
ウィンドウ・グループを作成し、存在しないメンバー・ウィンドウを指定すると、エラーが生成され、ウィンドウ・グループは作成されません。ウィンドウがすでにウィンドウ・グループのメンバーである場合、再度追加されることはありません。
ウィンドウ・グループはSYSスキーマ内に作成されます。ウィンドウ・グループは、ウィンドウと同様に、PUBLICに対するアクセス権限付きで作成されるため、ウィンドウ・グループにアクセスするための権限は必要ありません。
次の文では、downtimeというウィンドウ・グループが作成され、2つのウィンドウ（weeknightsとweekends）が追加されます。
BEGIN DBMS_SCHEDULER.CREATE_WINDOW_GROUP ( group_name => 'downtime', window_list => 'weeknights, weekends'); END; /
CREATE_WINDOW_GROUPプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
1つ以上のウィンドウ・グループを削除するには、DROP_WINDOW_GROUPプロシージャまたはEnterprise Managerを使用します。このプロシージャをコールすると、ウィンドウ・グループは削除されますが、ウィンドウ・グループのメンバーであるウィンドウは削除されません。ウィンドウ・グループ自体は削除せずに、ウィンドウ・グループのメンバーであるウィンドウをすべて削除する場合は、DROP_WINDOWプロシージャを使用し、そのコールにウィンドウ・グループ名を指定します。
DROP_WINDOW_GROUPプロシージャ・コールにウィンドウ・グループ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウ・グループを削除できます。たとえば、次の文では3つのウィンドウ・グループが削除されます。
BEGIN DBMS_SCHEDULER.DROP_WINDOW_GROUP('windowgroup1, windowgroup2, windowgroup3'); END; /
ウィンドウ・グループの追加および削除の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ウィンドウ・グループにウィンドウを追加するには、ADD_WINDOW_GROUP_MEMBERプロシージャを使用します。
ウィンドウのカンマ区切りのリストを指定すると、1回のコールで複数のメンバーをウィンドウ・グループに追加できます。たとえば、次の文ではウィンドウ・グループwindow_group1に3つのウィンドウが追加されます。
BEGIN DBMS_SCHEDULER.ADD_WINDOW_GROUP_MEMBER ('window_group1', 'window1, window2, window3'); END; /
すでにオープンしているウィンドウがウィンドウ・グループに追加された場合、スケジューラは、ウィンドウ・グループ内の次のウィンドウがオープンするまで、このウィンドウ・グループを指し示すジョブを開始しません。
ADD_WINDOW_GROUP_MEMBERプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ウィンドウ・グループから1つ以上のウィンドウを削除するには、REMOVE_WINDOW_GROUP_MEMBERプロシージャまたはEnterprise Managerを使用します。stop_on_window_closeフラグが設定されているジョブが停止するのは、ウィンドウがクローズするときのみです。オープン中のウィンドウをウィンドウ・グループから削除しても、この処理への影響はありません。
ウィンドウのカンマ区切りのリストを指定すると、1回のコールで複数のメンバーをウィンドウ・グループから削除できます。たとえば、次の文では3つのウィンドウが削除されます。
BEGIN DBMS_SCHEDULER.REMOVE_WINDOW_GROUP_MEMBER('window_group1', 'window1, window2, window3'); END; /
REMOVE_WINDOW_GROUP_MEMBERプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
1つ以上のウィンドウ・グループを有効（使用可能）にするには、ENABLEプロシージャまたはEnterprise Managerを使用します。デフォルトでは、ウィンドウ・グループはENABLEDで作成されます。次に例を示します。
BEGIN DBMS_SCHEDULER.ENABLE('sys.windowgroup1', 'sys.windowgroup2, sys.windowgroup3'); END; /
ENABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ウィンドウ・グループを無効（使用禁止）にするには、DISABLEプロシージャまたはEnterprise Managerを使用します。ウィンドウ・グループを使用禁止にした場合、そのウィンドウ・グループをスケジュールとして設定しているジョブは、メンバーのウィンドウがオープンしても実行されません。ただし、ウィンドウ・グループのメタデータはそのままであるため、ウィンドウ・グループを再び使用可能にできます。ウィンドウ・グループのメンバーはオープンすることに注意してください。
DISABLEプロシージャ・コールにウィンドウ・グループ名のカンマ区切りのリストを指定することで、1回のコールで複数のウィンドウ・グループを使用禁止にすることもできます。たとえば、次の文では3つのウィンドウ・グループが使用禁止になります。
BEGIN DBMS_SCHEDULER.DISABLE('sys.windowgroup1, sys.windowgroup2, sys.windowgroup3'); END; /
この例では、ウィンドウ・グループは使用禁止になりますが、ウィンドウ・グループのメンバーであるウィンドウは使用禁止になりません。
DISABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
この項の内容は次のとおりです。
イベントは、なんらかの処理または発生が検出されたことを、アプリケーションまたはシステム・プロセスが別のアプリケーションまたはシステム・プロセスに示すために送信するメッセージです。イベントは、1つのアプリケーションまたはプロセスによって呼び出され（送信）、1つ以上のアプリケーションまたはプロセスによって使用されます（受信）。
スケジューラには、次の2種類のイベントがあります。
スケジューラは、スケジューラ自体で発生する状態の変更を示すためにイベントを呼び出します。たとえば、スケジューラは、ジョブの開始時、ジョブの完了時、ジョブがその割当ての実行時間を超えたときなどにイベントを呼び出します。イベントのコンシューマは、そのイベントに対応して処理を実行するアプリケーションです。
たとえば、システムの負荷が高いために、スケジュールされた開始時間から30分をすぎてもジョブが開始されない場合、スケジューラは、ハンドラのアプリケーションがデータベース管理者に電子メール通知を送信するイベントを呼び出すことができます。
アプリケーションは、スケジューラが使用するイベントを呼び出すことができます。スケジューラは、ジョブを開始することでこのイベントを処理します。スケジュールは、日付、時間、繰り返し発生する情報を定義するかわりに、イベントを参照するように作成できます。 このようなスケジュール（イベント・スケジュール）が割り当てられたジョブは、イベントが呼び出されると実行されます。
たとえば、在庫が一定のしきい値を下回ったことを感知した在庫追跡システムでは、在庫の補充ジョブを開始するイベントを呼び出すことができます。
スケジューラは、Oracle Streamsアドバンスト・キューイングを使用してイベントを呼び出して使用します。ジョブの状態の変更に関するイベントが発生すると、スケジューラは、メッセージをデフォルトのイベント・キューにエンキューします。アプリケーションは、このキューをサブスクライブし、イベント・メッセージをデキューして、適切な処理を行います。ジョブの開始をスケジューラに通知するイベントが発生すると、アプリケーションは、このジョブの設定時に指定したキューにメッセージをエンキューします。
ジョブの状態が変化したときに、スケジューラがイベントを呼び出すようにジョブを設定できます。このためには、raise_eventsジョブ属性を設定します。この属性はCREATE_JOBプロシージャでは設定できないため、最初にジョブを作成し、SET_ATTRIBUTEプロシージャを使用してそのジョブを変更します。
デフォルトでは、SET_ATTRIBUTEを使用してジョブを変更するまで、ジョブによって状態変化のイベントは呼び出されません。
表27-8に、スケジューラによって呼び出されるイベントに関する1つの管理タスクの要約を示します。
| タスク | プロシージャ | 必要な権限 |
|---|---|---|
|
|
|
ジョブに対するジョブの状態変化イベントを有効（使用可能）にすると、スケジューラは、メッセージをスケジューラ・イベント・キューSYS.SCHEDULER$_EVENT_QUEUEにエンキューすることによってこれらのイベントを呼び出します。このキューはセキュアなキューであるため、アプリケーションによっては、特定のユーザーがキューの操作を実行できるようにキューを構成する必要があります。セキュアなキューの詳細は、『Oracle Streams概要および管理』を参照してください。
スケジュール・イベント・キューが無制限に大きくならないように、スケジューラが呼び出したイベントは、デフォルトで24時間で期限切れになります（期限切れイベントはキューから削除されます）。この有効期限を変更するには、SET_SCHEDULER_ATTRIBUTEプロシージャを使用してevent_expiry_timeスケジューラ属性を設定します。 詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
ジョブに対するジョブの状態変化イベントを使用可能にするには、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; /
スケジューラ・イベントを使用するには、アプリケーションがスケジューラ・イベント・キューSYS.SCHEDULER$_EVENT_QUEUEをサブスクライブする必要があります。このキューはセキュアなキューであり、所有者はSYSです。あるユーザーについてこのキューのサブスクリプションを作成するには、次の処理を実行します。
SYSユーザーまたはMANAGE ANY QUEUE権限のあるユーザーでデータベースにログインします。
DBMS_AQADM.ENABLE_DB_ACCESSを次のように実行します。
DBMS_AQADM.ENABLE_DB_ACCESS(agent_name, db_username);
agent_nameは、イベント・キューのサブスクライブに使用したエージェントを表し、db_usernameは、サブスクリプションを作成する対象のユーザーです。
ユーザーにデキュー権限を付与する必要はありません。スケジューラ・イベント・キューに関するデキュー権限は、PUBLICに付与されます。
または、次の例に示すように、ユーザーがADD_EVENT_QUEUE_SUBSCRIBERプロシージャを使用してスケジューラ・イベント・キューをサブスクライブすることもできます。
DBMS_SCHEDULER.ADD_EVENT_QUEUE_SUBSCRIBER(subscriber_name);
この例のsubscriber_nameは、スケジューラ・イベント・キューのサブスクライブに使用されるOracle Streamsアドバンスト・キューイング（AQ）エージェントの名前です。（NULLの場合は、呼出しユーザーのユーザー名でエージェントが作成されます）。このコールによって、スケジューラ・イベント・キューのサブスクリプションが作成され、指定エージェントを使用してデキューする許可がユーザーに付与されます。サブスクリプションはルールベースです。ルールによって、ユーザーが許可されるのは、所有するジョブが呼び出したイベントの参照のみで、その他のメッセージはすべて除外されます。サブスクリプションが使用可能になると、ユーザーは一定の間隔でメッセージをポーリングするか、またはメッセージが通知されるようにAQに登録できます。
詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。
スケジューラ・イベント・キューSYS.SCHEDULER$_EVENT_QUEUEのタイプはscheduler$_event_infoです。次に、このタイプの詳細を示します。
create or replace type sys.scheduler$_event_info as object ( event_type VARCHAR2(4000), object_owner VARCHAR2(4000), object_name VARCHAR2(4000), event_timestamp TIMESTAMP WITH TIME ZONE, error_code NUMBER, error_msg VARCHAR2(4000), event_status NUMBER, log_id NUMBER, run_count NUMBER, failure_count NUMBER, retry_count NUMBER, spare1 NUMBER, spare2 NUMBER, spare3 VARCHAR2(4000), spare4 VARCHAR2(4000), spare5 TIMESTAMP WITH TIME ZONE, spare6 TIMESTAMP WITH TIME ZONE, spare7 RAW(2000), spare8 RAW(2000), );
アプリケーションで、ジョブを開始するようにスケジューラに通知するイベントを呼び出すことができます。この方法で開始されるジョブは、イベントベースのジョブと呼ばれます。オプションで、ジョブはイベントのメッセージ内容を取得できます。
イベントベースのジョブを作成するには、次の2つの追加属性を設定する必要があります。
queue_specキュー仕様。アプリケーションがジョブ開始イベントを呼び出すためのメッセージをエンキューするキューの名前が含まれます。または、セキュアなキューの場合はキュー名の後にコンマとエージェント名が記述されます。
event_conditionメッセージ・プロパティに基づく条件式。メッセージによってジョブが開始されるにはTRUEに評価される必要があります。式には、Oracle Streamsアドバンスト・キューイング・ルールの構文を使用する必要があります。したがって、メッセージ・ペイロードがオブジェクト・タイプであり、式内のオブジェクト属性にtab.user_dataの接頭辞を付けている場合は、式にユーザー・データ・プロパティを組み込むことができます。
ルールの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_AQADM.ADD_SUBSCRIBERプロシージャに関する説明を参照してください。
次の例では、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は、インラインのジョブ属性として指定するか、またはこれらの属性を指定したイベント・スケジュールを作成し、ジョブからこのスケジュールを指し示すことができます。
表27-9に、アプリケーションによって呼び出される（スケジューラによって使用される）イベントに関する一般的な管理タスクとそれに対応するプロシージャを示します。
イベントベースのジョブを作成するには、CREATE_JOBプロシージャまたはEnterprise Managerを使用します。ジョブには、ジョブ属性としてイベント情報をインラインで組み込むか、またはイベント・スケジュールを指し示してイベント情報を指定できます。
時間スケジュールに基づくジョブと同様に、イベントベースのジョブは、ジョブ終了日をすぎるか、max_runsまたは最大失敗回数（max_failures）に達するまでは自動削除されません。
イベント情報をジョブ属性として指定するには、CREATE_JOBの代替構文を使用して、queue_specおよびevent_condition属性を組み込みます。
次の例では、ファイルがサーバーに到着したことを示すシグナルがアプリケーションからスケジューラに送信されるときに開始されるジョブを作成しています。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'process_file_j1', program_name => 'process_file_p1', event_condition => 'tab.user_data.event_type = ''FILE_ARRIVAL''', queue_spec => 'file_events_q, file_agent1', enabled => TRUE, comments => 'Start job when a file arrives on the system'); END; /
CREATE_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
イベント情報をイベント・スケジュールで指定するには、ジョブのschedule_name属性にイベント・スケジュールの名前を設定する必要があります。次に例を示します。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'process_file_j1', program_name => 'process_file_p1', schedule_name => 'file_events_schedule', enabled => TRUE, comments => 'Start job when a file arrives on the system'); END; /
詳細は、「イベント・スケジュールの作成」を参照してください。
イベントベースのジョブを変更するには、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 = ''FILE_ARRIVAL''', 'file_events_q, file_agent1'); END; /
SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
イベントに基づいたスケジュールを作成できます。作成したスケジュールは、複数のジョブに再利用できます。そのためには、CREATE_EVENT_SCHEDULEプロシージャまたはEnterprise Managerを使用します。次に、イベント・スケジュールの作成例を示します。
BEGIN DBMS_SCHEDULER.CREATE_EVENT_SCHEDULE ( schedule_name => 'file_events_schedule', start_date => SYSTIMESTAMP, event_condition => 'tab.user_data.event_type = ''FILE_ARRIVAL''', queue_spec => 'file_events_q, file_agent1'); END; /
イベント・スケジュールを削除するには、DROP_SCHEDULEプロシージャを使用します。 CREATE_EVENT_SCHEDULEの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
イベント・スケジュールのイベント情報を変更する方法は、ジョブのイベント情報を変更する方法と同じです。 詳細は、「イベントベースのジョブの変更」を参照してください。
次の例は、イベント・スケジュールのイベント情報を変更するためのSET_ATTRIBUTEプロシージャおよびevent_spec属性の使用方法を示しています。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ('file_events_schedule', 'event_spec', 'tab.user_data.event_type = ''FILE_ARRIVAL''', 'file_events_q, file_agent1'); END; /
SET_ATTRIBUTEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
メタデータの引数を介して、スケジューラは、イベントベースのジョブに対して、ジョブを開始したイベントのメッセージ内容を渡すことができます。次の規則が適用されます。
STORED_PROCEDUREの名前付きプログラムを使用する必要があります。
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 ; /
チェーンは、結合した1つの目的のために互いにリンクされた一連の名前付きタスクです。 チェーンは、前の1つ以上のジョブの結果に応じて異なるジョブが開始される依存性ベースのスケジューリングを実装できる手段です。
チェーンを作成して使用するには、次のタスクを実行します。
| タスク | 参照先 |
|---|---|
|
1. チェーン・オブジェクトを作成します。 |
|
|
2. チェーン内のステップを定義します。 |
|
|
3. ルールを追加します。 |
|
|
4. チェーンを使用可能にします。 |
|
|
5. チェーンを指し示すジョブ（チェーン・ジョブ）を作成します。 |
この項で説明する他の内容は、次のとおりです。
表27-10に、チェーンに関する一般的なタスクとそれに対応するプロシージャを示します。
チェーンを作成するには、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内で定義されたルール・セットです。
|
関連項目:
|
チェーン・オブジェクトの作成後、1つ以上のチェーン・ステップを定義します。各ステップは、次のいずれかを指し示します。
プログラムまたはネストしたチェーンを指し示すステップを定義するには、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; /
名前付きプログラムまたはチェーンは、ステップを定義する時点では、存在していなくてもかまいません。 ただし、チェーンの実行時には存在して使用可能になっている必要があります。そうでない場合は、エラーが生成されます。
外部実行可能ファイルを実行するステップを定義した後、ALTER_CHAINプロシージャを使用して、そのステップの資格証明を設定する必要があります。 リモートの外部実行可能ファイルの場合は、ALTER_CHAINプロシージャを使用してステップの宛先も設定してください。
イベントの発生を待機するステップを定義するには、DEFINE_CHAIN_EVENT_STEPプロシージャを使用します。プロシージャの引数を使用して、イベント・スケジュールを指し示すか、またはインラインのキュー仕様およびイベント条件を組み込むことができます。この例では、名前付きイベント・スケジュール内に指定されているイベントを待機する、3番目のチェーン・ステップが作成されます。
BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_EVENT_STEP ( chain_name => 'my_chain1', step_name => 'my_step3', event_schedule_name => 'my_event_schedule'); END; /
データベース・リカバリ後、デフォルトでは、実行中だったステップがSTOPPEDとしてマークされ、チェーンが続行されます。 ALTER_CHAINを使用してチェーン・ステップのrestart_on_recovery属性をTRUEに設定すると、これらのステップをデータベース・リカバリ後に自動的に再開するように指定できます。
DEFINE_CHAIN_STEP、DEFINE_CHAIN_EVENT_STEPおよびALTER_CHAINプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
チェーンにルールを追加するには、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属性がSUCCEEDED、FAILEDまたはSTOPPEDのときにはTRUEです。
表27-11に、state属性に可能な値を示します。 これらの値は、*_SCHEDULER_RUNNING_CHAINSビューの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プロシージャに関する項を参照してください。
チェーン・ジョブの開始時にチェーンを開始できるように、少なくとも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のもう1つのコールを使用して、そのルールを再定義できます。 新しい定義により前の定義が上書きされます。
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; /
|
関連項目:
|
スケジューラでは、チェーン・ジョブの開始時と各チェーン・ステップの終了時に、すべてのチェーン・ルールが評価されます。 1時間に1回など、一定の時間間隔でもルールが評価されるようにチェーンを構成できます。 この機能は、時間に基づいて、またはチェーン外部での発生に基づいてチェーン・ステップを開始する必要がある場合に役立ちます。 次に例を示します。
TRUEになる時期を判別するために、ルールをその都度評価する必要があります。
TRUEになる時期を判別するために、ルールをその都度評価する必要があります。 この条件はSQL WHERE句構文を使用し、次のようになります。
':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; /
チェーンを有効（使用可能）にするには、ENABLEプロシージャを使用します。ジョブでチェーンを実行するには、チェーンを使用可能にする必要があります。すでに使用可能なチェーンを使用可能にしてもエラーは戻りません。
次の例では、チェーンmy_chain1が使用可能になります。
BEGIN DBMS_SCHEDULER.ENABLE ('my_chain1'); END; /
ENABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
チェーンを実行するには、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エントリを記録します。
関連項目:
チェーンをステップとルールも含めて削除するには、DROP_CHAINプロシージャを使用します。次に、チェーンを削除する例を示します。この例では、my_chain1が削除されます。
BEGIN DBMS_SCHEDULER.DROP_CHAIN ( chain_name => 'my_chain1', force => TRUE); END; /
DROP_CHAINプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
次の2つのプロシージャを使用して、チェーンを即時に実行できます。
すでにチェーン用のチェーン・ジョブを作成している場合は、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; /
チェーンからルールを削除するには、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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
チェーンを無効（使用禁止）にするには、DISABLEプロシージャを使用します。次に、my_chain1を使用禁止にする例を示します。
BEGIN DBMS_SCHEDULER.DISABLE ('my_chain1'); END; /
DISABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
チェーンからステップを削除するには、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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
実行中のチェーンを停止するには、DBMS_SCHEDULER.STOP_JOBをコールして、チェーン・ジョブ（チェーンを開始したジョブ）の名前を渡します。 チェーン・ジョブを停止すると、実行中のチェーンの全ステップが停止され、チェーンが終了します。
STOP_JOBプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
個々のチェーン・ステップを停止するには2つの方法があります。
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パッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
チェーン全体、またはチェーンの個別ブランチを一時停止できます。 そのためには、DBMS_SCHEDULER.ALTER_CHAINまたはALTER_RUNNING_CHAINを使用して、1つ以上のステップのPAUSE属性をTRUEに設定します。 チェーン・ステップを一時停止すると、チェーンの実行をそのステップの実行後に一時停止できます。
ステップを一時停止すると、そのステップの実行後にstate属性がPAUSEDに変わりますが、completed属性はFALSEのままです。 そのため、一時停止したステップの完了に依存しているステップは実行されません。 一時停止したステップのPAUSE属性をFALSEにリセットすると、state属性が完了状態（SUCCEEDED、FAILEDまたはSTOPPED）に設定され、一時停止したステップの完了を待機しているステップを実行できるようになります。
図27-3では、ステップ3が一時停止されています。 ステップ3の一時停止が解除されるまで、ステップ5は実行されません。 ステップ2のみを一時停止した場合、ステップ4、6および7は実行されません。 ただし、ステップ1、3および5は実行できます。 いずれの場合も、チェーンのブランチを1つのみ一時停止することになります。
チェーン全体を一時停止するには、チェーンのステップをすべて一時停止します。 チェーンの一時停止を解除するには、チェーン・ステップの1つ、多数またはすべての一時停止を解除します。 図27-3のチェーンでは、ステップ1を一時停止すると、ステップ1の実行後にチェーン全体も一時停止します。
チェーンの1つ以上のステップをスキップできます。 そのためには、DBMS_SCHEDULER.ALTER_CHAINまたはALTER_RUNNING_CHAINを使用して、1つ以上のステップのSKIP属性をTRUEに設定します。 ステップのSKIP属性がTRUEの場合、そのステップを実行するためのチェーン条件を満たすと、そのステップは実行されるかわりに、即時に成功した場合と同様に処理されます。 SKIPをTRUEに設定しても、実行中のステップ、遅延後に実行するようにスケジュールされているステップまたは実行済のステップには影響しません。
ステップのスキップが特に役立つのは、チェーンのテスト時です。 たとえば、図27-3に示したチェーンをテストする際に、ステップ7をスキップすると、このステップはネストしたチェーンであるため、テスト時間を大幅に短縮できます。
チェーンの一部のみを実行するには2つの方法があります。
ALTER_CHAINプロシージャを使用して1つ以上のステップのPAUSE属性をTRUEに設定し、RUN_JOBを使用してチェーン・ジョブを開始するか、またはRUN_CHAINを使用してチェーンを開始します。 一時停止したステップに依存するステップは実行されません （ただし、一時停止したステップは実行されます）。この方法のデメリットは、チェーンを将来実行する場合に備えて、影響を受けるステップのPAUSE属性の設定をFALSEに戻す必要があることです。
RUN_CHAINプロシージャを使用して、実行しないステップをスキップし、チェーンの特定ステップのみを開始します。この方法の方が簡単であり、ステップの開始前に初期状態を設定することもできます。
この2つの方法の両方を使用して、チェーンの開始時と終了時の両方でステップをスキップすることが必要な場合もあります。
詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のRUN_CHAINプロシージャの説明を参照してください。
次の2つのビューを使用して、実行中のチェーンのステータスを表示できます。
*_SCHEDULER_RUNNING_JOBSビューには、チェーン・ジョブに関する1行と実行中の各ステップに関する1行が含まれています。 *_SCHEDULER_RUNNING_CHAINSビューには、各チェーン・ステップ（ネストしたチェーンを含む）に関する1行と、各ステップの実行ステータス（NOT_STARTED、RUNNING、STOPPED、SUCCEEDEDなど）が含まれています。
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
ステップの完了時には、常にチェーン・ルールが評価され、次に実行するステップが判別されます。 いずれのルールでも別のステップが開始されず、チェーンが終了せず、チェーンの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を実行し、必要な処理をトリガーする必要があります。
個々のジョブ・レベルでリソース割当てを管理するのは実用的ではないため、スケジューラでは、ジョブ間のリソース割当ての管理にジョブ・クラスの概念が使用されます。ジョブ・クラスの他に、リソース・マネージャも使用されます。
データベース・リソース・マネージャは、データベース・セッション間のリソース割当て方法を制御します。ジョブなどの非同期セッションのみでなく、ユーザー・セッションなどの同期セッションも制御します。データベース内のすべての作業単位をリソース・コンシューマ・グループにグループ化し、リソース・プランを使用して、様々なグループ間のリソース割当て方法を指定します。リソース・マネージャで制御されるリソースの種類の詳細は、第25章「Oracle Database Resource Managerを使用したリソース割当ての管理」を参照してください。
ジョブに対するリソース割当ては、ジョブ・クラスをコンシューマ・グループと関連付けるか、またはジョブ・クラスをデータベース・サービス名と関連付け、そのデータベース・サービスをコンシューマ・グループにマッピングすることによって指定します。ジョブ・クラスのマッピング先となるコンシューマ・グループは、ジョブ・クラスの作成時に指定できます。ジョブ・クラスの作成時にリソース・コンシューマ・グループまたはデータベース・サービス名が指定されていない場合、ジョブ・クラスはデフォルトのコンシューマ・グループにマッピングされます。ジョブ・クラスのresource_consumer_group属性とservice属性が設定されているときに、指定のサービスがリソース・コンシューマ・グループにマップされた場合は、resource_consumer_group属性に指定されているリソース・コンシューマ・グループが優先されます。
スケジューラは、完了に必要なリソースを確保できないまま同時に多数のジョブを実行するかわりに、少なくとも一部のジョブを完了できるように、同時に実行するジョブの数を制限しようとします。
スケジューラとリソース・マネージャは緊密に統合されています。ジョブ・コーディネータは、データベース・リソースの可用性をリソース・マネージャから取得します。この情報に基づいて、コーディネータは開始するジョブの数を判断します。実行するための十分なリソースがあるジョブ・クラスのジョブのみを開始します。コーディネータは、コンシューマ・グループにマッピングされている特定ジョブ・クラス内のジョブを開始し続けます。これは、そのコンシューマ・グループに割り当てられているリソースが最大に達したとリソース・マネージャが判断するまで続きます。つまり、実行準備が整っていても、実行に必要なリソースがないためにジョブ・コーディネータによって取り出されないジョブがジョブ表内に存在する可能性があります。したがって、スケジュールされた正確な時間にジョブが実行されることは保証されません。コーディネータは、どのコンシューマ・グループに使用可能なリソースがまだあるかを基準にして、ジョブ表からジョブを取り出します。
ジョブが実行中の場合も、リソース・マネージャは、指定したリソース・プランに基づいて実行中の各ジョブに割り当てられたリソースの管理を続けます。リソース・マネージャが管理できるのはデータベースのプロセスのみであることに注意してください。リソースのアクティブな管理は、外部ジョブには適用されません。
1つのデータベースで一度に有効にできるリソース・プランは1つのみです。DBMS_RESOURCE_MANAGER.SWITCH_PLANプロシージャを使用すると、システム上のアクティブなリソース・プランを手動で切り替えることができます。特別な場合は、特定のリソース・プランを実行し、ウィンドウのオープンによるリソース・プランの切替えを無効にすることもできます。そのためには、allow_scheduler_plan_switchesをFALSEに設定してDBMS_RESOURCE_MANAGER.SWITCH_PLANプロシージャを使用します。スケジューラのウィンドウには、リソース・プラン属性を指定できることにも注意してください。指定したリソース・プランは、ウィンドウのオープン中はアクティブな状態です。
次の例では、ジョブに対するリソースの割当て方法について説明します。「夜間プラン」というアクティブなリソース・プランがあり、3つのジョブ・クラスがあるとします。JC1はコンシューマ・グループDWに、JC2はコンシューマ・グループOLTPに、JC3はデフォルトのコンシューマ・グループにそれぞれマッピングされています。図27-4に、この例を簡単な図で示します。
このリソース・プランでは、ジョブ・クラスJC1に属するジョブが明らかに優先されます。コンシューマ・グループDWはリソースを60%取得するため、ジョブ・クラスJC1に属するジョブはリソースを60%取得します。コンシューマ・グループOLTPはリソースを30%取得するため、ジョブ・クラスJC2内のジョブはリソースを30%取得します。コンシューマ・グループOtherでは、他のすべてのコンシューマ・グループがリソースを10%取得することが指定されます。つまり、ジョブ・クラスJC3に属するすべてのジョブが、10%のリソースを共有し、リソースを最大10%取得できます。
あるコンシューマ・グループで未使用のリソースは、他のコンシューマ・グループで使用できます。したがって、ジョブ・クラスJC1のジョブが割当ての60%を完全に使用していない場合、その未使用部分はクラスJC2とJC3のジョブが使用できます。リソース・マネージャは、CPU使用が100%に達するまで、リソース使用の制限を開始しません。 詳細は、第25章「Oracle Database Resource Managerを使用したリソース割当ての管理」を参照してください。
