Oracle Database 管理者ガイド 11gリリース1(11.1) E05760-03 |
|
この章の内容は次のとおりです。
Oracle Scheduler(スケジューラ)を構成するときは、次のタスクを実行する必要があります。
スケジューラを管理するには、SCHEDULER_ADMIN
ロールが必要です。通常、データベース管理者(DBA)は、DBA
ロール(またはそれと等価のロール)の一部として、ADMIN
オプション付きでこのロールをすでに持っています。このロールは、次の文を発行して別の管理者に付与できます。
GRANT SCHEDULER_ADMIN TO username;
SCHEDULER_ADMIN
ロールは、権限を付与されたユーザーがコードを任意のユーザーとして実行できる強力なロールであるため、かわりにスケジューラの個々のシステム権限を付与することを考慮してください。オブジェクト権限とシステム権限は、標準的なSQL権限付与構文を使用して付与されます。例として、データベース管理者が次の文を発行したとします。
GRANT CREATE JOB TO scott;
この文が実行されると、scott
は、自分のスキーマ内にジョブ、スケジュールまたはプログラムを作成できます。別の例として、データベース管理者が次の文を発行したとします。
GRANT MANAGE SCHEDULER TO adam;
この文が実行されると、adam
は、ウィンドウ、ジョブ・クラスまたはウィンドウ・グループを、作成、変更または削除できます。また、スケジューラ属性の設定と検索、およびスケジューラ・ログのパージもできます。
スケジューラ・チェーンでは、基礎となるOracle Streamsルール・エンジン・オブジェクトと、それに関連する権限を使用します。ユーザーが自分のスキーマにチェーンを作成するには、自分のスキーマにルール、ルール・セットおよび評価コンテキストを作成するためのルール・エンジン権限に加え、CREATE
JOB
権限が必要です。これらの権限は、次の文を発行することで付与できます。
BEGIN DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE(DBMS_RULE_ADM.CREATE_RULE_OBJ, 'username'), DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE ( DBMS_RULE_ADM.CREATE_RULE_SET_OBJ, 'username'), DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE ( DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT_OBJ, 'username') END; /
ユーザーが、別のスキーマにチェーンを作成するには、自分のスキーマ以外のスキーマにルール、ルール・セットおよび評価コンテキストを作成するためのルール・エンジン権限に加え、CREATE
ANY
JOB
権限が必要です。これらの権限は、次の文を発行することで付与できます。
BEGIN DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE(DBMS_RULE_ADM.CREATE_ANY_RULE, 'username'), DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE ( DBMS_RULE_ADM.CREATE_ANY_RULE_SET, 'username'), DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE ( DBMS_RULE_ADM.CREATE_ANY_EVALUATION_CONTEXT, 'username') END; /
各自のスキーマ以外のスキーマのチェーンを変更または削除するには、ルール、ルール・セットおよび評価コンテキストについて、対応する各システムのルール・エンジン権限が必要です。Streamsルール・エンジン権限の詳細は、DBMS_RULE_ADM.GRANT_OBJECT_PRIVILEGE
の使用方法の説明を参照してください。
この項では、次のタスクについて説明します。
ジョブ・クラスを作成するには、CREATE_JOB_CLASS
プロシージャを使用します。次の文は、ジョブ・クラスの作成例です。
BEGIN DBMS_SCHEDULER.CREATE_JOB_CLASS ( job_class_name => 'my_jobclass1', resource_consumer_group => 'my_res_group1', comments => 'This is my first job class.'); END; /
この文では、属性としてリソース・コンシューマ・グループmy_res_group1
などが設定されたmy_jobclass1
というジョブ・クラスが作成されます。ジョブ・クラスの内容を確認するには、次の文を発行します。
SELECT * FROM DBA_SCHEDULER_JOB_CLASSES;
JOB_CLASS_NAME RESOURCE_CONSU SERVICE LOGGING_LEV LOG_HISTORY COMMENTS
----------------- -------------- ------- ----------- ----------- --------
DEFAULT_JOB_CLASS RUNS The default
AUTO_TASKS_JOB_CLASS AUTO_TASK_CON RUNS System maintenance
FINANCE_JOBS FINANCE_GROUP RUNS
MY_JOBCLASS1 MY_RES_GROUP1 RUNS My first job class
MY_CLASS1 my_service1 RUNS My second job class
5 rows selected.
ジョブ・クラスはSYS
スキーマ内に作成されることに注意してください。
関連項目:
|
ウィンドウを作成するには、CREATE_WINDOW
プロシージャを使用します。次の文は、ウィンドウの作成例です。
BEGIN DBMS_SCHEDULER.CREATE_WINDOW ( window_name => 'my_window1', resource_plan => 'my_resourceplan1', start_date => '15-APR-03 01.00.00 AM Europe/Lisbon', repeat_interval => 'FREQ=DAILY', end_date => '15-SEP-04 01.00.00 AM Europe/Lisbon', duration => interval '50' minute, window_priority => 'HIGH', comments => 'This is my first window.'); END; /
ウィンドウが正しく作成されたことを検証するには、DBA_SCHEDULER_WINDOWS
ビューを問い合せます。次に、文の発行例を示します。
SELECT WINDOW_NAME, RESOURCE_PLAN, DURATION, REPEAT_INTERVAL FROM DBA_SCHEDULER_WINDOWS; WINDOW_NAME RESOURCE_PLAN DURATION REPEAT_INTERVAL ----------- ------------- ------------- --------------- MY_WINDOW1 MY_RESOURCEPLAN1 +000 00:50:00 FREQ=DAILY
関連項目:
|
リソース・プランを作成するには、CREATE_SIMPLE_PLAN
プロシージャを使用します。このプロシージャでは、文を1回実行するだけで、コンシューマ・グループを作成し、それらにリソースを割り当てることができます。
次の文は、このプロシージャを使用して、my_simple_plan1
というリソース・プランを作成する例を示しています。
BEGIN DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN ( simple_plan => 'my_simple_plan1', consumer_group1 => 'my_group1', group1_cpu => 80, consumer_group2 => 'my_group2', group2_cpu => 20); END; /
この文では、my_simple_plan1
というリソース・プランが作成されます。リソース・プランの内容を確認するには、DBA_RSRC_PLANS
ビューを問い合せます。次に例を示します。
SELECT PLAN, STATUS FROM DBA_RSRC_PLANS; PLAN STATUS ------------------------------ -------------------------- SYSTEM_PLAN ACTIVE INTERNAL_QUIESCE ACTIVE INTERNAL_PLAN ACTIVE MY_SIMPLE_PLAN1 ACTIVE
ウィンドウ・グループを作成するには、CREATE_WINDOW_GROUP
およびADD_WINDOW_GROUP_MEMBER
プロシージャを使用します。次の文は、これらのプロシージャの使用例です。
BEGIN DBMS_SCHEDULER.CREATE_WINDOW_GROUP ( group_name => 'my_window_group1', comments => 'This is my first window group.'); DBMS_SCHEDULER.ADD_WINDOW_GROUP_MEMBER ( group_name => 'my_window_group1', window_list => 'my_window1, my_window2'); DBMS_SCHEDULER.ADD_WINDOW_GROUP_MEMBER ( group_name => 'my_window_group1', window_list => 'my_window3'); END; /
この文では、my_window2
とmy_window3
はすでに作成済であると想定されています。ウィンドウを作成するには、CREATE_WINDOW
プロシージャを使用します。
これらの文では、my_window_group1
というウィンドウ・グループが作成された後、そのウィンドウ・グループにmy_window1
、my_window2
およびmy_window3
が追加されます。ウィンドウ・グループの内容を確認するには、次の文を発行します。
SELECT * FROM DBA_SCHEDULER_WINDOW_GROUPS; WINDOW_GROUP_NAME ENABLED NUMBER_OF_WINDOWS COMMENTS ----------------- ------- ----------------- -------------------- MY_WINDOW_GROUP1 TRUE 3 This is my first window group. SELECT * FROM DBA_SCHEDULER_WINGROUP_MEMBERS; WINDOW_GROUP_NAME WINDOW_NAME ------------------------------ --------------- MY_WINDOW_GROUP1 MY_WINDOW1 MY_WINDOW_GROUP1 MY_WINDOW2 MY_WINDOW_GROUP1 MY_WINDOW3
関連項目:
|
スケジューラの動作を制御するスケジューラ属性がいくつかあります。それらは、default_timezone
、log_history
、max_job_slave_processes
およびevent_expiry_time
です。これらの属性の値は、SET_SCHEDULER_ATTRIBUTE
プロシージャを使用して設定できます。これらの属性を設定するには、MANAGE
SCHEDULER
権限が必要です。設定可能な属性は、次のとおりです。
default_timezone
カレンダ指定構文を使用したジョブとウィンドウの繰返しの場合は、それぞれの繰返し間隔で使用されるタイム・ゾーンを認識している必要があります。タイム・ゾーンは、通常start_date
から取得されます。ただし、start_date
が設定されていない場合(通常の状態)、タイム・ゾーンはdefault_timezone
スケジューラ属性から取得されます。
スケジューラは、default_timezone
の値をオペレーティング・システム環境から導出します。オペレーティング・システムから互換性のある値を検出できない場合、スケジューラはdefault_timezone
をNULL
に設定します。
default_timezone
が正しく設定されているかどうかの確認は非常に重要です。正しく設定されていない場合は、設定する必要があります。確認には、次の問合せを実行します。
SQL> select dbms_scheduler.stime from dual; STIME --------------------------------------------------------------------------- 14-OCT-04 02.56.03.206273000 PM US/PACIFIC
確実に夏時間が適用されるようにするには、default_timezone
を、絶対タイム・ゾーン・オフセットではなく、リージョン名に設定することをお薦めします。たとえば、データベースが米国フロリダ州のマイアミにある場合は、次の文を発行します。
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('default_timezone','US/Eastern');
有効なリージョン名のリストを表示するには、次の問合せを実行します。
SELECT DISTINCT TZNAME FROM V$TIMEZONE_NAMES;
default_timezone
属性を適切に設定しないと、繰返しジョブや繰返しウィンドウに使用されるデフォルトのタイム・ゾーンは、SYSTIMESTAMP
から取り出される絶対オフセット(データベースのオペレーティング・システム環境のタイム・ゾーン)となります。これは、start_date
が設定されていない繰返しジョブや繰返しウィンドウでは、夏時間調整が適用されないことになります。
log_history
この属性を使用すると、スケジューラが実行するロギングの量を制御できます。ジョブ・ログおよびウィンドウ・ログが無計画に大きくならないように、スケジューラには、保持する履歴の量(日数)を指定する属性があります。1日に1回、スケジューラは、指定した履歴より古いすべてのログ・エントリをジョブ・ログとウィンドウ・ログから自動的にパージします。デフォルト値は30日です。
デフォルト値を変更するには、SET_SCHEDULER_ATTRIBUTE
プロシージャを使用します。たとえば、90日に変更する場合は、次の文を発行します。
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('log_history','90');
有効値の範囲は1〜999です。
max_job_slave_processes
この属性を使用すると、特定のシステム構成と負荷に対する最大スレーブ・プロセス数を設定できます。スケジューラは、所定のシステム構成と負荷に対する最適なスレーブ・プロセス数を自動的に判別しますが、スケジューラに固定の制限を設定することもできます。制限を設定する場合に、この属性を設定できます。デフォルト値はNULL
で、有効値の範囲は1〜999です。
max_job_slave_processes
によって設定された数が実際の最大数ですが、指定された数のスレーブをスケジューラが開始するという意味ではありません。たとえば、この属性が10に設定されている場合でも、スケジューラは4個以上のスレーブ・プロセスを開始しない方がよいと判断する場合があります。ただし、スケジューラが15個のスレーブ・プロセスの開始を計画している場合に、最大数が10に設定されていると、11個以上のプロセスは開始しません。
event_expiry_time
この属性を使用すると、スケジューラが生成したイベントが終了する(つまり、自動的にキューからパージされる)までの時間(秒)を設定できます。
SET_SCHEDULER_ATTRIBUTE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
次の項では、スケジューラを監視および管理する方法について説明します。
現在アクティブなウィンドウとそのウィンドウに関連付けられているプランを表示するには、次の文を発行します。
SELECT WINDOW_NAME, RESOURCE_PLAN FROM DBA_SCHEDULER_WINDOWS WHERE ACTIVE='TRUE'; WINDOW_NAME RESOURCE_PLAN ------------------------------ -------------------------- MY_WINDOW10 MY_RESOURCEPLAN1
アクティブなウィンドウがない場合は、次の文を発行するとアクティブなリソース・プランを表示できます。
SELECT * FROM V$RSRC_PLAN;
ジョブの状態を確認するには、次の文を発行します。
SELECT JOB_NAME, STATE FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME = 'MY_EMP_JOB1'; JOB_NAME STATE ------------------------------ --------- MY_EMP_JOB1 DISABLED
この場合は、ENABLE
プロシージャを使用してジョブを使用可能にできます。表28-1に、ジョブの状態に関する有効値を示します。
現在実行中のジョブの進行状況を確認するには、次の文を発行します。
SELECT * FROM ALL_SCHEDULER_RUNNING_JOBS;
CPU_USED
列に有効なデータを表示するには、RESOURCE_LIMIT
初期化パラメータをtrue
に設定する必要があります。
実行中のチェーンの一部のジョブに関する情報を得るには、次の文を発行します。
SELECT * FROM ALL_SCHEDULER_RUNNING_CHAINS WHERE JOB_NAME='MY_JOB1';
cjqNNN
の形式のプロセスを検索すると、ジョブ・コーディネータが実行中かどうかをチェックできます。
スケジューラは、ジョブ・ログとウィンドウ・ログという2種類のログをサポートしています。
ジョブの実行、ジョブ・ステータスの変化およびジョブの失敗について、ジョブ・ログ内の情報を表示できます。 ジョブ・ログは、次の2つのデータ・ディクショナリ・ビューとして実装されます。
スケジューラがジョブに関して実行するロギングの量は、ジョブ・クラス・レベルと個別ジョブ・レベルの両方で制御できます。 通常、クラス内のジョブに関するロギングを厳密に制御できるため、ロギングをクラス・レベルで制御します。
各種ロギング・レベルの定義と、ジョブとジョブ・クラスの間のロギング・レベルの優先度については、「ジョブ・ログの表示」を参照してください。 デフォルトでは、ジョブ・クラスのロギング・レベルはLOGGING_RUNS
で、すべてのジョブの実行がログに記録されます。
ジョブ・クラスの作成時にlogging_level
属性を設定するか、後でSET_ATTRIBUTE
プロシージャを使用してロギング・レベルを変更できます。 次の例では、myclass1
ジョブ・クラス内のジョブのロギング・レベルをLOGGING_FAILED_RUNS
に設定しています。これは、異常終了した実行のみがログに記録されることを意味します。 すべてのジョブ・クラスはSYS
スキーマ内に作成されることに注意してください。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ( 'sys.myclass1', 'logging_level', DBMS_SCHEDULER.LOGGING_FAILED_RUNS); END;
ジョブ・クラスのロギング・レベルを設定するには、MANAGE
SCHEDULER
権限が付与されている必要があります。
関連項目:
|
スケジューラでは、次の操作が実行されるたびにウィンドウ・ログにエントリが1つ記録されます。
ウィンドウ・アクティビティのロギングには、ロギング・レベルはありません。
ウィンドウ・ログの内容を調べるには、DBA_SCHEDULER_WINDOW_LOG
ビューを問い合せます。次の文は、このビューの出力例を示しています。
SELECT log_id, to_char(log_date, 'DD-MON-YY HH24:MM:SS') timestamp, window_name, operation FROM DBA_SCHEDULER_WINDOW_LOG; LOG_ID TIMESTAMP WINDOW_NAME OPERATION ---------- -------------------- ----------------- -------- 4 10/01/2004 15:29:23 WEEKEND_WINDOW CREATE 5 10/01/2004 15:33:01 WEEKEND_WINDOW UPDATE 22 10/06/2004 22:02:48 WEEKNIGHT_WINDOW OPEN 25 10/07/2004 06:59:37 WEEKNIGHT_WINDOW CLOSE 26 10/07/2004 22:01:37 WEEKNIGHT_WINDOW OPEN 29 10/08/2004 06:59:51 WEEKNIGHT_WINDOW CLOSE
DBA_SCHEDULER_WINDOWS_DETAILS
ビューは、以前はアクティブで現在はクローズ(完了)されているすべてのウィンドウに関する情報を提供します。次の文は、このビューの出力例を示しています。
SELECT LOG_ID, WINDOW_NAME, ACTUAL_START_DATE, ACTUAL_DURATION FROM DBA_SCHEDULER_WINDOW_DETAILS; LOG_ID WINDOW_NAME ACTUAL_START_DATE ACTUAL_DURATION ---------- ---------------- ------------------------------------ --------------- 25 WEEKNIGHT_WINDOW 06-OCT-04 10:02.48.832438 PM PST8PDT +000 01:02:32 29 WEEKNIGHT_WINDOW 07-OCT-04 10.01.37.025704 PM PST8PDT +000 03:02:00
これらのビューの両方でログIDが対応しており、この例では、DBA_SCHEDULER_WINDOWS_DETAILS
ビューの行がDBA_SCHEDULER_WINDOW_LOG
ビューのCLOSE
操作に対応しています。
ジョブ・ログおよびウィンドウ・ログが無計画に大きくならないように、SET_SCHEDULER_ATTRIBUTE
プロシージャを使用して、保持する履歴の量(日数)を指定します。1日に1回、スケジューラは、指定した履歴期間より古いすべてのログ・エントリをジョブ・ログとウィンドウ・ログから自動的にパージします。デフォルトの履歴期間は30日です。たとえば、履歴期間を90日に変更する場合は、次の文を発行します。
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('log_history','90');
一部のジョブ・クラスは他のジョブ・クラスより重要です。そのため、このグローバルな履歴設定は、クラス別の設定を使用して上書きできます。例として、3つのジョブ・クラス(class1
、class2
およびclass3
)があるとします。ウィンドウ・ログおよびclass1
とclass3
については履歴を10日間保持し、class2
については30日間保持するとします。このように設定するには、次の文を発行します。
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('log_history','10'); DBMS_SCHEDULER.SET_ATTRIBUTE('class2','log_history','30');
ジョブ・クラスの作成時には、クラス別の履歴を設定することもできます。
チェーン実行のステップに関連したログ・エントリは、メインのチェーン・ジョブのエントリがパージされるまでパージされません。
PURGE_LOG
プロシージャを使用して、ログを手動でパージできます。例として、ジョブ・ログとウィンドウ・ログの両方からすべてのエントリをパージする文を示します。
DBMS_SCHEDULER.PURGE_LOG();
別の例として、3日前より古いすべてのエントリをジョブ・ログからパージする文を示します。ウィンドウ・ログはこの文の影響を受けません。
DBMS_SCHEDULER.PURGE_LOG(log_history => 3, which_log => 'JOB_LOG');
次の文では、10日前より古いすべてのウィンドウ・ログ・エントリと、job1
およびclass2
内のジョブに関連する10日前より古いすべてのジョブ・ログ・エントリがパージされます。
DBMS_SCHEDULER.PURGE_LOG(log_history => 10, job_name => 'job1, sys.class2');
ジョブの優先度を変更するには、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
ジョブのスケジュールと実行にスケジューラを使用する必要がある通常のユーザーに対しては、CREATE
JOB
システム権限を付与してください。システム・リソースを管理する必要があるデータベース管理者には、MANAGE
SCHEDULER
を付与してください。スケジューラに関するその他のシステム権限またはロールを付与するときは、十分に注意してください。特に、CREATE
ANY
JOB
システム権限と、この権限が含まれるSCHEDULER_ADMIN
ロールは、コードを任意のユーザーで実行できるため、非常に強力です。これらの権限とロールの付与は、非常に強力な権限を持つロールまたはユーザーに限定してください。
セキュリティに関して特に重要な問題は、外部ジョブの処理です。外部ジョブの処理は、データベース外でジョブを実行する必要があるユーザーにのみ実行を許可してください。それらのユーザーには、CREATE EXTERNAL JOB
システム権限を付与する必要があります。 詳細は、「外部ジョブの作成」を参照してください。スケジューラに関するセキュリティには、他に特別な要件はありません。 セキュリティの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
Oracle Scheduler(スケジューラ)では、リモート・ホストで外部ジョブをスケジュールし、実行できます。リモート・ホストにOracleデータベースがインストールされている必要はありませんが、スケジューラ・エージェントはインストールされている必要があります。これによって、スケジューリングするデータベースは、リモート・ホストでリモート外部ジョブを開始し、ジョブの出力とエラー情報を取得できます。 エージェントは、そのエージェントのホスト・コンピュータでリモート外部ジョブを開始する必要のあるすべてのデータベースに登録する必要があります。 リモート外部ジョブを実行する必要のある各データベースには、初期設定も必要です。この設定によって、データベースとリモートのスケジューラ・エージェント間でのセキュアな通信が可能になります。
リモート外部ジョブの有効化には、次の手順が含まれます。
この項では、次の内容も説明します。
データベースでリモートのスケジューラ・エージェントを使用してジョブを実行するには、その前に、データベースを正しく構成し、そのエージェントをデータベースに登録しておく必要があります。 リモートのスケジューラ・エージェントをセキュアに登録するには、エージェントの登録パスワードをデータベースに設定する必要があります。登録できるスケジューラ・エージェントの数を制限して、パスワードの有効期限を設定できます。
リモート外部ジョブを実行する必要のある各データベースに対して、次の手順を1回実行します。
リモート外部ジョブを実行するためのデータベースの設定手順
SYS
ユーザーとしてデータベースに接続します。手順については、「SQL*Plusを使用したデータベースへの接続」を参照してください。
SQL> DESC RESOURCE_VIEW
XML DBがインストールされていない場合は、このコマンドで「オブジェクトが存在しません。」エラーが戻ります。
BEGIN DBMS_XDB.SETHTTPPORT(port); END;
port
は、データベースがHTTP接続をリスニングするTCPポート番号です。
port
には1〜65536の整数を指定する必要があります。UNIXおよびLinuxの場合は、1023より大きい値にする必要があります。まだ使用されていないポート番号を選択してください。
prvtrsch.plb
を実行します。
SQL> @?/rdbms/admin/prvtrsch.plb
SET_AGENT_REGISTRATION_PASS
プロシージャを使用して、スケジューラ・エージェントの登録パスワードを設定します。次の例では、エージェント登録パスワードをmypassword
に設定します。
BEGIN DBMS_SCHEDULER.SET_AGENT_REGISTRATION_PASS('mypassword'); END;
特定のホストでリモート外部ジョブを実行するには、その前に、そのホスト上にスケジューラ・エージェントをインストールし、構成して起動しておく必要があります。スケジューラ・エージェントは、独自のOracleホームにインストールする必要があります。
Windows、LinuxおよびUNIXプラットフォームの場合、スケジューラ・エージェント・ソフトウェアはOracle Databaseゲートウェイのインストール・メディア(Databaseのインストール・メディア)に収録されており、次のサイトからオンラインで入手することもできます。
http://www.oracle.com/technology/software/products/database
IBM z/OSおよびIBM iSeries OS/400など、他のプラットフォーム用のエージェント・ソフトウェアは、該当するプラットフォーム用のOracle Scheduler Agentのインストール・メディアに収録されています。 これらのプラットフォーム上でエージェントをインストールするには、プラットフォーム固有のマニュアルを参照してください。
リモートのWindows、LinuxまたはUNIXホストでのスケジューラ・エージェントのインストール、構成および起動の手順は、次のとおりです。
directory_path
は、Oracle Databaseゲートウェイ製品のインストール・メディアへのパスです。
root.sh
の実行を求めるプロンプトを表示したら、root
ユーザーとして次のコマンドを入力します。
script_path/root.sh
このスクリプトは、エージェントのインストール用に選択したディレクトリに格納されています。
schagent.conf
のPORT=
ディレクティブのポート番号を確認します。このポート番号はリモート外部ジョブの作成時に必要になります。必要に応じて、他のエージェント構成パラメータを変更します。
AGENT_HOME/bin/schagent -registerdatabase db_host db_http_port
各項目の意味は次のとおりです。
db_host
は、データベースがあるホストのホスト名またはIPアドレスです。
db_http_port
は、データベースがリスニングするポート番号です(HTTP接続用)。 このパラメータは以前に「リモート外部ジョブを実行するためのデータベースの設定」で設定しました。次のSQL文をデータベースに発行することにより、ポート番号を確認できます。
SELECT DBMS_XDB.GETHTTPPORT() FROM DUAL;
ポート番号が0のときは、HTTP接続が無効になっています。
「リモート外部ジョブを実行するためのデータベースの設定」で設定したエージェント登録パスワードの入力を求めるプロンプトがエージェントによって表示されます。
AGENT_HOME/bin/schagent -start
スケジューラ・エージェントを停止すると、スケジューラ・エージェントがあるホストでリモート外部ジョブを実行できなくなります。
スケジューラ・エージェントを停止する手順は、次のとおりです。
データベースでリモート外部ジョブを実行する機能は、REMOTE_SCHEDULER_AGENT
ユーザーを削除することで、無効(使用禁止)にできます。
リモート外部ジョブを無効にする手順は、次のとおりです。
新規スケジューラ・エージェントの登録とリモート外部ジョブの実行は、prvtrsch.plb
を再度実行するまで無効(使用禁止)です。
スケジューラ・オブジェクトをエクスポートするには、データ・ポンプ・ユーティリティ(impdp
およびexpdp
)を使用します。スケジューラでは、以前のインポートおよびエクスポート・ユーティリティ(IMP
およびEXP
)は使用できません。また、スケジューラ・オブジェクトは、データベースが読取り専用モードの間はエクスポートできません。
エクスポートでは、スケジューラ・オブジェクトの作成に使用されたDDLが生成されます。すべての属性がエクスポートされます。インポートが実行されると、すべてのデータベース・オブジェクトが新規データベースに再作成されます。すべてのスケジュールは、それぞれのタイム・ゾーンで格納され、新規データベース内で保持されます。たとえば、「サンフランシスコにあるデータベースの月曜日午後1時(太平洋沿岸標準時)」というスケジュールは、エクスポートされドイツでデータベースにインポートされた場合でも同じです。
スケジューラの資格証明はエクスポートされますが、セキュリティ上の理由で、これらの資格証明のパスワードはエクスポートされません。スケジューラの資格証明をインポートした後は、DBMS_SCHEDULER
パッケージのSET_ATTRIBUTE
プロシージャを使用してパスワードを再設定する必要があります。
ここでは、トラブルシューティングに関する情報を提供します。この項の内容は、次のとおりです。
ジョブはいくつかの理由で実行に失敗する場合があります。実行されなかった可能性のあるジョブのトラブルシューティングを行う前に、次の文を発行し、ジョブが実行されていないことを確認してください。
SELECT JOB_NAME, STATE FROM DBA_SCHEDULER_JOBS;
標準的な出力は次のようになります。
JOB_NAME STATE ------------------------------ --------- MY_EMP_JOB DISABLED MY_EMP_JOB1 FAILED MY_NEW_JOB1 DISABLED MY_NEW_JOB2 BROKEN MY_NEW_JOB3 COMPLETED
実行中でないジョブには次の4つのタイプがあります。
ジョブ表内のジョブのステータスがFAILED
の場合、そのジョブは実行がスケジュールされたが実行に失敗したことを示します。ジョブが再起動可能として指定されていた場合は、すべての再試行に失敗しています。
実行の途中でジョブが失敗すると、最後のトランザクションのみがロールバックされます。複数のトランザクションを実行するジョブの場合は、restartable
をTRUE
に設定するときに注意する必要があります。失敗したジョブを問い合せるには、*_SCHEDULER_JOB_RUN_DETAILS
ビューを問い合せます。
中断されたジョブとは、特定の失敗数を超えたジョブです。この数はmax_failures
で設定され、変更できます。中断されたジョブは、ジョブ全体が中断されており、修正されるまで実行されません。デバッグとテストには、RUN_JOB
プロシージャを使用できます。
中断されたジョブを問い合せるには、*_SCHEDULER_JOBS
および*_SCHEDULER_JOB_LOG
ビューを問い合せます。
ジョブは次の理由で使用禁止になる場合があります。
ジョブは、end_date
またはmax_runs
に達すると完了します。(最近正常に完了したジョブが再度実行するようにスケジュールされると、ジョブの状態はSCHEDULED
になります。)
スケジューラは、次の場合に中断されたジョブのリカバリを試行します。
extjob
です。Windowsでは外部ジョブ・サービスです。)
ジョブ・リカバリは次のように実行されます。
OPERATION
はRUN
、STATUS
はSTOPPED
になっており、ADDITIONAL_INFO
には次のいずれかが挿入されます。
restartable
がTRUE
に設定されている場合は、ジョブが再開されます。
restartable
がFALSE
に設定されている場合は、次のようになります。
このリカバリ・プロセスの結果、ジョブが再開されると、新規実行はRECOVERY_RUN
操作としてジョブ・ログに記録されます。
プログラムは、プログラム引数が削除された場合やnumber_of_arguments
の変更ですべての引数を定義できなくなった場合に使用禁止になります。
プログラムの詳細は、「プログラムの使用」を参照してください。
ウィンドウは、次の場合に有効化できません。
ウィンドウの詳細は、「ウィンドウの使用」を参照してください。
この項の内容は、次のとおりです。
この項では、ジョブの作成例をいくつか示します。ジョブを作成するには、CREATE_JOB
またはCREATE_JOBS
プロシージャを使用します。
次の文では、oe
スキーマ内にmy_job1
という単一の標準ジョブが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'oe.my_job1', job_type => 'PLSQL_BLOCK', job_action => 'BEGIN DBMS_STATS.GATHER_TABLE_STATS(''oe'', ''sales''); END;', start_date => '15-JUL-08 1.00.00AM US/Pacific', repeat_interval => 'FREQ=DAILY', end_date => '15-SEP-08 1.00.00AM US/Pacific', enabled => TRUE, comments => 'Gather table statistics'); END; /
このジョブは、sales
表に関して表の統計を収集します。開始日は7月15日で、1日に1回実行され、終了日は9月15日です。ジョブが作成されたことを確認するには、次の文を発行します。
SELECT JOB_NAME FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME = 'MY_JOB1'; JOB_NAME ------------------------------ MY_JOB1例 28-2 単一トランザクションでの一連の軽量ジョブの作成例
次の例では、1つのトランザクションで一連の軽量ジョブが作成されます。
DECLARE newjob sys.job; newjobarr sys.job_array; BEGIN -- To create a lightweight job, the program must be enabled. -- The program action must be a PL/SQL block or stored procedure. DBMS_SCHEDULER.ENABLE('PROG1'); newjobarr := sys.job_array(); newjobarr.extend(5); FOR i IN 1..5 LOOP newjob := sys.job(job_name => 'LWJOB' || to_char(i), job_style => 'LIGHTWEIGHT', job_template => 'PROG1', repeat_interval => 'FREQ=MINUTELY;INTERVAL=3', start_date => systimestamp + interval '10' second, enabled => TRUE ); newjobarr(i) := newjob; end loop; DBMS_SCHEDULER.CREATE_JOBS(newjobarr, 'TRANSACTIONAL'); END; /
関連項目:
|
この項では、ジョブ・クラスの作成例をいくつか示します。ジョブ・クラスを作成するには、CREATE_JOB_CLASS
プロシージャを使用します。
次の文ではジョブ・クラスが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_JOB_CLASS ( job_class_name => 'my_class1', service => 'my_service1', comments => 'This is my first job class'); END; /
この文では、SYS
内にmy_class1
が作成されます。my_service1
というサービスが使用されます。ジョブ・クラスが作成されたことを確認するには、次の文を発行します。
SELECT JOB_CLASS_NAME FROM DBA_SCHEDULER_JOB_CLASSES WHERE JOB_CLASS_NAME = 'MY_CLASS1'; JOB_CLASS_NAME ------------------------------ MY_CLASS1例 28-4 ジョブ・クラスの作成
次の文ではジョブ・クラスが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_JOB_CLASS ( job_class_name => 'finance_jobs', resource_consumer_group => 'finance_group', service => 'accounting', comments => 'All finance jobs'); END; /
この文では、SYS
内にfinance_jobs
が作成されます。この文では、finance_group
というリソース・コンシューマ・グループが割り当てられ、accounting
サービスのサービス・アフィニティが指定されます。accounting
サービスがfinance_group
以外のリソース・コンシューマ・サービスにマップされた場合、このクラスのジョブはfinance_group
コンシューマ・グループで実行されることに注意してください。これは、resource_consumer_group
属性が優先されるためです。
関連項目:
|
この項では、プログラムの作成例をいくつか示します。プログラムを作成するには、CREATE_PROGRAM
プロシージャを使用します。
次の文では、oe
スキーマ内にプログラムが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_PROGRAM ( program_name => 'oe.my_program1', program_type => 'PLSQL_BLOCK', program_action => 'BEGIN DBMS_STATS.GATHER_TABLE_STATS(''oe'', ''sales''); END;', number_of_arguments => 0, enabled => TRUE, comments => 'My comments here'); END; /
この文では、sales
表に関する表統計を収集するPL/SQLを使用するmy_program1
が作成されます。プログラムが作成されたことを確認するには、次の文を発行します。
SELECT PROGRAM_NAME FROM DBA_SCHEDULER_PROGRAMS WHERE PROGRAM_NAME = 'MY_PROGRAM1'; PROGRAM_NAME ------------------------- MY_PROGRAM1例 28-6 プログラムの作成
次の文では、oe
スキーマ内にプログラムが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_PROGRAM ( program_name => 'oe.my_saved_program1', program_action => '/usr/local/bin/date', program_type => 'EXECUTABLE', comments => 'My comments here'); END; /
この文では、実行可能ファイルを使用するmy_saved_program1
が作成されます。
関連項目:
|
この項では、ウィンドウの作成例をいくつか示します。ウィンドウを作成するには、CREATE_WINDOW
プロシージャを使用します。
次の文では、SYS
内にmy_window1
というウィンドウが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_WINDOW ( window_name => 'my_window1', resource_plan => 'my_res_plan1', start_date => '15-JUL-03 1.00.00AM US/Pacific', repeat_interval => 'FREQ=DAILY', end_date => '15-SEP-03 1.00.00AM US/Pacific', duration => interval '80' MINUTE, comments => 'This is my first window'); END; /
このウィンドウは5月15日〜10月15日の間、毎日1回、午前1時から80分間オープンします。ウィンドウが作成されたことを確認するには、次の文を発行します。
SELECT WINDOW_NAME FROM DBA_SCHEDULER_WINDOWS WHERE WINDOW_NAME = 'MY_WINDOW1'; WINDOW_NAME ------------------------------ MY_WINDOW1例 28-8 ウィンドウの作成
次の文では、SYS
内にmy_window2
というウィンドウが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_WINDOW ( window_name => 'my_window2', schedule_name => 'my_stats_schedule', resource_plan => 'my_resourceplan1', duration => interval '60' minute, comments => 'My window'); END; /
関連項目:
|
この項では、ウィンドウ・グループの作成例を示します。ウィンドウ・グループを作成するには、CREATE_WINDOW_GROUP
プロシージャを使用します。
次の文では、my_window_group1
というウィンドウ・グループが作成されます。
BEGIN DBMS_SCHEDULER.CREATE_WINDOW_GROUP ('my_windowgroup1'); END; /
作成した後は、次の文を発行して、my_window_group1
に3つのウィンドウ(my_window1
、my_window2
およびmy_window3
)を追加できます。
BEGIN DBMS_SCHEDULER.ADD_WINDOW_GROUP_MEMBER ( group_name => 'my_window_group1', window_list => 'my_window1, my_window2'); DBMS_SCHEDULER.ADD_WINDOW_GROUP_MEMBER ( group_name => 'my_window_group1', window_list => 'my_window3'); END; /
ウィンドウ・グループが作成され、ウィンドウが追加されたことを確認するには、次の文を発行します。
SELECT * FROM DBA_SCHEDULER_WINDOW_GROUPS; WINDOW_GROUP_NAME ENABLED NUMBER_OF_WINDOWS COMMENTS ----------------- ------- ----------------- --------------- MY_WINDOW_GROUP1 TRUE 3 This is my first window group
関連項目:
|
この項では、属性の設定例をいくつか示します。属性を設定するには、SET_ATTRIBUTE
およびSET_SCHEDULER_ATTRIBUTE
プロシージャを使用します。
次の例では、my_emp_job1
が日次で実行されるように頻度が再設定されます。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'my_emp_job1', attribute => 'repeat_interval', value => 'FREQ=DAILY'); END; /
変更されたことを確認するには、次の文を発行します。
SELECT JOB_NAME, REPEAT_INTERVAL FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME = 'MY_EMP_JOB1'; JOB_NAME REPEAT_INTERVAL ---------------- --------------- MY_EMP_JOB1 FREQ=DAILY例 28-11 コメント属性の設定
次の例では、my_saved_program1
に対するコメントが再設定されます。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'my_saved_program1', attribute => 'comments', value => 'For nightly table stats'); END; /
変更されたことを確認するには、次の文を発行します。
SELECT PROGRAM_NAME, COMMENTS FROM DBA_SCHEDULER_PROGRAMS; PROGRAM_NAME COMMENTS ------------ ----------------------- MY_PROGRAM1 My comments here MY_SAVED_PROGRAM1 For nightly table stats例 28-12 継続時間属性の設定
次の例では、my_window3
の継続時間が90分に再設定されます。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'my_window3', attribute => 'duration', value => interval '90' minute); END; /
変更されたことを確認するには、次の文を発行します。
SELECT WINDOW_NAME, DURATION FROM DBA_SCHEDULER_WINDOWS WHERE WINDOW_NAME = 'MY_WINDOW3'; WINDOW_NAME DURATION ----------- --------------- MY_WINDOW3 +000 00:90:00例 28-13 データベース・ロール属性の設定
次の例では、ジョブmy_job
のデータベース・ロールがLOGICAL
STANDBY
に設定されます。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'my_job', attribute => 'database_role', value =>'LOGICAL STANDBY'); END; /
データベース・ロールが変更されたことを確認するには、次のコマンドを発行します。
SELECT JOB_NAME, DATABASE_ROLE FROM DBA_SCHEDULER_JOB_ROLES WHERE JOB_NAME = 'MY_JOB'; JOB_NAME DATABASE_ROLE -------- ----------------- MY_JOB LOGICAL STANDBY例 28-14 イベント失効属性の設定
次の例では、イベントの失効時間を秒(最大3600秒)で設定しています。
BEGIN DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE ( attribute => event_expiry_time, value => 3600); END; /例 28-15 一連のジョブに対する複数のジョブ属性の設定
次の例では、5つの各ジョブに4つの異なる属性が設定されます。
DECLARE newattr sys.jobattr; newattrarr sys.jobattr_array; j number; BEGIN -- Create new JOBATTR array newattrarr := sys.jobattr_array(); -- Allocate enough space in the array newattrarr.extend(20); j := 1; FOR i IN 1..5 LOOP -- Create and initialize a JOBATTR object type newattr := sys.jobattr(job_name => 'TESTJOB' || to_char(i), attr_name => 'MAX_FAILURES', attr_value => 5); -- Add it to the array. newattrarr(j) := newattr; j := j + 1; newattr := sys.jobattr(job_name => 'TESTJOB' || to_char(i), attr_name => 'COMMENTS', attr_value => 'Test job'); newattrarr(j) := newattr; j := j + 1; newattr := sys.jobattr(job_name => 'TESTJOB' || to_char(i), attr_name => 'END_DATE', attr_value => systimestamp + interval '24' hour); newattrarr(j) := newattr; j := j + 1; newattr := sys.jobattr(job_name => 'TESTJOB' || to_char(i), attr_name => 'SCHEDULE_LIMIT', attr_value => interval '1' hour); newattrarr(j) := newattr; j := j + 1; END LOOP; -- Call SET_JOB_ATTRIBUTES to set all 20 set attributes in one transaction DBMS_SCHEDULER.SET_JOB_ATTRIBUTES(newattrarr, 'TRANSACTIONAL'); END; /
関連項目:
|
この項では、チェーンの作成例を示します。チェーンを作成するには、CREATE_CHAIN
プロシージャを使用します。 チェーンを作成した後、DEFINE_CHAIN_STEP
またはDEFINE_CHAIN_EVENT_STEP
プロシージャを使用してチェーンにステップを追加し、DEFINE_CHAIN_RULE
プロシージャを使用してルールを定義します。
次の例では、my_program2
およびmy_program3
の前にmy_program1
を実行するチェーンが作成されます。my_program1
の完了後、my_program2
およびmy_program3
は、並行して実行されます。
この例のユーザーには、CREATE
EVALUATION
CONTEXT
、CREATE
RULE
およびCREATE
RULE
SET
権限が必要です。 詳細は、「チェーンの各権限の設定」を参照してください。
BEGIN DBMS_SCHEDULER.CREATE_CHAIN ( chain_name => 'my_chain1', rule_set_name => NULL, evaluation_interval => NULL, comments => NULL); END; / --- define three steps for this chain. Referenced programs must be enabled. BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain1', 'stepA', 'my_program1'); DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain1', 'stepB', 'my_program2'); DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain1', 'stepC', 'my_program3'); END; / --- define corresponding rules for the chain. BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_RULE('my_chain1', 'TRUE', 'START stepA'); DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( 'my_chain1', 'stepA COMPLETED', 'Start stepB, stepC'); DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( 'my_chain1', 'stepB COMPLETED AND stepC COMPLETED', 'END'); END; / --- enable the chain BEGIN DBMS_SCHEDULER.ENABLE('my_chain1'); END; / --- create a chain job to start the chain daily at 1:00 p.m. 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; /例 28-17 チェーンの作成
次の例では、最初にmy_program1
を実行してチェーンを作成します。正常に実行された場合はmy_program2
、失敗した場合はmy_program3
が実行されます。
BEGIN DBMS_SCHEDULER.CREATE_CHAIN ( chain_name => 'my_chain2', rule_set_name => NULL, evaluation_interval => NULL, comments => NULL); END; / --- define three steps for this chain. BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain2', 'step1', 'my_program1'); DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain2', 'step2', 'my_program2'); DBMS_SCHEDULER.DEFINE_CHAIN_STEP('my_chain2', 'step3', 'my_program3'); END; / --- define corresponding rules for the chain. BEGIN DBMS_SCHEDULER.DEFINE_CHAIN_RULE ('my_chain2', 'TRUE', 'START step1'); DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( 'my_chain2', 'step1 SUCCEEDED', 'Start step2'); DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( 'my_chain2', 'step1 COMPLETED AND step1 NOT SUCCEEDED', 'Start step3'); DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( 'my_chain2', 'step2 COMPLETED OR step3 COMPLETED', 'END'); END; /
関連項目:
|
この項では、イベント・ベースのジョブおよびイベント・スケジュールの作成例を示します。イベント・ベースのジョブを作成するには、CREATE_JOB
プロシージャを使用します。イベント・ベースのスケジュールを作成するには、CREATE_EVENT_SCHEDULE
プロシージャを使用します。
これらの例では、アプリケーションでシステムにファイルが到着したことが検出されたときに、イベントをmy_events_q
キューにエンキューするアプリケーションがあることを想定しています。
次の例では、午前9時前にファイルがシステムに到着したことを示すイベントをスケジューラが受信するたびに、ジョブの開始に使用可能なスケジュールを作成する方法を示しています。
BEGIN DBMS_SCHEDULER.CREATE_EVENT_SCHEDULE ( schedule_name => 'scott.file_arrival', start_date => systimestamp, event_condition => 'tab.user_data.object_owner = ''SCOTT'' and tab.user_data.event_name = ''FILE_ARRIVAL'' and extract hour from tab.user_data.event_timestamp < 9', queue_spec => 'my_events_q'); END; /例 28-19 イベントベースのジョブの作成
次の例では、ファイルがシステムに到着したことを示すイベントをスケジューラが受信したときに開始されるジョブを作成しています。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => my_job, program_name => my_program, start_date => '15-JUL-04 1.00.00AM US/Pacific', event_condition => 'tab.user_data.event_name = ''FILE_ARRIVAL''', queue_spec => 'my_events_q' enabled => TRUE, comments => 'my event-based job'); END; /
Oracle Data Guard環境では、スケジューラには、2つのデータベース・ロール(プライマリとロジカル・スタンバイ)に対する追加のサポートが含まれています。データベースのロールがプライマリの場合のみ、またはデータベースのロールがロジカル・スタンバイの場合のみ、ジョブが実行されるように構成できます。そのためには、database_role
属性を設定します。この例では、両方のデータベース・ロールでジョブを実行できるようにする方法を説明します。ジョブのコピーを2つ作成し、それぞれに異なるdatabase_role
を割り当てる方法を使用します。
デフォルトでは、ジョブが実行されるのは、データベースのロールがそのジョブの作成時と同じロールの場合です。両方のロールで同じジョブを実行する手順は、次のとおりです。
この例は、プライマリ・データベースでprimary_job
というジョブを作成することで起動します。次に、このジョブのコピーを作成し、database_role
属性をLOGICAL
STANDBY
に設定します。プライマリ・データベースがロジカル・スタンバイになると、ジョブはそのスケジュールに従って引き続き実行されます。
ジョブをコピーした場合、新しいジョブは使用禁止になっているため、使用可能にする必要があります。
BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'primary_job', program_name => 'my_prog', schedule_name => 'my_sched'); DBMS_SCHEDULER.COPY_JOB('primary_job','standby_job'); DBMS_SCHEDULER.ENABLE(name=>'standby_job', commit_semantics=>'ABSORB_ERRORS'); DBMS_SCHEDULER.SET_ATTRIBUTE('standby_job','database_role','LOGICAL STANDBY'); END; /
この例を実行すると、DBA_SCHEDULER_JOB_ROLES
ビューのデータは、次のようになります。
SELECT JOB_NAME, DATABASE_ROLE FROM DBA_SCHEDULER_JOB_ROLES WHERE JOB_NAME IN ('PRIMARY_JOB','STANDBY_JOB'); JOB_NAME DATABASE_ROLE -------- ---------------- PRIMARY_JOB PRIMARY STABDBY_JOB LOGICAL STANDBY
ここでは、Oracle Schedulerの参照情報を提供します。この章の内容は、次のとおりです。
表28-2に、スケジューラの様々な権限をリストします。
SCHEDULER_ADMIN
ロールは、表28-2に記載されているすべてのシステム権限付き(ADMIN
オプション付き)で作成されます。SCHEDULER_ADMIN
ロールはDBA
(ADMIN
オプション付き)に付与されます。
SELECT
ALL_SCHEDULER_*
ビュー、SELECT
USER_SCHEDULER_*
ビュー、SELECT
SYS.SCHEDULER$_JOBSUFFIX_S
(ジョブ名生成用)、およびEXECUTE
SYS.DEFAULT_JOB_CLASS
の各オブジェクト権限が、PUBLIC
に付与されます。
スケジューラの情報は、多数のビューで確認できます。次に、my_job1
の完了したインスタンスに関する情報の表示例を示します。
SELECT JOB_NAME, STATUS, ERROR# FROM DBA_SCHEDULER_JOB_RUN_DETAILS WHERE JOB_NAME = 'MY_JOB1'; JOB_NAME STATUS ERROR# -------- -------------- ------ MY_JOB1 FAILURE 20000
表28-3に、スケジューラに関連付けられたビューを示します。*_SCHEDULER_JOBS
、*_SCHEDULER_SCHEDULES
、*_SCHEDULER_PROGRAMS
、*_SCHEDULER_RUNNING_JOBS
、*_SCHEDULER_JOB_LOG
および *_SCHEDULER_JOB_RUN_DETAILS
の各ビューは、ジョブの管理に特に役立ちます。 スケジューラのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。