管理者は、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形式)は、管理プラグイン・アーカイブに追加されます。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リポジトリ・データベース内のスキーマに直接ロードできるコマンド・ブロックをリモート・コマンドに生成させることができます。
実行されたコマンドによって生成された標準出力は、ジョブ・システムによって、そのステップに対応する出力として格納されます。
ファイル転送コマンドのコマンド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
コマンドのコマンド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
コマンドのコマンド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: 標準エラー・ストリームを標準出力にリダイレクトできませんでした。
ジョブ・システムを使用すると、インテグレータは管理サービス・レベルで作業を実行するコマンドを書き込むことができます。たとえば、データベースから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問合せまたはPL/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>
スカラー・パラメータおよびベクトル・パラメータの両方の値を保持する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プロシージャには任意の数のパラメータを使用できます。ただし、ジョブ・システム用に特別な入力パラメータと特別な出力パラメータを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
パラメータ・ソースを使用すると、ジョブ・システムは、指定された一連のパラメータに一連の値が指定されているかチェックできます。パラメータに指定された値が含まれていない場合、ジョブ・システムによってジョブが中断または一時停止されます。
<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パラメータ・ソースは、指定された一連のターゲットの個々のターゲットについて、名前の付いた一連のターゲット・プロパティをフェッチし、それぞれのプロパティ値セットをベクトル・パラメータに格納します。
次の例では、指定された一連のターゲット(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>
多くの場合、ジョブの実行では、リソースを取得することが必要になります。たとえば、データベースにパッチを適用するジョブでは、パッチを適用する間、データベースで(システム内の他のユーザーによって発行された)他のジョブが実行されるのを防ぐメカニズムが必要になります。言い換えれば、同じロックを取得しようとする他のジョブをブロック(または中断)するために、データベース・ターゲットのロックを取得する必要があります。これにより、パッチ適用ジョブを開始すると、中断することなく作業が実行されます。ロックは複数のレベルで行われる場合もあります。たとえば、データベースのホット・バックアップでは、他のホット・バックアップを続行できますが(データベースが停止されないため)、コールド・バックアップまたはデータベースの停止ジョブは続行できません(最終的にデータベースが停止されるため)。ターゲットのロックを取得することで、ジョブ実行は、ターゲットのリソースを予約することを示すことができます。ロックは、ターゲットの一部の機能を予約するためのプロキシです。実行がロックを取得すると、ターゲットで同じロックを取得しようとする他の実行はブロックされます。ロックは名前およびタイプで識別されます。ロックには次のタイプがあります。
グローバル: ターゲットに関連付けられていないロックです。グローバル・ロックを保持する実行は、同じグローバル・ロック(同じ名前を持つロックなど)を取得しようとする他の実行をブロックします。
排他ターゲット: ターゲットに関連付けられているロックです。ターゲットの排他ロックを保持する実行は、ターゲットの名前付きロックを取得しようとする実行およびターゲットの排他ロックを取得しようとする実行をブロックします。ターゲット排他ロックには名前はなく、排他ロックはターゲットごとに1つしかありません。
名前付きターゲット: ターゲットの名前付きロックは、ターゲットの特定の機能のみのロックを取得するのに似ています。名前付きロックにはユーザー指定の名前が付きます。名前付きロックを保持する実行は、同じ名前付きロックを取得しようとする他の実行、およびターゲットの排他ロックを取得しようとする実行をブロックします。
ジョブ・タイプが取得する必要があるロックは、ジョブ・タイプの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
(実行が中断する)です。実行およびロックに関する注意点は次のとおりです。
実行によってロックの取得が試行されるのは、実行の開始時のみです(ただし、後述のように、この設定はネストされたジョブを使用して上書きできます)。
1つの実行が複数のロックを取得できます。ロックは常に、指定された順序で取得されます。そのため、間違った順序でロックを取得しようとすると、複数の実行の間でデッドロックが発生する可能性があります。
ターゲット・ロックは常に、<targetList>タグで指定された順序でターゲットで取得されます。
ターゲット・リスト内のターゲットがnullまたは存在しない場合、実行は中断します。
すでに保持しているロックを取得しようとした場合、実行は成功します。
ロックを取得できない場合(通常、他の実行によってそのロックが保持されているため)、その実行は一時停止するか中断するかを選択できます。一時停止を選択した場合、すでに取得したすべてのロックが解放され、実行が一時停止中/ロックの状態になります。
実行が保持するすべてのロックは、実行が完了したか中断または停止したかに関係なく、実行の終了時に解放されます。解放されたそれぞれのロックについて、待機中の実行が複数ある可能性があります。これらの実行は時間でソートされ、最も早いリクエストがロックを取得します。
ロックおよびネストされたジョブ: 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
属性を使用することで、その中の各ステップ、ステップセットまたはジョブの再起動動作に影響を与える場合があります。この属性は、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に設定すると、ジョブを作成中のユーザーが新規に追加されたジョブ・タイプを「ジョブの作成」メニューから選択できます。
ジョブ・タイプを「ジョブ・アクティビティ」ページから使用できるようにすると、ユーザーは新規に追加されたジョブ・タイプを使用してジョブを作成する際に、デフォルトの「ジョブの作成」ユーザー・インタフェースにもアクセスできます。
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に示すとおり、新規に追加されたジョブ・タイプが「ライブラリ・ジョブの作成」メニューから選択可能なオプションになります。
ジョブ・タイプを編集可能にする設定
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>
例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が失敗しS4が失敗した
S2が成功しS3が失敗した
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番目のターゲットにすることが前提になる場合があります。このジョブは、次のいずれかが発生した場合に失敗します。
パラレル・ステップセットSS1が失敗した(S1またはS2のどちらか、もしくは両方が失敗した)
S1とS2の両方が成功したがS3が失敗した
ジョブ・タイプ自体がエージェントにバインドされていることを宣言している点にも注意してください。これは、(最初のターゲットまたは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パラメータ・ソースを使用して)パラメータを取得する場合は、通常のパフォーマンス改善のためのガイドラインが適用されます。これには、索引を必要な場所のみに使用する、大きな表の結合を避けるなどが含まれます。
新規ジョブ・タイプを管理プラグインでパッケージ化するには、いくつかの実装ガイドラインに従う必要があります。
管理プラグインでパッケージ化される新規ジョブ・タイプには2つの新規ファイルがあります。
ジョブ・タイプ定義XMLファイル: 管理プラグインのデプロイ時に、新規ジョブ・タイプを定義するためにジョブ・システムで使用されます。各ジョブ・タイプにつき、1つのXMLファイルがあります。
ジョブ・タイプ・スクリプト・ファイル: 管理プラグインのデプロイ時に、選択されたエージェントにインストールされます。1つのスクリプトが各ジョブの間で共有される場合があります。
次の2つのプロパティを、ジョブ・タイプ定義XMLファイルの先頭行でtrueに設定する必要があります。
agentBound
singleTarget
次に例を示します。
<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を作成するには、次の手順を実行します。
EM CLIクライアントがインストールされているマシンでターミナル・ウィンドウを開きます。
コマンド・プロンプトで、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";
簡単に説明すると、動詞オプションは次のとおりです。
mpa
管理プラグインを追加する管理プラグイン・アーカイブの名前。
mp_version
作成する管理プラグインのバージョン。管理プラグインのいずれかのファイルが変更されるたびに、管理プラグイン・バージョンを増やす必要があります。
tdd
ターゲット・タイプ・メタデータ・ファイルの明示的パス。
dc
デフォルトの収集ファイルの明示的パス。
oms_version
この管理プラグインと互換性のある最小OMSバージョン。
file
追加する他の管理プラグイン・ファイルのタイプとパス。次のタイプがサポートされています。
MONITORING_BINARY
POLICY_DEPLOY
POLICY_UNDEPLOY
MONITORING_SCRIPT
REPORT_DEFINITION
JOB_SCRIPT
JOB_DEFINITON
func_desc
管理プラグインの機能説明。この説明は、プラグインがインポートされた後でEnterprise Managerコンソールに表示されます。
req_desc
管理プラグインの要件説明。この説明はEnterprise Managerコンソールに表示されるもので、プラグイン・デプロイ要件を指定します。
新しいジョブ・タイプを含む管理プラグインをEnterprise Managerに追加したら、そのターゲット・タイプのインスタンスを監視できます。また、ジョブ・システムで、新たに定義したジョブ・タイプをこれらのターゲット・インスタンスに対して実行させることができます。
重要: 管理プラグインのジョブは、プラグインのターゲット・タイプのインスタンスがEnterprise Manager環境に追加されるまで表示されません。 |