11gリリース1（11.1）
E05760-03
 目次 |
 索引 |
| Oracle Database 管理者ガイド 11gリリース1（11.1） E05760-03 |
|
この章の内容は次のとおりです。
数百または数千ものタスクのスケジューリングを簡素化するために、Oracle Databaseにはエンタープライズ・ジョブ・スケジューラであるOracle Schedulerが組み込まれています。 Oracle Scheduler（スケジューラ）は、DBMS_SCHEDULER PL/SQLパッケージのプロシージャおよびファンクションにより実装されます。
スケジューラを使用すると、企業環境において様々なコンピューティング・タスクをいつどこで実行するかを制御できます。また、これらのタスクの効率的な管理および計画に役立ちます。 多数の日常的なコンピューティング・タスクが手動で操作することなく確実に実行されるため、操作コストの削減、信頼性の高いルーチンの実現、人為的なエラーの最小化および必要期間の短縮が可能です。
この項の内容は次のとおりです。
スケジューラでは、洗練された柔軟なエンタープライズ・スケジューリング機能が提供されます。次のことを実行できます。
特定の日時に1回または繰り返し実行するようにジョブをスケジュールできます。 「特定の休日を除き毎週月曜日と木曜日の午前3時」または「業務上の各四半期の最終水曜日」のように、複雑な繰返し間隔を定義できます。
スケジューラでは、システム・イベントまたはビジネス・イベントに対応してジョブを開始できます。アプリケーションは、イベントを検出するとスケジューラに通知します。送信された通知のタイプに応じて、スケジューラは特定のジョブを開始します。 イベントベースのスケジューリングの例として、ファイルがシステムに着信した時点、在庫が事前に指定したレベルを下回った時点、またはトランザクションに失敗した時点でジョブを開始させる場合があります。
スケジューラでは、前の1つ以上のタスクの結果に基づいてタスクを実行できます。 ブランチやネストしたチェーンを含んだ複雑な依存性チェーンを定義できます。
スケジューラを使用すると、競合するジョブ間のリソース割当てを制御でき、ビジネス・ニーズに基づいてジョブ処理を調整できます。これは次の方法で実現されます。
ジョブの作成から完了までの間には様々な状態があります。スケジューラのアクティビティはログに記録されるため、ジョブのステータスや最終の実行時間などの情報を簡単に追跡できます。 この情報はビューに格納され、Enterprise ManagerまたはSQLで簡単に問い合せることができます。 このビューからジョブとその実行内容に関する有益な情報が得られるため、これを使用してジョブをより適切にスケジュールし管理できます。 たとえば、DBAは特定のユーザーの失敗ジョブをすべて簡単に追跡できます。 「スケジューラの監視と管理」を参照してください。
クラスタは、同じタスクを実行するために連携して動作するデータベース・インスタンスのセットです。Oracle Real Application Clusters（RAC）は、アプリケーションを変更せずにスケーラビリティと信頼性を提供します。スケジューラは、このようなクラスタ化された環境でのジョブの実行を完全にサポートします。システムの負荷を均等にし、パフォーマンスを向上させるために、ジョブを実行するデータベース・サービスを指定することもできます。 詳細は、「Real Application Clusters環境におけるスケジューラの使用」を参照してください。
スケジューラを使用するには、スケジューラ・オブジェクトを作成します。 これは、ジョブ・スケジューリングの内容、時期および方法を定義するスキーマ・オブジェクトです。 スケジューラ・オブジェクトにより、モジュール化された方法でタスクを管理できます。 この方法のメリットの1つは、既存のタスクに類似する新規タスクを作成する際にオブジェクトを再利用できることです。
すべてのスケジューラ・オブジェクトには属性があります。 これらの属性には、オブジェクトの作成時または変更時に値を割り当てます。
スケジューラ・オブジェクトは次のとおりです。
これらの各オブジェクトの詳細は、他の項を参照してください。 重要なスケジューラ・オブジェクトはジョブです。 ジョブでは、実行する処理とその実行に使用するスケジュールを定義します。 スケジュールを定義するには、スタンドアロンで行う方法と他のスケジューラ・オブジェクトを参照する方法があります。
スケジューラ・オブジェクトはスキーマに属しているため、オブジェクト権限を付与できます。 ジョブ・クラス、ウィンドウおよびウィンドウ・グループのような一部のスケジューラ・オブジェクトは、作成ユーザーがユーザーSYSでない場合も常にSYSスキーマに作成されます。 他のオブジェクトはすべて、作成ユーザーのスキーマまたは指定のスキーマに作成されます。
プログラム・オブジェクト（プログラム）では、スケジューラによって実行される内容が記述されます。 プログラムの要素は次のとおりです。
'STORED_PROCEDURE'または'PLSQL_BLOCK'など
プログラムは、ジョブとは別個のエンティティです。 ジョブは特定の時間または特定のイベントが発生した場合に実行され、特定のプログラムを起動します。ジョブは、既存のプログラム・オブジェクトを指し示すように作成できます。これは、様々なジョブで同じプログラムを使用でき、そのプログラムを様々な時間に様々な設定で実行できることを意味します。したがって、適切な権限があれば、様々なユーザーが同じプログラムを再定義せずに使用できます。このため、ユーザーが既存プログラムのリストから選択できるプログラム・ライブラリの作成が可能です。
プログラムで参照されるストアド・プロシージャまたは外部実行可能ファイルが引数を受け入れる場合は、これらの引数をプログラムの作成後に個別ステップで定義します。 各引数のデフォルト値を定義することもできます。
プログラムの詳細は、「プログラムの作成」を、ジョブの概要は、「ジョブ」を参照してください。
スケジュール・オブジェクト（スケジュール）は、ジョブの実行時期と実行回数を指定します。 スケジュールは複数のジョブで共有できます。たとえば、業務上の四半期の終了時期は、多くのジョブにとって共通の期間である可能性があります。ジョブの作成者は、新規のジョブを定義するたびに四半期の終了時期のスケジュールを定義するかわりに、名前付きのスケジュールを指し示すことができます。
スケジュールには、時間スケジュールとイベント・スケジュールの2種類があります。
時間スケジュールでは、ジョブを後で実行するか即時に実行するようにスケジュールできます。 時間スケジュールには、開始日時、オプションの終了日時およびオプションの繰返し間隔が含まれています。
イベント・スケジュールでは、ファイルがシステムに着信した時点など、特定のイベントが発生した時点でジョブを実行するように指定できます。 イベントの詳細は、「イベントの使用」を参照してください。
詳細は、「スケジュールの作成」を参照してください。
ジョブ・オブジェクト（ジョブ）は、1回以上実行するようにスケジュールされるユーザー定義タスクを記述したメタデータの集合です。ジョブは、実行する必要がある内容（処理）と実行時期（スケジュール）の組合せです。
ジョブの処理は、次のいずれかの方法で指定します。
ジョブ所有者には、プログラムに対するEXECUTE権限またはEXECUTE ANY PROGRAMシステム権限が必要です。
ジョブ・スケジュールは、次のいずれかの方法で指定します。
ジョブを作成して有効化した後は、スケジューラにより自動的にジョブがスケジュールに従って実行されます。 ジョブの実行ステータスとジョブ・ログは、データ・ディクショナリ・ビューを問い合せることで確認できます。
この項の内容は次のとおりです。
ジョブ・インスタンスは、ジョブの特定の実行を表します。1回のみ実行するようにスケジュールされたジョブのインスタンスは1つのみです。繰返しスケジュールされたジョブには複数のインスタンスがあり、ジョブの各実行が1つのインスタンスを表します。たとえば、2002年10月8日、火曜日に実行されるようにスケジュールされたジョブのインスタンスは1つです。1週間毎日正午に実行されるジョブには7つのインスタンスがあり、ジョブの実行ごとに1つのインスタンスが対応します。
ジョブの作成時に、ジョブを表すためにスケジューラのジョブ表に追加されるエントリは1つのみです。 ロギング・レベルの設定に応じて、ジョブが実行されるたびにエントリが1つジョブ・ログに追加されます。したがって、繰返しスケジュールのジョブを作成した場合、ジョブのビューには1つのエントリが、ジョブ・ログには複数のエントリが存在します。各ジョブ・インスタンスのログ・エントリでは、特定の実行に関して、ジョブの完了ステータス、開始時間と終了時間などの情報が提供されます。ジョブの各実行には一意のログIDが割り当てられます。このIDは、ジョブ・ログのビューとジョブ実行の詳細ビューの両方に使用されます。
詳細は、「スケジューラのデータ・ディクショナリ・ビュー」を参照してください。
ジョブでプログラム・オブジェクト（プログラム）を参照する場合、ジョブ引数を指定してデフォルトのプログラム引数値を上書きするか、デフォルト値のないプログラム引数の値を提供できます。 また、ジョブが指定するインライン処理（例: ストアド・プロシージャ）に対しても引数値を提供できます。
必要なプログラム引数値のすべてが、参照先のプログラム・オブジェクトにデフォルトとして定義されているか、またはジョブ引数として定義されるまで、ジョブは使用できません。
ジョブの一般的な例には、一連のレポートを夜間に実行するジョブがあります。様々な部門で様々なレポートが必要な場合は、このタスクのプログラムを、様々な部門の様々なユーザー間で共有できるように作成できます。このプログラム処理では、レポート・スクリプトが実行され、プログラムには1つの引数として、部門番号を設定します。各ユーザーはこのプログラムを指し示すジョブを作成し、部門番号をジョブ引数として指定できます。
実行内容と実行時期を定義するには、プログラム、ジョブおよびスケジュール間に関連を割り当てます。図26-1に、これらの関連の例を示します。
図26-1を理解するために、表を分析する場合を考えてみます。この例では、P1が、DBMS_STATSパッケージを使用して表を分析するプログラムです。このプログラムには、表名に対する入力パラメータがあります。2つのジョブJ1とJ2は、両方とも同じプログラムを指し示していますが、別々の表名が指定されています。さらに、スケジュールS1には、毎日午前2時の実行時間を指定できます。最終的な結果として、J1とJ2で名前が指定された2つの表は、毎日午前2時に分析されます。
J4は、すべての関連情報がそのジョブ自体に定義された自己完結のジョブで、他のエンティティを指し示していないことに注意してください。P2、P9およびS2は、必要に応じて、プログラムまたはスケジュールに関連を割り当てないままにできることを示しています。たとえば、年度末の在庫を計算するプログラムを作成し、一時的に、そのプログラムをどのジョブにも割り当てないままにできます。
スケジューラは、次のタイプのジョブをサポートしています。
データベース・ジョブでは、PL/SQL無名ブロック、PL/SQLストアド・プロシージャおよびJavaストアド・プロシージャなどのOracle Databaseプログラム・ユニットが実行されます。 処理がインラインで指定されているデータベース・ジョブの場合、job_typeは'PLSQL_BLOCK'または'STORED_PROCEDURE'に設定され、job_actionにはPL/SQL無名ブロックのテキストまたはストアド・プロシージャ名が含まれています。 （処理がインライン指定されるかわりにプログラム・オブジェクト名が指定されている場合は、それに応じて対応するprogram_typeおよびprogram_actionが設定されます。）
チェーンは、依存性ベースのスケジューリングを可能にするスケジューラ・メカニズムです。 最も単純な形式では、プログラム・オブジェクトのグループとプログラム・オブジェクト間の依存性が定義されます。 ジョブは、単一のプログラム・オブジェクトを指し示すかわりにチェーンを指し示すことができます。 その場合、ジョブはチェーンを開始する役割を持ちます。 チェーン・ジョブの場合、job_typeは'CHAIN'として指定されます。
詳細は、「チェーン」を参照してください。
外部ジョブでは、外部実行可能ファイルが実行されます。 外部実行可能ファイルは、オペレーティング・システムの実行可能ファイルで、データベースの外部で実行されます。 外部ジョブの場合、job_typeは'EXECUTABLE'として指定されます （名前付きプログラムを使用している場合は、対応するprogram_typeが'EXECUTABLE'になります）。job_action（名前付きプログラムを使用している場合は対応するprogram_action）には、必要な外部実行可能ファイルのパス（コマンドライン引数を除く）が、オペレーティング・システムに依存したフルパスの形式で入ります。たとえば、/usr/local/bin/perlやC:¥perl¥bin¥perlのようになります。 タイプ'EXECUTABLE'のプログラムまたはジョブの引数は、CHARまたはVARCHAR2などの文字列型であることが必要です。
Windowsのバッチ・ファイルは直接実行できないため、cmd.exeを使用して実行する必要があることに注意してください。
スケジューラのジョブと同様に、ジョブの作成時にはスキーマを割り当てることができます。割り当てたスキーマはジョブの所有者になります。外部ジョブはSYSスキーマに作成できますが、この方法はお薦めしません。
外部ジョブを実行するスキーマには、CREATE JOBとCREATE EXTERNAL JOBの両方の権限が必要です。
外部実行可能ファイルは、オペレーティング・システム・ユーザーとして実行する必要があります。 したがって、スケジューラでは、作成する外部ジョブにオペレーティング・システムの資格証明を割り当てることができます。そのためには、Oracle Database 11g リリース1で導入された資格証明と呼ばれるデータベース・オブジェクトを使用します。
外部ジョブには、ローカル外部ジョブとリモート外部ジョブの2つのタイプがあります。 ローカル外部ジョブでは、そのジョブがスケジュールされているデータベースと同じコンピュータ上で外部実行可能ファイルが実行されます。 リモート外部ジョブでは、リモート・ホスト（つまり、そのジョブがスケジュールされているデータベースを実行しているコンピュータとは別のホスト・コンピュータ）で実行可能ファイルが実行されます。 リモート・ホストではOracleデータベースは必要ありません。
次の各項では、資格証明、ローカル外部ジョブおよびリモート外部ジョブについて説明します。
資格証明は、専用のデータベース・オブジェクトに格納されているホスト・ユーザー名とパスワードのペアです。外部ジョブの資格証明を指定するには、そのジョブのcredential_name属性を設定します。 これにより、ジョブの外部実行可能ファイルは、その資格証明に指定されているユーザー名とパスワードで実行されます。
資格証明を作成するには、DBMS_SCHEDULER.CREATE_CREDENTIALプロシージャを使用します。 自分のスキーマに資格証明を作成するにはCREATE JOB権限が、SYS以外のスキーマに資格証明を作成するにはCREATE ANY JOB権限が必要です。資格証明を使用できるのは、資格証明のEXECUTE権限がジョブの所有者に付与されているジョブ、またはジョブの所有者が資格証明の所有者を兼ねているジョブのみです。資格証明は他のスキーマ・オブジェクトのようにスキーマに属しているため、資格証明に対する権限はGRANT SQL文を使用して付与します。
BEGIN DBMS_SCHEDULER.CREATE_CREDENTIAL('HRCREDENTIAL', 'hruser', 'hr001515'); END; GRANT EXECUTE ON HRCREDENTIAL to HR;
データベース内の資格証明のリストを表示するには、*_SCHEDULER_CREDENTIALSビューを問い合せます。資格証明パスワードは不明瞭な状態で格納されるため、*_SCHEDULER_CREDENTIALSビューには表示されません。
ローカル外部ジョブでは、そのジョブがスケジュールされているOracleデータベースと同じコンピュータ上で外部実行可能ファイルが実行されます。このようなジョブの場合、destinationジョブ属性はNULLか、またはlocalhostの値が格納されます。
ローカル外部ジョブでは、stdoutおよびstderrの出力がディレクトリORACLE_HOME/scheduler/log内のログ・ファイルに書き込まれます。 これらのファイルの内容は、DBMS_SCHEDULER.GET_FILEで取得できます。
ローカル外部ジョブには資格証明を割り当てる必要はありません。ただし、セキュリティ向上のために割り当てることをお薦めします。 資格証明を割り当てなかった場合、ジョブはデフォルト資格証明を使用して実行されます。表26-1に、各プラットフォームおよびジョブ所有者のデフォルトの資格証明を示します。
資格証明が割り当てられていないローカル外部ジョブの実行を禁止するには、ORACLE_HOME/rdbms/admin/externaljob.oraファイルからrun_user属性を削除する（UNIXとLinuxの場合）か、OracleJobSchedulerサービスを停止します（Windowsの場合）。SYSスキーマ内のローカル外部ジョブは、これらのステップでは実行不可になりません。
|
関連項目:
|
リモート外部ジョブでは、そのジョブがスケジュールされているOracleデータベースを実行しているコンピュータとは別のホスト・コンピュータで外部実行可能ファイルが実行されます。 説明上、ここでは、リモート実行可能ファイルが実行されるコンピュータをリモート・ホストと呼びます。リモート・ホストには、Oracle Databaseがインストールされている場合も、されていない場合もあります。 ただし、いずれの場合も、リモート・ホストには、データベースがリモート・ホストで外部実行可能ファイルを起動する際に通信するスケジューラ・エージェントがあります。このエージェントは、実行結果をデータベースに戻す処理にも関係しています。エージェントは、個別にインストールされるリモート・ホスト上の実行可能ファイルです。エージェントは、着信ジョブ・リクエストをネットワーク・ポートでリスニングして実行します。
リモート外部ジョブを作成する場合は、そのジョブのdestination属性としてリモート・ホストとポート番号を指定します。また、リモート外部ジョブの資格証明も指定する必要があります。
リモート外部ジョブでは、stdoutおよびstderrの出力がディレクトリAGENT_HOME/data/log内のログ・ファイルに書き込まれます。 これらのファイルの内容は、DBMS_SCHEDULER.GET_FILEで取得できます。stdoutの出力の取得方法は、例27-6「ローカル外部ジョブの作成とstdoutの取得」を参照してください。 この例はローカル外部ジョブに関するものですが、メソッドはリモート外部ジョブの場合も同じです。
デタッチ済ジョブを使用して、スケジューラから独立して非同期的に個別プロセスで実行されるスクリプトまたはアプリケーションを起動します。 通常、デタッチ済ジョブは別のプロセスを起動してから終了します。 デタッチ済ジョブは、終了時（ジョブの処理の完了時）も実行中の状態のままです。 この状態は、ジョブにより起動された非同期プロセスがまだアクティブであることを示します。 非同期プロセスは、処理が終了した時点でデータベースに接続し、DBMS_SCHEDULER.END_DETACHED_JOB_RUNをコールする必要があります。これによりジョブが終了します。
ジョブは、detached属性がTRUEに設定されているプログラム・オブジェクト（プログラム）（デタッチ済プログラム）を指している場合、デタッチ済です。
デタッチ済ジョブは、次の2つの場合に使用します。
たとえば、非同期Webサービスにリクエストを送信する場合です。 Webサービスが応答するまでに数時間から数日かかる可能性があり、応答を待機する間スケジューラ・ジョブ・スレーブを保持することは望ましくありません。 （ジョブ・スレーブの詳細は、「スケジューラのアーキテクチャ」を参照してください。）
たとえば、スケジューラ・ジョブを使用して、データベースの停止、コールド・バックアップの作成およびデータベースの再起動を実行するRMANスクリプトを起動する場合です。 例27-7を参照してください。
デタッチ済ジョブの動作は次のとおりです。
END_DETACHED_JOB_RUNがコールされます。
実行中のデタッチ済ジョブを終了するには、STOP_JOBをコールする方法もあります。
頻繁に実行する短時間のジョブが多数ある場合は、軽量ジョブを使用します。 特定の状況では、軽量ジョブを使用することで、わずかながらパフォーマンスが向上する場合があります。
軽量ジョブには、次の特性があります。
軽量ジョブを指定するには、job_styleジョブ属性を'LIGHTWEIGHT'に設定します。 もう1つのジョブ・スタイルは、デフォルトの'REGULAR'です。
プログラムやスケジュールと同様に、標準ジョブはスキーマ・オブジェクトです。 Oracle Database 11g リリース1より前のリリースでは、標準ジョブがスケジューラでサポートされる唯一のジョブ・スタイルでした。
標準ジョブは最大の柔軟性を提供しますが、作成または削除する際に多少のオーバーヘッドを伴います。ユーザーは、ジョブの権限をきめ細かく制御できます。ジョブには、別のユーザーが所有するプログラムやストアド・プロシージャを処理として指定できます。
実行頻度が低い比較的少数のジョブを作成する必要がある場合は、軽量ジョブよりも標準ジョブが優先されます。
軽量ジョブでは、プログラム・オブジェクト（プログラム）を参照してジョブの処理を指定する必要があります。 プログラムは軽量ジョブの作成時に有効化されている必要があり、プログラム・タイプは'PLSQL_BLOCK'または'STORED_PROCEDURE'であることが必要です。 軽量ジョブはスキーマ・オブジェクトではないため、権限は付与できません。 軽量ジョブは指定のプログラムから権限を継承します。 したがって、プログラムに対して特定の権限セットを持つユーザーは、軽量ジョブに対して対応する権限を持つことになります。
チェーンは、前の1つ以上のジョブの結果に応じて異なるジョブが開始される依存性スケジューリングを実装できる手段です。 チェーンは、依存性ルールを使用して結合された複数のステップで構成されています。 依存性ルールでは、タスクまたはチェーン自体の開始または停止に使用できる条件を定義します。 条件には、前のタスクの成功、失敗、完了コードまたは終了コードを使用できます。 AND/ORなどの論理式を条件に使用することもできます。 チェーンは、実行するタスクと、タスクの実行時期の選択に関して多くの可能なパスを持ち、ある意味でDecision Treeに似ています。
最も単純な形式のチェーンは、1つの目的のために互いにリンクされた複数のスケジューラ・プログラム・オブジェクト（プログラム）で構成されています。 チェーンの例には、「プログラムAを実行してからプログラムBを実行するが、プログラムAとプログラムBの両方が正常に完了した場合にのみプログラムCを実行し、正常に完了しない場合は1時間待機してからプログラムDを実行する」などがあります。
チェーンの作成が必要な典型的な状況として、融資申請を検証して承認した後に融資するなど、正常な取引のために様々なプログラムの結合を必要とする金融取引などがあります。
スケジューラ・ジョブは、単一のプログラム・オブジェクトを指し示すかわりにチェーンを指し示すことができます。 その場合、ジョブはチェーンを開始する役割を持ちます。 このジョブはチェーン・ジョブと呼ばれます。 複数のチェーン・ジョブで同じチェーンを指し示すことができ、そのうちの複数のジョブを同時に実行することで、チェーンの様々な進捗ポイントで同じチェーンの複数インスタンスをそれぞれ作成できます。
チェーン内の各位置はステップと呼ばれます。通常は、最初の一連のチェーン・ステップを開始し、後続のステップは、1つ以上前のステップの完了に従って実行されます。各ステップは、次のいずれかを指し示します。
プログラムでは、データベース・プログラム・ユニット（ストアド・プロシージャまたはPL/SQL無名ブロックなど）を実行するか、ローカルまたはリモートの外部実行可能ファイルを実行できます。 リモート外部実行可能ファイルの場合は、宛先ホストを指定します。
チェーンをネストするレベル数に制限はありません。
イベント・スケジュールを指し示すステップ、またはインライン・イベント指定を持つステップは、特定のイベントが呼び出されるまで待機します。 イベントが発生すると、このステップは完了し、イベント・ステップに依存するステップが実行可能になります。 チェーン内のイベントの一般例は、承認や拒否のようなユーザーの介入です。
チェーン内の複数のステップは、同じプログラムまたはネストしたチェーンを起動できます。
図26-2に、複数のブランチを持つチェーンを示します。 このチェーンでは、ルールが次のように定義されているとします。
ステップ4、5、6および7の実行は、他のルールにより制御されます。
チェーンを指し示しているジョブの実行中は、実行しているチェーンのすべてのステップについて現在の状態を監視できます。 各ステップには、スケジューラによって、チェーン・ジョブと同じジョブ名と所有者を設定したステップ・ジョブが作成されます。 各ステップ・ジョブにはさらに、そのジョブを一意に識別するためのサブ名があります。 ステップ・ジョブ・サブ名は、ビュー*_SCHEDULER_RUNNING_JOBS、*_SCHEDULER_JOB_LOGおよび*_SCHEDULER_JOB_RUN_DETAILSにJOB_SUBNAME列として、*_SCHEDULER_RUNNING_CHAINSビューにSTEP_JOB_SUBNAME列として含まれています。
詳細は、「チェーンの使用」を参照してください。
通常、ジョブ・クラスを作成するのは、スケジューラ管理者のロールを持っている場合のみです。
ジョブ・クラスは、次の内容を実行します。
各ジョブ・クラスでは、ロギング・レベルなどの属性セットを指定します。ジョブをジョブ・クラスに割り当てると、そのジョブはこれらの属性を継承します。たとえば、全給与ジョブに対するログ・エントリのパージに関して、同じポリシーを指定できます。
ジョブ・クラスのservice属性を必要なデータベース・サービス名に設定できます。これによって、Real Application Clusters環境のインスタンスが決まります。このインスタンスは、メンバーのジョブを実行し、必要に応じて、メンバーのジョブに割り当てられたシステム・リソースを実行します。 詳細は、「スケジューラ使用時のサービス・アフィニティ」を参照してください。
各ジョブ・クラスでは、リソース・コンシューマ・グループを属性として指定できるため、ジョブ・クラスでは、データベース・リソース・マネージャとスケジューラ間のリンクが提供されます。このため、指定したコンシューマ・グループに属するメンバーのジョブには、現行のリソース・プランの設定に応じて、リソースが割り当てられます。
また、resource_consumer_group属性をNULLのままにし、ジョブ・クラスのservice属性を必要なデータベース・サービス名に設定できます。このサービスは、リソース・コンシューマ・グループにマップできます。resource_consumer_group属性とservice属性が設定されているときに、指定のサービスがリソース・コンシューマ・グループにマップされた場合は、resource_consumer_group属性に指定されているリソース・コンシューマ・グループが優先されます。
コンシューマ・グループへのサービスのマッピングの詳細は、第25章「Oracle Database Resource Managerを使用したリソース割当ての管理」を参照してください。
同じジョブ・クラス内では、個々のジョブに1〜5の優先度値を割り当てることができます。このため、クラス内の2つのジョブが同時に開始するようにスケジュールされている場合は、優先度の高いジョブが優先されます。この機能によって、重要度の高いジョブが時間どおりに完了するのを重要度の低いジョブが妨げることはありません。
2つのジョブに同じ優先値が割り当てられている場合は、開始日の早いジョブが優先されます。ジョブに優先度が割り当てられていない場合、そのジョブの優先度は3にデフォルト設定されます。
ジョブ・クラスの定義するときは、ジョブを機能別に分類してください。マーケティング、生産、販売、財務および人事など、同様のデータにアクセスするジョブをグループに分けることを考慮してください。
次の制限事項に注意してください。
DEFAULT_JOB_CLASSクラスのメンバーになります。
DEFAULT_JOB_CLASSクラスに割り当てられます。削除したクラスに属しているジョブの中ですでに実行中のジョブは、ジョブの開始時に判別されたクラスの設定のまま実行されます。
通常、ウィンドウを作成するのは、スケジューラ管理者のロールを持っている場合のみです。
日または週などの様々な期間中に、ジョブを自動的に開始したり、複数のジョブ間のリソース割当てを変更するには、ウィンドウを作成します。ウィンドウは、午前12時〜午前6時など、開始と終了が明確に定義された期間で表されます。
ウィンドウは、ジョブ・クラスを使用して、リソース割当てを制御します。各ウィンドウは、ウィンドウがオープンしたとき（アクティブになったとき）に、アクティブにするリソース・プランを指定し、各ジョブ・クラスは、リソース・コンシューマ・グループを指定するか、コンシューマ・グループにマップできるデータベース・サービスを指定します。したがって、ウィンドウ内で実行するジョブには、そのジョブ・クラスのコンシューマ・グループとウィンドウのリソース・プランに応じてリソースが割り当てられます。
図26-3に、2つのウィンドウが設定された稼働日を示します。この構成では、コンシューマ・グループ1にリンクしているジョブ・クラスに属するジョブが、午後よりも午前にリソースを多く使用しています。コンシューマ・グループ2にリンクしているジョブ・クラスのジョブは、この逆です。
リソース・プランおよびコンシューマ・グループの詳細は、第25章「Oracle Database Resource Managerを使用したリソース割当ての管理」を参照してください。
各ウィンドウには、優先度を割り当てることができます。ウィンドウが重複する場合は、優先度の高いウィンドウが優先度の低いウィンドウより優先して選択されます。スケジューラは、ウィンドウの開始時間と終了時間に従って、各ウィンドウを自動的にオープンしたり、クローズします。
ジョブは、そのschedule_name属性でウィンドウを指定できます。スケジューラは、このウィンドウがオープンするとジョブを開始します。ウィンドウがすでにオープンしている場合にそのウィンドウを指し示す新規ジョブが作成されると、そのジョブはウィンドウが次回オープンするまで開始されません。
ウィンドウの作成と使用については、「ウィンドウの作成」を参照してください。
|
注意:
必要な場合は、現行のリソース・プランが切り替わらないように一時的にウィンドウをブロックできます。 詳細は、「Oracle Database Resource Managerの有効化とプランの切替え」、または『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』の |
通常、ウィンドウ・グループを作成するのは、スケジューラ管理者のロールを持っている場合のみです。
ジョブのスケジュールで、ウィンドウを使いやすいようにグループ化できます。ウィンドウ・グループを使用すると、1日あるいは1週間などの間に複数期間実行するジョブを簡単にスケジュールできます。ジョブのschedule_name属性をこのウィンドウ・グループの名前に設定すると、ウィンドウ・グループで指定したすべての期間で、このジョブを実行できます。
たとえば、「週末」という名前のウィンドウと「平日夜間」という名前のウィンドウがあり、この2つのウィンドウを「停止時間」という名前のウィンドウ・グループに追加するとします。データ・ウェアハウスの従業員は、この「停止時間」ウィンドウ・グループに従って、問合せを実行するジョブを作成できます。このウィンドウ・グループ（「平日夜間」と「週末」の時間帯）では、問合せに対して使用可能なリソースが高い比率で割り当てられる可能性があります。
ウィンドウ・グループのウィンドウがすでにオープンしているときに、そのウィンドウ・グループを指し示す新規ジョブが作成された場合、そのジョブはウィンドウ・グループの次のウィンドウがオープンするまで開始されません。
ウィンドウ・グループの作成例は、「ウィンドウ・グループの作成」を参照してください。
この項では、スケジューラのアーキテクチャについて説明します。この項の内容は、次のとおりです。
図26-4に、データベースによるジョブの処理方法を示します。
ジョブ表は、すべてのジョブに対するコンテナです。データベースごとに1つの表があります。ジョブ表には、すべてのジョブに関して、ロギング・レベルや所有者名などの情報が格納されます。この情報は*_SCHEDULER_JOBSビューで参照できます。
ジョブはデータベース・オブジェクトであるため、累積されて多くの領域を使用する場合があります。これを回避するために、ジョブ・オブジェクトは、ジョブの完了後、デフォルトで自動的に削除されます。この動作は、auto_dropジョブ属性によって制御されます。
使用可能なジョブのビューと管理については、「スケジューラのデータ・ディクショナリ・ビュー」を参照してください。
ジョブ・コーディネータ・バックグラウンド・プロセス（cjqNNN）は、必要になると自動的に起動し、停止します。データベースの起動時に、ジョブ・コーディネータは起動されません。しかし、近いうちに実行されるジョブまたはオープンされるウィンドウがあるかどうかは、データベースが監視しています。コーディネータは、このようなジョブやウィンドウがある場合に起動されます。
実行中のジョブまたはウィンドウがある間は、コーディネータは継続的に実行されます。スケジューラが一定期間非アクティブな状態にあり、近い将来にスケジュールされたジョブまたはウィンドウがない場合、コーディネータは自動的に停止します。
ジョブ・コーディネータを起動するかどうかをデータベースが判断する際は、ジョブのサービス・アフィニティが考慮されます。たとえば、近い将来スケジュールされるジョブが1つのみで、このジョブが属するジョブ・クラスで、4つのRACインスタンスのうち2つのみにサービス・アフィニティがある場合は、この2つのインスタンスのジョブ・コーディネータのみが起動されます。 詳細は、「スケジューラ使用時のサービス・アフィニティ」を参照してください。
ジョブ・コーディネータの機能は次のとおりです。
CREATE_JOBプロシージャを使用してジョブが作成されたときに起動します。
ジョブ・コーディネータによるジョブ表のチェックの時期は、設定する必要はありません。期間はシステムによって自動的に選択されます。起動するジョブ・スレーブ数は、CPUの負荷と未処理のジョブ数に基づいて、コーディネータで自動的に決定されます。特別な場合は、データベース管理者がDBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTEプロシージャにMAX_JOB_SLAVE_PROCESSESパラメータを設定することで、起動するスレーブの最大数を制限できます。
インスタンスごとに1つのジョブ・コーディネータが使用されます。これは、RAC環境の場合も同じです。
|
関連項目:
ジョブ・コーディネータの管理については、「スケジューラのデータ・ディクショナリ・ビュー」を参照してください。RACの情報については、「Real Application Clusters環境におけるスケジューラの使用」を参照してください。 |
処理のためにジョブが取り出されると、ジョブ・スレーブは次のことを実行します。
ジョブ・スレーブは、発行されたジョブを実際に実行します。ジョブの実行時期になるとジョブ・コーディネータによって起動されます。ジョブ・スレーブは、ジョブ表からジョブを実行するためのメタデータを収集します。
ジョブが終了すると、スレーブは次のことを実行します。
スケジューラは、必要に応じてスレーブ・プールを動的にサイズ変更します。
Real Application Clusters（RAC）環境でのスケジューラでは、各データベースに対して1つのジョブ表が使用され、各インスタンスに対して1つのジョブ・コーディネータが使用されます。ジョブ・コーディネータは相互に通信し、情報を最新に保ちます。スケジューラは、ジョブ・クラスのジョブの負荷を均等にするように試みます。ジョブ・クラスにサービス・アフィニティがない場合は、使用可能なすべてのインスタンス間で負荷を均等にし、ジョブ・クラスにサービス・アフィニティがある場合は、特定のサービスに割り当てられたインスタンス間で負荷を均等にします。
図26-5に、典型的なRACアーキテクチャを示します。各インスタンスのジョブ・コーディネータは他のコーディネータと情報を交換します。
スケジューラを使用すると、ジョブを実行するデータベース・サービスを指定できます（サービス・アフィニティ）。この結果、インスタンス・アフィニティより可用性が向上します。これは、インスタンスが停止した場合に、そのサービスに他のノードが動的に割り当てられることが保証されるためです。インスタンス・アフィニティにはこの機能がないため、インスタンスが停止した場合、そのインスタンスに対するアフィニティを持つジョブはいずれもインスタンスが回復するまで実行できません。図26-6は、サービスとインスタンスの典型的な使用例です。
図26-6では、サービスのプロパティが変更可能で、その変更はスケジューラによって自動的に認識されます。
各ジョブ・クラスで、データベース・サービスを指定できます。サービスの指定がない場合、このジョブ・クラスは、起動しているすべてのインスタンスへのマッピングが保証されている内部サービスに属します。
Oracle Database 11g リリース1からは、データベースがプライマリ・データベースかロジカル・スタンバイ・データベースかに基づいて、スケジューラがOracle Data Guard環境でジョブを実行できるようになりました。
フィジカル・スタンバイ・データベースの場合、スケジューラのオブジェクトに対する変更またはプライマリ・データベース上のスケジューラのジョブによるデータベースの変更は、他のデータベースの変更と同様にフィジカル・スタンバイに適用されます。
プライマリ・データベースおよびロジカル・スタンバイ・データベースの場合は、データベースのロールがプライマリ・データベースの場合のみ、またはデータベースのロールがロジカル・スタンバイの場合のみジョブを実行できるように指定する追加機能があります。 指定するには、DBMS_SCHEDULER.SET_ATTRIBUTEプロシージャを使用してdatabase_roleジョブ属性を'PRIMARY'または'LOGICAL STANDBY'のいずれかの値に設定します （両方のロールでジョブを実行するには、ジョブのコピーを作成して、一方のジョブのdatabase_roleを'PRIMARY'に設定し、もう一方のジョブを'LOGICAL STANDBY'に設定します）。スイッチオーバーまたはフェイルオーバーの際、スケジューラは、新しいロールに固有のジョブの実行に自動的に切り替わります。フェイルオーバーの際は、プライマリ・データベースでそれまで正常に実行されていた記録を利用できるように、DMLがジョブ・イベント・ログに複製されます。
|
関連項目:
|
