ヘッダーをスキップ
Oracle® Enterprise Manager拡張ガイド
11gリリース1（11.1.0.1）
B61026-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

5 ジョブ・タイプの追加

管理者は、Enterprise Managerジョブ・システムの実用性と柔軟性を拡張するために、新しいジョブ・タイプを定義することができます。また、問題修正処理を強化するためのジョブ・タイプを追加することもできます。この章では、すでにEnterprise Managerのジョブ・システムに関する知識があることを前提として、ジョブ・タイプについて説明します。この章の内容は次のとおりです。

ジョブ・タイプについて

Enterprise Managerでは、様々なタイプのジョブを定義して、それらをEnterprise Managerジョブ・システムで実行できます。これによって、より多くの、より複雑なタスクを自動化することが可能になっています。

ジョブ・タイプとは、ジョブが実行するひとまとまりの作業を明確に区別するための、特定のカテゴリのことです。それぞれのジョブ・タイプは、特定の文字列によって一意に識別されます。たとえば、リモート・コマンドを実行するジョブ・タイプとして、OSCommandを使用したりします。ジョブ・タイプは、XML形式の仕様を通じて定義します。この仕様では、ジョブ内の各ステップ、各ステップが実行する作業（コマンド）、および各ステップ間の関係を定義します。

次の表に、Enterprise Managerジョブ・タイプの一部とその機能を示します。

表5-1 ジョブ・タイプの例

ジョブ・タイプ 用途

Backup

データベースをバックアップする。

Backup Management

選択したバックアップ・コピー、バックアップ・セット、またはファイルに対して、クロスチェックや削除などの管理機能を実行する。

CloneHome

Oracleホーム・ディレクトリをクローニングする。

DBClone

Oracleデータベース・インスタンスをクローニングする。

DBConfig

10gより前のリリースのデータベースの監視方法を構成する。

Export

特定のEnterprise Managerユーザーのスキーマや表に含まれる、データベースの内容やデータベース・オブジェクトをエクスポートする。

GatherStats

オプティマイザ統計を生成および変更する。

OSCommand

オペレーティング・システムのコマンドまたはスクリプトを実行する。

HostComparison

複数のホストの構成を比較する。

Import

オブジェクトや表の内容をインポートする。

Load

Oracle以外のデータベースからOracleデータベースにデータをロードする。

Move Occupant

SYSAUX表領域の占有データを別の表領域に移動する。

Patch

Oracle製品にパッチを適用する。

Recovery

データベース、表領域、データファイルまたはアーカイブ・ログをリストアまたはリカバリする。

RefreshFromMetalink

Enterprise ManagerがOracleMetaLinkサポート・サイトからパッチおよびクリティカル・パッチ・アドバイザ情報をダウンロードできるようにする。

Reorganize

断片化したデータベースの索引や表を再構築したり、異なる表領域にオブジェクトを移動したり、指定したオブジェクトの記憶域属性を最適化する。

Multi-Task

複数のタスクで構成される複合ジョブを実行する。

SQLScript

SQLまたはPL/SQLスクリプトを実行する。

新しいジョブ・タイプの導入

1つのEnterprise Managerジョブは、ひとまとまりのステップから構成されます。各ステップは、特定のコマンドまたはスクリプトを実行します。ジョブ・タイプは、それらのステップの組立て方法を定義します。たとえば、ステップをシリアルに（逐次的に）実行するかパラレルに（並行して）実行するかを指定したり、ステップの実行順序やステップ間の依存関係を定義したりします。ジョブ・タイプ、ステップ、およびコマンドの仕様はXMLで定義します（「XMLでの新しいジョブ・タイプの指定」を参照）。その仕様に基づいてジョブ・システムが実行計画を作成し、それにより、指定した順序でステップを実行できるようになります。

XMLでの新しいジョブ・タイプの指定

新しいジョブ・タイプの仕様はXMLで定義します。ジョブ・タイプの仕様は、ジョブ・システムに次の情報を提供します。

作成されたジョブ・タイプ仕様（XML形式）は、管理プラグイン・アーカイブに追加されます。Enterprise Managerに管理プラグインが追加されると、ジョブ・システムは、ジョブにどのステップを含めるかや、各ステップ内で何を実行するかをスケジュールするために必要な情報へアクセスできるようになります。

例5-1「ジョブ・タイプのDTD」に示すのは、ジョブ・タイプの指定に使用されるXML記述を定義したDTDです。

例5-1 ジョブ・タイプのDTD

<!ELEMENT jobtype (stepset)>
<!ATTLIST jobtype name CDATA #REQUIRED>
<!ATTLIST jobtype version CDATA #REQUIRED>
<!ATTLIST jobtype agentBound (true|false) false>
<!ELEMENT stepset (step|stepset|job)+>
<!ATTLIST stepset type (serial|parallel|iterativeSerial|iterativeParallel) #REQUIRED>
<!ATTLIST stepset ID CDATA #REQUIRED>
<!ATTLIST stepset successOf IDREF #IMPLIED>
<!ATTLIST stepset failureOf IDREF #IMPLIED>
<!ATTLIST stepset abortOf IDREF #IMPLIED>
<!ATTLIST stepset stepsetStatus CDATA #IMPLIED>
<!ATTLIST stepset switchVarName CDATA #IMPLIED>
<!ATTLIST stepset switchCaseVal CDATA #IMPLIED>
<!ATTLIST stepset restartMode (always|failure) failure>
<!-- For iterative serial stepsets only: specify whether the iterative serial
   - step set should halt at the first abort/failure in one of the child stepset
   - executions.
-->
<!ATTLIST stepset iterateHaltOnFailure (true|false) false>
<!-- For iterative stepsets, the vector parameter to iterate over -->
<!ATTLIST stepset iterateParam CDATA #IMPLIED>
<!-- For iterative stepsets only: the value to filter values in the vector parameter by -->
<!ATTLIST stepset iterateParamFilyer CDATA #IMPLIED>
<!ELEMENT job (target_list), (param_list)?>
<!ATTLIST job type CDATA #REQUIRED>
<!ATTLIST job ID CDATA #REQUIRED>
<!ATTLIST job successOf IDREF #IMPLIED>
<!ATTLIST job failureOf IDREF #IMPLIED>
<!ATTLIST job switchCaseVal CDATA #IMPLIED>
<!ATTLIST job restartMode (always|failure) failure>
<!ELEMENT targetList (target)*>
<!ATTLIST targetList allTargets (true|false) false>
<!ELEMENT target EMPTY>
<!ATTLIST target name CDATA #REQUIRED>
<!ATTLIST target type CDATA #REQUIRED>
<!ELEMENT step (param_list)?>
<!ATTLIST step ID CDATA #REQUIRED>
<!ATTLIST step successOf IDREF #IMPLIED>
<!ATTLIST step failureOf IDREF #IMPLIED>
<!ATTLIST stepset abortOf IDREF #IMPLIED>
<!ATTLIST stepset switchCaseVal CDATA #IMPLIED>
<!ATTLIST step command CDATA #REQUIRED>
<!ATTLIST step restartMode (always|failure) failure>
<!ELEMENT paramList (param)+>
<!ATTLIST paramList allParams (true|false) false>
<!-- A scalar param is just PCDATA. A vector param is
     represented as a set of parameterValue tags, one
     after another
