| Oracle® Database管理者ガイド 11gリリース2 (11.2) B56301-08 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
数百または数千ものタスクのスケジューリングを簡素化するために、Oracle Databaseにはエンタープライズ・ジョブ・スケジューラであるOracle Schedulerが組み込まれています。Oracle Scheduler(スケジューラ)は、DBMS_SCHEDULER PL/SQLパッケージのプロシージャおよびファンクションにより実装されます。
スケジューラを使用すると、企業環境で様々なコンピューティング・タスクをいつどこで実施するかを制御できます。これらのタスクの効率的な管理および計画に役立ちます。多数の日常的なコンピューティング・タスクが手動で操作することなく確実に実行されるため、操作コストの削減、信頼性の高いルーチンの実現、人為的なエラーの最小化および必要期間の短縮が可能です。
スケジューラでは、洗練された柔軟なエンタープライズ・スケジューリング機能が提供されます。次のことを実行できます。
ローカル・データベースまたは1つ以上のリモートOracle Databaseで、プログラム・ユニット(PL/SQL無名ブロック、PL/SQLストアド・プロシージャおよびJavaストアド・プロシージャ)を実行できます。
外部実行可能ファイル(データベースの外部の実行可能ファイル)の実行
アプリケーション、シェル・スクリプト、バッチ・ファイルなどの外部実行可能ファイルをローカル・システムまたは1つ以上のリモート・システムで実行できます。リモート・システムにOracle Databaseをインストールする必要はありません。スケジューラ・エージェントのみが必要です。スケジューラ・エージェントは、Oracle Databaseがサポートするすべてのプラットフォームおよび他の一部のプラットフォームで使用できます。
次の方法によるジョブ実行のスケジュール。
特定の日時に1回または繰り返し実行するようにジョブをスケジュールできます。「特定の休日を除き毎週月曜日と木曜日の午前3時」または「業務上の各四半期の最終水曜日」のように、複雑な繰返し間隔を定義できます。詳細は、「ジョブの作成、実行および管理」を参照してください。
システム・イベントまたはビジネス・イベントに対応してジョブを開始できます。アプリケーションは、イベントを検出するとスケジューラに通知します。送信された通知のタイプに応じて、スケジューラは特定のジョブを開始します。イベントベースのスケジューリングの例として、ファイルがシステムに着信した時点、在庫が事前に指定したレベルを下回った時点、またはトランザクションに失敗した時点でジョブを開始させる場合があります。Oracle Database 11g リリース2以降では、File Watcherと呼ばれるスケジューラ・オブジェクトによって、ファイルがリモート・システムに到着したときに開始するジョブの構成タスクが簡略化されます。詳細は、「イベントを使用したジョブの開始」を参照してください。
前の1つ以上のタスクの結果に基づいてタスクを実行するようにスケジューラを設定できます。ブランチやネストしたチェーンを含んだ複雑な依存性チェーンを定義できます。詳細は、「ジョブ・チェーンの作成と管理」を参照してください。
ビジネス要件に基づくジョブの優先度付け。
スケジューラを使用すると、競合するジョブ間のリソース割当てを制御でき、ビジネス・ニーズに基づいてジョブ処理を調整できます。これは次の方法で実現されます。
ジョブ・クラスによるリソースの制御
共通の特性や動作を共有するジョブは、ジョブ・クラスと呼ばれるさらに大きなエンティティにグループ化できます。クラス間に優先度を付けるには、各クラスに割り当てられるリソースを制御します。そのため、重要なジョブが優先され、ジョブの完了に必要なリソースを確保できます。たとえば、データ・ウェアハウスをロードする重要なプロジェクトがある場合は、複数のデータ・ウェアハウス・ジョブをすべて1つのクラスにまとめ、使用可能なリソースの割当て比率を高くすることによって、その他のジョブより優先的に実行できます。また、ジョブ・クラス内のジョブに相対的な優先度を割り当てることもできます。
スケジュールに基づいたジョブの優先度の制御
スケジュールに基づいてジョブの優先度を変更できます。重要なジョブの定義は時間の経過とともに変化する場合があるため、スケジューラでは、期間ごとにジョブ間での優先度を変更することもできます。たとえば、データ・ウェアハウスのロードに使用される抽出、転送およびロード(ETL)のジョブが、オフピーク時に重要になり、ピーク時には重要にならない場合があります。また、業務上の四半期の終了時期に実行する必要があるジョブは、ETLジョブよりも優先させることが必要となる場合があります。このような場合は、各ジョブ・クラスに割り当てるリソースを変更して、クラス間での優先度を変更できます。詳細は、「ジョブ・クラスの作成」および「ウィンドウの作成」を参照してください。
ジョブの管理と監視
作成から完了までの間にジョブが通過する複数の状態を管理および監視できます。スケジューラはアクティビティをログに記録して、Enterprise ManagerまたはSQLを使用してビューを問い合せることで、ジョブのステータスやジョブの最終実行時刻などの情報を簡単に追跡できるようにします。このビューからジョブとその実行内容に関する有益な情報が得られるため、これを使用してジョブをより適切にスケジュールし管理できます。たとえば、DBAは特定のユーザーの失敗ジョブをすべて簡単に追跡できます。「スケジューラのデータ・ディクショナリ・ビュー」を参照してください。
複数の宛先のジョブ(1つのデータベースで定義され、複数のリモート・ホストで実行されるジョブ)を作成する場合、宛先ごとにジョブの状態を個別に監視するか、または親ジョブの状態を全体的に監視できます。
ジョブを詳細に監視するために、スケジューラがイベント・キューに提供するジョブの状態変更通知をアプリケーションによってサブスクライブできます。また、スケジューラでは、ジョブの状態が変化したとき、電子メール通知を送信することもできます。
「スケジューラの監視と管理」を参照してください。
クラスタ化された環境におけるジョブの実行と管理
クラスタは、同じタスクを実行するために連携して動作するデータベース・インスタンスのセットです。Oracle Real Application Clusters(Oracle RAC)は、アプリケーションを変更せずにスケーラビリティと信頼性を提供します。スケジューラは、このようなクラスタ化された環境でのジョブの実行を完全にサポートします。システムの負荷を均等にし、パフォーマンスを向上させるために、ジョブを実行するデータベース・サービスを指定することもできます。詳細は、「Real Application Clusters環境におけるスケジューラの使用」を参照してください。
スケジューラを使用するには、スケジューラ・オブジェクトを作成します。スキーマ・オブジェクトには、ジョブ・スケジューリングの内容、時期および場所を定義します。スケジューラ・オブジェクトにより、モジュール化された方法でタスクを管理できます。この方法のメリットの1つは、既存のタスクに類似する新規タスクを作成する際にオブジェクトを再利用できることです。
重要なスケジューラ・オブジェクトはジョブです。ジョブは、実行する処理、処理のスケジュール、処理が行われる場所を定義します。他のほとんどのスケジューラ・オブジェクトは、ジョブをサポートするために作成されます。
|
注意: DBMS_JOBパッケージはOracle Schedulerジョブで置き換えられますが、下位互換性を保つために引き続きサポートされます。この章では、スケジューラ・ジョブのみを使用しているものと仮定します。両方を一度に使用しているか、DBMS_JOBからスケジューラ・ジョブに移行している場合は、付録A「Oracle Database 11gリリース2におけるDBMS_JOBのサポート」を参照してください。 |
スケジューラ・オブジェクトは次のとおりです。
これらの各オブジェクトの詳細は、後で説明します。
スケジューラ・オブジェクトはスキーマに属しているため、オブジェクト権限を付与できます。ジョブ・クラス、ウィンドウおよびウィンドウ・グループのような一部のスケジューラ・オブジェクトは、ユーザーがSYSでない場合も常にSYSスキーマに作成されます。他のオブジェクトはすべて、ユーザー自身のスキーマまたは指定のスキーマに作成されます。
プログラム・オブジェクト(プログラム)では、スケジューラによって実行される内容が記述されます。プログラムの要素は次のとおりです。
処理: ストアド・プロシージャ名、オペレーティング・システムのファイル・システムにある実行可能ファイル(外部実行可能ファイル)の名前、PL/SQL無名ブロックのテキストなど。
タイプ: STORED_PROCEDURE、PLSQL_BLOCKまたはEXTERNALがあり、EXTERNALは外部実行可能ファイルを示します。
引数の数: ストアド・プロシージャまたは外部実行可能ファイルが受け入れる引数の数。
プログラムはジョブとは別のエンティティです。ジョブは特定の時刻または特定のイベントの発生により実行されて、特定のプログラムを起動します。既存のプログラム・オブジェクトを指し示すジョブを作成できるため、様々なジョブが同じプログラムを使用して、別の時刻に別の設定でプログラムを実行できます。正しい権限があると、様々なユーザーが同じプログラムを再定義せずに使用できます。そのため、既存のプログラムのリストからユーザーが選択できるプログラム・ライブラリを作成できます。
プログラムで参照されるストアド・プロシージャまたは外部実行可能ファイルが引数を受け入れる場合は、これらの引数をプログラムの作成後に個別ステップで定義します。各引数のデフォルト値を定義することもできます。
スケジュール・オブジェクト(スケジュール)は、ジョブの実行時期と実行回数を指定します。スケジュールは複数のジョブで共有できます。たとえば、業務上の四半期の終了時期は、多くのジョブにとって共通の期間である可能性があります。ジョブの作成者は、新規のジョブを定義するたびに四半期の終了時期のスケジュールを定義するかわりに、名前付きのスケジュールを指し示すことができます。
スケジュールには、次の2種類があります。
時間スケジュール
時間スケジュールでは、ジョブを即時に実行するか、後で実行するようにスケジュールできます。時間スケジュールには、開始日時、オプションの終了日時およびオプションの繰返し間隔が含まれています。
イベント・スケジュール
イベント・スケジュールでは、在庫がしきい値を下回った時点、またはファイルがシステムに到着した時点など、特定のイベントが発生した時点でジョブを実行するように指定できます。イベントの詳細は、「イベントを使用したジョブの開始」を参照してください。
ジョブ・オブジェクト(ジョブ)は、ユーザー定義のタスクを記述するメタデータのコレクションです。実行される内容(処理)、タイミング(1回のみ、定期的なスケジュールまたはトリガー・イベント)、場所(宛先)および使用される資格証明を定義します。ジョブにはスキーマである所有者が存在し、ジョブはそのスキーマで作成されます。
1つ以上の宛先を指定して、ジョブが実行される場所を定義します。宛先もスケジューラ・オブジェクトであり、この項で後述します。宛先を指定しないと、ローカル・データベースでジョブが実行されるとみなされます。
ジョブの処理は、次のいずれかの方法で指定します。
実行するデータベース・プログラム・ユニットまたは外部実行可能ファイルをジョブ属性として指定する方法。この方法をジョブの処理のインライン指定と呼びます。
既存のプログラム・オブジェクト(プログラム)名をジョブ属性として指定し、実行するデータベース・プログラム・ユニットまたは外部実行可能ファイルをプログラムで指定する方法。ジョブ所有者には、プログラムに対するEXECUTE権限またはEXECUTE ANY PROGRAMシステム権限が必要です。
データベース・プログラム・ユニットを実行するジョブをデータベース・ジョブと呼びます。外部実行可能ファイルを実行するジョブを外部ジョブと呼びます。
ジョブ・スケジュールは、次のいずれかの方法で指定します。
ジョブ・オブジェクトの属性を設定して開始日時、終了日時および繰返し間隔を定義するか、またはジョブを開始するイベントを定義する方法。この方法をスケジュールのインライン指定と呼びます。
開始日時、終了日時および繰返し間隔を定義する既存のスケジュール・オブジェクト(スケジュール)の名前をジョブ属性として指定するか、イベントを定義する方法。
ジョブの宛先は、次のいずれかの方法で指定します。
指定された単一の宛先オブジェクトをジョブ属性として指定する方法。この場合、ジョブは1つのリモートの場所で実行されます。
指定された宛先グループ(リモートの場所のリストと同じ)をジョブ属性として指定する方法。この場合、ジョブはすべてのリモートの場所で実行されます。
宛先属性を定義せずにジョブをローカルに実行する方法。ジョブは次のいずれかを実行します。
ローカル・データベースのデータベース・プログラム・ユニット(ジョブが作成されたデータベース)
ジョブ処理タイプに応じた、ローカル・ホストの外部実行可能ファイル
ジョブの資格証明は、次のいずれかの方法で指定します。
ジョブ属性を名前付き資格証明オブジェクトとして指定する方法で、次のいずれかが含まれます。
データベースのユーザー名とパスワード(データベース・ジョブの場合)
ホスト・オペレーティング・システムのユーザー名とパスワード(外部ジョブの場合)
ジョブは、資格証明に指定されているユーザーとして実行されます。
ジョブの資格証明属性をNULLのままにする方法。(表28-1を参照。)ジョブの所有者は、ジョブが作成されたスキーマです。
1つ以上のリモートの場所でデータベース・プログラム・ユニットを実行するジョブをリモート・データベース・ジョブと呼びます。1つ以上のリモートの場所で外部実行可能ファイルを実行するジョブをリモート外部ジョブと呼びます。
ジョブを作成して有効化した後は、スケジューラによりスケジュールに従って自動的にジョブが実行されるか、または指定のイベントが検出されたときに実行されます。ジョブの実行ステータスとジョブ・ログは、データ・ディクショナリ・ビューを問い合せることで確認できます。ジョブが複数の宛先で実行される場合は、各宛先でジョブの状態を問い合せることができます。
宛先オブジェクト(宛先)は、ジョブを実行する場所を定義します。
宛先には、次の2種類があります。
外部宛先: リモート外部ジョブを実行するリモート・ホストの名前とIPアドレスを指定します。
データベース宛先: リモート・データベース・ジョブを実行するリモート・データベース・インスタンスを指定します。
外部実行可能ファイルを実行するジョブ(外部ジョブ)では外部宛先を指定する必要があり、データベース・プログラム・ユニットを実行するジョブ(データベース・ジョブ)ではデータベース宛先を指定する必要があります。
ジョブの作成時に宛先を指定すると、その宛先でジョブが実行されます。宛先を指定しないと、ジョブが作成されたシステムでローカルに実行されます。
宛先のリストで構成される宛先グループを作成して、この宛先グループをジョブの作成時に参照することもできます。この場合、ジョブはグループのすべての宛先で実行されます。
|
注意: 宛先グループには、キーワードLOCALをグループ・メンバーとして含めることもでき、これはローカル・ホストまたはローカル・データベースでもジョブを実行することを示します。 |
別のユーザーによって作成された宛先を使用する場合に、オブジェクト権限は必要ありません。
宛先オブジェクトで指定されたリモートの場所でスケジューラ・エージェントが実行されており、かつ、ジョブを作成するデータベースにそのエージェントが登録されている必要があります。スケジューラ・エージェントを使用すると、ローカル・スケジューラとリモート・ホストとの通信や、リモート・ホストでのジョブの開始と停止が可能になり、リモート・ジョブの状態をローカル・データベースに戻すことができます。詳細は、「宛先の作成」を参照してください。
外部宛先を明示的に作成することはできません。外部宛先は、データベースにスケジューラ・エージェントを登録するとき、ローカル・データベースで作成されます。外部宛先に割り当てられる名前は、エージェント名と同じです。エージェント名はエージェントのインストール後に構成できますが、ホスト名の最初の部分(最初のドット区切りの前)であるデフォルトのエージェント名も使用できます。たとえば、dbhost1.us.example.comというホストにエージェントをインストールした場合、デフォルトのエージェント名はDBHOST1になります。
データベース宛先は、DBMS_SCHEDULER.CREATE_DATABASE_DESTINATIONプロシージャを使用して作成します。
|
注意: ローカル・ホストで複数のデータベース・インスタンスが実行されている場合は、他のインスタンスを指定してデータベース宛先を作成することによって、そのインスタンスでジョブを実行できます。したがって、リモート・データベース・インスタンスは、必ずしもリモート・ホストに存在している必要はありません。このような追加のインスタンスでリモート・データベース・ジョブを実行できるようにするには、ローカル・ホストでスケジューラ・エージェントが実行されている必要があります。 |
あるファイルがシステムに到着するとスケジューラによってジョブが開始されるようにする場合、File Watcherオブジェクト(File Watcher)にはそのファイルの場所、名前および他のプロパティを定義します。ファイル・ウォッチャを作成し、次に、そのファイル・ウォッチャを参照する任意の数のイベントベースのジョブまたはイベント・スケジュールを作成します。ファイル・ウォッチャでは、指定されたファイルの到着を検出すると、到着イベントを呼び出します。ファイルの到着イベントによって開始されたジョブでは、新しく到着したファイルを示すイベント・メッセージを取得できます。
File Watcherでは、ローカル・システム(Oracle Databaseを実行しているホスト・コンピュータと同じ)またはリモート・システム(リモート・システムでスケジューラ・エージェントが稼働している場合)でファイルが監視されます。
File Watcherを使用するには、データベースのJava仮想マシン(JVM)コンポーネントをインストールする必要があります。
詳細は、「File Watcherの概要」を参照してください。
資格証明は、専用のデータベース・オブジェクトに格納されているユーザー名とパスワードのペアです。データベース・インスタンスまたはオペレーティング・システムで資格証明を使用してジョブが認証されると、ジョブを実行できます。資格証明には、次の用途があります。
リモート・データベース・ジョブ: 資格証明には、データベースのユーザー名とパスワードが含まれます。リモート・データベース・ジョブで指定されるストアド・プロシージャまたはPL/SQLブロックは、このデータベース・ユーザーとして実行されます。
外部ジョブ(ローカルまたはリモート): 資格証明には、ホスト・オペレーティング・システムのユーザー名とパスワードが含まれています。ジョブの外部実行可能ファイルは、このユーザー名とパスワードを使用して実行されます。
File Watcher: 資格証明には、ホスト・オペレーティング・システムのユーザー名とパスワードが含まれています。ファイルの到着イベントを処理するジョブは、このユーザー名とパスワードを使用して、到着したファイルにアクセスします。
データベース内の資格証明のリストを表示するには、*_SCHEDULER_CREDENTIALSビューを問い合せます。資格証明パスワードは不明瞭な状態で格納されるため、*_SCHEDULER_CREDENTIALSビューには表示されません。
チェーンは、前の1つ以上のジョブの結果に応じて異なるジョブが開始される依存性スケジューリングを実装できる手段です。チェーンは、依存性ルールを使用して結合された複数のステップで構成されています。依存性ルールでは、ステップまたはチェーン自体の開始または停止に使用できる条件を定義します。条件には、前のステップの成功、失敗、完了コードまたは終了コードを使用できます。AND/ORなどの論理式を条件に使用することもできます。チェーンは、実行するタスクと、タスクの実行時期の選択に関して多くの可能なパスを持ち、ある意味でDecision Treeに似ています。
最も単純な形式のチェーンは、1つの目的のために互いにリンクされた複数のスケジューラ・プログラム・オブジェクト(プログラム)で構成されています。チェーンの例には、「プログラムAを実行してからプログラムBを実行するが、プログラムAとプログラムBの両方が正常に完了した場合にのみプログラムCを実行し、正常に完了しない場合は1時間待機してからプログラムDを実行する」などがあります。
チェーンの作成が必要な例として、融資申請を検証して承認した後に融資するなど、正常な取引のために様々なプログラムの結合を必要とする金融取引などがあります。
スケジューラ・ジョブは、単一のプログラム・オブジェクトを指し示すかわりにチェーンを指し示すことができます。その場合、ジョブはチェーンを開始する役割を持ちます。このジョブはチェーン・ジョブと呼ばれます。複数のチェーン・ジョブで同じチェーンを指し示すことができ、そのうちの複数のジョブを同時に実行することで、チェーンの様々な進捗ポイントで同じチェーンの複数インスタンスをそれぞれ作成できます。
チェーン内の各位置はステップと呼ばれます。通常は、最初の一連のチェーン・ステップを開始し、後続のステップは、1つ以上前のステップの完了に従って実行されます。各ステップは、次のいずれかを指し示します。
プログラム・オブジェクト(プログラム)
プログラムでは、データベース・プログラム・ユニット(ストアド・プロシージャまたはPL/SQL無名ブロックなど)または外部実行可能ファイルを実行できます。
別のチェーン(ネストしたチェーン)
チェーンをネストするレベル数に制限はありません。
イベント・スケジュール、インライン・イベントまたはFile Watcher
イベント・スケジュールを指し示すステップ、またはインライン・イベント指定を持つステップを開始した後、ステップは特定のイベントが呼び出されるまで待機します。同様に、File Watcherインラインを参照するステップ、またはFile Watcherを参照するイベント・スケジュールを指し示すステップは、ファイルの到着イベントが呼び出されるまで待機します。ファイルの到着イベントまたは他のタイプのイベントの場合、イベントが発生すると、このステップが完了し、イベント・ステップに依存するステップが実行可能になります。チェーン内のイベントの一般例は、承認や拒否のようなユーザーの介入です。
チェーン内の複数のステップは、同じプログラムまたはネストしたチェーンを起動できます。
各ステップには、ステップが実行されるデータベース宛先または外部宛先のいずれかを指定できます。宛先を指定しないと、ステップが元の(ローカル)データベースまたはローカル・ホストで実行されます。チェーン内の各ステップは、異なる宛先で実行できます。
図28-1に、複数のブランチを持つチェーンを示します。このチェーンでは、ルールが次のように定義されているとします。
ステップ1が正常に完了した場合は、ステップ2を開始します。
ステップ1が失敗してエラー・コード20100が戻された場合は、ステップ3を開始します。
ステップ1が失敗して他のエラー・コードが戻された場合は、チェーンを終了します。
ステップ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属性に指定されているリソース・コンシューマ・グループが優先されます。
コンシューマ・グループに対するサービスのマッピングの詳細は第27章のOracle Database Resource Managerを使用したリソースの管理を参照してください。
ジョブの優先度によるグループ化
同じジョブ・クラス内では、個々のジョブに対して1から5の優先度値を割り当てて、クラス内の2つのジョブが同時に起動するようにスケジュールされた場合に、優先度の高いジョブが優先されるように設定できます。こうすることで、重要度の高いジョブが適切なタイミングで完了するのを、重要度の低いジョブが妨げないようにできます。
2つのジョブに同じ優先値が割り当てられている場合は、開始日の早いジョブが優先されます。ジョブに優先度が割り当てられていない場合、そのジョブの優先度は3にデフォルト設定されます。
|
注意: ジョブの優先度は、同じクラス内のジョブの間で優先度を付ける場合にのみ使用されます。同じスケジュールを共有している場合でも、クラスA内の優先度の高いジョブが、クラスB内の優先度の低いジョブより先に開始されることは保証されません。異なるクラスのジョブ間の優先度付けは、現行のリソース・プランと、指定されたリソース・コンシューマ・グループまたは各ジョブ・クラスのサービス名に応じて異なります。 |
ジョブ・クラスを定義するときは、ジョブを機能別に分類してください。マーケティング、生産、販売、財務および人事など、同様のデータにアクセスするジョブをグループに分けることを考慮してください。
次の制限事項に注意してください。
ジョブは必ず1つのクラスに属している必要があります。ジョブを作成するときは、そのジョブが属するクラスを指定できます。クラスを指定しない場合、ジョブは自動的にDEFAULT_JOB_CLASSクラスのメンバーになります。
クラス内にジョブが存在している状態でクラスを削除するとエラーになります。クラスのメンバーであるジョブがまだ存在している場合でもクラスを強制的に削除することはできますが、そのクラスを参照しているジョブはすべて自動的に使用禁止になり、DEFAULT_JOB_CLASSクラスに割り当てられます。削除したクラスに属しているジョブの中ですでに実行中のジョブは、ジョブの開始時に判別されたクラスの設定のまま実行されます。
通常、ウィンドウを作成するのは、スケジューラ管理者のロールを持っている場合のみです。
日または週などの様々な期間中に、ジョブを自動的に開始したり、複数のジョブ間のリソース割当てを変更するには、ウィンドウを作成します。ウィンドウは、午前12時から午前6時など、開始と終了が明確に定義された期間で表されます。
ウィンドウは、ジョブ・クラスを使用して、リソース割当てを制御します。各ウィンドウは、ウィンドウがオープンしたとき(アクティブになったとき)に、アクティブにするリソース・プランを指定し、各ジョブ・クラスは、リソース・コンシューマ・グループを指定するか、コンシューマ・グループにマップできるデータベース・サービスを指定します。したがって、ウィンドウ内で実行するジョブには、そのジョブ・クラスのコンシューマ・グループとウィンドウのリソース・プランに応じてリソースが割り当てられます。
図28-2に、2つのウィンドウが設定された稼働日を示します。この構成では、コンシューマ・グループ1にリンクしているジョブ・クラスに属するジョブが、午後よりも午前にリソースを多く使用しています。コンシューマ・グループ2にリンクしているジョブ・クラスのジョブは、この逆です。
リソース・プランおよびコンシューマ・グループの詳細は、第27章のOracle Database Resource Managerを使用したリソースの管理を参照してください。
各ウィンドウには、優先度を割り当てることができます。ウィンドウが重複する場合は、優先度の高いウィンドウが優先度の低いウィンドウより優先して選択されます。スケジューラは、ウィンドウの開始時間と終了時間に従って、各ウィンドウを自動的にオープンしたり、クローズします。
ジョブは、そのschedule_name属性でウィンドウを指定できます。スケジューラは、このウィンドウがオープンするとジョブを開始します。ウィンドウがすでにオープンしている場合にそのウィンドウを指し示す新規ジョブが作成されると、そのジョブはウィンドウが次回オープンするまで開始されません。
|
注意: 必要な場合は、現行のリソース・プランが切り替わらないように一時的にウィンドウをブロックできます。詳細は、「Oracle Database Resource Managerの有効化とプランの切替え」または |
お薦めする方法ではありませんが、ウィンドウは重複して設定できます。
一度にアクティブにできるウィンドウは1つのみであるため、ウィンドウが重複したときにどのウィンドウをアクティブにするかを判別するために、次のルールが使用されます。
同じ優先度のウィンドウが重複している場合は、アクティブなウィンドウがオープンしたままになります。ただし、優先度の高いウィンドウと重複している場合は、優先度の低いウィンドウがクローズし、優先度の高いウィンドウがオープンします。優先度の低いウィンドウを指定しているスケジュールを持つ現在実行中のジョブは、ジョブの作成時に割り当てた動作に従って停止される場合があります。
ウィンドウの終了時に、定義されているウィンドウが複数ある場合は、優先度の最も高いウィンドウがオープンします。すべてのウィンドウの優先度が同じ場合は、残りの時間の比率の最も高いウィンドウがオープンします。
削除対象のオープン中のウィンドウは、自動的にクローズします。この時点で前述のルールが適用されます。
2つのウィンドウが重複した場合は、スケジューラのログにエントリが必ず記録されます。
図28-3に、24時間スケジュールの場合のウィンドウ、リソース・プランおよび優先度の判別方法に関する一般的な例を示します。次の2つの例では、ウィンドウ1はリソース・プラン1に、ウィンドウ2はリソース・プラン2に関連付けられ、以下も同様に関連付けられているとします。
図28-3では、次の処理が発生します。
午前12時から午前4時
いずれのウィンドウもオープンしていないため、デフォルトのリソース・プランが有効です。
午前4時から午前6時
ウィンドウ1には低い優先度が割り当てられていますが、高い優先度のウィンドウが他に存在しないためウィンドウ1がオープンします。したがって、リソース・プラン1が有効です。
午前6時から午前9時
ウィンドウ1より優先度の高いウィンドウ3がオープンします。したがって、リソース・プラン3が有効です。
午前9時から午前11時
優先度が高いウィンドウがオープンしたために、ウィンドウ1は午前6時にクローズされましたが、この優先度の高いウィンドウが午前9時にクローズしたため、ウィンドウ1の元のスケジュールの2時間がウィンドウ1にまだ残っています。この残り2時間のためにそれが再オープンされ、リソース・プランが有効になります。
午前11時から午後2時
いずれのウィンドウもオープンしていないため、デフォルトのリソース・プランが有効です。
午後2時から午後3時
ウィンドウ2がオープンするため、リソース・プラン2が有効です。
午後3時から午後8時
ウィンドウ4の優先度はウィンドウ2と同じであるため、ウィンドウ2への割込みはなく、リソース・プラン2が有効です。
午後8時から午後10時
ウィンドウ4がオープンしているため、リソース・プラン4が有効です。
午後10時から午前12時
いずれのウィンドウもオープンしていないため、デフォルトのリソース・プランが有効です。
図28-4に、24時間スケジュールの場合のウィンドウ、リソース・プランおよび優先度の判別方法に関する別の例を示します。
図28-4では、次の処理が発生します。
午前12時から午前4時
デフォルトのリソース・プランが有効です。
午前4時から午前6時
ウィンドウ1には低い優先度が割り当てられていますが、高い優先度のウィンドウが他に存在しないためウィンドウ1がオープンします。したがって、リソース・プラン1が有効です。
午前6時から午前9時
ウィンドウ1より優先度の高いウィンドウ3がオープンします。ウィンドウ6は優先度の高い別のウィンドウがすでに有効であるためオープンしません。
午前9時から午前11時
午前9時の時点では、ウィンドウ5またはウィンドウ1の2つが選択対象です。両方とも優先度が低いため、残り継続時間の比率の大きさに基づいて選択されます。ウィンドウ1の総継続時間と比較して、ウィンドウ5の残り時間の比率の方が大きい状態です。たとえば、ウィンドウ1が午前11時30分まで延長された場合でも、ウィンドウ5の残り継続時間に対する比率が2/3×100%であるのに対して、ウィンドウ1は2.5/7×100%であるため比率が小さくなります。したがって、リソース・プラン5が有効になります。
グループは、スケジューラ・オブジェクトのリストを指定します。オブジェクトのリストを引数としてDBMS_SCHEDULERパッケージ・プロシージャに渡すかわりに、オブジェクトがメンバーとして含まれるグループを作成した後、グループ名をプロシージャに渡すことができます。
グループには、次の3種類があります。
データベース宛先グループ: リモート・データベース・ジョブを実行するためのデータベース宛先がメンバーです。
外部宛先グループ: リモート外部ジョブを実行するための外部宛先がメンバーです。
ウィンドウ・グループ: スケジューラのウィンドウがメンバーです。
グループ内のすべてのメンバーは同一タイプで、各メンバーが一意であることが必要です。
グループは、DBMS_SCHEDULER.CREATE_GROUPプロシージャを使用して作成します。
ジョブを複数の宛先で実行する場合、データベース宛先グループまたは外部宛先グループを作成し、それをジョブのdestination_name属性に割り当てます。ジョブに複数の宛先を指定する場合は、宛先グループをジョブのdestination_nameとして指定する必要があります。
通常、ウィンドウ・グループを作成するのは、スケジューラ管理者のロールを持っている場合のみです。
ジョブのスケジュールで、ウィンドウを使いやすいようにグループ化できます。ウィンドウ・グループを使用すると、1日あるいは1週間などの間に複数期間実行するジョブを簡単にスケジュールできます。ジョブのschedule_name属性をこのウィンドウ・グループ名に設定すると、ウィンドウ・グループ内のウィンドウで指定されたすべての期間で、このジョブを実行できます。
たとえば、「Weekends」というウィンドウと「Weeknights」というウィンドウがある場合に、これらの2つのウィンドウを「Downtime」というウィンドウ・グループに追加できます。これにより、使用可能なリソースを高い割合で問合せに割り当てることができる時間帯(平日の夜と週末)のDowntimeウィンドウ・グループに問合せを実行するジョブをデータ・ウェアハウスのスタッフが作成できます。
ウィンドウ・グループのウィンドウがすでにオープンしているときに、そのウィンドウ・グループを指し示す新規ジョブが作成された場合、そのジョブはウィンドウ・グループの次のウィンドウがオープンするまで開始されません。
この項の内容は次のとおりです。
スケジューラは、次のタイプのジョブをサポートしています。
データベース・ジョブでは、PL/SQL無名ブロック、PL/SQLストアド・プロシージャおよびJavaストアド・プロシージャなどのOracle Databaseプログラム・ユニットが実行されます。処理がインラインで指定されているデータベース・ジョブの場合、job_typeは'PLSQL_BLOCK'または'STORED_PROCEDURE'に設定され、job_actionにはPL/SQL無名ブロックのテキストまたはストアド・プロシージャ名が含まれています。(プログラムがインラインで指定されているプログラム処理ではなく名前付きプログラム・オブジェクトである場合は、それに応じて対応するprogram_typeおよびprogram_actionを設定する必要があります。)
元のデータベース(ジョブが作成されたデータベース)で実行されるデータベース・ジョブをローカル・データベース・ジョブまたは単にジョブと呼びます。元のデータベース以外のターゲット・データベースで実行されるデータベース・ジョブをリモート・データベース・ジョブと呼びます。
ローカル・データベース・ジョブおよびリモート・データベース・ジョブの両方の実行結果を元のデータベースのジョブ・ログ・ビューに表示できます。
ローカル・データベース・ジョブは、ジョブの所有者であるデータベース・ユーザーとして元のデータベースで実行されます。ジョブの所有者は、ジョブが作成されたスキーマの名前です。
リモート・データベース・ジョブのターゲット・データベースは、リモート・ホスト上のOracle Databaseまたは元のデータベースと同じホスト上の別のデータベース・インスタンスのどちらにもできます。リモート・データベース・ジョブは、ジョブのdestination_name属性に含まれる既存のデータベース宛先オブジェクトの名前を指定して識別します。
リモート・データベース・ジョブを作成するには、Oracle Database 11g リリース2以降が必要です。ただし、ジョブのターゲット・データベースとしては、任意のOracle Databaseリリースを使用できます。ターゲット・データベースに対するパッチは不要です。(ターゲット・データベース・ホストが元のデータベース・ホストと同じ場合でも)ターゲット・データベース・ホストにスケジューラ・エージェントをインストールして、元のデータベースにエージェントを登録する必要があるだけです。エージェントはOracle Client 11g リリース2以降からインストールする必要があります。
リモート・データベース・ジョブは、ターゲット・データベースで有効なユーザーとして実行する必要があります。必要なユーザー名とパスワードを、リモート・データベース・ジョブに割り当てた資格証明オブジェクトとともに指定します。
外部ジョブでは、外部実行可能ファイルが実行されます。外部実行可能ファイルは、データベースの外部で実行されるオペレーティング・システム実行可能ファイルです。外部ジョブの場合、job_typeは'EXECUTABLE'と指定されています。(名前付きプログラムを使用している場合は、対応するprogram_typeが'EXECUTABLE'になります)。job_action(または対応するprogram_action)には、必要な外部実行可能ファイルのパス(コマンドライン引数を除く)が、オペレーティング・システムに依存したフルパスの形式で入ります。たとえば、/usr/local/bin/perlやC:\perl\bin\perlのようになります。
Windowsのバッチ・ファイルは直接実行できないため、コマンド・プロンプト(cmd.exe)で実行する必要があることに注意してください。
データベース・ジョブの場合と同様に、外部ジョブを作成する際にスキーマを割り当てることができます。割り当てたスキーマはジョブの所有者になります。外部ジョブをSYSスキーマに作成することもできますが、この方法はお薦めしません。
ローカル外部ジョブまたはリモート外部ジョブを作成するには、CREATE JOB権限とCREATE EXTERNAL JOB権限の両方が必要です。
外部実行可能ファイルは、オペレーティング・システム・ユーザーとして実行する必要があります。したがって、スケジューラでは、作成する外部ジョブにオペレーティング・システムの資格証明を割り当てることができます。リモート・データベース・ジョブの場合と同様に、これらの資格証明をスケジューラ資格証明オブジェクト(資格証明)で指定し、資格証明を外部ジョブに割り当てます。
外部ジョブには、ローカル外部ジョブとリモート外部ジョブの2つのタイプがあります。ローカル外部ジョブでは、そのジョブがスケジュールされているデータベースと同じコンピュータ上で外部実行可能ファイルが実行されます。リモート外部ジョブは、リモート・ホスト上の実行可能ファイルを実行します。リモート・ホストにはOracle Databaseは必要なく、スケジューラ・エージェントをインストールして登録するのみで十分です。
|
注意: Windowsでは、外部実行可能ファイルを実行するホスト・ユーザーにLog on as a batch jobログオン権限を割り当てる必要があります。 |
次の項では、ローカル外部ジョブおよびリモート外部ジョブについて詳細に説明します。
ローカル外部ジョブでは、そのジョブがスケジュールされているOracle Databaseと同じコンピュータ上で外部実行可能ファイルが実行されます。このようなジョブでは、destination_nameジョブ属性がNULLになっています。
ローカル外部ジョブでは、stdoutおよびstderrの出力がディレクトリORACLE_HOME/scheduler/log内のログ・ファイルに書き込まれます。これらのファイルの内容は、DBMS_SCHEDULER.GET_FILEで取得できます。
ローカルの外部ジョブに資格証明を割り当てる必要はありませんが、セキュリティ向上のために割り当てることをお薦めします。資格証明を割り当てない場合、デフォルトの資格証明を使用してジョブが実行されます。表28-1に、様々なプラットフォームおよび様々なジョブ所有者のデフォルト資格証明を示します。
表28-1 ローカル外部ジョブに対するデフォルトの資格証明
| SYSスキーマのジョブか | プラットフォーム | デフォルトの資格証明 |
|---|---|---|
|
はい |
すべて |
Oracle Databaseをインストールしたユーザー。 |
|
いいえ |
UNIXとLinux |
ファイル |
|
いいえ |
Windows |
注意: このサービスは手動で有効化して開始する必要があります。セキュリティ向上のため、ローカル・システム・アカウントのかわりに指名ユーザーを使用することをお薦めします。 |
|
注意: デフォルト資格証明は以前のリリースのOracle Databaseとの互換性のために含まれており、将来のリリースでは非推奨になる可能性があります。そのため、すべてのローカル外部ジョブに資格証明を割り当てることをお薦めします。 |
資格証明が割り当てられていないローカル外部ジョブの実行を禁止するには、ORACLE_HOME/rdbms/admin/externaljob.oraファイルからrun_user属性を削除する(UNIXとLinuxの場合)か、OracleJobSchedulerサービスを停止します(Windowsの場合)。SYSスキーマ内のローカル外部ジョブは、これらのステップでは実行不可になりません。
|
関連項目:
|
リモート外部ジョブは、リモート・ホスト上の実行可能ファイルを実行します。リモート・ホストには、Oracle Databaseがインストールされている場合も、されていない場合もあります。特定のリモート・ホストでリモート外部ジョブを実行できるようにするには、リモート・ホストでスケジューラ・エージェントをインストールし、それをローカル・データベースで登録する必要があります。データベースは、外部実行可能ファイルを開始し、実行結果を取得するためにエージェントと通信します。
リモート外部ジョブを作成する場合、ジョブのdestination_name属性で既存の外部宛先オブジェクトの名前を指定します。
リモート外部ジョブでは、stdoutおよびstderrの出力がディレクトリAGENT_HOME/data/log内のログ・ファイルに書き込まれます。これらのファイルの内容は、DBMS_SCHEDULER.GET_FILEで取得できます。例29-8「ローカル外部ジョブの作成とstdoutの取得」には、stdoutの出力の取得方法が示されています。この例はローカル外部ジョブに関するものですが、メソッドはリモート外部ジョブの場合も同じです。
複数の宛先のジョブとは、ジョブのインスタンスが複数のターゲット・データベースまたはホストで実行されても、中核となる1つのデータベースで制御および監視できるジョブのことです。複数のデータベースまたは複数のホストを管理する必要があるDBAまたはシステム管理者にとって、複数の宛先のジョブは管理が大幅に簡略化されます。複数の宛先のジョブでは、次の操作を行うことができます。
ジョブを実行する必要のある複数のデータベースまたはホストの指定。
複数のターゲットでスケジュールされているジョブの1回の操作による変更。
1つ以上のリモート・ターゲットで実行しているジョブの停止。
各リモート・ターゲットでのジョブ・インスタンスの状態(実行中、完了、失敗など)の判断。
ジョブ・インスタンスの集合の全体的な状態の判断。
複数の宛先のジョブは、特定の目的のための単一エンティティとみなしたり、別の目的のために独立して実行されるジョブの集合とみなすことができます。ジョブのメタデータを作成するときには、複数の宛先のジョブは単一エンティティのように見えます。ただし、ジョブ・インスタンスが実行されているときは、各ジョブのほぼ同一コピーであるジョブの集合とみなす方が適切です。ソース・データベースで作成されたジョブを親ジョブと呼び、様々な宛先で実行されるジョブ・インスタンスを子ジョブと呼びます。
複数の宛先のジョブを作成するには、宛先グループをジョブのdestination_name属性に割り当てます。ジョブは、スケジュールされた時間または指定のイベントの検出時に、グループ内のすべての宛先で実行されます。ローカル・ホストは、ジョブが実行される宛先に含めることができます。
ジョブの処理がデータベース・プログラム・ユニットの場合は、destination_name属性でデータベース宛先グループを指定する必要があります。データベース宛先グループのメンバーには、元の(ローカル)データベースを示すデータベース宛先とキーワードLOCALが含まれます。ジョブの処理が外部実行可能ファイルの場合は、destination_name属性で外部宛先グループを指定する必要があります。外部宛先グループのメンバーには、ローカル・ホストを示す外部宛先とキーワードLOCALが含まれます。
|
注意: データベース宛先は、リモート・データベースを必ずしも参照する必要はありません。データベース宛先は、ジョブが作成されたデータベースと同じホストで実行している他のデータベースを参照できます。 |
複数の宛先のジョブとタイム・ゾーン
一部のジョブの宛先は、親ジョブが作成されたデータベース(元のデータベース)のタイムゾーンとは異なるタイムゾーンにある場合があります。この場合、ジョブの開始時刻は、常に元のデータベースのタイム・ゾーンを基にします。したがって、親ジョブをロンドン(英国)で作成して開始時刻を午後8時に指定し、宛先として東京、ロサンゼルス、ニューヨークを指定した場合、子ジョブはロンドン時刻の午後8時に開始します。すべての宛先での開始時刻は、システムの負荷の違いや再試行を必要とする問題などによって、多少のずれが発生する場合があります。
イベント・ベースの複数の宛先のジョブ
イベント・ベースの複数の宛先のジョブの場合、親ジョブがイベントをホストで検出すると、すべての子ジョブがすべての宛先で開始します。子ジョブは、それぞれのホストでイベントを検出しません。
チェーンは、依存性ベースのスケジューリングを可能にするスケジューラ・メカニズムです。最も単純な形式では、プログラム・オブジェクトのグループとプログラム・オブジェクト間の依存性が定義されます。ジョブは、単一のプログラム・オブジェクトを指し示すかわりにチェーンを指し示すことができます。その場合、ジョブはチェーンを開始する役割を持ちます。チェーン・ジョブの場合、job_typeは'CHAIN'として指定されます。
デタッチされたジョブを使用して、スケジューラとは独立して非同期に別のプロセスで実行されるスクリプトやアプリケーションを起動できます。通常、デタッチされたジョブは別のプロセスを起動してから終了します。終了時(ジョブ処理の完了時)に、デタッチされたジョブは実行状態のままになります。この実行状態は、このジョブが起動した非同期プロセスがまだアクティブであることを示しています。非同期プロセスは、その作業を完了するときに、データベースに接続して、ジョブを終了させるDBMS_SCHEDULER.END_DETACHED_JOB_RUNを呼び出す必要があります。
use_current_sessionパラメータがTRUEに設定されている場合、run_jobを使用して手動で実行をトリガーして、デタッチされたジョブを実行することはできません。
ジョブは、detached属性がTRUEに設定されているプログラム・オブジェクト(プログラム)(デタッチ済プログラム)を指している場合、デタッチ済です。
デタッチ済ジョブは、次の2つの場合に使用します。
必要以上にリソースを保持するため、起動した非同期プロセスが完了するまで待機することが実際的でない場合。
一例として、非同期Webサービスにリクエストを送信する場合があります。Webサービスが応答するのに何時間または何日もかかる場合があり、応答待ちの間、スケジューラ・ジョブ・スレーブを保留することはできません。(ジョブ・スレーブの詳細は、「スケジューラのアーキテクチャ」を参照してください。)
プロセスによりデータベースが停止されるため、起動した非同期プロセスが完了するまで待機できない場合。
たとえば、スケジューラ・ジョブを使用して、データベースの停止、コールド・バックアップの作成およびデータベースの再起動を実行するRMANスクリプトを起動する場合です。例29-5を参照してください。
デタッチ済ジョブの動作は次のとおりです。
ジョブの開始時に、ジョブ・コーディネータによりジョブにジョブ・スレーブが割り当てられ、デタッチ済プログラムに定義されているプログラム処理がジョブ・スレーブにより実行されます。プログラム処理は、PL/SQLブロック、ストアド・プロシージャまたは外部実行可能ファイルのいずれかです。
プログラム処理は、別のスクリプトまたは実行可能ファイル(この例ではプロセスA)の即時リターン・コールを実行してから終了します。プログラム処理の動作は完了しているため、ジョブ・スレーブは終了しますが、ジョブは実行中の状態のまま残ります。
プロセスAにより処理が実行されます。データベースに対するDMLを実行する場合は、その処理をコミットする必要があります。処理が完了すると、プロセスAによりデータベースにログが記録され、END_DETACHED_JOB_RUNがコールされます。
デタッチ済ジョブが完了として記録されます。
実行中のデタッチ済ジョブを終了するには、STOP_JOBをコールする方法もあります。
軽量ジョブは、多数の短時間のジョブを頻繁に実行する場合に使用します。特定の条件下では、軽量ジョブを使用してもパフォーマンスがあまり向上しない場合があります。
軽量ジョブには、次の特性があります。
標準ジョブとは異なり、スキーマ・オブジェクトではありません。
スキーマ・オブジェクトを作成する際のオーバーヘッドを伴わないため、作成および削除に必要な時間が標準ジョブよりも大幅に短縮されます。
セッションの平均作成時間が標準ジョブよりも短縮されます。
ジョブのメタデータと実行時データに関して、ディスク上のフットプリントが小さくなります。
軽量ジョブを指定するには、job_styleジョブ属性を'LIGHTWEIGHT'に設定します。もう1つのジョブ・スタイルは、デフォルトの'REGULAR'です。
プログラムやスケジュールと同様に、標準ジョブはスキーマ・オブジェクトです。Oracle Database 11g リリース1より前のリリースでは、標準ジョブがスケジューラでサポートされる唯一のジョブ・スタイルでした。
通常のジョブは最も柔軟性がありますが、作成または削除されるときに多少のオーバーヘッドを伴います。ユーザーはジョブの権限を細かく制御でき、別のユーザーが所有するプログラムやストアド・プロシージャをジョブの処理として指定できます。
実行頻度が低い比較的少数のジョブを作成する必要がある場合は、軽量ジョブよりも標準ジョブが優先されます。
軽量ジョブでは、プログラム・オブジェクト(プログラム)を参照してジョブの処理を指定する必要があります。プログラムは軽量ジョブの作成時に有効化されている必要があり、プログラム・タイプは'PLSQL_BLOCK'または'STORED_PROCEDURE'であることが必要です。軽量ジョブはスキーマ・オブジェクトではないため、権限は付与できません。軽量ジョブは指定のプログラムから権限を継承します。したがって、プログラムに対して特定の権限セットを持つユーザーは、軽量ジョブに対して対応する権限を持つことになります。
ジョブ・インスタンスは、ジョブの特定の実行を表します。1回だけ実行するようにスケジュールされているジョブには、1つのインスタンスのみがあります。繰返しスケジュールされているジョブおよびイベントが発生するたびに実行されるジョブには、複数のインスタンスがあり、ジョブの各実行がインスタンスを表します。たとえば、2009年10月8日火曜日のみに実行するようにスケジュールされているジョブには1つのインスタンスがあり、1週間毎日正午に実行されるジョブには7つのインスタンスがあり、ファイルがリモート・システムに到着すると実行されるジョブには、ファイル到着イベントごとに1つのインスタンスがあります。
複数の宛先のジョブには、宛先ごとに1つのインスタンスがあります。複数の宛先のジョブが繰返しスケジュールされている場合は、各宛先のジョブの実行ごとに1つのインスタンスがあります。
ジョブが作成されると、ジョブを表すエントリがスケジューラのジョブ表に1つのみ追加されます。ロギング・レベルの設定に応じて、ジョブが実行されるたびに、ジョブ・ログにエントリが追加されます。そのため、繰返しのスケジュールが設定されているジョブを作成すると、ジョブ・ビュー(*_SCHEDULER_JOBS)には1つのエントリが存在し、ジョブ・ログには複数のエントリが存在することになります。各ジョブ・インスタンスのログ・エントリは、ジョブの完了ステータス、開始時刻、終了時刻など、特定の実行に関する情報を提供します。ジョブの各実行には一意のログIDが割り当てられて、ジョブ・ログとジョブ実行詳細ビュー(*_SCHEDULER_JOB_LOGと*_SCHEDULER_JOB_RUN_DETAILS)の両方に表示されます。
ジョブでプログラム・オブジェクト(プログラム)を参照する場合、ジョブ引数を指定してデフォルトのプログラム引数値を上書きするか、デフォルト値のないプログラム引数の値を提供できます。また、ジョブが指定するインライン処理(例: ストアド・プロシージャ)に対しても引数値を提供できます。
必要なプログラム引数値のすべてが、参照先のプログラム・オブジェクトにデフォルトとして定義されているか、またはジョブ引数として定義されるまで、ジョブは使用できません。
ジョブの一般的な例には、一連のレポートを夜間に実行するジョブがあります。様々な部門で様々なレポートが必要な場合は、このタスクのプログラムを、様々な部門の様々なユーザー間で共有できるように作成できます。このプログラム処理では、レポート・スクリプトが実行され、プログラムには1つの引数として、部門番号を設定します。各ユーザーはこのプログラムを指し示すジョブを作成し、部門番号をジョブ引数として指定できます。
実行内容と実行時期を定義するには、プログラム、ジョブおよびスケジュール間に関連を割り当てます。図28-5に、これらの関連の例を示します。
図28-5を理解するために、表を分析する場合を考えてみます。この例では、プログラムP1がDBMS_STATSパッケージを使用して表を分析します。このプログラムには、表名に対する入力パラメータがあります。2つのジョブJ1とJ2は、両方とも同じプログラムを指し示していますが、別々の表名が指定されています。さらに、スケジュールS1には、毎日午前2時の実行時間を指定します。最終的な結果として、J1とJ2で名前が指定された2つの表は、毎日午前2時に分析されます。
J4は、すべての関連情報がそのジョブ自体に定義された自己完結のジョブで、他のエンティティを指し示していないことに注意してください。P2、P9およびS2は、必要に応じて、プログラムまたはスケジュールに関連を割り当てないままにできることを示しています。たとえば、年度末の在庫を計算するプログラムを作成し、一時的に、そのプログラムをどのジョブにも割り当てないままにできます。
この項では、スケジューラのアーキテクチャについて説明します。この項の内容は、次のとおりです。
図28-6に、データベースによるジョブの処理方法を示します。
ジョブ表はすべてのジョブのコンテナであり、データベースごとにあります。ジョブ表には、すべてのジョブに関する所有者名やロギング・レベルなどの情報が保存されています。この情報は、*_SCHEDULER_JOBSビューにあります。
ジョブはデータベース・オブジェクトであるため、累積されて多くの領域を使用する場合があります。これを回避するために、ジョブ・オブジェクトは、ジョブの完了後、デフォルトで自動的に削除されます。この動作は、auto_dropジョブ属性によって制御されます。
使用可能なジョブのビューと管理については、「スケジューラのデータ・ディクショナリ・ビュー」を参照してください。
ジョブ・コーディネータは、データベースの制御のもと、ジョブ表の情報を使用してジョブ・スレーブを制御および起動します。
ジョブ・コーディネータ・バックグラウンド・プロセス(cjqNNN)は、必要に応じて自動的に起動および停止します。データベースの起動時に、ジョブ・コーディネータは起動されませんが、実行するジョブがあるかどうか、および近い将来開くウィンドウがあるかどうかをデータベースが監視します。ある場合は、コーディネータが起動されます。
実行中のジョブまたはウィンドウがある間は、コーディネータは継続的に実行されます。スケジューラが一定期間非アクティブな状態にあり、近い将来にスケジュールされたジョブまたはウィンドウがない場合、コーディネータは自動的に停止します。
ジョブ・コーディネータを起動するかどうかをデータベースが判断する際は、ジョブのサービス・アフィニティが考慮されます。たとえば、近い将来スケジュールされるジョブが1つのみで、4つのRACインスタンスのうち2つのみにサービス・アフィニティがあるジョブ・クラスにこのジョブが属している場合は、この2つのインスタンスのジョブ・コーディネータのみが起動されます。詳細は、「スケジューラ使用時のサービス・アフィニティ」を参照してください。
ジョブ・コーディネータの機能は次のとおりです。
ジョブ・スレーブを制御および起動します。
ジョブ表を問い合せます。
ジョブ表からジョブを定期的に取り出し、メモリー・キャッシュに格納します。この結果、ディスクへのトリップが減るため、パフォーマンスが向上します。
メモリー・キャッシュからジョブを取り出し、実行するためにジョブ・スレーブに渡します。
スレーブが不要になると、ジョブ・スレーブ・プールをクリーン・アップします。
スケジュールされているジョブがないときは休止状態になります。
新規ジョブが実行されるとき、またはCREATE_JOBプロシージャを使用してジョブが作成されたときに起動します。
データベースの異常停止後の起動時に、実行していたジョブをリカバリします。
ジョブ・コーディネータがジョブ表を確認する時間を設定する必要はありません。タイム・フレームはシステムで自動的に選択されます。
インスタンスごとに1つのジョブ・コーディネータが使用されます。これは、Oracle RAC環境の場合も同じです。
|
関連項目: ジョブ・コーディネータの管理については、「スケジューラのデータ・ディクショナリ・ビュー」を参照してください。Oracle RACの情報については、「Real Application Clusters環境におけるスケジューラの使用」を参照してください。 |
ジョブ・スレーブは、発行されたジョブを実際に実行します。ジョブの実行時期になるとジョブ・コーディネータによって起動されます。ジョブ・スレーブは、ジョブ表からジョブを実行するためのメタデータを収集します。
処理のためにジョブが取り出されると、ジョブ・スレーブは次のことを実行します。
プログラム引数や権限情報など、ジョブの実行に必要なすべてのメタデータを収集します。
ジョブの所有者としてデータベース・セッションを開始し、トランザクションを開始した後に、ジョブの実行を開始します。
ジョブが完了すると、スレーブはトランザクションをコミットし、終了します。
セッションをクローズします。
ジョブが終了すると、スレーブは次のことを実行します。
必要に応じて、ジョブを再スケジュールします。
ジョブ表の状態を更新して、ジョブを完了するか、再スケジュールするかを反映します。
エントリをジョブ・ログ表に挿入します。
実行回数を更新し、必要に応じて、失敗の回数と再試行の回数を更新します。
クリーン・アップします。
新規作業を検索します(検出されない場合は休止状態になります)。
スケジューラは、必要に応じてスレーブ・プールを動的にサイズ変更します。
Oracle Real Application Clusters (Oracle RAC)環境では、スケジューラは、データベースごとに1つのジョブ表を使用し、インスタンスごとに1つのジョブ・コーディネータを使用します。ジョブ・コーディネータは相互に通信して情報を最新に保ちます。ジョブ・クラスにサービス・アフィニティがない場合、スケジューラは、使用可能なすべてのインスタンス間でジョブ・クラスのジョブの負荷を分散しようとしますが、ジョブ・クラスにサービス・アフィニティがある場合は、特定のサービスに割り当てられているインスタンス間で負荷を分散しようとします。
図28-7に、典型的なOracle RACアーキテクチャを示します。各インスタンスのジョブ・コーディネータは他のコーディネータと情報を交換します。
スケジューラを使用すると、ジョブを実行するデータベース・サービス(サービス・アフィニティ)を指定できます。これにより、インスタンスがダウンした場合に他のノードにサービスが必ず動的に割り当てられるため、インスタンス・アフィニティの場合よりも可用性がよくなります。インスタンス・アフィニティにはこの機能がないので、インスタンスがダウンすると、そのインスタンスへのアフィニティが指定されたジョブは、そのインスタンスがダウン状態から回復するまで実行されません。図28-8は、サービスおよびインスタンスの一般的な使用例を示しています。
図28-8では、サービスのプロパティが変更可能で、その変更はスケジューラによって自動的に認識されます。
各ジョブ・クラスで、データベース・サービスを指定できます。サービスの指定がない場合、このジョブ・クラスは、起動しているすべてのインスタンスへのマッピングが保証されている内部サービスに属します。
Oracle Database 11g リリース1からは、データベースがプライマリ・データベースかロジカル・スタンバイ・データベースかに基づいて、スケジューラがOracle Data Guard環境でジョブを実行できるようになりました。
フィジカル・スタンバイ・データベースの場合、スケジューラのオブジェクトに対する変更またはプライマリ・データベース上のスケジューラのジョブによるデータベースの変更は、他のデータベースの変更と同様にフィジカル・スタンバイに適用されます。
プライマリ・データベースおよびロジカル・スタンバイ・データベースの場合は、データベースがプライマリ・データベースまたはロジカル・スタンバイのロールの場合にのみ、ジョブを実行できるように指定できるという追加機能があります。これは、DBMS_SCHEDULER.SET_ATTRIBUTEプロシージャを使用して、database_roleジョブ属性を'PRIMARY'または'LOGICAL STANDBY'の2つの値のどちらかに設定して使用します。(両方のロールでジョブを実行するには、ジョブのコピーを作成して、1つのジョブのdatabase_roleを'PRIMARY'に設定し、もう1つのジョブでは'LOGICAL STANDBY'に設定します。)スイッチオーバーまたはフェイルオーバー時には、新しいロール固有のジョブを実行するようにスケジューラが自動的に切り替わります。プライマリ・データベースで障害が発生するまで正常に実行されたレコードを、フェイルオーバー時に使用できるように、ジョブ・イベント・ログにDMLが複製されます。