-->
<!ELEMENT param ((#PCDATA)|(parameterValue)*))>
<!ATTLIST param name CDATA #REQUIRED>
<!ATTLIST param encrypted (true|false) false>
<ELEMENT parameterValue (#PCDATA)>
<!-- The following tags deal with how parameters can be fetched -->
<!ELEMENT paramSource (sourceParams)?,(#PCDATA)>
<!-- The type of the parameter source: pre-built sources 
     are sql, credential and user
 -->
<!ATTLIST paramSource sourceType CDATA #REQUIRED>
<!-- The names of the parameters that are to be fetched -->
<!ATTLIST paramSource paramNames CDATA #REQUIRED>
<!-- Set this to true if paramSource is "user" and the parameter
     is a required parameter
-->
<!ATTLIST paramSource required (true|false) false>
<!-- Set to true to indicate that the parameter must be stored encrypted -->
<!ATTLIST paramSource encrypted (true|false) false>
<!ELEMENT sourceParams (sourceParam)+>
<!ELEMENT sourceParam EMPTY>
<!ATTLIST sourceParam name CDATA #REQUIRED>
<!ATTLIST sourceParam value CDATA #REQUIRED>

ジョブ・タイプのカテゴリ

ジョブ・タイプは、ターゲットに対してタスクをどのように実行するかによって、次のいずれかのカテゴリに分類されます。

  • 単一ノード: 単一ノード・ジョブ・タイプは、各ターゲットに対し、同じステップ・セットを同時に実行するジョブ・タイプです。通常、このジョブ・タイプに対応するターゲット・リストは固定されません。つまり、ターゲットの数に制限はありません。単一ノード・ジョブ・タイプの例としては、OSCommandジョブ・タイプ（すべてのターゲットに対してOSのコマンドまたはスクリプトを実行する）や、SQLタイプ（すべてのターゲットに対して指定されたSQLスクリプトを実行する）があります。

  • 複数ノード/組合せ: 複数ノード・ジョブ・タイプは、複数のターゲットに対し、複数のタスク（場合によっては相互に関係を持つ複数タスク）を実行するジョブ・タイプです。通常、このジョブ・タイプは固定されたターゲット・セットを対象とします。たとえば、アプリケーション・スキーマをクローニングするCloneジョブには、2つのターゲット（ソース・データベースとターゲット・データベース）が必要です。


注意:

複数のターゲットに対して同じアクティビティを繰り返すため、複数ノードおよび組合せのジョブ・タイプに反復ステップセットが使用される場合があります。

エージェントにバインドされたジョブ・タイプ

エージェントにバインドされたジョブ・タイプは、ターゲット・リストに含まれる1つ以上のターゲットのエージェントが機能および反応していないかぎりジョブを実行できないジョブ・タイプです。このカテゴリに当てはまるジョブ・タイプは、それ自体がエージェントにバインドされていることを宣言する必要があります。これを行うにはjobType XMLタグのagentBound属性をtrueに設定します。ジョブ・タイプがエージェントにバインドされている場合、ジョブ実行のターゲット・リストに含まれるターゲットに対応する1つ以上のエージェントが停止している（または応答していない）と、そのジョブ・タイプの実行がジョブ・システムによってスケジュールされません。ジョブ（およびそのすべてのスケジュール済ステップ）は一時停止/エージェント停止という特別な状態に設定されます。ジョブは、Enterprise Managerリポジトリ層によってEMDが再び起動したことが検出されるまで、この状態を維持します。検出された時点で、ジョブ（およびそのステップ）は再びスケジュール済ステータスに設定され、ジョブが実行可能になります。ジョブ・タイプがエージェントにバインドされているとして宣言することで、ジョブ・タイプ・ライターは、エージェントが停止していることが検出された場合にジョブ・システムによるジョブのスケジュールが行われないように設定できます。


注意:

単一ノード・ジョブ・タイプはデフォルトでエージェントにバインドされていますが、複数ノード・ジョブ・タイプはバインドされていません。

エージェントにバインドされているジョブのターゲット・リストに複数のターゲットがある場合は、エージェントの1つが停止するとジョブは一時停止としてマークされます。

エージェントにバインドされたジョブ・タイプのわかりやすい例はOSCommandジョブ・タイプです。このジョブ・タイプでは指定されたターゲットのエージェントを使用してOSCommandが実行されます。ただし、すべてのジョブ・タイプがエージェントにバインドされているわけではありません。リポジトリでSQLを実行するジョブ・タイプはエージェントにバインドされていません。

Oracle Enterprise Managerではハートビート・メカニズムが採用されているため、リモートEMDがいつ停止するかをリポジトリ層がすばやく判断することができます。EMDが停止中としてマークされると、そのEMDがターゲットの1つとしてターゲット・リストに含まれる、エージェントにバインドされているすべてのジョブの実行が、一時停止/エージェント停止とマークされます。ただし、EMDが停止してからリポジトリによってその事実が検出されるまでの間に、ジョブ・システムによってリモート操作のディスパッチが試行される可能性は残されています。この場合、ステップの実行時にエージェントに接続できないと、ステップは再びスケジュール済の状態に設定され、ジョブ・システムによって再試行されます。ハートビート・メカニズムによってノードが停止中としてマークされ、その時点でジョブが一時停止するまで、一連の再試行が続行されます。

ジョブ・システムのデフォルトでは、ジョブが一時停止/エージェント停止としてマークされると、EMDが再び起動するまでジョブの状態は変わりません。実行タイムアウトというパラメータが定義されている場合は、この動作を上書きできます。実行タイムアウトは、ジョブが一時停止状態を続ける最大時間（時間単位）です。この時間内にエージェントが再び起動しない場合、ジョブ（およびその一時停止中のステップ）はすべて中断状態に設定されます。実行タイムアウトはジョブの属性であり、ジョブ・タイプではありません。実行タイムアウトは、「コマンド」の項に記載されているsubmit_jobのフレーバの1つを使用して設定できます。

一時停止/エージェント停止の状態にあるジョブ実行を再開する唯一の方法は、エージェントを再び起動させることです。resume_execution() APIを使用してジョブを再開することはできません。

ジョブ・ステップ

1つのジョブ内における処理実行の単位をステップを呼びます。1つのステップには1つのコマンドが含まれます。ステップがどのような処理を実行するかは、このコマンドによって決まります。各コマンドにはコマンド・エグゼキュータと呼ばれるJavaクラスが含まれています。これは、コマンドを実装するクラスです。また、コマンドには一連のパラメータが含まれています。これらは、コマンド・エグゼキュータによって解釈されます。ジョブ・システムには、あらかじめ作成されている、固定のコマンド・セットが用意されています。たとえば、コマンドをリモートで実行するリモート操作コマンド、2つのエージェント間でファイルを転送するファイル転送コマンド、エージェント層で作成されたログ・ファイルを管理リポジトリへ送るファイル取得コマンドなどがあります。

ステップは、ステップセットと呼ばれるかたまりにグループ化されます。ステップセットには、ステップだけでなく、自身以外のステップセットを含めることもできます。ステップセットは次のタイプに分類されます。

シリアル・ステップセット: シリアル・ステップセットに属するステップは、シリアルに（1つずつ順に）実行されます。シリアル・ステップセット内のステップには、それが実行されるかどうかを左右する依存性を設定することもできます。たとえば、ステップS1が正常に実行された場合のみステップS2が実行され、ステップS1が失敗した場合のみステップS3が実行されるようなジョブにすることもできます。ただし、シリアル・ステップセット内のステップに設定できる依存性は、同じステップセットに属する、他のステップまたはステップセットに対する依存性のみです。シリアル・ステップセットは、デフォルトでは、セット内の最後のステップが正常に実行された場合にのみ、正常に実行されたとみなされます。セット内の最後のステップが中断された場合は、中断または失敗したとみなされます。この判断基準は、stepsetStatus属性を使用することによって上書きされる場合があります。上書きは、他のステップに対する依存性がステップに設定されていない場合のみ可能です（successOf/failureOf/abortOf属性ではない）。

パラレル・ステップセット: パラレル・ステップセットに属するステップは、すべて並行して（同時に）実行されます。パラレル・ステップセット内のステップには、依存性を設定することはできません。パラレル・ステップセットは、セット内のすべてのパラレル・ステップが正常に実行された場合にのみ、成功したとみなされます。中断したステップが1つでもある場合は、中断したとみなされます。デフォルトでは、パラレル・ステップセットは、1つ以上のステップが失敗したが、いずれのステップも中断されなかった場合に、失敗したとみなされます。デフォルトでは、パラレル・ステップセットは、1つ以上のステップが失敗したが、いずれのステップも中断されなかった場合に、失敗したとみなされます。この判断基準は、stepsetStatus属性を使用することによって上書きすることもできます。

反復ステップセット: 反復ステップセットは、ベクトル・パラメータ内の値ごとにセット全体を繰り返し実行する、特別なステップセットです。なお、ベクトル・パラメータには、特殊な例として、ジョブのターゲット・リスト（job_target_names）も該当します。反復ステップセットは、ターゲット・リストまたはベクトル・パラメータの構成要素ごとに反復処理を実行します。つまり、ターゲット・リストまたはベクトル・パラメータ内の値ごとに、ステップセットを1回ずつ実行します。反復ステップセットでは、処理をパラレルに実行する（複数のステップセット・インスタンスを同時に実行する）ことも、シリアルに実行する（複数のステップセット・インスタンスを1つずつ順に実行する）こともできます。反復ステップセットは、発生したすべてのインスタンスが正常に実行された場合にのみ、成功したとみなされます。中断されたステップセット・インスタンスが1つでもある場合は、中断したとみなされます。失敗したステップセット・インスタンスが1つ以上あるが、中断されたインスタンスはないという場合は、失敗したとみなされます。反復ステップセットの各インスタンスに含まれるステップは、シリアル・ステップセット内のステップと同様に、シリアルに実行されます。なお、シリアル実行の範囲内であれば、依存性を設定することもできます。反復シリアル・ステップセットには、iterateHaltOnFailureという属性があります。この属性がtrueに設定されている場合、ステップセットは、失敗または中断した最初の子反復で停止します。デフォルト（iterateHaltOnFailure=false）では、反復シリアル・ステップセットのいずれかの反復が失敗しても、後続のすべての反復までが実行されます。

スイッチ・ステップセット: スイッチ・ステップセットは、指定されたジョブ・パラメータ値に基づいて、ステップセット内の1つのステップのみが実行されるステップセットです。スイッチ・ステップセットには、switchVarNameという属性があります。この属性は、ステップセット内のどのステップを実行するかを判断するためにジョブ・システムによって使用されるジョブ・パラメータ（スカラー）です。スイッチ・ステップセット内の各ステップには、switchCaseValという属性があります。この属性は、switchVarNameのパラメータ値に使用できる値の1つです。スイッチ・ステップセット内のステップのうち、実行されるのは、このswithCaseValの値がスイッチ・ステップセットのswitchVarNameの値と一致するステップです。スイッチ・ステップセットでは、選択された1つのステップのみが実行されます。スイッチ・ステップセット内のステップは、同じステップセット内であっても、またその外部との間であっても、他のステップやステップセットと依存関係を持つことはできません。スイッチ・ステップセットが正常に実行されたとみなされるのは、デフォルトでは、ステップセット内の選択されたステップが正常に実行された場合に限られます。ステップセット内の選択されたステップが中断または失敗した場合は、中断または失敗したとみなされます。また、ステップセット内のいずれのステップも選択されなかった場合も、スイッチ・ステップセットは成功しません。たとえば、スイッチ・セットアップに、S1、S2という2つのステップがあったとします。このとき、switchVarNameをsendEmailと指定したうえで、S1のswitchCaseValをtureに、S2についてはfalseに指定したとします。この場合、ジョブ・パラメータsendEmailがtrueに設定されたジョブが発行されると、S1が実行されます。ジョブ・パラメータsendEmailがfalseに設定されたジョブが発行されると、S2が実行されます。sendEmailの値がどちらでもない場合は、ステップセットは成功しますが、何も実行されません。

ネストされたジョブ: ステップセットでは、セット内のステップが別のジョブ・タイプへの参照となっている場合があります。つまり、ジョブ・タイプは、その中に他のジョブ・タイプを含むことができます。ただし、ジョブ・タイプからそのジョブ・タイプ自身を参照することはできません。ジョブのネスト化は、機能ブロックを再利用するのに便利な方法です。たとえば、データベース・バックアップを実行するジョブが必要な場合、複雑なステップ構成を定義して、1つのジョブ内で完結するジョブを作成することもできますが、必要なバックアップ機能が、他のジョブ・タイプ（パッチ適用やクローニングなど）ですでにネストされたジョブとして使用されている可能性もあります。ネストされたジョブには、ジョブ・タイプに含まれるジョブのすべてのターゲットを渡すことも、ターゲットのサブセットのみを渡すこともできます。同様に、ジョブ・タイプに含まれるジョブから、ネストされたジョブにすべてのパラメータを渡すかどうかや、ネストされたジョブで（親ジョブのパラメータから導出された）独自のパラメータ・セットを使用するかどうかを指定することもできます。ネストされたジョブのステータスは、ネストされたジョブ内の個々のステップやステップセット（また、場合によってはその他のネストされたジョブ）によって決まります。

ステップセットのステータスへの影響

ステップセットのステータスをそのセット内のステップに基づいて判別するためのデフォルトのアルゴリズムは、ステップセットのstepsetStatus属性を使用すれば変更することもできます。stepsetStatusをステップセット内の特定のステップ、ステップセット、またはジョブの名前（ID）に設定すると、ステップセットのステータスは、指定したステップ、ステップセット、またはジョブのstepStatus属性に依存するようになります。この機能は、ステップセット内の特定のステップが失敗した場合でも、ステップセットの実行が成功するようにしたい場合に便利です。たとえば、ステップセットの最後に実行するステップで、ジョブのステータスを知らせる電子メールを一連の管理者に送信するような場合です。このような場合、ジョブのステータスは、電子メールを送信したステップのステータスではなく、実際の作業を実行したステップのステータスに設定する必要があります。なお、stepsetStatus属性に指定できるのは、無条件に実行されるステップのみです。successOfまたはfailureOfによる依存条件に応じて実行されるステップ、ステップセット、およびジョブは、stepsetStatus属性には指定できません。

ジョブ・パラメータの渡し方

ジョブのパラメータをステップから参照するには、パラメータ名を%で囲みます。これはプレースホルダと呼ばれます。たとえば、%patchNo%はpatchNoというパラメータの値を表します。このようなパラメータの値は、ステップのコマンド・エグゼキュータに渡されるときにジョブ・システムによって置き換えられます。[]を使用すれば、ベクトル・パラメータにもプレースホルダを定義できます。たとえば、patchListというベクトル・パラメータの最初の値を参照するには%patchList%[1]、2番目の値を参照するには%patchList%[2]のように表記します。

ジョブ・システムには、使用可能な一連の定義済プレースホルダが用意されています。これらのプレースホルダはすべて、job_という接頭辞で始まります。用意されているプレースホルダは次のとおりです。

  • job_iterate_index: 反復ステップセットでベクトル・パラメータを反復処理しているときの、現在のパラメータ値の索引。索引は、最も近い囲みステップセットのみを参照します。ネストされた反復ステップセットの場合、外側の反復索引にはアクセスできません。

  • job_iterate_param: 反復ステップセットの、繰り返しの対象となるパラメータの名前。

  • job_target_names[n]: 位置nでのジョブ・ターゲット名。単一ノード・ジョブについては、ジョブが複数ノードに対して発行された場合でも、配列は常にサイズ1のみであり、ジョブが実行される現在のノードのみを参照します。

  • job_target_types[n]: 位置nでのジョブ・ターゲットのタイプ。単一ノード・ジョブについては、ジョブが複数ノードに対して発行された場合でも、配列は常にサイズ1のみであり、ジョブが実行される現在のノードのみを参照します。

  • job_name: ジョブの名前。

  • job_type: ジョブのタイプ。

  • job_owner: ジョブを発行したEnterprise Managerユーザー。

  • job_id: ジョブID。これはGUIDを表す文字列です。

  • job_execution_id: 実行ID。これはGUIDを表す文字列です。

  • job_step_id: ステップID。これは整数です。

これらのプレースホルダ以外に、次のターゲット関連のプレースホルダもサポートされます。

  • emd_root: EMDインストールのルートの場所。

  • perlbin: （Enterprise Manager）Perlインストールの場所。

  • scriptsdir: EMD固有のスクリプトの場所。

これらのプレースフォルダは、ジョブ・システムでは解釈されません。かわりにエージェントによって解釈されます。たとえば、%emd_root%が、remoteOpコマンドのremoteCommandまたはargsパラメータに使用された場合や、putFile、getFile、またはtransferFileコマンド内でいずれかのファイル内に使用された場合、エージェントは、このプレースホルダをエージェント・ルートの実際の値に置き換えます。

ジョブ・ステップの出力とエラー

ステップは、ステータス（ステップの成功、失敗、または中断を示す）、出力（ステップのログ）、およびエラー・メッセージから構成されます。ステップが失敗すると、そのステップから実行されたコマンドによって、エラー・メッセージ列にエラーが示されることがあります。デフォルトでは、非同期リモート操作の標準出力と標準エラーは、そのリモート操作をリクエストしたステップの出力になるように設定されています。各ステップでは、エラー・メッセージの挿入方法として、CommandManagerのgetErrorWriter()メソッド（同期）を使用するか、mgmt_jobsパッケージのinsert_step_error_message API（通常、リモートで実行中のスクリプトによってコマンド・チャネル内でコールされる）を使用するかを選択できます。

コマンド

この項では、使用できるコマンドと、それらに関連付けられているパラメータについて説明します。次に示すパラメータのうち、ターゲット名またはターゲット・タイプを指定する各パラメータには、任意のタイプのターゲットを指定できます。ジョブ・システムは、指定されたターゲットを監視するエージェントを自動的に特定し、それらにアクセスします。

リモート操作

リモート操作コマンドのコマンドIDは、remoteOpです。使用できるパラメータは次のとおりです。

  • remoteCommand: 実行する実行可能ファイルまたはスクリプトのパス名（たとえば/usr/local/bin/perl）。

  • args: remoteCommandに対する引数のリスト（カンマ区切り）。

  • targetName: コマンドの実行対象となるターゲットの名前。ターゲットはプレースホルダを使用して表すこともできます。後述の例を参照してください。

  • targetType: コマンドの実行対象となるターゲットのタイプ。

  • username: 実行者となるOSユーザー。

  • password: ユーザーの認証に使用するパスワード。

  • executeSynchronous: このオプションのデフォルト設定はfalseです。デフォルトでは、リモート・コマンドは常にエージェント上で非同期に実行され、ステップのステータスはコマンドの完了後に更新されます。trueに設定すると、コマンドは同期で実行され、エージェントが処理を完了するまで待機されます。通常、短時間で完了するリモート操作（リスナーの起動など）では、このパラメータをtrueに設定します。実行に長時間かかるリモート操作の場合は、このパラメータを常にfalseに設定してください。

  • successStatus: ステップの成功を示す値として定義する整数値のリスト（カンマ区切り）。リモート・コマンドが終了ステータスとして戻した値がこれらの数値のいずれかであった場合、ステップは成功したとみなされます。デフォルト値はゼロです。これらの値が適用されるのは、executeSynchronousがtrueに設定されている場合のみです。

  • failureStatus: ステップの失敗を示す値として定義する整数値のリスト（カンマ区切り）。リモート・コマンドが終了ステータスとして戻した値がこれらの数値のいずれかであった場合、ステップは失敗したとみなされます。デフォルト値は、ゼロ以外のすべての値です。これらの値が適用されるのは、executeSynchronousがtrueに設定されている場合のみです。

  • input: これを指定した場合、その値は標準入力としてリモート・プログラムに渡されます。

  • outputType: outputTypeには、リモート・コマンドに生成させる出力の種類を指定します。指定できる値はnormal（デフォルト）またはcommandの2つです。標準（normal）出力とは、そのステップに対応するログに格納され、解釈されることのない出力です。コマンド（command）出力とは、1つ以上のコマンド・ブロックを含むことができる出力です。コマンド・ブロックは、事前登録済のSQLプロシージャ・コールにマップするXMLシーケンスです。コマンド出力オプションを使用すると、Enterprise Managerリポジトリ・データベース内のスキーマに直接ロードできるコマンド・ブロックをリモート・コマンドに生成させることができます。

実行されたコマンドによって生成された標準出力は、ジョブ・システムによって、そのステップに対応する出力として格納されます。

fileTransfer

ファイル転送コマンドのコマンドIDは、fileTransferです。このコマンドは、1つのエージェントから別のエージェントへファイルを転送します。また、ソース・エージェントでコマンドを実行し、その標準出力をファイルとしてターゲット・エージェントに転送したり、標準入力としてターゲット・エージェントのコマンドに転送することもできます。fileTransferコマンドは常に非同期です。使用できるパラメータは次のとおりです。

  • sourceTargetName: ソース・エージェントに対応するターゲットの名前。

  • sourceTargetType: ソース・エージェントに対応するターゲットのタイプ。

  • destTargetName: ターゲット・エージェントに対応するターゲットの名前。

  • destTargetType: ターゲット・エージェントに対応するターゲットのタイプ。

  • sourceFile: ソース・エージェントから転送されるファイル。

  • sourceCommand: ソース・エージェントで実行されるコマンド。このパラメータを指定した場合、指定したコマンドの標準出力がターゲット・エージェントに送られます。sourceFileおよびsourceCommandは、いずれも指定できません。

  • sourceArgs: sourceCommandに対する一連のコマンドライン・パラメータ（カンマ区切り）。

  • sourceUsername: ソース・エージェントで使用するユーザー名。指定するユーザーには、少なくともソース・ファイルの読取り権限が付与されている必要があります。

  • sourcePassword: ソース・エージェントで使用するパスワード。

  • destFile: ターゲット・エージェントでファイルの格納先となる場所とファイル名。

  • destCommand: ターゲットEMDで実行されるコマンド。このパラメータを指定した場合、ソースEMDから生成されたストリームが、そのコマンドの標準入力に送られます（生成元がファイルであるかコマンドであるかにかかわらず）。destFileおよびdestCommandは、いずれも指定できません。

  • destArgs: destCommandに対する一連のコマンドライン・パラメータ（カンマ区切り）。

  • destUsername: ターゲット・エージェントで使用する（OS）ユーザー名。指定するユーザーには、少なくともターゲットの場所での書込み権限が付与されている必要があります。

  • destPassword: ターゲット・エージェントで使用するパスワード。

fileTransferコマンドは、ファイルがエージェント間で正常に転送された場合に成功とみなされます。その場合は、ステータス・コード0が戻されます。エラーが発生した場合は、障害の理由に応じたエラー・コードが戻されます。

putFile

putFileコマンドのコマンドIDは、putFileです。このコマンドは、サイズの大きいデータを、Enterprise Managerリポジトリからエージェントのファイルへ転送するために使用します。転送するデータは、リポジトリ内のBLOBや、ファイル・システム上のファイルから選択することもできますし、パラメータ内に埋め込むこともできます（インライン）。

ファイルを転送する場合は、そのファイルの場所がリポジトリ・インストールからアクセス可能である必要があります。データベース内のBLOBを転送する場合は、そのBLOBが、リポジトリ・スキーマ・ユーザー（通常mgmt_rep）からアクセスできるリポジトリ・データベース内の表に含まれている必要があります。

putFileコマンドに必要なパラメータは次のとおりです。

  • sourceType: ソース・データのタイプ。sql、fileまたはinlineを指定できます。

  • targetName: ファイルの転送先となるターゲットの名前（ターゲット・エージェント）。

  • targetType: 転送先ターゲットのタイプ。

  • sourceFile: リポジトリから転送されるファイル（sourceTypeがfileSystemに設定されている場合）。リポジトリ・インストールからアクセス可能なファイルである必要があります。

  • sqlType: SQLデータのタイプ（sourceTypeがsqlに設定されている場合）。有効な値はCLOBおよびBLOBです。

  • accessSql: BLOBデータの取得に使用するSQL文（sourceTypeがsqlに設定されている場合）。例: select output from my_output_table where blob_id=%blobid%

  • destFile: ターゲット・エージェントでのファイルの格納先となる場所とファイル名。

  • contents: sourceTypeをinlineを設定した場合は、このパラメータにファイルの内容を含めます。テキストには、%param%という形式でパラメータのプレースホルダを含めることもできます。

  • username: ターゲット・エージェントで使用する（OS）ユーザー名。ターゲットの場所での書込み権限を持つユーザーである必要があります。

  • password: ターゲット・エージェントで使用するパスワード。

putFileコマンドは、ファイルが正常に転送された場合に成功とみなされます。その場合は、ステータス・コードが0に設定されます。失敗した場合、ステータス・コードは障害の理由に応じた整数に設定されます。

getFile

getFileコマンドのコマンドIDは、getFileです。このコマンドは、エージェントからリポジトリへファイルを転送します。転送されたファイルは、このコマンドを実行したステップの出力として格納されます。

getFileコマンドのパラメータは次のとおりです。

  • sourceFile: エージェントから転送するファイルの場所。

  • targetName: ターゲットの名前。このターゲットのエージェントにアクセスしてファイルを取得します。

  • targetType: ターゲットのタイプ。

  • username: エージェントで使用する（OS）ユーザー名。指定するユーザーには、転送するファイルの読取り権限が付与されている必要があります。

  • password: エージェントで使用するパスワード。

getFileコマンドは、ファイルが正常に転送された場合に成功とみなされます。その場合は、ステータス・コードが0に設定されます。失敗した場合、ステータス・コードは障害の理由に応じた整数に設定されます。

コマンド・エラー・コード

remoteOp、putFile、fileTransferおよびgetFileの各コマンドは、次のエラー・コードを戻します。次のメッセージに含まれる「コマンド・プロセス」はエージェントによって実行されるプロセスを表し、このエージェントによって、指定されたリモート・コマンドが実際に実行され、実行されたコマンドの標準出力および標準エラーが取得されます。UNIXインストールでは、このプロセスはnmoと呼ばれ、$EMD_ROOT/binにあります。このプロセスを正常に使用するには、SETUIDを使用してルートでの作業を可能にしておく必要があります。有効なユーザー名およびパスワードが設定されていないかぎり、nmoによってコマンドが実行されることはありません。そのため、セキュリティ上の問題は発生しません。

0: エラーなし。

1: コア・モジュールを初期化できませんでした。エージェントのインストールまたは環境に問題がある可能性があります。

2: エージェントがメモリー不足です。

3: エージェントが入力ストリームから情報を読み取れませんでした。

4: 入力パラメータのサイズが大きすぎたためエージェントが処理できませんでした。

5: コマンド・プロセスがルートへのsetuidではありませんでした。（それぞれのUNIXエージェント・インストールにはnmoという実行可能ファイルがあり、これをルートへのsetuidにする必要があります）

6: 指定したユーザーはこのシステムに存在しません。

7: パスワードが不適切です。

8: 指定したユーザーとして実行できませんでした。

9: コマンド・プロセス（nmo）の分岐化に失敗しました。

10: 指定されたプロセスの実行に失敗しました。

11: 起動したプロセスの終了ステータスを取得できませんでした。

12: コマンド・プロセスの終了前に割込みがありました。

13: 標準エラー・ストリームを標準出力にリダイレクトできませんでした。

OMSでの長時間のコマンドの実行

ジョブ・システムを使用すると、インテグレータは管理サービス・レベルで作業を実行するコマンドを書き込むことができます。たとえば、データベースから2つのLOBを読み取って様々な変換を実行し、再度書き込むコマンドを使用できます。ジョブ・システムでは、このようなコマンドはLongRunningCommandという（空の）インタフェースを実装すると予測されます。このインタフェースは、コマンドが中間層で同時に実行され、実行が長時間に及ぶ可能性があることを示します。これにより、ジョブ・システムのディスパッチャと呼ばれるコンポーネントが、長時間のコマンドをシステムのスループットを低下させないように最も効率的にスケジュールできるようになります。

長時間のコマンドを処理するためのジョブ・ディスパッチャの構成

ディスパッチャはジョブ・システムのコンポーネントの1つで、ジョブの様々なステップを、実行準備ができたときに実行します。各ステップに関連付けられているコマンド・クラスがコールされ、そのコマンド・クラスによってリクエストされた非同期操作がディスパッチされます。ステップのディスパッチと呼ばれるプロセスです。ディスパッチャはスレッド・プールを使用してステップを実行します。スレッド・プールは指定された数のワーカー・スレッドの集まりで、いずれのワーカー・スレッドでもステップをディスパッチできます。ジョブ・システム・ディスパッチャでは2つのスレッド・プールが使用されます。非同期ステップおよび短い同期ステップをディスパッチするための短いコマンド・プール、および長時間のコマンドを含むステップをディスパッチするための長いコマンド・プールです。通常、長時間のプールに10のスレッドがあるとすると、短いコマンドのプールには25というように比較的多数のスレッドがあります。理論上、中間層の長時間のステップは、多数の短時間のコマンドと比較すると少なくなります。ただし、2つのプールのサイズは、特定のサイトでの混合ジョブに合せてディスパッチャで完全に構成できます。異なるノードで複数のディスパッチャを実行できるため、サイト管理者は、ディスパッチャを長時間のステップ専用または短時間のステップ専用にすることも可能です。

パラメータ・ソースの指定

ジョブ・システムのデフォルト設定では、ジョブの発行時または実行時に（パラメータを動的に追加または更新して）すべてのジョブ・パラメータの値をインテグレータが指定する必要があります。通常、アプリケーションは次の3つのうちいずれかの方法でこれらのパラメータを指定します。

ジョブ・システムによって提供されるパラメータ・ソースの概念により、インテグレータは、（前述の2番目のカテゴリのような）ジョブまたはステップ・パラメータのフェッチおよび移入のために記述する必要があるアプリケーション固有のコードの量を単純化できます。パラメータ・ソースは、ジョブの発行時または実行開始直前にジョブ・システムが一連のパラメータをフェッチするために使用するメカニズムです。ジョブ・システムはSQL（一連のパラメータをフェッチするためのPL/SQLプロシージャ）、資格証明（Enterprise Manager資格証明表からのユーザー名およびパスワード情報の取得）、およびユーザーをサポートします。インテグレータは、これらの事前作成ソースを使用して多様なパラメータをフェッチできます。ジョブ・システムがパラメータ・ソースを使用して1つ以上のパラメータをフェッチするように構成されている場合、これらのパラメータはジョブの発行時にジョブのパラメータ・リスト内で指定されている必要はありません。ジョブ・システムによって自動的にパラメータがフェッチされ、ジョブのパラメータ・リストに追加されます。

ジョブ・タイプは、XML指定でオプションのparamInfoセクションを使用してフェッチされた必要なパラメータの情報を埋め込むことができます。次に示すのは、a、bおよびcの3つのパラメータをフェッチするためにname_value_pair_tableというアプリケーション固有の表でSQL問合せを実行するジョブ・タイプの一部です。

<jobType version="1.0" name="OSCommand" >
<paramInfo>
    <!-- Set of scalar params -->
    <paramSource paramNames="a,b,c" sourceType="sql" overrideUser="true">
        select name, value from name_value_pair_table where
            name in ('a', 'b', 'c');
    </paramSource>
</paramInfo>
.... description of job type follows ....
</jobType>

この例では、paramInfoセクションが1つ以上のparamSourceタグで構成されています。それぞれのparamSourceタグは、1つ以上のパラメータをフェッチするのに使用できるパラメータ・ソースを参照します。paramNames属性は、パラメータ・ソースがフェッチする予定の一連のパラメータの名前（カンマ区切り）です。sourceType属性は、パラメータ（sql、credentialまたはuserのいずれか）をフェッチするのに使用されるソースを示します。overrideUser属性がtrueに設定された場合は、ジョブの発行時にパラメータがユーザー（またはアプリケーション）によって指定されたとしても、パラメータの値をフェッチする際には常にこのパラメータ・フェッチ・メカニズムが使用されることを示します。overrideUser属性のデフォルトはfalseです。デフォルトでは、ジョブの発行時にパラメータがすでに指定されていた場合は、パラメータ・ソース・メカニズムが無効になります。パラメータ・ソースには、フェッチング・メカニズムをより詳細に説明するソース固有の追加のプロパティを含めることができます。これらのプロパティの説明は後続の項を参照してください。

SQLパラメータ・ソース

SQLパラメータ・ソースを使用すると、インテグレータは一連のパラメータをフェッチするSQL問合せまたはPL/SQLプロシージャを指定できます。

SQL問合せを使用した一連のスカラー・パラメータのフェッチ

デフォルトでは、paramSourceタグのparamNames属性で指定されたすべてのパラメータがスカラーであるとみなされます。スカラー・パラメータは任意のSQL問合せによってフェッチできます。SQL問合せは、必ず2つの列を持つカーソルを生成する必要があり、最初の列はパラメータ名を参照し、2番目の列はパラメータ値を参照する必要があります。次の例では、次の問合せによってname_value_pair_tableというアプリケーション固有の表からのフェッチが行われます。この表にはnameおよびvalueの2つの列があり、必要なアプリケーション・パラメータの名前および値がそれぞれの列に保持されることを前提としています。

<paramInfo>
    <!-- Set of scalar params -->
    <paramSource paramNames="a,b,c" sourceType="sql">
        select name, value from name_value_pair_table where
            name in ('a', 'b', 'c') and app_name='app';
    </paramSource>
</paramInfo>

SQL問合せを使用したスカラーおよびベクトル・パラメータの混在のフェッチ

スカラー・パラメータおよびベクトル・パラメータの両方の値を保持するparameter_valuesという表があり、次のように各行に1つの値があるとします。

表5-2 スカラー・パラメータおよびベクトル・パラメータの値を含む表の例

Parameter_Name Parameter_Value Parameter_Index

vector1

pv1

1

vector1

pv2

2

vector1

pv3

3

scalar1

s1

1

scalar2

s2

1

この表には、3つの値（pv1、pv2、pv3）を持つvector1というベクトル・パラメータがあり、scalar1およびscalar2という2つのスカラー・パラメータがあります。ベクトル・パラメータのparameter_index列は、パラメータの順序を指定します。次のブロックでは、単一の問合せを使用してパラメータがフェッチされます。ソース・パラメータscalarParamsおよびvectorParamsは、どのパラメータがスカラーかベクトルかをそれぞれ指定します。次の例では、パラメータvector1がベクトル・パラメータであり、パラメータscalar1およびscalar2がスカラー・パラメータであることがジョブ・システムに伝えられます。これによってジョブ・システムはパラメータを適切に構成できます。明確にスカラーまたはベクトルのディレクティブに含まれていないパラメータは、スカラーとみなされます。

<paramInfo>
    <!-- Mixture of scalar and vector parameters -->
    <paramSource paramNames="vector1,scalar1,scalar2" sourceType="sql">
        <sourceParam name="scalarParams" value="scalar1, scalar2" />
        <sourceParam name="vectorParams" value="vector1" />
        select parameter_name, parameter_value from parameter_values where
            parameter_name in ('scalar1', 'scalar2', 'vector1') order by
                   parameter_name, parameter_index;
    </paramSource>
</paramInfo>

この表には、3つの値（pv1、pv2、pv3）を持つvector1というベクトル・パラメータがあり、scalar1およびscalar2という2つのスカラー・パラメータがあります。ベクトル・パラメータのparameter_index列は、パラメータの順序を指定します。次のブロックでは、単一の問合せを使用してパラメータがフェッチされます。ソース・パラメータscalarParamsおよびvectorParamsは、どのパラメータがスカラーかベクトルかをそれぞれ指定します。次の例では、パラメータvector1がベクトル・パラメータであり、パラメータscalar1およびscalar2がスカラー・パラメータであることがジョブ・システムに伝えられます。これによってジョブ・システムはパラメータを適切に構成できます。明確にスカラーまたはベクトルのディレクティブに含まれていないパラメータは、スカラーとみなされます。

<paramInfo>
    <!-- Mixture of scalar and vector parameters -->
    <paramSource paramNames="vector1,scalar1,scalar2" sourceType="sql">
        <sourceParam name="scalarParams" value="scalar1, scalar2" />
        <sourceParam name="vectorParams" value="vector1" />
        select parameter_name, parameter_value from parameter_values where
            parameter_name in ('scalar1', 'scalar2', 'vector1') order by
                   parameter_name, parameter_index;
    </paramSource>
</paramInfo>

PL/SQLプロシージャを使用したスカラーおよびベクトル・パラメータのフェッチ

パラメータをフェッチするPL/SQLプロシージャを記述することもできます。PL/SQLプロシージャには任意の数のパラメータを使用できます。ただし、ジョブ・システム用に特別な入力パラメータと特別な出力パラメータを1つずつ予約する必要があります。入力パラメータはSMP_Agent_STRING_ARRAYタイプであることが必要です。これは、フェッチするパラメータの名前であるvarchar2値の配列です。出力パラメータはカーソルまたはMGMT_JOB_PARAM_LISTであることが必要です。これらの特別な入力パラメータおよび出力パラメータは、プロシージャへのコールの最初と2番目のバインド・パラメータであることが必要です（次の例を参照）。また、outProcソース・パラメータは1に設定する必要があり、出力パラメータのタイプはソース・パラメータsqloutparamtypeを使用して指定する必要があります。これをcursor（出力パラメータはカーソル）またはparamList（出力パラメータはMGMT_JOB_PARAM_LIST）に設定する必要があります。

いくつかの例を示してこれらの概念を説明します。次のシグネチャを含むPL/SQLプロシージャを記述したとします。

PROCEDURE fetch_params(application_name varchar2, param_names SMP_Agent_STRING_ARRAY,
                       param_values OUT MGMT_JOB_PARAM_LIST);

ジョブ・システムによって要求される特別な入力パラメータおよび出力パラメータは、それぞれバインド・パラメータの最初と2番目の位置にあります。次のXMLブロックは、このプロシージャを使用してパラメータをフェッチするためのジョブ・システムの構成方法を示しています。ジョブ・システムは、入力パラメータの値をバインドして出力パラメータを抽出します。

<paramInfo>
    <!-- pl/sql proc to fetch a mixture of scalar and vector parameters -->
    <paramSource paramNames="vector1,scalar1,scalar2" sourceType="sql">
        <sourceParam name="scalarParams" value="scalar1, scalar2" />
        <sourceParam name="outProc" value="1" />      
        <sourceParam name="vectorParams" value="vector1" />
        <sourceParam name="sqloutparamtype" value="paramList" />  
        BEGIN fetch_params('pts', :1, :2); END; 
    </paramSource>
</paramInfo>

次に、2つの列を持つカーソルを戻すPL/SQLプロシージャがあり、これらの列が名前およびパラメータの値を指定すると仮定します。

TYPE MYCURSOR is REF CURSOR;
FUNCTION fetch_params_cursor(param_names SMP_Agent_STRING_ARRAY, params OUT MYCURSOR);

次のXMLブロックは、このプロシージャを使用して一連のパラメータをフェッチする方法を示しています。

<paramInfo>
    <!-- pl/sql proc to fetch a mixture of scalar and vector parameters -->
    <paramSource paramNames="vector1,scalar1,scalar2" sourceType="sql">
        <sourceParam name="scalarParams" value="scalar1, scalar2" />
        <sourceParam name="vectorParams" value="vector1" />
        <sourceParam name="outProc" value="1" />      
        <sourceParam name="sqloutparamtype" value="cursor" />  
        BEGIN fetch_params_cursor(:1, :2); END; 
    </paramSource>
</paramInfo>

資格証明パラメータ・ソース

Enterprise Manager資格証明表が提供する記憶域メカニズムは、アプリケーションがタスクを実行するのに必要な資格証明に役立ちます。資格証明は一連の名前/値ペアです。たとえば、ノード資格証明には、ユーザー名用とパスワード用の2つの名前/値ペアが含まれます。データベース資格証明には、ユーザー名用、パスワード用およびロール用の3つの名前/値ペアが含まれる場合があります。資格証明表の概念構造を次に示します。

ターゲット 資格証明列名 資格証明値 ユーザー名 コンテナの場所
o815.dlsun966 node_username skini USER1 null
o815.dlsun966 node_password hahaha USER1 null
o815.dlsun966 patch_node_username patchman SYSTEM /private/skini
o815.dlsun966 patch_node_password patchpwd SYSTEM null
o815.dlsun966 patch_db_username system SYSTEM /private/oracle
o815.dlsun966 patch_db_password manager SYSTEM /private/oracle
o815.dlsun966 patch_db_role sysdba SYSTEM /private/oracle

この表では、列node_usernameおよびnode_passwordは、ユーザーUSER1のターゲットo815.dlsun966のノード資格証明を格納するために使用されています。接頭辞patchが付く一連の資格証明列（patch_node_usernameやpatch_node_passwordなど）は、ユーザーがデータベースにパッチを適用する必要がある一連の資格証明を格納するために一緒に使用されます。

ユーザー固有およびシステム固有の2種類の資格証明を格納できます。通常、システム固有の資格証明は権限（たとえばパッチ適用）に関連付けられます。この資格証明は、特定の操作（この場合はデータベースへのパッチ適用）を実行するすべてのユーザーに適用されます。ユーザー固有の資格証明は、特定のユーザーに関連付けられ、通常はユーザー・プリファレンスです。

資格証明には複数の行を関連付けることができます。たとえば、データベースへのパッチ適用の資格証明は、一連のノード資格証明および一連のデータベース資格証明で構成されます（資格証明列にはすべてpatch_という接頭辞が付きます）。

オプションとして一部の資格証明をコンテナの場所に関連付けることもできます。コンテナの場所は、概念上、特定のデータベース（またはアプリケーション）がインストールされているappltopまたはOracleホームのパス名に対応しています。資格証明がコンテナの場所に関連付けられていない場合（通常、アプリケーション資格証明を除くほとんどの資格証明は関連付けられません）、コンテナの場所をnullに設定できます。

アプリケーションが必要な資格証明をEnterprise Manager資格証明表に格納している場合、ジョブ・システムによって、資格証明表から特定の資格証明値を取得するのに使用できるパラメータ・ソースが提供されます。次のXMLブロックは、パッチ適用資格証明を使用して特定のターゲットの資格証明表からノードのユーザー名およびパスワードを取得する方法を指定しています。通常、資格証明表からパラメータが取得される場合、ジョブ・タイプの作成者はoverrideUserをtrueに設定して、ユーザーが異なる資格証明のセットを使用してジョブを発行できないようにします。

<paramInfo>
    <!-- Fetch params from the credentials table -->
    <paramSource paramNames="username,password" overrideUser="true" sourceType="credentials">
      <sourceParams>
            <sourceParam name="credential_columns" value="node_username,node_password" />
            <sourceParam name="target_names" value="dlsun966" />
            <sourceParam name="target_types" value="host" />
            <sourceParam name="credential_scope" value="system" />
      </sourceParams>
    </paramSource>
</paramInfo>

このXMLのcredential_columnsパラメータは、フェッチする必要がある列のリスト（カンマ区切り）です。これらの列は、paramNames属性で指定されたパラメータのユーザー名およびパスワードと1対1の対応関係にあります。ジョブ・システムはnode_username値をusernameパラメータにフェッチし、node_password値をpasswordパラメータにフェッチします。


注意:

資格証明ソースは常にベクトル・パラメータにフェッチします。前述の例の場合、資格証明ソースは、それぞれが1つの値を持つユーザー名およびパスワードの2つのベクトル・パラメータにフェッチします。

credential_scopeパラメータは、資格証明がシステム資格証明かユーザー資格証明かを指定します。userに設定すると、ジョブを発行したユーザーに対応する資格証明が取得されます。systemに設定するとシステム資格証明が使用されます。ジョブの発行者が他のユーザーの資格証明を使用することはできません。

一連の資格証明を一連のベクトル・パラメータにフェッチすることも可能です。次の例では、targetNames、targetTypesおよびcontainerPathsの各属性がカンマで区切られています。containerPaths属性はオプションです。この属性を指定しない場合は、資格証明をフェッチする際にコンテナの場所が考慮されません。指定する場合は、すべてのターゲットに対して有効な値を指定する必要があります。

<paramInfo>
    <!-- Fetch params from the credentials table into vector parameters -->
    <paramSource paramNames="vec_usernames,vec_passwords" overrideUser="true" sourceType="credentials">
      <sourceParams>
            <sourceParam name="credentialType" value="patch" />
            <sourceParam name="credentialColumns" value="node_username,node_password" />
            <sourceParam name="targetNames" value="dlsun966,ap952sun" />
            <sourceParam name="targetTypes" value="host,host" />
            <sourceParam name="containerPaths" value="/private/skini,/private/oracle" /> 
            <sourceParam name="credentialScope" value="system" />
      </sourceParams>
    </paramSource>
</paramInfo>

ベクトル・パラメータを使用してターゲット名およびターゲット・タイプも指定できます。次の例では、targetNamesParamおよびtargetTypesParamを使用して、資格証明をフェッチする際にターゲットの名前および値を指定するための2つのベクトル・パラメータが指定され、これらがベクトル・パラメータvec_usernamesおよびvec_passwordsにそれぞれ入力されます。containerPathsParamパラメータの使用方法にも注意してください。これは、各ターゲットに対応するコンテナを含めるためのジョブ・パラメータです。containerPathsParamを指定する場合は、すべてのターゲットに対してnull以外の値を指定する必要があります。

<paramInfo>
    <!-- Fetch params from the credentials table into vector parameters -->
    <paramSource paramNames="vec_usernames,vec_passwords" overrideUser="true" sourceType="credentials">
      <sourceParams>
            <sourceParam name="credentialType" value="patch" />
            <sourceParam name="credentialColumns" value="node_username,node_password" />
            <sourceParam name="targetNamesParam" value="job_target_names" />
            <sourceParam name="targetTypesParam" value="job_target_types" />
            <sourceParam name="containerPathsParam" value="container_paths" /> 
            <sourceParam name="credentialScope" value="system" />
      </sourceParams>
    </paramSource>
</paramInfo>

ユーザー・パラメータ・ソース

ジョブ・システムにはuserという特別なパラメータ・ソースも用意されています。userは、そのタイプのジョブが発行された場合に一連のパラメータが提供される必要があることを示します。パラメータをソースuserとして宣言し、required属性をtrueに設定すると、ジョブ・システムによって、ジョブの発行時にソース内の指定されたすべてのパラメータが提供されていることが検証されます。

ユーザー・ソースはジョブの発行時またはジョブの実行時に評価できます。発行時に評価すると、必要なパラメータが含まれていない場合に例外がスローされます。実行時に評価すると、必要なパラメータが含まれていない場合に実行が中断します。

<paramInfo>
    <!-- Indicate that parameters a, b and c are required params -->
    <paramSource paramNames="a, b, c" required="true" sourceType="user" />
</paramInfo>

また、ユーザー・ソースを使用して、パラメータのペアがターゲット・パラメータであることを示すこともできます。次に例を示します。

<paramInfo>
    <!-- Indicate that parameters a, b, c, d, e, f are target params -->
    <paramSource paramNames="a, b, c, d, e, f" sourceType="user" >
        <sourceParam name="targetNameParams" value="a, b, c" />
        <sourceParam name="targetTypeParams" value="d, e, f" />
    </paramSource>
</paramInfo>

このブロックは、パラメータ（a、d）、（b、e）、（c、f）がターゲット情報を保持するパラメータであることを示しています。パラメータaはターゲット名、dは対応するターゲット・タイプをそれぞれ保持しています。パラメータbとe、cとfも同様です。ターゲット名を保持する各パラメータには、ターゲット・タイプを保持する対応するパラメータが必要です。これらのパラメータはスカラーまたはベクトルのいずれかです。

インライン・パラメータ・ソース

インライン・パラメータ・ソースを使用すると、ジョブ・タイプは、他のパラメータとの関係でパラメータを定義できます。このメカニズムは、ジョブ・タイプの他の部分で再利用できるパラメータを構成するのに役立ちます。たとえば、次のセクションでは、ジョブ実行IDに基づいてfilenameというパラメータが作成されます。このパラメータはジョブ・タイプの他の部分でも利用されると考えられます。

<jobType>
    <paramInfo>
        <!-- Indicate that value for parameter filename is provided inline -->
        <paramSource paramNames="fileName"  sourceType="inline" >
            <sourceParam name="paramValues" value="%job_execution_id%.log" />
        </paramSource>
    </paramInfo>
.....
    <stepset ID="main" type="serial">
        <step command="putFile" ID="S1">
             ...
             <param name="destFile">%fileName%</param>
             ...
        </step>
    </stepset>
</jobType>

次の例では、vparamというベクトル・パラメータが値v1、v2、v3およびv4のベクトルに設定されます。インライン・ソースを使用して一度に設定できるベクトル・パラメータは1つのみです。

<jobType>
    <paramInfo>
        <!-- Indicate that value for parameter vparam is provided inline -->
        <paramSource paramNames="vparam"  sourceType="inline" >
            <sourceParam name="paramValues" value="v1,v2,v3,v4" />
            <sourceParam name="vectorParams" value="vparam" />
        </paramSource>
    </paramInfo>
.....

checkValueパラメータ・ソース

checkValueパラメータ・ソースを使用すると、ジョブ・システムは、指定された一連のパラメータに一連の値が指定されているかチェックできます。パラメータに指定された値が含まれていない場合、ジョブ・システムによってジョブが中断または一時停止されます。

<paramInfo>
    <!-- Check that the parameter halt has the value true. If not, suspend the job -->
    <paramSource paramNames="halt"  sourceType="checkValue" >
        <sourceParam name="paramValues" value="true" />
        <sourceParam name="action" value="suspend" />
    </paramSource>
</paramInfo>

次の例では、ベクトル・パラメータvに値v1、v2、v3およびv4が含まれているかどうかがチェックされます。checkValueパラメータ・ソースで一度に指定できるベクトル・パラメータは1つのみです。ベクトル・パラメータにこれらの値が指定の順序で含まれていない場合、ジョブは中断します。

<paramInfo>
    <!-- Check that the parameter halt has the value true. If not, suspend the job -->
    <paramSource paramNames="v"  sourceType="checkValue" >
        <sourceParam name="paramValues" value="v1,v2,v3,v4" />
        <sourceParam name="action" value="abort" />
        <sourceParam name="vectorParams" value="v" />
    </paramSource>
</paramInfo>

propertiesパラメータ・ソース

propertiesパラメータ・ソースは、指定された一連のターゲットの個々のターゲットについて、名前の付いた一連のターゲット・プロパティをフェッチし、それぞれのプロパティ値セットをベクトル・パラメータに格納します。

次の例では、指定された一連のターゲット（dlsun966およびap952sun）に対するプロパティOracleHomeおよびOracleSIDを、ベクトル・パラメータohomesおよびosidsにそれぞれフェッチします。ohomesパラメータの最初のベクトル値には、dlsun966に対するOracleHomeプロパティが含まれ、2番目のベクトル値にはap952sunに対するOracleHomeプロパティが含まれることになります。OracleSIDプロパティについても同様です。

<paramInfo>
    <!-- Fetch the OracleHome and OracleSID property into the vector params ohmes, osids -->
    <paramSource paramNames="ohomes,osids" overrideUser="true" sourceType="properties">
      <sourceParams>
            <sourceParam name="propertyNames" value="OracleHome,OracleSID" />
            <sourceParam name="targetNames" value="dlsun966,ap952sun" />
            <sourceParam name="targetTypes" value="host,host" />
      </sourceParams>
    </paramSource>
</paramInfo>

資格証明ソースの場合と同様に、ターゲットの名前およびタイプのベクトル・パラメータ名を指定できます。

<paramInfo>
    <!-- Fetch the OracleHome and OracleSID property into the vector params ohmes, osids -->
    <paramSource paramNames="ohomes,osids" overrideUser="true" sourceType="properties">
      <sourceParams>
            <sourceParam name="propertyNames" value="OracleHome,OracleSID" />
            <sourceParam name="targetNamesParam" value="job_target_names" />
            <sourceParam name="targetTypes" value="job_target_types" />
      </sourceParams>
    </paramSource>
</paramInfo>

パラメータ・ソースおよびパラメータ置換

パラメータ・ソースは指定された順序で適用されます。パラメータ置換（%param%形式）は、sourceParamタグの内部で使用できますが、パラメータ・ソースが評価される際に置換対象のパラメータが存在する必要があります。存在しない場合、ジョブ・システムによってパラメータの位置に空の文字列が代用されます。

パラメータの暗号化

ジョブ・システムには、指定されたパラメータを暗号化された形式で格納する機能があります。パスワードなどの機密情報を含むパラメータは、暗号化して格納する必要があります。パラメータ・ソースでencrypted属性をtrueに設定すると、パラメータ・ソースを介してフェッチされたパラメータが暗号化されることをジョブ・タイプで示すことができます。次に例を示します。

<paramInfo>
    <!-- Fetch params from the credentials table into vector parameters; store them encrypted -->
    <paramSource paramNames="vec_usernames,vec_passwords" overrideUser="true" 
                                  sourceType="credentials" encrypted="true">
      <sourceParams>
            <sourceParam name="credentialType" value="patch" />
            <sourceParam name="credentialColumns" value="node_username,node_password" />
            <sourceParam name="targetNames" value="dlsun966,ap952sun" />
            <sourceParam name="targetTypes" value="host,host" />
            <sourceParam name="credentialScope" value="system" />
      </sourceParams>
    </paramSource>
</paramInfo>

また、ユーザーが提供したパラメータが暗号化されて格納されることをジョブ・タイプで指定することもできます。

<paramInfo>
    <!-- Indicate that parameters a, b and c are required params -->
    <paramSource paramNames="a, b, c" required="true" sourceType="user" encrypted="true" />
</paramInfo>

セキュリティ情報の指定

通常、ジョブ・タイプは、特権的とみなされるアクションを実行する傾向にあります。たとえば、本番データベースへのパッチ適用や、Oracleホームまたはappltopにインストールされたソフトウェアへの作用などです。そのため、このようなジョブ・タイプは、これらのアクションを実行するのに適したレベルの権限を持つEnterprise Managerユーザーによってのみ発行されることが必要です。ジョブ・システムにはsecurityInfoというセクションが用意されており、ジョブ・タイプの作成者はこれを使用して、そのタイプのジョブの発行者に必要な最低レベルの権限（システム、ターゲット）を指定できます。Enterprise Managerユーザー・モデルおよびシステムとターゲットの権限の詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

ジョブ・タイプの作成者は、securityInfoセクションを使用して、ジョブの発行に関連付けられているセキュリティ要件をジョブ・タイプ自体の内部にカプセル化できます。セキュリティを実行するためにそれ以外のコードを記述する必要はありません。また、この処理を行うことで、ジョブ・タイプの作成者によって定義された一連の権限を持たないかぎり、Enterprise Managerユーザーが特定のタイプのジョブを（ジョブ・システムAPIを使用し、アプリケーションをバイパスして）直接発行できなくなります。

一般的なsecurityInfoセクションの例を次に示します。ここでは、データベースをクローニングする、次のようなジョブ・タイプを記述すると仮定します。このジョブ・タイプでは、2つのターゲットが要求されます。1つはソース・データベースで、もう1つはターゲット・データベースが作成されるターゲット・ノードです。また、クローン・ジョブを発行するユーザーがソース（データベース）のCLONE FROM権限およびターゲット（ノード）のMAINTAIN権限を持つことが要求されます。ユーザーは、システムに新しいターゲットを導入するためのCREATE TARGETシステム権限を持つ必要があります。ジョブ・タイプは、ターゲット・リストの最初のターゲットがソースで、ターゲット・リストの2番目のターゲットがターゲットになるように記述されています。このようなジョブ・タイプのセキュリティ要件は、次のように指定されます。

<jobType>
  <securityInfo>
    <privilege name="CREATE TARGET" type="system" />
    <privilege name="CLONE FROM" type="target" evaluateAtSubmission="false" >
        <target name="%job_target_names%[1]" type="%job_target_types%[1]" />
    </privilege>
    <privilege name="MAINTAIN" type="target" evaluateAtSubmission="false">
        <target name="%job_target_names%[2]" type="%job_target_types%[2]" />
    </privilege>
  </securityInfo>
  <!-- An optional <paramInfo> section will follow here, followed by the stepset
       definition of the job
  -->
  <paramInfo>
   ....
  </paramInfo>
  <stepset ...>
  </stepset>
</jobType>

securityInfoセクションは一連の<privilege>タグで構成されます。それぞれの権限はシステム権限またはターゲット権限で、<privilege>タグのタイプ属性によって示されます。権限がターゲット権限の場合、権限が付与されるターゲットを明示的に列挙するか、（後述の2番目の例のように）target_names_param属性およびtarget_types_param属性を使用する必要があります。通常の%param%表記を使用して、ジョブ・パラメータおよびターゲットのプレースホルダを示すことができます。

デフォルトでは、securityInfoセクションの<privilege>ディレクティブは、発行時間パラメータ・ソースがすべて評価された後で、ジョブの発行時に評価されます。securityInfoセクションで指定されている権限をユーザーが持たない場合、ジョブ・システムによって例外がスローされます。実行時間パラメータ・ソースは、ジョブの発行時には評価されないため、まだ評価されていない可能性があるジョブ・パラメータを使用しないように注意する必要があります。ジョブ・システムに、ジョブの実行時に権限ディレクティブを評価させることができます。これを行うには、（前述の例の2番目と3番目の権限タグのように）evaluateAtSubmissionパラメータをfalseに設定します。この処理を行う唯一の状況として考えられるのは、ジョブの対象となる一連のターゲットがジョブの実行時まではっきりわからない場合です（たとえば、実行時間パラメータ・ソースを介して一連のターゲットが計算される場合）。実行時間権限ディレクティブは、すべての実行時間パラメータ・ソースが評価された後で評価されます。

2番目の例として、それぞれのターゲットでMODIFY権限が要求されるジョブ・タイプを記述するとします。ただし、記述する時点では正確なターゲット数は不明です。この場合はtarget_names_param属性およびtarget_types_param属性を使用できます。これらの属性により、ジョブ・システムがターゲット名および対応するターゲット・タイプを取得する場所であるベクトル・パラメータが指定されます。任意のベクトル・パラメータを指定できますが、この例ではジョブ・ターゲット・リスト（job_target_namesおよびjob_target_types）を使用します。

<securityInfo>
    <privilege name="MODIFY" type="target" target_names_param="job_target_names" 
                target_types_param="job_target_types" />
</securityInfo>

ロック情報の指定

多くの場合、ジョブの実行では、リソースを取得することが必要になります。たとえば、データベースにパッチを適用するジョブでは、パッチを適用する間、データベースで（システム内の他のユーザーによって発行された）他のジョブが実行されるのを防ぐメカニズムが必要になります。言い換えれば、同じロックを取得しようとする他のジョブをブロック（または中断）するために、データベース・ターゲットのロックを取得する必要があります。これにより、パッチ適用ジョブを開始すると、中断することなく作業が実行されます。ロックは複数のレベルで行われる場合もあります。たとえば、データベースのホット・バックアップでは、他のホット・バックアップを続行できますが（データベースが停止されないため）、コールド・バックアップまたはデータベースの停止ジョブは続行できません（最終的にデータベースが停止されるため）。ターゲットのロックを取得することで、ジョブ実行は、ターゲットのリソースを予約することを示すことができます。ロックは、ターゲットの一部の機能を予約するためのプロキシです。実行がロックを取得すると、ターゲットで同じロックを取得しようとする他の実行はブロックされます。ロックは名前およびタイプで識別されます。ロックには次のタイプがあります。

ジョブ・タイプが取得する必要があるロックは、ジョブ・タイプのlockInfoセクションを指定して取得できます。このセクションには、ジョブが取得するロック、ロックのタイプ、ロックの取得対象となるターゲットのリストが含まれます。次のセクションについて考えます。

<lockInfo action="suspend">
    <lock type="targetExclusive">
        <targetList>
            <target name="%backup_db%" type="oracle_database" />
        </targetList>
    </lock>
    <lock type="targetNamed" name="LOCK1" >
        <targetList>
            <target name="%backup_db%" type="oracle_database" />
            <target name="%job_target_names%[1]" type="%job_target_types%[1]" />
            <target name="%job_target_names%[2]" type="%job_target_types%[2]" />
        </targetList>
    </lock>
    <lock type="global" name="GLOBALLOCK1" />
</lockInfo>

このセクションは、ジョブ・パラメータbackup_dbによって名前が指定されるデータベース・ターゲットのターゲット排他ロックを取得するジョブ・タイプを示しています。また、3つのターゲットのLOCK1という名前付きターゲット・ロックも取得します。これらのターゲットは、ジョブ・パラメータbackup_dbに名前が格納されるデータベース、およびジョブのターゲット・リストにある最初の2つのターゲットです。最後に、GLOBALLOCK1という名前のグローバル・ロックを取得します。action属性は、セクション内のいずれかのロックを取得できない（他の実行によってロックが保持されていると考えられる）場合に、ジョブ・システムが実行をどのように処理するかを指定します。指定できる値はsuspend（すべてのロックが解放され、実行状態が一時停止中のロックに変更される）およびabort（実行が中断する）です。実行およびロックに関する注意点は次のとおりです。

ロックおよびネストされたジョブ: lockInfoセクションを持つ複数のジョブが相互にネストされている場合、ネストされたジョブのロックは、実行の開始時ではなく、ネストされたジョブが最初に実行されたときに取得されます。ロックを使用できない場合、親実行のいくつかのステップが実行される可能性はありますが、その後で親実行は一時停止または中断します。

lockInfoの例

（1）HOTBACKUPおよびCOLDBACKUPという2つのジョブ・タイプについて考えます。これらのジョブ・タイプは、データベースでホット・バックアップおよびコールド・バックアップをそれぞれ実行します。コールド・バックアップではデータベースが停止するのに対して、ホット・バックアップでは起動したままの状態を保ちます。ホット・バックアップは一度に1つしか実行できないため、他のホット・バックアップおよびコールド・バックアップを遮断する必要があります。コールド・バックアップの実行時には、（実行の一部としてデータベースが停止するため）他のジョブ・タイプを実行できません。3つ目のジョブ・タイプSQLANALYZEについて考えます。このジョブ・タイプでは、スケジュールされたメンテナンス・アクティビティが実行され、その結果、データベース・チューニング・パラメータが変更されます。2つのSQLANALYZEを同時に実行することはできません。次の表は、ジョブ・タイプ間の非互換性を示しています。Xはジョブ・タイプに互換性がないことを示します。OKはジョブ・タイプに互換性があることを示します。

ジョブ・タイプ HOTBACKUP COLDBACKUP SQLANALYZE
HOTBACKUP X X OK
COLDBACKUP X X X
SQLANALYZE OK X X

3つのジョブ・タイプのlockInfoセクションを次に示します。コールド・バックアップでは、データベースの排他ターゲット・ロックが取得されます。ホット・バックアップ・ジョブでは、排他ロックは取得されず、名前付きロックBACKUP_LOCKのみが取得されます。同様に、SQLANALYZEジョブでは、SQLANALYZE_LOCKという名前付きターゲット・ロックが取得されます。ジョブの対象となるデータベースが、ジョブのターゲット・リストにある最初のターゲットと仮定します。2つのジョブのロック・セクションは次のようになります。

<jobType name="HOTBACKUP">
    <lockInfo action="suspend">
        <lock type="targetNamed" name="BACKUP_LOCK" >
            <targetList>
                <target name="%job_target_names%[1]" type="%job_target_names%[1]" />
            </targetList>
        </lock>
    </lockInfo>
    ....... Rest of the job type follows
</jobType>
<jobType name="COLDBACKUP">
    <lockInfo action="suspend">
        <lock type="targetExclusive">
            <targetList>
                <target name="%job_target_names%[1]" type="%job_target_names%[1]" />
            </targetList>
        </lock>
    </lockInfo>
    ........ Rest of the job type follows
</jobType>

<jobType name="SQLANALYZE">
    <lockInfo action="abort">
        <lock type="targetNamed" name="SQLANALYZE_LOCK" >
            <targetList>
                <target name="%job_target_names%[1]" type="%job_target_names%[1]" />
            </targetList>
        </lock>
    </lockInfo>
    ........ Rest of the job type follows
</jobType>

名前付きターゲット・ロックはすべての排他ターゲット・ロックをブロックするため、ホット・バックアップを実行するとコールド・バックアップが一時停止しますが、（異なる名前付きロックを取得しようとするため）分析ジョブは一時停止しません。SQL分析ジョブを実行すると、他のSQL分析ジョブが中断し、コールド・バックアップが一時停止しますが、ホット・バックアップは一時停止しません。コールド・バックアップを実行すると、ホット・バックアップが一時停止し、SQL分析ジョブが中断します。

（2）PATCHCHECKというジョブ・タイプについて考えます。このジョブ・タイプはパッチのステージング領域を定期的にチェックし、新たにステージングされたパッチの情報をEnterprise Managerリポジトリにダウンロードします。このようなジョブは2つ同時に実行できませんが、ジョブは実際にどのターゲットにも関連付けられません。このジョブ・タイプの解決法は、グローバル・ロックの取得を試みることです。

<jobType name="PATCHCHECK">
    <lockInfo>
        <lock type="global" name="PATCHCHECK_LOCK" />
    </lockInfo>
    ........ Rest of the job type follows
</jobType>

（3）次のように、内部にSQLANALYZEタイプをネストするジョブ・タイプについて考えます。ネストされたジョブは、最初のステップであるS1の実行後に実行されます。

<jobType name="COMPOSITEJOB">
    <stepset ID="main" type="serial">
        <step ID="S1" ...>
           ....
         </step>
         <job name="nestedsql" type="SQLANALYZE">
            ....
         </job>
    </stepset>
</jobType>

この例の場合、ネストされたジョブは（SQLANALYZEにlockInfoセクションが含まれるため）実行時にロックを取得しようとします。その時点で他の実行によってロックが保持されている場合は、（lockInfoで指定されているように）ネストされたジョブが中断し、最終的には親ジョブが中断します。

ジョブまたはステップの一時停止

一時停止は、ジョブのステップがスケジュールおよび実行の対象として考慮されないことを示す特別な状態です。suspend_job PL/SQL APIを介して、実行中のジョブのステップによってジョブが一時停止することもあります。この場合は現在実行中のステップおよびジョブ自体がともに一時停止します。

ジョブの一時停止には次のようなセマンティクスがあります。現在スケジュール済状態にあるジョブのすべてのステップが一時停止としてマークされ、その後はスケジュールも実行も行われません。現在実行中のすべてのステップ（パラレル・ステップセットなどの場合）は、そのまま実行されます。ただし、現在実行中のステップのいずれかが完了すると、ジョブ内の後続のステップはスケジュールされず、一時停止状態になります。ジョブが発行時に一時停止した場合は、スケジュールされる予定だったジョブの最初のステップ（単数または複数）にこれが適用されます。

一時停止中のジョブは、restart_job() PL/SQL APIをコールすることでいつでも再起動できます。ただし、シリアライズ（ロック）のルールによって一時停止したジョブは手動では再起動できません。このようなジョブは、そのジョブ・タイプの現在実行中のジョブが完了したときに、ジョブ・システムによって自動的に再起動されます。ジョブが再起動されると、一時停止中のすべてのステップの状態が効率的にスケジュール済に変更されます。その後、ジョブの実行が通常どおりに行われます。

ジョブの再起動

ジョブが一時停止、失敗または中断した場合、任意のステップ（通常は失敗または中断したステップが含まれるステップセット）から再起動できます。失敗または中断したジョブについて、ジョブが再起動されたときに実際に再スケジュールされるステップは、ジョブの再起動が開始されたステップによって異なります。

再起動および再発行

ジョブのステップが再発行された場合、そのステップの初回の実行が完了したか失敗したかに関係なく、そのジョブは実行されます。ステップセットが再発行された場合は、ステップセットの最初のステップ、ステップセットまたはジョブが再帰的に再発行されます。したがって、ジョブが再発行された場合は、初期ステップセットが再帰的に再発行されてジョブ全体が再実行されます。使用されるパラメータおよびターゲットは、ジョブが最初に発行されたときと同じものです。また、ジョブは、指定された一連のパラメータおよびターゲットを使用して、初回の発行時のように実行されます。ジョブは、mgmt_jobsパッケージのresubmit_job APIを使用して再発行できます。ジョブの再発行は、前回までの実行が正常に行われた場合でも可能です。

中断または失敗したジョブの実行を再起動できます。通常、ジョブの再起動は、最後に失敗したステップからジョブの実行を再開することを意味します（ただし、後述するように、ジョブ・タイプはステップ、ステップセットまたはジョブのrestartMode属性を使用してこの動作を制御できます）。よくある例として、失敗したジョブの実行の中で実際には成功したステップは、再実行されません。失敗または中断したジョブは、mgmt_jobsパッケージのrestart_job APIをコールして再起動できます。正常に実行されたジョブは再起動できません。

デフォルトの再起動動作

ジョブを再起動すると、再起動実行と呼ばれる新しい実行が作成されます。失敗した初回のジョブの実行は、ソース実行と呼ばれます。すべてのパラメータおよびターゲットがソース実行から再起動実行へコピーされます。パラメータ・ソースの再評価は、最初のジョブの中断がパラメータ・ソースの障害によるものだった場合を除き、行われません。

シリアル（または反復）ステップセットを再起動する場合は、ジョブ・システムによって、最初にシリアル・ステップセットのステータスが調査されます。シリアル・ステップセットのステータスが完了の場合は、構成ステップのすべてのエントリがソース実行から再起動実行へコピーされます。ステップセットのステータスが失敗または中断の場合、ジョブ・システムは、包括的にステップセットの最初のステップから開始します。前回正常に実行されたソース実行内のステップは、再起動実行にコピーされます。前回失敗または中断したステップは、再起動実行で実行の対象として再スケジュールされます。このようなステップの実行が終了した後で、ジョブ・システムは実行する次のステップを判別します。これらは、successOfまたはfailureOf依存、もしくは単純に現在のステップの後に実行されるステップ、ステップセットまたはジョブの可能性があります。ソース実行で後続のステップが正常に実行された場合、そのステップは実行の対象としてスケジュールされません。ジョブ・システムによって、そのステップのソース実行ステータスが単純に再起動実行にコピーされるだけです。ステップセットの最後に到達するまで、引き続き同様の処理が行われます。その後、新しい実行に基づいてステップセットのステータスが再計算されます。

パラレル・ステップセットを再起動する場合は、前述と同様、ジョブ・システムによって、最初にシリアル・ステップセットのステータスが調査されます。ステップセットのステータスが完了の場合は、構成ステップのすべてのエントリがソース実行から再起動実行へコピーされます。ステップセットのステータスが失敗または中断の場合は、ステップセット内の成功したすべてのステップがソース実行から再起動実行へコピーされます。ソース実行で失敗または中断したすべてのステップは、並列的に再スケジュールされます。これらのステップの実行が終了した後、ステップセットのステータスが再計算されます。

ネストされたジョブを再起動する場合は、ネストされたジョブの最初（外側）のステップセットに、再起動アルゴリズムが再帰的に適用されます。

前の段落の内容で、対象となるエンティティの1つがステップセットまたはネストされたジョブの場合は、再起動のメカニズムがステップセットまたはジョブに再帰的に適用されます。ステップのエントリが再起動実行にコピーされる際、子実行エントリは親実行と同じ出力CLOBエントリを指定します。

restartModeディレクティブの使用方法

ジョブ・タイプは、restartMode属性を使用することで、その中の各ステップ、ステップセットまたはジョブの再起動動作に影響を与える場合があります。この属性は、failure（デフォルト）またはalwaysに設定できます。failureに設定した場合、前項で説明した包括的なコピー処理が発生すると、ソース実行で成功したステップ、ステップセットまたはジョブは、再実行されずにコピーされます。ソース実行で失敗または中断した場合は、最後の障害の場所で再帰的に再起動されます。

ステップに対してrestartMode属性をalwaysに設定した場合、ソース実行で成功したか失敗したかに関係なく、そのステップは再起動時に常に再実行されます。この属性は、再起動時の際にジョブの特定のステップを常に再実行する必要がある場合（たとえば、データベースをバックアップする前にデータベースを停止させるステップ）に使用すると便利です。

ステップセットまたはネストされたジョブに対してrestartMode属性をalwaysに設定した場合、ステップセットまたはネストされたジョブのすべてのステップが再起動されます。ソース実行で正常に実行されたステップも例外ではありません。failureに設定すると、ステップセットまたはネストされたジョブのステータスがソース実行で失敗または中断に設定された場合のみ、再起動が試行されます。ステップセットまたはネストされたジョブに含まれる個々のステップに対してrestartModeをalwaysに設定することも可能です。このようなステップは常に再実行されます。

再起動の例

例1

次のような一連のステップを伴うシリアル・ステップセットがあるとします。

<jobtype ...>
<stepset ID="main" type="serial" >
    <step ID="S1" ...>
     ...
    </step>
    <step ID="S2" ...>
     ...
    </step>
    <step ID="S3" failureOf="S2"...>
     ...
    </step>
    <step ID="S4" successOf="S2"...>
     ...
    </step> 
</stepset>
</jobtype>

このステップセットについて、ソース実行でステップS1が正常に実行され、ステップS2およびS3（S2の失敗依存）が失敗したと仮定します。ジョブが再起動されると、ステップS1は（ソース実行で正常に実行されたため）再実行されずにソース実行から再起動実行へコピーされます。ソース実行で失敗したステップS2は、再スケジュールされて実行されます。S2が正常に実行された場合は、その成功依存であり、ソース実行で実行されていないS4がスケジュールされて実行されます。このステップセット（およびジョブ）のステータスはS4のステータスになります。反対に、S2が失敗した場合は、その失敗依存であるS3が（ソース実行で失敗したため）再スケジュールされて実行され、ステップセット（およびジョブ）のステータスはS3のステータスになります。

ここで、ソース実行においてステップS1が成功し、S2が失敗し、S3（S2の失敗依存）が成功したと仮定します。また、結果としてステップセット（したがってジョブ実行）は成功したとします。この場合、ステップの1つが失敗しても実行は正常に完了したため、この実行を再起動することはできません。

最後に、ステップS1およびS2が成功し、S4（S2の成功依存）が失敗したと仮定します。この場合、S3はスケジュールされません。実行が再起動されると、ジョブ・システムによってソース実行から再起動実行へS1およびS2の実行がコピーされ、S4は再スケジュールされて実行されます。S4が成功するとジョブは成功します。

例2

次の例について考えます。

<jobtype ...>
<stepset ID="main" type="serial" stepsetStatus="S2" >
    <step ID="S1" restartMode="always" ...>
     ...
    </step>
    <step ID="S2" ...>
     ...
    </step>
    <step ID="S3" ...>
     ...
    </step> 
</stepset>
</jobtype>

この例について次のように仮定します。ステップS1は正常に実行され、S2は失敗しました。また、（S2に依存しないため）S3が実行されて成功しました。ただし、ステップセットmainのstepsetStatusがS2に設定されているため、ジョブは失敗しました。ジョブが再起動されると、初回に正常に実行されたにもかかわらず、S1は全体的にもう一度実行されます。これは、S1のrestartModeがalwaysに設定されているためです。ステップS2は、ソース実行で失敗したため、再スケジュールされて実行されます。S2の実行後、ステップS3は実行の対象として再スケジュールされません。これは、S3がソース実行で正常に実行されたためです。再起動実行でS3を実行する必要がある場合は、S3のrestartModeをalwaysに設定する必要があります。

この例でS1およびS2が成功し、S3が失敗しても、ステップセットmainは成功します（S2によってステップセットのステータスが決まるため）。この場合、ジョブは成功するためジョブを再起動できません。

例3

次の例について考えます。

<jobtype ...>
<stepset ID="main" type="serial"  >
  <stepset type="serial" ID="SS1" stepsetStatus="S1">
    <step ID="S1" ...>
     ...
    </step>
    <stepset ID="S2" ...>
     ...
    </step>
  </stepset>
  <stepset type="parallel" ID="PS1" successOf="S1" >
    <step ID="P1" ...>
     ...
    </step>
    <step ID="P2" ...>
     ...
    </step>
    <step ID="P3" ...>
     ...
    </step>
  </stepset>
</stepset>
</jobtype>

この例について次のように仮定します。ステップS1およびS2が成功しました（したがって、ステップセットSS1が正常に実行されました）。その後、パラレル・ステップセットPS1がスケジュールされ、P1が正常に実行されましたがP2およびP3は失敗しました。その結果、ステップセットmain（およびそのジョブ）は失敗しました。実行が再起動されると、ステップS1およびS2（したがってステップセットSS1）は実行されずにコピーされます。パラレル・ステップセットPS1では、失敗した両方のステップ（P2およびP3）が再スケジュールされて実行されます。

ここで、ソース実行でS1が正常に実行され、S2が失敗したと仮定します。この場合も、ステップセットSS1は正常に実行されます。これは、ステップセットのステータスが（stepsetStatusディレクティブの設定により）S2ではなくS1によって決まるためです。次に、PS1がスケジュールされP1が失敗し、P2およびP3が正常に実行されたと仮定します。このジョブが再スケジュールされる際に、（ステップセットSS1が正常に実行されたため）ステップS2は再実行されません。ステップP1は再スケジュールされて実行されます。

（4）次に示すのは、例3のXMLを若干変更した例です。

<jobtype ...>
<stepset ID="main" type="serial"  >
  <stepset type="serial" ID="SS1" stepsetStatus="S1" restartMode="always" >
    <step ID="S1" ...>
     ...
    </step>
    <stepset ID="S2" ...>
     ...
    </step>
  </stepset>
  <stepset type="parallel" ID="PS1" successOf="S1" >
    <step ID="P1" ...>
     ...
    </step>
    <step ID="P2" ...>
     ...
    </step>
    <step ID="P3" ...>
     ...
    </step>
  </stepset>
</stepset>
</jobtype>

この例について次のように仮定します。S1およびS2が成功しました（したがって、ステップセットSS1が正常に実行されました）。その後、パラレル・ステップセットPS1がスケジュールされ、P1が正常に実行されましたがP2およびP3は失敗しました。ジョブが再起動されると、（restartModeがalwaysに設定されているため）ステップセットSS1全体が再起動されます。つまり、ステップS1およびS2は、連続してスケジュールされて実行されます。次に、ステップセットPS1が再起動されますが、restartModeが指定されていないため（デフォルトで常にfailure）、障害の場所で再起動されます。この場合、失敗したステップP2およびP3は再実行されますが、P1は実行されません。

「ジョブ・アクティビティ」および「ジョブ・ライブラリ」の各ページへのジョブ・タイプの追加

Enterprise Managerコンソールの「ジョブ・アクティビティ」または「ジョブ・ライブラリ」のどちらかのページ、あるいはその両ページから新規のジョブ・タイプにアクセスできるようにするには、特定のXMLタグ属性を変更する必要があります。「ジョブ・アクティビティ」ページでジョブ・タイプを表示するには、次の例のようにuseDefaultCreateUIをtrueに設定します。

<displayInfo useDefaultCreateUI="true"/>

「ジョブ・ライブラリ」ページでジョブ・タイプを表示するには、useDefaultCreateUI属性を設定する以外に、jobtypeのeditable属性もtrueに設定する必要があります。

<jobtype name="jobType1" editable="true">

useDefaultCreateUI="true"でeditable="false"の場合、ジョブ・タイプは「ジョブ・アクティビティ」ページのみに表示され、「ジョブ・ライブラリ」ページには表示されません。また、ジョブ定義は編集できません。

「ジョブ・アクティビティ」ページへのジョブ・タイプの追加

図5-1に示すように、useDefaultCreateUI属性をtrueに設定すると、ジョブを作成中のユーザーが新規に追加されたジョブ・タイプを「ジョブの作成」メニューから選択できます。

図5-1 「ジョブ・アクティビティ」ページで使用できるジョブ・タイプ

図5-1の説明が続きます
「図5-1 「ジョブ・アクティビティ」ページで使用できるジョブ・タイプ」の説明

ジョブ・タイプを「ジョブ・アクティビティ」ページから使用できるようにすると、ユーザーは新規に追加されたジョブ・タイプを使用してジョブを作成する際に、デフォルトの「ジョブの作成」ユーザー・インタフェースにもアクセスできます。

図5-2 デフォルトの「ジョブの作成」ユーザー・インタフェース

図5-2の説明が続きます
「図5-2 デフォルトの「ジョブの作成」ユーザー・インタフェース」の説明

displayInfoタグの追加

次の例に示すように、</stepset>タグの後ろで、ジョブ定義ファイルの最終行にある</jobtype>タグの前の任意の場所に、displayInfoタグを追加できます。

<jobtype ...>
<stepset ID="main" type="serial"  >
  <stepset type="serial" ID="SS1" stepsetStatus="S1">
    <step ID="S1" ...>
     ...
    </step>
    <stepset ID="S2" ...>
     ...
    </step>
  </stepset>
  <stepset type="parallel" ID="PS1" successOf="S1" >
    <step ID="P1" ...>
     ...
    </step>
    <step ID="P2" ...>
     ...
    </step>
    <step ID="P3" ...>
     ...
    </step>
  </stepset>
</stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobtype>

「ジョブ・ライブラリ」ページへのジョブ・タイプの追加

「ジョブ・ライブラリ」ページでジョブ・タイプを使用可能にするには、displayInfoタグを追加する以外に、jobTypeタグのeditable属性もtrueに設定する必要があります。これによって、図5-3に示すとおり、新規に追加されたジョブ・タイプが「ライブラリ・ジョブの作成」メニューから選択可能なオプションになります。

図5-3 「ジョブ・ライブラリ」ページのジョブ・タイプ

図5-3の説明が続きます
「図5-3 「ジョブ・ライブラリ」ページのジョブ・タイプ」の説明

ジョブ・タイプを編集可能にする設定

jobtypeタグのeditable属性は、次の例に示すとおり、ジョブ定義ファイルの先頭行で設定されます。

<jobtype name="jobType1" editable="true">
<stepset ID="main" type="serial"  >
  <stepset type="serial" ID="SS1" stepsetStatus="S1">
    <step ID="S1" ...>
     ...
    </step>
    <stepset ID="S2" ...>
     ...
    </step>
  </stepset>
  <stepset type="parallel" ID="PS1" successOf="S1" >
    <step ID="P1" ...>
     ...
    </step>
    <step ID="P2" ...>
     ...
    </step>
    <step ID="P3" ...>
     ...
    </step>
  </stepset>
</stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobtype>

例: XMLでのジョブ・タイプの指定

例1

次のXMLは、S1、S2、S3およびS4という4つのステップを定義する、jobType1というジョブ・タイプを説明しています。S1およびS2は直列的に、逐次実行されます。ステップS3はステップS2が成功した場合のみ実行され、ステップS4はステップS2が失敗した場合のみ実行されます。すべてのステップは反復サブセット内で実行されるため、これらのアクションは、タイプがデータベースのジョブ・ターゲット・リストに含まれるすべてのターゲットで、並列的に実行されます。また、%patchno%、%username%、%password%および%job_target_name%など、パラメータを示すために%記号が使用されています。ジョブ・システムにより、%patchno%は、patchnoという名前のジョブ・パラメータの値に置き換えられます。同様に、%username%および%password%は、対応するパラメータの値に置き換えられます。%job_target_name%および%job_target_type%は事前作成プレースホルダで、現在ステップが実行されているターゲットの名前のかわりに使用されます。

ステップS2、S3およびS4は、remoteOpコマンドを使用してSQL*Plusスクリプトをエージェントで実行する方法を示しています。

次のいずれかが発生した場合、ジョブのステータスは失敗になります。

S2は（S1が成功したか失敗したかに関係なく）S1の後に実行されるため、S1のステータスがジョブのステータスに影響することはありません。

<jobtype name="jobType1" editable="true" version="1.0">
  <stepset ID="main" type="iterativeParallel" iterate_param="job_target_types"
        iterate_param_filter="oracle_database" >
        <step ID="s1" command="remoteOp"">
          <paramList>
            <param name="remoteCommand">myprog</param>
            <param name="targetName">%job_target_names%[%job_iterate_index%]</param>
            <param name="targetType">%job_target_types%[%job_iterate_index%]</param>
            <param name="args">-id=%patchno%</param>
            <param name="successStatus">3</param>
            <param name="failureStatus">73</param>
            <param name="username">%username%</param>
            <param name="password">%password%</param>
          </paramList>
        </step>
        <step ID="s2" command="remoteOp"">
          <paramList>
            <param name="remoteCommand">myprog2</param>
            <param name="targetName">%job_target_names%[%job_iterate_index%]</param>
            <param name="targetType">%job_target_types%[%job_iterate_index%]</param>
            <param name="args">-id=%patchno%</param>
            <param name="successStatus">3</param>
            <param name="failureStatus">73</param>
            <param name="username">%username%</param>
            <param name="password">%password%</param>
          </paramList>
        </step>
         <step ID="s3" successOf="s2" command="remoteOp">
           <paramList>
             <param name="command">prog1</command> 
             <param name="script">
             <![CDATA[
                   select * from MGMT_METRICS where
                       target_name=%job_target_type%[%job_iterate_param_index%]
              ]]>
              </param>
            <param name="args">%db_username%/%db_passwd%@%db_alias%</param>
            <param name="targetName">%job_target_names%[%job_iterate_index%]</param>
            <param name="targetType">%job_target_types%[%job_iterate_index%]</param>
            <param name="successStatus">0</param>
            <param name="failureStatus">1</param>
            <param name="username">%username%</param>
            <param name="password">%password%</param>
            </paramList>
         </step>
<step ID="s4" failureOf="s2" command="remoteOp">
          <paramList>
            <param name="input">
            <![CDATA[
                This is standard input to the executed progeam. You can use 
                    placeholders for parameters, such as 
                    %job_target_name%[%job_iterate_param_index%]
            ]]>
            </param>
            <param name="remoteCommand">prog2</param>
            <param name="targetName">%job_target_names%[%job_iterate_index%]</param>
            <param name="targetType">%job_target_types%[%job_iterate_index%]</param>
            <param name="args"></param>
            <param name="successStatus">0</param>
            <param name="failureStatus">1</param>
            <param name="username">%username%</param>
            <param name="password">%password%</param>
          </paramList>
         </step>
  </stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobtype>

例2

次のXMLは、（パラレル・ステップセットss1内で）並列的に実行されるS1とS2の2つのステップ、およびS1とS2の両方が正常に実行された場合のみ実行される3つ目のステップS3を持つジョブ・タイプを説明しています。これを実現するために、同じくパラレル・ステップセットss1を含むシリアル・ステップセット（main）の中に、ステップS3が配置されています。このジョブ・タイプは複数ノード・ジョブです。コマンドへのパラメータ内で%job_target_name%[1]、%job_target_name%[2]が使用されています。反復ステップセット以外のステップセットでジョブ・ターゲットを参照できる唯一の方法は、（順序付けされた）ターゲット配列内でのそのジョブ・ターゲットの位置を使用することです。つまり、%job_target_name%[1]は最初のターゲット、%job_target_name%[2]は2番目のターゲット、以下同様になります。ほとんどの複数ノード・ジョブは、ターゲットの順序が同じであることを前提としています。たとえば、クローン・ジョブでは、ソース・データベースを最初のターゲット、およびターゲット・データベースを2番目のターゲットにすることが前提になる場合があります。このジョブは、次のいずれかが発生した場合に失敗します。

ジョブ・タイプ自体がエージェントにバインドされていることを宣言している点にも注意してください。これは、（最初のターゲットまたは2番目のターゲットに対応する）どちらかのEMDが停止した場合に、ジョブが一時停止/エージェント停止の状態に設定されることを意味します。

<jobtype name="jobType2" version="1.0" agentBound="true" >
  <stepset ID="main" type="serial" editable="true">
      <!-- All steps in this stepset ss1 execute in parallel -->
      <stepset ID="ss1" type="parallel" >
          <step ID="s1" command="remoteCommand" >
            <paramList>
              <param name="remoteCommand">myprog</param>
              <param name="targetName">%job_target_names%[1]</param>
              <param name="targetType">%job_target_types%[1]</param>
              <param name="args">-id=%patchno%</param>
              <param name="successStatus">3</param>
              <param name="failureStatus">73</param>
              <param name="username">%username%</param>
              <param name="password">%password%</param>              
            </paramList>
          </step>
          <step ID="s2" command="remoteCommand" >
            <paramList>
              <param name="remoteCommand">myprog</param>
              <param name="targetName">%job_target_names%[2]</param>
              <param name="targetType">%job_target_types%[2]</param>
              <param name="args">-id=%patchno%</param>
              <param name="successStatus">3</param>
              <param name="failureStatus">73</param>
              <param name="username">%username%</param>
              <param name="password">%password%</param> 
            </paramList>
          </step>
      </stepset>
      <!-- This step executes after stepset ss1 has executed, since it is
           inside the serial subset "main"
      -->
      <step ID="s3" successOf="ss1" command="remoteCommand" >
           ...
      </step>
  </stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobtype>

例3

次の例は、タイプjobType1およびjobType2のジョブを逐次実行するjobType3という新しいジョブ・タイプを定義しています。タイプjobType2のジョブjob2は、最初のジョブが失敗した場合のみ実行されます。別のジョブを実行するには、ターゲット・リストおよびパラメータ・リストが渡される必要があります。targetListタグにはallTargetsというパラメータが含まれており、このパラメータがtrueに設定されると、このジョブに渡されたターゲット・リスト全体が渡されます。allTargetsをfalseに設定すると、ジョブ・タイプは、ターゲットのサブセットを他のジョブ・タイプに渡すことを選択できます。次の例では、jobType3によってタイプjobType1のジョブのインスタンスにすべてのターゲットが渡されますが、タイプjobType2のジョブ・インスタンスには、ターゲット・リストの最初の2つのターゲットのみが（同じ順序で）渡されます。もう1つの（paramListに関連付けられている）allParamsという属性は、パラメータに関して同様の機能を実行します。allParamsをtrueに設定すると、親ジョブのすべてのパラメータがネストされたジョブに渡されます。ただし、通常、ネストされたジョブでは（名前の異なる）別のパラメータのセットが使用されます。allParamsがfalseに設定されている場合（デフォルト）、ジョブ・タイプはネストされたジョブのパラメータに明示的に名前を付けることができます。親ジョブと同じ名前にする必要はありません。この例のように、パラメータ置換を使用して、親ジョブのパラメータの観点からネストされたジョブのパラメータを表すことができます。

ステップやステップセットの場合と同様の方法で、ネストされたジョブ間の依存性を表すことができます。この例の場合、タイプjobType3のジョブは、ネストされたジョブjob1が成功するかjob1が失敗してjob2が成功すると成功します。

<jobType name="jobType3" editable="true" version="1.0">
  <stepset ID="main" type="serial">
     <job type="jobType1" ID="job1" >
        <target_list allTargets="true" />
        <paramList>
          <param name="patchno">%patchno%</param>
          <param name="username">%username%</param>
          <param name="password">%password%</param>
        </paramList>
      </job>
      <job type="jobType2" ID="job2" failureOf="job1" >
        <targetList>
          <target name="%job_target_names%[1]" type="%job_target_types%[1]" />
          <target name="%job_target_names%[2]" type="%job_target_types%[2]" />
        </targetList>
        <paramList>
          <param name="patchno">%patchno%</param>
          <param name="username">%username%</param>
          <param name="password">%password%</param>
        </paramList>
      </job>
  </stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobType>

例4

この例は、generateFileコマンドの使用方法を示しています。次のような一連のスクリプトを実行すると仮定します。すべてのスクリプトは、環境変数を設定する1つの共通ファイルをソースとする必要があり、これらの環境変数は実行時まで不明です。このようなスクリプトを実行する方法の1つは、一意の名前を持つファイル内で変数を生成することです。後続のすべてのスクリプトには、必要な環境またはシェル変数を設定するために読み取るコマンドライン引数の1つとして、このファイルの名前が渡されます。

このジョブの最初のステップS1は、generateFileコマンドを使用して<app-home>/<execution-id>.envという名前のファイルを生成します。ジョブの実行IDは常に一意であるため、ファイル名も一意になります。ENVVAR1、ENVVAR2、ENVVAR3の3つの環境変数が生成され、それぞれがジョブ・パラメータparam1、param2およびparam2の値に設定されます。これらのパラメータには、ジョブの発行時に正しい値を設定する必要があります。%job_execution_id%は、ジョブ・システムによって提供されたプレースホルダです。一方%app-home%は、ジョブの発行時に明示的に指定する必要があるジョブ・パラメータです。

2番目のステップS2は、myscriptというスクリプトを実行します。このスクリプトの最初のコマンドライン引数は、生成されたファイル名です。このスクリプトは、必要な環境変数を設定する生成されたファイルをソースとする必要があり、その後、次に示すようにその他のタスクに進みます。

#!/bin/ksh
ENVFILE=$1
# Execute the generated file, sets the required environment vars
. $ENVFILE
# I can now reference the variables set in the file
doSomething $ENVVAR1 $ENVVAR2 $ENVVAR3...

完全なジョブ・タイプ指定を次に示します。ステップS3によって、最初のステップS1で作成されたファイルが削除されます。putFileコマンドおよびgenerateFileコマンドを使用してエージェントで一時ファイルを記述する場合は、後でクリーンアップすることが重要です。ここではクリーンアップは別個のステップとして明示的に行われますが、リモート・ホストで実行されるスクリプトの1つで行うこともできます。

また、securityInfoセクションが使用されていることにも注意してください。このセクションでは、このジョブ・タイプのジョブを発行するユーザーが、ジョブの対象となる両方のターゲットのMAINTAIN権限を持つ必要があることが指定されています。

<jobtype name="jobType4" editable="true" version="1.0">
  <securityInfo>
    <privilege name="MAINTAIN" type="target" evaluateAtSubmission="false">
        <target name="%job_target_names%[1]" type="%job_target_types%[1]" />
        <target name="%job_target_names%[2]" type="%job_target_types%[2]" />
    </privilege>
  </securityInfo>

<stepset ID="main" type="serial">
          <step ID="s1" command="putFile" >
            <paramList>
              <param name=sourceType>inline</param>
              <param name="destFile">%app-home%/%job_execution_id%.env</param>
              <param name="targetName">%job_target_names%[1]</param>
              <param name="targetType">%job_target_types%[1]</param>              
              <param name="username">%username%</param>
              <param name="password">%password%</param>
              <param name=contents">
              <![CDATA[#!/bin/ksh
                 export ENVVAR1=%param1%
                 export ENVVAR2=%param2%
                 export ENVVAR3=%param3%
              ]]> 
              </param>              
            </paramList>
          </step>
          <step ID="s2" command="remoteCommand" >
            <paramList>
              <param name="remoteCommand">myscript</param>
              <param name="targetName">%job_target_names%[2]</param>
              <param name="targetType">%job_target_types%[2]</param>
              <param name="args">%app-home%/%job_execution_id%.env</param>
              <param name="successStatus">3</param>
              <param name="failureStatus">73</param>
              <param name="username">%username%</param>
              <param name="password">%password%</param> 
            </paramList>
          </step>
          <step ID="s3" command="remoteCommand" >
            <paramList>
              <param name="remoteCommand">rm</param>
              <param name="targetName">%job_target_names%[2]</param>
              <param name="targetType">%job_target_types%[2]</param>
              <param name="args">-f, %app-home%/%job_execution_id%.env</param>
              <param name="successStatus">0</param>
              <param name="username">%username%</param>
              <param name="password">%password%</param> 
            </paramList>
          </step>
  </stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobtype>

例5

この例は、repSQLコマンドを使用して、リポジトリに対してSQL文および無名PL/SQLブロックを実行する方法を示しています。このジョブ・タイプ指定は、最初のステップS1で単純なSQL文をコールし、2番目のステップでPL/SQLプロシージャをコールします。特別なジョブ・システムのプレースホルダである変数%job_id%および%job_name%が使用されています。他のジョブ・パラメータも同様に回避できます。SQL問合せにバインド・パラメータが使用されていることにも注意してください。パラメータsqlinparam[n]を使用するとバインド・パラメータを指定できます。バインド・パラメータごとに、sqlinparam[n]形式の1つのパラメータが必要です。データベース・リソースを最大限に活用するために、できるかぎりバインド・パラメータを使用する必要があります。

<jobtype name="repSQLJob" editable="true" version="1.0">
 <stepset ID="main" type="serial">
   <step ID="s1" command="repSQL" >
    <paramList>
       <param name="sql">update mytable set status='executed' where name=?</param>
       <param name="sqlinparam1">%job_name%</param>
    </paramList>
   </step>
 <step ID="s2" command="repSQL" >
   <paramList>
      <param name="sql">begin mypackage.job_done(?,?,?); end;</param>
      <param name="sqlinparam1">%job_id%</param>
      <param name="sqlinparam2">3</param><param name="sqlinparam3">mgmt_rep</param>
   </paramList>
</step>
</stepset>
<displayInfo useDefaultCreateUI="true"/>
</stepset>
</jobtype>

例6

この例は、スイッチ・ステップセットの使用方法を示しています。このジョブのmainステップセットは、switchVarNameがstepTypeというジョブ・パラメータであるスイッチ・ステップセットです。このパラメータに使用できる値（switchCaseVal）は、simpleStep、parallelおよびOSJobです。これらの値は、最終的にステップSWITCHSIMPLESTEP、パラレル・ステップセットSWITCHPARALLELSTEPまたはネストされたジョブJ1をそれぞれ選択します。

<jobType version="1.0" name="SwitchSetJob" editable="true">
  <stepset ID="main" type="switch" switchVarName="stepType" >
    <step ID="SWITCHSIMPLESTEP" switchCaseVal="simpleStep" command="remoteOp">
      <paramList>
        <param name="remoteCommand">%command%</param>
        <param name="args">%args%</param>
        <param name="targetName">%job_target_names%[1]</param>
        <param name="targetType">%job_target_types%[1]</param>
        <param name="username">%username%</param>
        <param name="password">%password%</param>
      </paramList>
    </step>
    <stepset ID="SWITCHPARALLELSTEP" type="parallel" switchCaseVal="parallelStep">
      <step ID="P11" command="remoteOp" >
        <paramList>
          <param name="remoteCommand">%command%</param>
          <param name="args">%args%</param>
          <param name="targetName">%job_target_names%[1]</param>
          <param name="targetType">%job_target_types%[1]</param>
          <param name="username">%username%</param>
          <param name="password">%password%</param>
        </paramList>
      </step>
      <step ID="P12" command="remoteOp" >
        <paramList>
          <param name="remoteCommand">%command%</param>
          <param name="args">%args%</param>
          <param name="targetName">%job_target_names%[1]</param>
          <param name="targetType">%job_target_types%[1]</param>
          <param name="username">%username%</param>
          <param name="password">%password%</param>
        </paramList>
      </step>
    </stepset>
    <job ID="J1" type="OSCommandSerial" switchCaseVal="OSJob" >
        <paramList>
            <param name="command">%command%</param>
            <param name="args">%args%</param>
            <param name="username">%username%</param>
            <param name="password">%password%</param>
        </paramList>
        <targetList>
            <target name="%job_target_names%[1]" type="%job_target_types%[1]" />
        </targetList>
    </job>
  </stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobType>

例7

この例は、次のジョブ・タイプについて、最初のターゲットに対するCLONE FROM権限と2番目のターゲットに対するMAINTAIN権限を持つユーザーのみがジョブを発行できるようにするための、<securityInfo>タグの使用方法を示したものです。

<jobType name="Clone" editable="true" version="1.0" >
  <securityInfo>
    <privilege name="CREATE TARGET" type="system" />
    <privilege name="CLONE FROM" type="target" evaluateAtSubmission="false" >
        <target name="%job_target_names%[1]" type="%job_target_types%[1]" />
    </privilege>
    <privilege name="MAINTAIN" type="target" evaluateAtSubmission="false">
        <target name="%job_target_names%[2]" type="%job_target_types%[2]" />
    </privilege>
  </securityInfo>
  <!-- An optional <paramInfo> section will follow here, followed by the stepset
       definition of the job
  -->
  <paramInfo>
   ....
  </paramInfo>
  <stepset ...>
   .......
  </stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobType>

パフォーマンスの問題

この項では、ジョブ・タイプの設計時に留意しておく必要がある、ジョブ・タイプおよびジョブ・システム全体のパフォーマンスに影響する問題について簡単に説明します。

パラメータ・ソースの使用方法

  • パラメータ・ソースは、（リポジトリや資格証明表などの）既知のソースから必要なパラメータを取得するのに便利です。パラメータ・ソースは、すでにどこかに格納されている情報をフェッチする、クイック問合せのみに使用する必要があります。

  • 一般的に、ジョブの実行時に評価されるパラメータ・ソース（evaluateAtSubmission=true）は、ジョブ・ディスパッチャのスループットに影響するため、慎重に使用する必要があります。実行時のパラメータのフェッチを避けられない場合もありますが、実行時または発行時のどちらにパラメータがフェッチされても構わない場合は、evaluateAtSubmission=falseに設定してください。

  • SQL問合せを実行して（SQLパラメータ・ソースを使用して）パラメータを取得する場合は、通常のパフォーマンス改善のためのガイドラインが適用されます。これには、索引を必要な場所のみに使用する、大きな表の結合を避けるなどが含まれます。

Enterprise Managerへのジョブ・タイプの追加

新規ジョブ・タイプを管理プラグインでパッケージ化するには、いくつかの実装ガイドラインに従う必要があります。

管理プラグインでパッケージ化される新規ジョブ・タイプには2つの新規ファイルがあります。

次の2つのプロパティを、ジョブ・タイプ定義XMLファイルの先頭行でtrueに設定する必要があります。

次に例を示します。

<jobType version="1.0" name="PotatoUpDown" singleTarget="true" agentBound="true" targetTypes="potatoserver_os">

新規ジョブ・タイプに対するJavaの使用は、管理プラグインでパッケージ化されるジョブ・タイプについてはサポートされていないため、新規ジョブ・タイプはagentBoundで、エージェントに提供されたスクリプト（ジョブ・タイプ・スクリプト・ファイル）を通して操作を実行します。ジョブ・タイプ定義XMLファイルにはジョブ・タイプ・スクリプト・ファイルへの参照が含まれ、ジョブがEnterprise Managerコンソールから実行される際は常に、エージェントでそのファイルを実行します。

ジョブ・タイプ定義XMLファイルには、エージェントでスクリプトを実行するために必要な資格証明セットへの参照も含まれます。これらの資格証明への参照をコンソールで作成するには、新規の資格証明セット（および資格証明のタイプ）をターゲット・タイプの定義ファイルで作成する必要があります。作成が完了すると、新規の資格証明セットはEnterprise Managerコンソールで設定が可能な優先資格証明となります。資格証明はエージェントにおけるスクリプトの実行に使用されるため、これらはエージェント・ホストに対する資格証明となります。エージェント・ホスト資格証明はコンソールに存在しますが、ジョブ・タイプについては、次の例のように、使用する資格証明をターゲット・タイプに対して指定し、ターゲット・タイプ定義で作成する必要があります。

  <CredentialInfo>
    <!-- The credential type for target type host -->
    <CredentialType NAME="PotatoHostCreds" >
      <Display>
        <Label NLSID="POTATO_HOSTCREDS">Host Credentials</Label>
      </Display>
      <CredentialTypeColumn NAME="HostUsername" IS_KEY="TRUE">
        <Display>
          <Label NLSID="POTATO_HOST_USERNAME">UserName</Label>
        </Display>
      </CredentialTypeColumn>
      <CredentialTypeColumn NAME="HostPassword">
        <Display>
          <Label NLSID="POTATO_HOST_Password">Password</Label>
        </Display>
      </CredentialTypeColumn>
    </CredentialType>

    <CredentialSet NAME="PotatoHostCreds" CREDENTIAL_TYPE="PotatoHostCreds" 
               USAGE="PREFERRED_CRED">
      <Display>
        <Label NLSID="CREDS_POTATO_HOST">Potato Host Credentials</Label>
      </Display>

      <CredentialSetColumn TYPE_COLUMN="HostUsername" 
         SET_COLUMN="username">
        <Display>
          <Label NLSID="CREDS_POTATO_HOST_UNSERNAME">Agent Host Username</Label>
        </Display>
      </CredentialSetColumn>
      <CredentialSetColumn TYPE_COLUMN="HostPassword" 
         SET_COLUMN="password">
        <Display>
          <Label NLSID="CREDS_POTATO_HOST_PASSWORD">Agent Host Password</Label>
        </Display>
      </CredentialSetColumn>
    </CredentialSet>
</CredentialInfo>

列を結び付けるにはCredentialSetColumn TYPE_COLUMNとCredentialTypeColumn NAMEを一致させる必要があります。

管理プラグイン・アーカイブへのジョブ・タイプの追加

ジョブ・タイプ定義XMLファイルを作成し、ターゲット・タイプ定義ファイルの変更が終了したら、その他のターゲット・タイプと同様にそのファイルを管理プラグイン・アーカイブ（MPA）に追加できます。詳細は、第2章「管理プラグインの開発」を参照してください。

管理プラグインは、Enterprise Managerコマンドライン・インタフェース（EM CLI）を使用して、前に説明したファイルをMPAに追加することで作成されます。EM CLIをコールするたびに、別の一意の管理プラグインがMPAに追加されます。各管理プラグインについて、EM CLIでは、プラグインの機能を必要とする管理エージェントのベース・バージョン、およびプラグインが管理リポジトリにインポートされるために必要なOracle管理サービスのベース・バージョンを指定できます。MPAを作成するには、次の手順を実行します。

  1. EM CLIクライアントがインストールされているマシンでターミナル・ウィンドウを開きます。

  2. コマンド・プロンプトで、add_mp_to_mpa動詞を発行します。次の例に、指定する必要のある動詞パラメータを示します。ジョブ・タイプを追加するには、JOB_SCRIPTおよびJOB_DEFINITIONのファイル・タイプを使用します。add_mp_to_mpa verbの詳細は、EM CLIコマンドライン・ヘルプまたはOracle Enterprise Managerコマンドライン・インタフェース・ガイドを参照してください。

例5-2 EM CLIを使用した管理プラグイン・アーカイブの作成

emcli add_mp_to_mpa 
  -mpa=$HS_HOME/lib/host_sample.jar -mp_version=1.1 
  -ttd=$HS_HOME/metadata/host_sample_ttd.xml 
  -dc=$HS_HOME/metadata/host_sample_dc.xml 
  -file="REPORT_DEFINITION:$HS_HOME/sql/host_sample_perf_report.sql" 
  -file="REPORT_DEFINITION:$HS_HOME/sql/host_sample_config_report.sql" 
  -file="MONITORING_SCRIPT:$HS_HOME/scripts/data_collector.pl" 
  -file="HOMEPAGE_DEFINITION:$HS_HOME/metadata/host_sample_homepage_charts.xml" 
  -file="JOB_DEFINITION:$HS_HOME/jobs/host_sample_job_killprocess.xml" 
  -file="JOB_SCRIPT:$HS_HOME/scripts/kill_process.pl" 
  -func_desc="Demo Plug-in: Linux host monitoring."  
  -req_desc="Requirements:  Requires that the Agent that hosts the target 
     instances be running on Linux. If the 'Use Fake Data' property is set 
     when adding a target instance, then all the data provided will be 
     generated and a Linux Agent is not required";

簡単に説明すると、動詞オプションは次のとおりです。

新しいジョブ・タイプを含む管理プラグインをEnterprise Managerに追加したら、そのターゲット・タイプのインスタンスを監視できます。また、ジョブ・システムで、新たに定義したジョブ・タイプをこれらのターゲット・インスタンスに対して実行させることができます。


重要:

管理プラグインのジョブは、プラグインのターゲット・タイプのインスタンスがEnterprise Manager環境に追加されるまで表示されません。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引