| Oracle® Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス 13c リリース2 E92082-01 |
|
 前 |
 次 |
管理者は、Enterprise Managerジョブ・システムの実用性と柔軟性を拡張するために、新しいジョブ・タイプを定義することができます。また、問題修正処理を強化するための新しいジョブ・タイプを追加することもできます。この章では、すでにEnterprise Managerのジョブ・システムに関する知識があることを前提として、ジョブ・タイプについて説明します。
Enterprise Managerジョブ・システムの詳細は、Oracle Enterprise Manager管理者ガイド参照してください。
この章の内容は次のとおりです。
プラグイン開発者は、ジョブ・タイプの追加において、次の手順に従う必要があります。
ジョブ・タイプの定義
ジョブのステップ、各ステップが実行する作業(コマンド)およびステップの関係を定義するXML仕様を使用して、ジョブ・タイプを定義します。
詳細は、「ジョブ・タイプについて」を参照してください。
長時間のコマンドの実行
ジョブ・システムでは、プラグイン開発者が、管理サービス・レベルで作業を実行するコマンドを作成できます。
詳細は、「Oracle Management Serviceでの長時間のコマンドの実行」を参照してください。
パラメータ・ソースの指定
ジョブ・システムのデフォルト設定では、ジョブの発行時または実行時に(パラメータを動的に追加または更新して)すべてのジョブ・パラメータの値をプラグイン開発者が指定する必要があります。
詳細は、「パラメータ・ソースの指定」を参照してください。
資格証明情報の指定
詳細は、「資格証明情報の指定」を参照してください。
セキュリティ情報の指定
詳細は、「セキュリティ情報の指定」を参照してください。
ロック情報の指定
詳細は、「ロック情報の指定」を参照してください。
ジョブまたはステップの一時停止
詳細は、「ジョブまたはステップの一時停止」を参照してください。
ジョブの再起動
詳細は、「ジョブの再起動」を参照してください。
Enterprise Managerでは、様々なタイプのジョブを定義して、それらをEnterprise Managerジョブ・システムで実行できるため、より多くの、より複雑なタスクを自動化することが可能になっています。
定義上、ジョブ・タイプは、明確に定義された作業単位を実行する、ジョブの特定のカテゴリです。ジョブ・タイプは、文字列によって一意に識別されます。たとえば、OSCommandは、リモート・コマンドを実行するジョブ・タイプである可能性があります。ジョブのステップ、各ステップが実行する作業(コマンド)およびステップの関係を定義するXML仕様を使用して、ジョブ・タイプを定義します。
表8-1に、Enterprise Managerジョブ・タイプの一部とその機能を示します。
表8-1 ジョブ・タイプの例
| ジョブ・タイプ | 用途 |
|---|---|
バックアップ |
データベースをバックアップする。 |
バックアップ管理 |
選択したバックアップ・コピー、バックアップ・セット、またはファイルに対して、クロスチェックや削除などの管理機能を実行する。 |
クローン・ホーム |
Oracleホーム・ディレクトリをクローニングする。 |
DBクローン |
Oracleデータベース・インスタンスをクローニングする。 |
DB構成 |
リリース10gより前のリリースのデータベースの監視方法を構成する。 |
エクスポート |
特定のEnterprise Managerユーザーのスキーマや表に含まれる、データベースの内容やデータベース・オブジェクトをエクスポートする。 |
統計収集 |
オプティマイザ統計を生成および変更する。 |
OSコマンド |
オペレーティング・システムのコマンドまたはスクリプトを実行する。 |
ホスト比較 |
複数のホストの構成を比較する。 |
インポート |
オブジェクトや表の内容をインポートする。 |
ロード |
Oracle以外のデータベースからOracle Databaseにデータをロードする。 |
占有データの移動 |
SYSAUX表領域の占有データを別の表領域に移動する。 |
パッチ |
Oracle製品にパッチを適用する。 |
リカバリ |
データベース、表領域、データファイルまたはアーカイブ・ログをリストアまたはリカバリする。 |
Metalinkからのリフレッシュ |
Enterprise ManagerがMy Oracle Support ( |
再編成 |
断片化したデータベースの索引や表を再構築したり、異なる表領域にオブジェクトを移動したり、指定したオブジェクトの記憶域属性を最適化する。 |
マルチタスク |
複数のタスクで構成される複合ジョブを実行する。 |
SQLスクリプト |
SQL*Plusを使用してSQLまたはPL/SQLスクリプトを実行します。 |
1つのEnterprise Managerジョブは一連のステップから構成され、各ステップは1つのコマンドまたはスクリプトを実行します。ジョブ・タイプは、それらのステップの組立て方法を定義します。たとえば、ステップをシリアルに(逐次的に)実行するかパラレルに(並行して)実行するかを指定したり、ステップの実行順序やステップ間の依存関係を定義したりします。ジョブ・タイプ、ステップ、コマンドはXMLで表現できます(詳細は、「新しいジョブ・タイプのXMLでの指定」を参照してください)。ジョブ・システムはXML仕様から実行計画を構成し、それにより、指定された順序でのステップの実行が可能になります。
新しいジョブ・タイプの仕様はXMLで定義します。ジョブ・タイプ指定によってジョブ・システムに次の情報が提供されます。
ジョブに含まれる各ステップ。
各ステップで実行されるコマンドまたはスクリプト。
ステップ間の関係。たとえば、複数のステップをパラレルに(並行して)実行するかシリアルに(逐次的に)実行するかの指定や、あるステップが別のステップに依存するかどうかの指定など。
ジョブを認証するためのユーザー資格証明(通常は、ジョブの所有者が提供する必要があります)。ジョブ・タイプ作成者は、ジョブ・タイプXMLでこれらの資格証明を宣言する必要もあります。
特定のジョブ・パラメータの計算方法(オプション)。
ジョブの実行中に取得する必要があるロックと、そのロックが使用できない場合の動作。
ジョブを発行するためにユーザーに必要な権限。
作成されたジョブ・タイプ仕様(XML形式)は、メタデータ・プラグイン・アーカイブに追加されます。Enterprise Managerにメタデータ・プラグインが追加されると、ジョブ・システムは、ジョブにどのステップを含めるかや、各ステップ内で何を実行するかをスケジュールするために必要な情報へアクセスできるようになります。
ジョブ・タイプは、適用先ターゲット上でどのようにタスクを実行するかに応じて、次のカテゴリのいずれかに分類できます。
単一ノード
単一ノード・ジョブ・タイプは、ジョブが実行されるすべてのターゲット上で、同じステップのセットを並列に実行するジョブ・タイプです。通常、これらのジョブ・タイプのターゲット・リストは固定されていません。多くのターゲットをとることがあります。単一ノード・ジョブ・タイプの例を以下に示します。
OSコマンド
すべてのターゲット上で、OSコマンドまたはスクリプトを実行します。
SQL
すべてのターゲット上で、指定されたSQLスクリプトを実行します。
複数ノードまたは組合せ
複数ノード・ジョブ・タイプは、複数のターゲットに対し、複数のタスク(場合によっては相互に関係を持つ複数タスク)を実行するジョブ・タイプです。通常、このジョブ・タイプは固定されたターゲット・セットを対象とします。たとえば、アプリケーション・スキーマをクローニングするクローン・ジョブは、ソース・データベースとターゲット・データベースの2つのターゲットを必要とすることがあります。
注意:
複数のターゲットに対して同じアクティビティを繰り返すために、複数ノードおよび組合せのジョブ・タイプに反復ステップセットを使用できます。
エージェントにバインドされているジョブ・タイプは、ターゲット・リストにある1つ以上のターゲットの管理エージェントが稼働していて応答しないかぎり、ジョブを実行できないものです。このカテゴリに適合するジョブ・タイプは、jobType XMLタグのagentBound属性をtrueに設定することによって、エージェントにバインドされていると宣言する必要があります。
ジョブ・タイプがエージェントにバインドされているとき、ジョブ実行のターゲット・リストにあるターゲットに対応する管理エージェントの1つ以上が応答しない場合、ジョブ・システムはいかなる実行もスケジュールしません。ジョブ(およびすべてのそのスケジュールのステップ)は、一時停止/エージェント停止と呼ばれる特別な状態に設定されます。Enterprise Managerリポジトリ層が管理エージェントの再起動を検知するまで、ジョブはこの状態で保持されます。
この時点でジョブおよびそのステップはスケジュール済のステータスに再設定され、ジョブを実行できる状態になります。ジョブ・タイプがエージェントにバインドされていると宣言することで、ジョブ・タイプ作成者は、管理エージェントの停止が検出された場合、ジョブ・システムがジョブをスケジュールしないようにできます。
注意:
単一ノード・ジョブ・タイプはデフォルトでエージェントにバインドされていますが、複数ノード・ジョブ・タイプはバインドされていません。
エージェントにバインドされているジョブのターゲット・リストに複数のターゲットがある場合は、管理エージェントの1つが停止するとジョブは一時停止としてマークされます。
エージェントにバインドされているジョブ・タイプの例はOSCommandジョブ・タイプで、指定されたターゲットの管理エージェントを使用してOSCommandを実行します。ただし、すべてのジョブ・タイプが、エージェントにバインドされているわけではありません。たとえば、管理リポジトリでSQLを実行するジョブ・タイプは、エージェントにバインドされません。
Enterprise Managerではハートビート・メカニズムが採用されているため、リモート管理エージェントが停止した時をすばやく検知することができます。管理エージェントが停止中としてマークされると、この管理エージェントがターゲット・リストに含まれる、エージェントにバインドされているすべてのジョブの実行が、一時停止/エージェント停止とマークされます。ただし、管理エージェントが停止してから管理リポジトリによってその事実が検出されるまでの間に、ジョブ・システムによってリモート操作のディスパッチが試行される可能性は残されています。この場合、ステップの実行時に管理エージェントに接続できないと、ステップは再びスケジュール済の状態に設定され、ジョブ・システムによって再試行されます。ハートビート・メカニズムによってノードが停止中としてマークされ、その時点でジョブが一時停止するまで、一連の再試行が続行されます。
ジョブが一時停止/エージェント停止とマークされている場合、ジョブ・システムは、管理エージェントが再起動するまでデフォルトでジョブをその状態に保持します。ただし、猶予期間と呼ばれるパラメータが定義されている場合、この動作をオーバーライドできます。猶予期間とは、ジョブ実行がその時間内に実行開始できる時間の最大値です(単位は分)。この猶予期間内にジョブが開始できない場合、そのスケジュールではそのジョブ実行がスキップされます。
一時停止/エージェント停止の状態にあるジョブ実行を再開する唯一の方法は、管理エージェントを再び起動させることです。resume_execution() APIを使用してジョブを再起動することはできません。
ジョブにおける実行の単位は、ステップと呼ばれます。ステップは、ステップがする作業を決定するコマンドを持ちます。各コマンドにはコマンドを実装するJavaクラスがあり、コマンド実行者と呼ばれます。また、コマンドには一連のパラメータが含まれています。これらは、コマンド・エグゼキュータによって解釈されます。
ジョブ・システムは、次のようなあらかじめ作成されたコマンドの固定セットを提供します。
コマンドをリモートで実行するリモート操作コマンド。詳細は、「remoteOpコマンドの使用」を参照してください。
2つの管理エージェント間でファイルを転送するファイル転送コマンド。詳細は、「fileTransferコマンドの使用」を参照してください。
管理エージェント層で生成されたログ・ファイルを管理リポジトリにストリーミングするファイル取得コマンド。詳細は、「getFileコマンドの使用」を参照してください。
ステップは、ステップセットと呼ばれるセットにグループ化されます。ステップセットには、ステップだけでなく、自身以外のステップセットを含めることもできます。ステップセットは次のタイプに分類されます。
シリアル・ステップセット
シリアル・ステップセットは、ステップがシリアルに実行されるステップセットです。シリアル・ステップセットのステップは、ステップの実行に依存していることがあります。たとえば、あるジョブで、ステップS1が正常に完了した場合のみステップS2が実行されるように指定されたり、S1が失敗した場合のみステップS3が実行されるように指定されたりすることが考えられます。
シリアル・ステップセットのステップは、同じステップセット内の、他のステップまたはステップセットに対してのみ依存関係を持つことができます。デフォルトでは、シリアル・ステップセットが正常に完了したとみなされるのは、最後のステップが正常に完了した場合です。ステップセット内の最後のステップが失敗した場合、ステップセットが失敗したとみなされます。この動作は、stepsetStatus属性を使用してオーバーライドできますが、オーバーライドは、そのステップが別の(successOf/failureOf/abortOf属性でない)ステップに依存していない場合のみ可能です。
パラレル・ステップセット
パラレル・ステップセットは、ステップが並列に(同時に)実行されるステップセットです。パラレル・ステップセットのステップは、依存関係を持てません。パラレル・ステップセットが成功したと見なされるのは、すべてのパラレル・ステップが正常に完了した場合です。その中にあるステップのいずれかが失敗した場合、失敗したとみなされます。デフォルトでは、それを構成するステップの1つ以上が失敗し、中断されたステップがない場合、パラレル・ステップセットは失敗したとみなされます。stepsetStatus属性を使用して、この動作をオーバーライドできます。
反復ステップセット
反復ステップセットは、ベクトル・パラメータを反復する特別なステップセットです。ジョブのターゲット・リストは、job_target_namesとjob_target_typesという名前の特別な暗黙パラメータを使用して取得できます。反復ステップセットは、ターゲット・リストまたはベクトル・パラメータに基づいて反復し、基本的にステップセットをN回(ターゲット・リストまたはベクトル・パラメータのそれぞれの値に対して1回ずつ)実行します。
反復ステップセットは、パラレルにも(N 個のステップセット・インスタンスを同時実行)、シリアルにも(N 個のステップセット・インスタンスをシリアルに、順次スケジュール)実行できます。反復ステップセットが成功したと言われるのは、そのN個のインスタンスがすべて成功した場合です。そうでない場合、N個のステップセットのうち1つでも中断されたときは、失敗したと言われます。N個のステップセットの1つ以上が失敗し、中断されたものがないときは、失敗したと言われます。中断された場合、反復ステップセットのそれ以降の処理は常に停止されます。
各反復ステップセット・インスタンス内のステップはシリアルに実行され、シリアル・ステップセット内の場合に類似したシリアルな依存関係を持てます。反復シリアル・ステップセットは、iterateHaltOnFailureと呼ばれる属性を持っています(iterativeParallelステップセットには適用されません)。これがtrueに設定されている場合、ステップセットは、最初に失敗したか中断された子反復で停止します。デフォルトでは、一部の反復が失敗した場合でも(iterateHaltOnFailure=false)、反復シリアル・ステップセットのすべての反復が実行されます。
スイッチ・ステップセット
スイッチ・ステップセットは、指定されたジョブ・パラメータの値に基づいて、ステップセット内のステップの1つのみが実行されるステップセットです。スイッチ・ステップセットにはジョブ(スカラー)パラメータであるswitchVarName属性があり、ジョブ・システムは、ステップセット内で実行しなければならないステップを決定するためにその値を確認します。スイッチ・ステップセットの各ステップにはswitchCaseVal属性があり、それは、switchVarNameで指定されたパラメータがとり得る値の1つです。
スイッチ・ステップセットで実行されるステップは、switchCaseValパラメータの値がスイッチ・ステップセットのswitchVarNameパラメータの値と一致するものです。スイッチ・ステップセット内の選択されたステップだけが実行されます。スイッチ・ステップセットのステップは、同じステップセット内またはそれ以外の、他のステップまたはステップセットに対する依存関係を持つことができません。
デフォルトでは、スイッチ・ステップセットが正常に完了したとみなされるのは、選択されたステップが正常に完了した場合です。ステップセット内の選択されたステップが失敗した場合、ステップセットが失敗したとみなされます。また、ステップセット内のステップが選択されなかった場合、スイッチ・ステップセットは成功します。
たとえば、S1とS2の2つのステップがあるスイッチ・ステップセットで次のように指定します。
switchVarNameをsendEmailと指定
S1のswitchCaseValをtrueに設定
S2のswitchCaseValをfalseに設定
ジョブ・パラメータsendEmailがtrueに設定されたジョブが発行された場合、S1が実行されます。ジョブ・パラメータsendEmailがfalseに設定されたジョブが発行された場合、S2が実行されます。sendEmailの値がそれ以外である場合、その場合もステップセットは成功しますが、何も実行されません。
ネストされたジョブ
ステップセットでは、セット内のステップが別のジョブ・タイプへの参照となっている場合があります。ジョブ・タイプは、その中に他のジョブ・タイプを含むことができます。ただし、ジョブ・タイプからそのジョブ・タイプ自身を参照することはできません。
ジョブのネスト化は、機能ブロックを再利用するのに便利な方法です。たとえば、データベース・バックアップの実行は、複雑なステップの順序を持つジョブです。しかし、他のジョブ・タイプ(たとえばパッチとクローン)が、バックアップ・ファシリティを、ネストされたジョブとして使用する可能性があります。ネストされたジョブには、ジョブ・タイプに含まれるジョブのすべてのターゲットを渡すことも、ターゲットのサブセットのみを渡すこともできます。また、ジョブ・タイプに含まれるジョブから、ネストされたジョブにすべてのパラメータを渡すかどうかや、ネストされたジョブで(親ジョブのパラメータから導出された)独自のパラメータ・セットを使用するかどうかを指定することもできます。
ネストされたジョブ内の個々のステップおよびステップセット(また、場合によってはその他のネストされたジョブ)のステータスによって、ネストされたジョブのステータスは決まります。
注意:
ネストされたジョブが、singleTargetセットをtrueに設定したジョブ・タイプを参照している場合、ネストされたジョブのtargetType属性を使用してネストされたジョブに適用可能なターゲット・タイプを明示的に指定する必要があります。指定しない場合、ネストされたジョブはそのジョブ・タイプのデフォルトのターゲット・タイプのみに対応するターゲットを選択します。
ステップのステータスからそのステップセットのステータスを計算するデフォルト・アルゴリズムは、ジョブ・タイプから、ステップセットのstepsetStatus属性を使用して変更できます。stepsetStatusを、ステップセットに含まれるステップ、ステップセットまたはジョブの名前(ID)に設定することで、ステップセットのステータスが、stepStatus属性で名前を指定された特定のステップ、ステップセットまたはジョブのステータスに依存することを示すことができます。この機能は、ジョブ・タイプの作成者が、ステップセット内の一部のステップが失敗してもステップセットが成功したとみなすことを意図する場合に便利です。
例は、ジョブ内のステップセットの最後に実行されるステップで、そのジョブでは管理者のリストにジョブのステータスに関する電子メールを送信します。ジョブのステータスは、作業を実行するステップのステータスに設定する必要があります(電子メールを送信したステップのステータスではありません)。stepsetStatus属性で名前を指定できるのは、無条件で実行されるステップだけです。successOfまたはfailureOfの依存関係として実行されるステップ、ステップセットまたはジョブの名前は、stepsetStatus属性で指定できません。
ジョブのパラメータをステップに渡すには、パラメータ名を2つの%記号で囲まれたプレースホルダに入れます。たとえば、%patchNo%は、patchNoという名前のパラメータの値を表します。それがステップのコマンド実行者に渡されると、ジョブ・システムがこのパラメータの値を置換します。
[]記法を使用することにより、ベクトル・パラメータに対応するプレースホルダを定義することもできます。たとえば、patchListと呼ばれるベクトル・パラメータの1つ目の値は%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。これは、Globally Unique IDentifier (GUID)を表す文字列です。
job_execution_id
実行ID。これはGUIDを表す文字列です。
job_step_id
ステップID。整数を指定します。
これらのプレースホルダ以外に、次のターゲット関連のプレースホルダもサポートされます。
emd_root: 管理エージェント・インストールの場所
perlbin: (Enterprise Manager)Perlインストールの場所
scriptsdir: 管理エージェント固有スクリプトの場所
上の各プレースホルダは、ジョブ・システムによってではなく、管理エージェントによって解釈されます。たとえば、%emd_root%がremoteOpコマンドのremoteCommandまたはargsパラメータで使用されるか、putFile、getFileおよびtransferFileコマンドにおけるいずれかのファイル名で使用される場合、管理エージェントが、管理エージェント・ルート位置の実際の値をこのプレースホルダに置換します。
1つのステップは、ステータス(それが成功したか、失敗したか、終了したかを示す)、何らかの出力(そのステップのログ)およびエラー・メッセージから構成されます。ステップが失敗すると、そのステップから実行されたコマンドによって、エラー・メッセージ列にエラーが示されることがあります。デフォルトでは、非同期のリモート操作の標準出力と標準エラーは、リモート操作を要求したステップの出力と同一になるように設定されます。
次のいずれかを使用して、ステップにエラー・メッセージを挿入するよう選択できます。
CommandManager (同期)のgetErrorWriter()メソッド
mgmt_jobsパッケージのinsert_step_error_ message API (通常、リモートで実行中のスクリプトによってコマンド・チャネル内でコールされる)
この項では、利用できるコマンドと関連パラメータについて説明します。次の項で説明するターゲット名とターゲット・タイプ・パラメータには、任意のタイプのターゲットを指定できます。ジョブ・システムは、指定されたターゲットをモニターする管理エージェントを自動的に識別し、接続します。
リモート操作コマンドには、remoteOpという識別子が付けられます。コマンドは、ターゲットのホスト上で操作を実行するために必要な、defaultHostCredという名前を持つ資格証明使用を受け入れます。バインディングは、次のように表すことができます。
<step ID="Step_2" command="remoteOp">
<credList>
<cred usage="defaultHostCred" reference="osCreds"/>
</credList>
<paramList>
<param name="targetName">%job_target_names%[1]</param>
<param name="targetType">%job_target_types%[1]</param>
<param name="remoteCommand">%remoteCommand%</param>
<param name="args">%args%</param>
<param name="executeSynchronous">false</param>
</paramList>
</step>
defaultHostCredは、コマンドが認識する資格証明使用です。たとえば、コマンド内のJavaコードはこの文字列を持つ資格証明をコールしますが、ここでosCredsは最上位レベルのジョブ・タイプで宣言された資格証明使用です。
リモート操作コマンドは次のパラメータを取ります。
remoteCommand: 実行可能ファイルまたはスクリプトのパス名(たとえば/usr/local/bin/perl)。
args: remoteCommandの引数のカンマ区切りリスト。
targetName: コマンドの実行対象となるターゲットの名前。プレースホルダを使用してターゲットを表すことができます。
targetType: コマンドの実行対象となるターゲットのターゲット・タイプ。
executeSynchronous: このオプションのデフォルトはfalseで、その場合リモート・コマンドは管理エージェント上で常に非同期で実行され、ステップのステータスはコマンドの実行後に更新されます。
このオプションをtrueに設定すると、コマンドは管理エージェントが処理を完了するまで待機し、同期して実行されます。通常、このパラメータがtrueに設定されるのは、瞬時に起動し、持続時間の短いリモート操作の場合です(リスナーの起動など)。実行に長い時間がかかるリモート操作の場合、このパラメータは、falseに設定する必要があります。
注意:
このパラメータはfalseに設定されており、この設定をオーバーライドすることはできません。
successStatus: ステップの成功を示す値として定義する整数値のリスト(カンマ区切り)。リモート・コマンドが終了ステータスとして返した値がこれらの数値のいずれかであった場合、ステップは成功しています。デフォルトはゼロです。これらの値が適用されるのは、executeSynchronousがtrueに設定されている場合のみです。
failureStatus: ステップの失敗を示す値として定義する整数値のリスト(カンマ区切り)。リモート・コマンドが終了ステータスとして戻した値がこれらの数値のいずれかであった場合、ステップは失敗しています。デフォルト値は、ゼロ以外のすべての値です。これらの値が適用されるのは、executeSynchronousがtrueに設定されている場合のみです。
input: これを指定した場合、その値は標準入力としてリモート・プログラムに渡されます。
outputType: リモート・コマンドが生成する出力のタイプを指定します。このオプションには次の2つの値があります。
normal (デフォルト)
normalの出力は、このステップに対応するログに格納され、いかなる方法でも解釈されない出力です。
command
commandの出力は、1つ以上のコマンド・ブロックを含むことができる出力で、あらかじめ登録されたSQLプロシージャ・コールにマップされるXML順序です。このオプションを使用すると、リモート・コマンドは、管理リポジトリでスキーマに直接ロードできるコマンド・ブロックを生成できます。
実行されたコマンドによって生成された標準出力は、ジョブ・システムによって、そのステップに対応する出力として格納されます。
場合によっては、リモート操作のために追加の資格証明を渡すことが必要になります。これらの資格証明は、リモート操作を作成する管理エージェントに接続するために必要なホスト資格証明に加えて使用されるため、補助資格証明と呼ばれます。
補助資格証明の処理は、管理エージェントで作成される処理に依存します。ジョブ・システムにより、資格証明の列値を変数に抽出するメカニズムが提供され、この変数をリモート操作コマンド(remoteOp)の入力パラメータ内の置換に使用できます。
このオプションを使用するには、補助資格証明の適切な設定が必要なジョブ・タイプおよび資格証明タイプで、補助資格証明使用を定義する必要があります。
リモート操作内で資格証明を使用するには、次を使用します。
<step ID="Command" command="remoteOp">
<credList>
<cred usage="defaultHostCred" reference="defaultHostCred"/>
<cred usage="defaultDBCred" reference="defaultDBCred">
<map toParam="db_username" credColumn="DBUserName"/>
<map toParam="db_password" credColumn="DBPassword"/>
<map toParam="db_role" credColumn="DBRole"/>
</cred>
</credList>
<paramList>
<param name="remoteCommand">%perlbin%/perl</param>
<param name="args">-I,%emd_root%/sysman/admin/scripts/jobutil,mylocation/runSQL.pl,%OracleHome%, %SID%, %sqlplus_args%</param>
<param name="input"><![CDATA[
__EM_JOB_SQL_USER__=%db_username%
__EM_JOB_SQL_PASSWORD__=%db_password%
__EM_JOB_SQL_DBROLE__=%db_role%
__EM_JOB_INPUT_STREAM_END__
]]>
</param>
<param name="targetName">%job_target_names%[1]</param>
<param name="targetType">%job_target_types%[1]</param>
</paramList>
</step>
fileTransferコマンドは、ある管理エージェントから別の管理エージェントにファイルを転送します。ソース管理エージェント上でコマンドを実行してその標準出力をファイルとしてターゲット管理エージェントに転送したり、ターゲット管理エージェント上のコマンドへの標準入力として転送したりすることもできます。fileTransferコマンドは常に非同期で、次のパラメータを取ります。
<step ID="S1" command="fileTransfer">
<credList>
<cred usage="srcReadCreds" reference="mySourceReadCreds"/>
<cred usage="dstWriteCreds" reference="myDestWriteCreds"/>
</credList>
<paramList>
<param name="sourceTargetName">%job_target_names%[1]</param>
<param name="sourceTargetType">%job_target_types%[1]</param>
<param name="destTargetName">%job_target_names%[2]</param>
<param name="destTargetType">%job_target_types%[2]</param>
<param name="sourceFile">%sourceFile%</param>
<param name="sourceCommand">%sourceCommand%</param>
<param name="sourceArgs">%sourceArgs%</param>
<param name="sourceInput">%sourceInput%</param>
<param name="destFile">%destFile%</param>
<param name="destCommand">%destCommand%</param>
<param name="destArgs">%destArgs%</param>
</paramList>
</step>
次のコマンドは、2つの資格証明を使用します。srcReadCreds資格証明はソースからファイルを読み取るために使用され、dstWriteCreds資格証明はファイルをターゲットに書き込むために使用されます。バインディングは、次のように表すことができます。
<step ID="S1" command="fileTransfer">
<credList>
<cred usage="srcReadCreds" reference="mySourceReadCreds"/>
<cred usage="dstWriteCreds" reference="myDestWriteCreds"/>
</credList>
<paramList>
<param name="sourceTargetName">%job_target_names%[1]</param>
<param name="sourceTargetType">%job_target_types%[1]</param>
<param name="destTargetName">%job_target_names%[2]</param>
<param name="destTargetType">%job_target_types%[2]</param>
<param name="sourceFile">%sourceFile%</param>
<param name="sourceCommand">%sourceCommand%</param>
<param name="sourceArgs">%sourceArgs%</param>
<param name="sourceInput">%sourceInput%</param>
<param name="destFile">%destFile%</param>
<param name="destCommand">%destCommand%</param>
<param name="destArgs">%destArgs%</param>
</paramList>
</step>
sourceTargetName: ソース管理エージェントに対応するターゲットの名前。
destTargetName: ターゲット管理エージェントに対応するターゲットの名前。
destTargetType: ターゲット管理エージェントに対応するターゲット・タイプ。
sourceFile: ソース管理エージェントから転送されるファイル。
sourceCommand: ソース管理エージェントで実行されるコマンド。これが指定されると、このコマンドの標準出力がターゲット管理エージェントにストリーミングされます。sourceFileとsourceCommandパラメータを両方とも指定することはできません。
sourceArgs: sourceCommandに対する一連のコマンドライン・パラメータ(カンマ区切り)。
destFile: ファイルがターゲット管理エージェント上で格納される場所またはファイル名。
destCommand: ターゲット管理エージェント上で実行されるコマンド。これを指定すると、ソース管理エージェントから(ファイルからであってもコマンドからであっても)生成されたストリームは、このコマンドの標準入力に送信されます。destFileパラメータとdestCommandパラメータの両方を指定することはできません。
destArgs: destCommandに対する一連のコマンドライン・パラメータ(カンマ区切り)。
管理エージェント間でファイルが正常に転送されると、fileTransferコマンドは成功します(ステータス・コード0を戻します)。エラーが発生した場合、障害の理由として適切なエラー・コードを戻します。
putFileコマンドを使用すると、大量のデータを管理リポジトリから管理エージェント上のファイルに転送できます。転送されるデータは、管理リポジトリのバイナリ・ラージ・オブジェクト(BLOB: ファイル・システムにあるファイル)に由来することも、仕様に埋め込まれている(inline)こともあります。
ファイルを転送する場合は、そのファイルの場所が管理リポジトリ・インストールからアクセス可能である必要があります。管理リポジトリ内のBLOBを転送する場合は、そのBLOBが、管理リポジトリ・スキーマ・ユーザー(通常mgmt_rep)からアクセスできる管理リポジトリ内の表に含まれている必要があります。
コマンドは、defaultHostCredという名前を持つ資格証明使用を受け入れます。ターゲットのホストでファイルを書き込むには、これらの資格証明が必要です。バインディングは、次のように表すことができます。
<step ID="S1" command="putFile">
<credList>
<cred usage="defaultHostCred" reference="osCreds"/>
</credList>
<paramList>
<param name="sourceType">file</param>
<param name="targetName">%job_target_names%[1]</param>
<param name="targetType">%job_target_types%[1]</param>
<param name="sourceFile">%oms_root%/myfile</param>
<param name="destFile">%emd_root%/yourfle</param>
</paramList>
</step>
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%という形式でパラメータのプレースホルダを含めることができます。
ファイルが正常に転送され、ステータス・コードが0に設定されると、putFileコマンドが成功します。失敗した場合、ステータス・コードは失敗の理由を示す整数に設定されます。
getFileコマンドは、管理エージェントから管理リポジトリにファイルを転送します。ファイルは、このコマンドを実行したステップの出力として格納されます。
コマンドは、ターゲットのホスト上でファイルを読み込むために必要な、defaultHostCredという名前を持つ資格証明使用を受け入れます。バインディングは、次のように表すことができます。
<step ID="S1" command="getFile">
<credList>
<cred usage="defaultHostCred" reference="osCreds"/>
</credList>
<paramList>
<param name="targetName">%job_target_names%[1]</param>
<param name="targetType">%job_target_types%[1]</param>
<param name="sourceFile">%sourceFile%</param>
<param name="destType">%destType%</param>
<param name="destFile">%destFile%</param>
<param name="destParam">%destParam%</param>
</paramList>
</step>
getFileコマンドのパラメータは次のとおりです。
sourceFile: 管理エージェントに転送されるファイルの場所。
targetName: 管理エージェントがファイルを取得するために接続するターゲットの名前。
targetType: ターゲットのタイプ。
ファイルが正常に転送され、ステータス・コードが0に設定されると、getFileコマンドが成功します。失敗した場合、ステータス・コードは失敗の理由を示す整数に設定されます。
execAndSuspendコマンドは、remoteOpコマンドに似ていますが、管理エージェントを再起動するホスト・プロセスを実行するために使用されます。通常、管理エージェントのバイナリや構成を更新し、管理エージェントの再起動が必要なシナリオでこのコマンドを使用します。このコマンドによって管理エージェントに対するエージェントベースの操作がポストされ、その操作ステータスは即座に成功に切り替えられ、同時に以降のステップは管理エージェントからの起動通知を待機する一時停止ステータスに移行します。
次の制限とガイドラインに従うことが重要です。
管理エージェントで実行されるコマンドいかなる標準出力またはエラーも生成する必要はありません。このような出力がある場合、発行された操作の一部としてファイルまたはnullにリダイレクトする必要があります。リダイレクトできない場合、コマンドが失敗することがあります。
ジョブ・タイプにはexecAndSuspendコマンドを実行するステップの直後にステップが含まれている必要があります。この後続のステップがexecAndSuspendステップの一部として発行された操作が成功したかどうかを確認します。エージェントベースの操作が失敗している場合があるため、後続のステップではremoteOpの使用を避け、直接のエージェントベースJavaコールを使用して操作のステータスを確認する必要があります。
このコマンドのほとんどの引数は、remoteOpコマンドと同様です。このコマンドは、ターゲットのホスト上で操作を実行するために必要な、defaultHostCredという名前を持つ資格証明使用を受け入れます。バインディングは、次のように表すことができます。
<step ID="Ta_S1_suspend" command="execAndSuspend">
<credList>
<cred usage="defaultHostCred" reference="osCreds"/>
</credList>
<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="suspendTimeout">2</param>
</paramList>
</step>
execAndSuspendコマンドのパラメータは次のとおりです。
remoteCommand: 実行可能ファイルまたはスクリプトのパス名(例: /usr/local/bin/perl)。
args: remoteCommandに対する引数のリスト(カンマ区切り)。
targetName: コマンドの実行対象となるターゲットの名前。プレースホルダを使用してターゲットを表すことができます。
targetType: コマンドの実行対象となるターゲットのターゲット・タイプ。
input: これを指定した場合、その値は標準入力としてリモート・プログラムに渡されます。
suspendTimeout: 管理エージェントの起動通知を待機する期間(分)この時間内に通知を受信しない場合、実行が再開され後続のステップが実行されます(管理エージェントの起動通知を受信した場合も後続のステップが実行されるため、後続のステップがタイムアウトしたのか正常に実行されたのかを判断する必要があります)。
ここでdefaultHostCredは、コマンドが認識する資格証明使用です。たとえば、コマンド内のJavaコードはこの文字列を持つ資格証明をコールしますが、ここでosCredsは最上位レベルのジョブ・タイプで宣言された資格証明使用です。
remoteOp、putFile、fileTransferおよびgetFileコマンドは、表8-2にリストされているエラー・コードを返します。次のメッセージで、「コマンド・プロセス」は、指定されたリモート・コマンドを実際に実行して、実行されたコマンドの標準出力と標準エラーを取得する管理エージェントが実行するプロセスを指します。
UNIXインストールでは、このプロセスはnmoと呼ばれ、$EMD_ROOT/binに所在します。そのSetUIDがrootでないと、正常に使用できません。nmoは、有効なユーザー名とパスワードを持たないかぎり、いかなるコマンドも実行しないため、これはセキュリティ・リスクにつながりません。
表8-2 コマンド・エラー・コード
| エラー・コード | 説明 |
|---|---|
0 |
エラーはありません。 |
1 |
コア・モジュールを初期化できませんでした。エージェントのインストールまたは環境に問題がある可能性があります。 |
2 |
エージェントがメモリー不足です。 |
3 |
エージェントが入力ストリームから情報を読み取れません。 |
4 |
入力パラメータのサイズが大きいため、エージェントが処理できません。 |
5 |
コマンド・プロセスのsetuidがrootに設定されていません。UNIX Agent にはnmoという実行可能ファイルが用意されています。このファイルにはsetuid rootを設定する必要があります。 |
6 |
指定したユーザーはこのシステムに存在しません。 |
7 |
パスワードが正しくありません。 |
8 |
指定されたユーザーでは実行できません。 |
9 |
コマンド・プロセス(nmo)の分岐化に失敗しました。 |
10 |
指定されたプロセスが実行できません。 |
11 |
起動したプロセスのイグジット・ステータスが取得できません。 |
12 |
コマンド・プロセスの終了前に割込みがありました。 |
13 |
標準エラー・ストリームを標準出力にリダイレクトできませんでした。 |
ジョブ・システムでは、プラグイン開発者が、管理サービス・レベルで作業を実行するコマンドを作成できます。たとえば、データベースから2つのラージ・オブジェクト(LOB)を読み取って、各種の変換を実行し、書き戻すコマンドです。ジョブ・システムは、そのようなコマンドがLongRunningCommandと呼ばれる(空の)インタフェースを実装することを想定しています。これはコマンドが中間層の上で同期実行され、長時間実行されることがありうることを示しています。これにより、ディスパッチャと呼ばれるジョブ・システムのコンポーネントが、システムのスループットを低下させない方法で、可能なかぎり効率的に長時間のコマンドをスケジュールすることができます。
ディスパッチャはジョブ・システムのコンポーネントで、ジョブの、実行可能な状態にある様々なステップを実行します。各ステップで関連付けられるコマンド・クラスがコールされ、それが要求するすべての非同期操作がディスパッチされます。ステップのディスパッチと呼ばれる処理です。ディスパッチャは、スレッド・プールを使用してステップを実行します。スレッド・プールは指定された数のワーカー・スレッドのコレクションで、そのどれでもステップをディスパッチすることができます。
ジョブ・システム・ディスパッチャは、次の2つのスレッド・プールを使用します。
非同期のステップと短い同期のステップをディスパッチするための短いコマンド・プール
長時間のコマンドを持つステップをディスパッチするための長いコマンド・プール
通常、短いコマンド・プールには、長時間のプールのスレッド数(たとえば、10)と比較して、より多数のスレッド(たとえば、25)があります。
通常、より多数の短時間のコマンドと比較して、長時間の中間層ステップはあまりありません。ただし、2つのプールのサイズは、特定のサイトにおけるジョブの割合に適合するように、ディスパッチャで完全に構成可能です。複数のディスパッチャを異なるノードで実行できるため、サイト管理者は、あるディスパッチャを長時間のステップまたは短時間のステップの専用にすることもできます。
ジョブ・システムのデフォルト設定では、ジョブの発行時または実行時に(パラメータを動的に追加または更新して)すべてのジョブ・パラメータの値をプラグイン開発者が指定する必要があります。通常、アプリケーションは次のいずれかの方法でこれらのパラメータを指定します。
ジョブの発行時にアプリケーションのユーザーに指定させる。
アプリケーション固有のデータ(表など)からパラメータの値をフェッチし、ジョブ・パラメータ・リストに挿入する。
リモート・コマンドの出力のコマンド・ブロックを介して動的に新しいパラメータを生成する。これらのパラメータは後続のステップで使用できます。
ジョブ・システムにはパラメータ・ソースの概念があるため、プラグイン開発者は、ジョブまたはステップのパラメータをフェッチして移入するために書かなければならないアプリケーション固有のコード(たとえば上の2番目のカテゴリ)の量を簡素化できます。パラメータ・ソースは、ジョブが発行されるか、実行を開始しようとしているときに、ジョブ・システムがパラメータのセットをフェッチするために使用するメカニズムです。
ジョブ・システムは、SQL(パラメータのセットをフェッチするPL/SQLプロシージャ)、資格証明(Enterprise Manager資格証明表からのユーザー名とパスワード情報の取得)およびユーザー・ソースをサポートします。プラグイン開発者は、これらのあらかじめ作成されたソースを使用して、多種多様なパラメータをフェッチできます。ジョブ・システムが、パラメータ・ソースを使用して1つ以上のパラメータをフェッチするように構成されている場合、ジョブ発行時にジョブに対してパラメータ・リストでパラメータを指定する必要はありません。ジョブ・システムが自動的にパラメータをフェッチして、ジョブのパラメータ・リストに追加します。
ジョブ・タイプは、オプションのparamInfoセクションを使用して、フェッチする必要があるパラメータの情報をXML仕様に埋め込むことができます。次の例に示すのは、a、bおよびcの3つのパラメータをフェッチするためにアプリケーション固有の表で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セクションに次の要素が含まれます。
paramSource: 各paramSourceタグは、1つ以上のパラメータをフェッチするために使用できるパラメータ・ソースを参照しています。
paramNames: paramNames属性は、パラメータ・ソースがフェッチすると予期されるパラメータ名の、カンマ区切りの集合です。
sourceType: sourceType属性は、パラメータをフェッチするために使用されるソースを示します(SQL、資格証明またはユーザーのいずれか)。
overrideUser: overrideUser属性は、trueに設定されている場合、たとえジョブ発行時にユーザー(またはアプリケーション)がパラメータを指定した場合でも、パラメータの値が、常にこのパラメータ・フェッチ・メカニズムを使用してフェッチされることを示します。overrideUser属性のデフォルトはfalseで、パラメータがジョブ発行時にすでに指定されている場合、パラメータ・ソース・メカニズムが無効になることを示します。
フェッチ・メカニズムをより詳細に記述するパラメータ・ソースに追加のソース固有プロパティを追加できます。「SQLParameterソースの理解」に、詳細が記載されています。
evaluateOnRetry: evaluateOnRetry属性はオプションの属性で、すべてに適用できます。デフォルト設定は、資格証明を除くすべてに対してfalseです。資格証明では、設定された値は無視され、強制的にtrueとなります。これは、このジョブ・タイプの実行が失敗して再試行されるときに、パラメータ・ソースを再実行する必要があるかどうかを示します。
SQLパラメータ・ソースを使用することで、プラグイン開発者は、パラメータのセットをフェッチするSQL問合せまたはPL/SQLプロシージャを指定できます。
ジョブ・タイプのXML構文は、次のとおりです。
<paramSource sourceType="sql" paramNames="param1, param2, ...">
<sourceParam name="procName" value="MyPackage.MyPLSQLProc"/>
<sourceParam name="procParams" value="%a%, %b%[1], ..."/>
</paramSource>
paramNamesで指定される値は、procNameで指定されているPL/SQLプロシージャによって戻されると予期されるパラメータの名前です。procParamsの値は、PL/SQLプロシージャに渡される値のリストを指定します。
PL/SQLプロシージャの定義
PL/SQLプロシージャの定義は、次のガイドラインを厳守する必要があります。
PL/SQLプロシージャは、SYSMANスキーマからアクセスできる必要があります。
PL/SQLプロシージャには次のシグネチャが必要です。
PROCEDURE MySQLProc(p_param_names MGMT_JOB_VECTOR_PARAMS,
p_proc_params MGMT_JOB_VECTOR_PARAMS,
p_param_list OUT MGMT_JOB_PARAM_LIST)
paramNamesで指定されるパラメータのリストは、p_param_namesとしてプロシージャに渡されます。
procParamsで指定された値のカンマ区切りリストを使用することで、スカラー(文字列/VARCHAR2)値のリストをパラメータとしてプロシージャに渡すことができます。これらの値は、ジョブ・パラメータ参照が使用される場合にはそれを使用して値が置換され、XMLで指定された順序で配列にまとめられ、第2のパラメータ(p_proc_params)としてPL/SQLプロシージャに渡されます
第3のパラメータはOUTパラメータで、プロシージャがフェッチするパラメータのリストを含む必要があります。このOUTパラメータによって返されるパラメータの名前は、p_param_namesで指定されている名前と一致する必要があります。
注意:
このチェックは現在強制ではありませんが、p_param_listによって返されるパラメータの名前が、p_param_namesで渡されるパラメータ名のリストと一致しているか、そのサブセットであることを確認するよう強くお薦めします。
例
次のSQLパラメータ・ソースは、db_roleという名前の既存のパラメータに基づいて、db_role_suffixという名前のパラメータを作成します。元のパラメータのタイプ(スカラー/ベクトル)も維持するため、値を渡されるのでなく、内部の表のパラメータを参照します(db_roleは置換値としてでなくリテラルとして渡されます)。job_idとjob_execution_idの値は、置換されて渡されます。
<paramSource sourceType="sql" paramNames="db_role_suffix">
<sourceParam name="procName" value="MGMT_JOB_FUNCTIONS.get_dbrole_
prefix"/>
<sourceParam name="procParams" value="%job_id%, %job_execution_id%, db_
role"/>
</paramSource>
PL/SQLプロシージャMGMT_JOB_FUNCTIONS.get_dbrole_prefix内で、p_proc_paramsリストには、索引1におけるjob_idと索引2におけるexecution_idに対応する値が含まれます。索引3の要素はリテラル・テキストdb_roleに対応します。
利用できるSQL Paramsourceプロシージャ
Enterprise Manager全域のジョブ・タイプで使用するために、次のPL/SQLプロシージャがジョブ・システム・チームによって用意されています。
is_null
渡されたジョブ変数がnullであるかどうか確認します。存在しない変数も、nullとみなされます。渡された各変数について、渡された変数が存在しないかnullの場合、プロシージャは、スカラー値trueを持つ対応する変数を作成します。それ以外のすべての場合、スカラー値falseが設定されます。要素が0個のベクトルはnullでないと見なされます。
例:
<paramSource sourceType="sql" paramNames="a_is_null, b_is_null, c_is_null">
<sourceParam name="procName" value="MGMT_JOB_FUNCTIONS.is_null"/>
<sourceParam name="procParams" value="%job_id%, %job_execution_id%, a, b,
c"/>
</paramSource>
この例の場合、ジョブ変数a、bおよびcがnull値でないかチェックされ、それぞれ変数a_is_null、b_is_nullおよびc_is_nullに、trueかfalseの値が割り当てられます。
add_dbrole_prefix
渡されるすべての変数について、値がnullまたはNormal(大文字と小文字は区別されません)でない場合、プロシージャにより文字列に接頭辞ASが付けられ、それ以外の場合はnullが戻されます。このため、変数の値がSYSDBAの場合、値はAS SYSDBAになりますが、値がNormalの場合、nullが返されます。渡された変数がベクトルに対応している場合、ベクトルの個々の要素に同じロジックが適用されます。これは、DB資格証明を使用してSQL*Plusセッションに接続する際に便利です。
例:
<paramSource sourceType="sql" paramNames="db_role_suffix1, db_role_
suffix2">
<sourceParam name="procName" value="MGMT_JOB_FUNCTIONS.get_dbrole_
prefix"/>
<sourceParam name="procParams" value="%job_id%, %job_execution_id%, db_
role1, db_role2"/>
</paramSource>
ここで、変数db_role1およびdb_role2の値には必要に応じて接頭辞ASが付けられ、それぞれ変数db_role_suffix1とdb_role_suffix2に保存されます。
ジョブ・システムには、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も同様です。ターゲット名を保持する各パラメータには、ターゲット・タイプを保持する対応するパラメータが必要です。これらのパラメータはスカラーまたはベクトルのいずれかです。
inlineパラメータ・ソースを使用すると、ジョブ・タイプは、他のパラメータに関するパラメータを定義できます。ジョブ・タイプの他の部分で再利用できるパラメータを構成するための便利なメカニズムです。次の例では、ジョブ実行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 Enterprise 11gリリース1までは、資格証明は、2つのパラメータ(ユーザー名とパスワード)で表されていました。ジョブ・タイプ所有者は、資格証明パラメータ・ソースによりこれらのパラメータを抽出するか、それらをユーザー・パラメータとして定義して、パラメータを必要とする様々なステップに渡すことができます。
資格証明セット、資格証明タイプ、およびそれらの列についてのこの必要な知識と、様々な認証メカニズムについての知識は、Enterprise Managerがサポートしている可能性のある認証スキームのプールに関わらず、ジョブ・タイプによってサポートされている必要があります。これにより、ジョブ・タイプ所有者は、ジョブ・タイプだけをモデル化して、操作の実行に必要な認証を無視する自由を制限されました。これらの問題を克服し、ジョブ・タイプの統合メカニズムを進化させて資格証明を指定するために、資格証明の使用と呼ばれる新しい概念が導入されました。
資格証明バインディングとは、ステップによる資格証明の参照です。各ステップは、実行する必要がある資格証明使用をメタデータで公開しています。このため、各資格証明バインディングは、メタデータの資格証明使用セクションで定義されている参照資格証明使用を参照します。ステップが独自の資格証明使用を要求する場合、バインディングは、特定の自動化エンティティ(ジョブまたはDPインスタンス)においてどの資格証明送信をそのステップに渡すべきかの解決に役立ちます。
以前のリリースでは、ジョブ・タイプは、資格証明パラメータ・ソースを使用してジョブに渡すユーザー名とパスワードを資格証明(JobCredRecord)から抽出しており、それらはジョブ・タイプ全体からパラメータとして利用できました。この動作はサポート対象外で非推奨となり、新しい資格証明使用のしくみが導入されました。
次のジョブ・タイプ例は、ジョブ・タイプにおける資格証明宣言の使用を示しています。
<jobType version="1.0" name="OSCommandNG"
singleTarget="true" targetTypes="all"
defaultTargetType="host" editable="true"
restartable="true" suspendable="true" >
<credentials>
<credential usage="hostCreds" authTargetType="host"
defaultCredentialSet="HostCredsNormal"/>
</credentials>
<paramInfo>
<paramSource sourceType="user" paramNames="command"
required="true" evaluateAtSubmission="true" />
<paramSource sourceType="inline"
paramNames="TargetName,TargetType"
overrideUser="true"
evaluateAtSubmission="true">
<sourceParam name="paramValues"
value="%job_target_names%[1],
%job_target_types%[1]" />
</paramSource>
<paramSource sourceType="properties"
overrideUser="true"
evaluateAtSubmission="false" >
<sourceParam name="targetNamesParam"
value="job_target_names" />
<sourceParam name="targetTypesParam"
value="job_target_types" />
</paramSource>
<paramSource sourceType="substValues"
paramNames="host_command,host_args,os_script"
overrideUser="true" evaluateAtSubmission="false">
<sourceParam name="sourceParams"
value="command,args,os_script" />
</paramSource>
</paramInfo>
<stepset ID="main" type="serial" >
<step ID="Command" command="sampleRemoteOp">
<credList>
<cred usage="OS_CRED" reference="hostCreds"/>
</credList>
<paramList>
<param name="remoteCommand">%host_command%</param>
<param name="args">%host_args%</param>
<param name="input"><![CDATA[%os_script%]]></param>
<param name="largeInputParam">large_os_script</param>
<param name="substituteLargeParam">true</param>
<param name="targetName">%job_target_names%[1]</param>
<param name="targetType">%job_target_types%[1]</param>
<param name="executeSynchronous">false</param>
</paramList>
</step>
</stepset>
</jobType>
最初の3行の部分は、ジョブ・タイプにおける資格証明使用を宣言しています。次の数行の部分は、資格証明使用をそのステップのものにバインドしています。ジョブ・システムがユーザー名とパスワードを抽出できないため、それらがパラメータとして公開されることはありません。
XSD要素の資格証明使用と資格証明バインディングについて、表8-3と表8-4で説明します。
表8-3 資格証明使用(credential)
| 属性 | 必須(Y/N) | 説明 |
|---|---|---|
|
Y |
資格証明がジョブ・タイプで参照されるときの名前。すべての資格証明送信は、この名前で行われます。 |
|
Y |
あらゆる操作で、認証の実行対象となるターゲット・タイプ。たとえば、あらゆるターゲットを対象とするlsの実行は、ホストに対する認証を意味します。 |
|
Y |
資格証明使用が必須なのに送信が検出されない場合に、資格証明として取得される資格証明セットの名前。 |
|
N |
資格証明の指定にのみ使用できる資格証明タイプの名前。これは、資格証明セレクタUIコンポーネントでの資格証明のフィルタリングを容易にするためのものです。 |
|
N |
資格証明セレクタUIで表示するための名前。 |
|
N |
資格証明セレクタUIで表示するための説明。 |
表8-4 資格証明バインディング(cred)
| 属性/サブ要素 | 必須(Y/N) | 説明 |
|---|---|---|
|
Y |
ステップによって認識される資格証明使用。 |
|
Y |
ジョブ・タイプまたはDPメタデータの宣言に存在し、参照される資格証明使用。 |
注意:
資格証明バインディング要素は、ジョブ・タイプXMLのステップまたはジョブ要素内部でのみ使用できます。
通常、ジョブ・タイプは、privilegedとみなされるアクションを実行する傾向があります。たとえば、本番データベースに対するパッチ適用や、Oracleホーム・ディレクトリまたはAPPL_TOPディレクトリにインストールされているソフトウェアの変更です。そのようなジョブ・タイプは、それらのアクションを実行する適切なレベルの権限を持っているEnterprise Managerユーザーによって、発行される必要があります。
ジョブ・システムにはsecurityInfoというセクションが用意されており、ジョブ・タイプの作成者はそれを使用して、このタイプのジョブの発行者が持つ必要のある最小限のレベルの権限(systemおよびtarget)を指定することができます。
securityInfoセクションにより、ジョブ・タイプの作成者は、ジョブ・タイプ自身においてジョブ発行に関連付けられているセキュリティ要件をカプセル化することができます。セキュリティを強制的に適用するために追加のコードを記述する必要はありません。また、ジョブ・タイプ作成者によって定義された権限セットがない限り、Enterprise Managerユーザーが特定のタイプのジョブを直接発行する(ジョブ・システムAPIを使用して、アプリケーションを回避する)ことができないようにすることができます。
例1
次の例は、典型的なsecurityInfoセクションを示しています。データベースをクローニングするジョブ・タイプを作成していると想定します。このジョブ・タイプは、2つのターゲット(ソース・データベースと、宛先データベースが作成される宛先ノード)を必要とします。このジョブ・タイプでは、クローン・ジョブを発行するユーザーは、ソース(データベース)上にCLONE FROM権限を、宛先(ノード)上にMAINTAIN権限を持っている必要があります。
さらに、システムに新しいターゲットを導入するCREATE TARGETシステム権限を持つ必要があります。ジョブ・タイプが、ターゲット・リストの第1ターゲットがソース、ターゲット・リストの第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>タグで構成されます。それぞれの権限はsystem権限またはtarget権限で、タグのタイプ属性によって示されます。権限がtarget権限の場合、権限がアタッチされるターゲットを明示的に列挙するか、target_names_paramとtarget_types_param属性を次の例で示すように使用する必要があります。通常の%param%表記を使用して、ジョブ・パラメータおよびターゲットのプレースホルダを示すことができます。
デフォルトでは、すべてのsubmit-timeパラメータ・ソースが評価された後、securityInfoセクションのすべての<privilege>ディレクティブがジョブ発行時に評価されます。ユーザーがsecurityInfoセクションで指定された権限のいずれも持っていない場合、ジョブ・システムは例外を送出します。
Execution-timeパラメータ・ソースはジョブ送信時に評価されないため、未評価の可能性があるジョブ・パラメータを使用しないように注意する必要があります。evaluateAtSubmissionパラメータをfalseに設定することによって、権限ディレクティブをジョブ実行時に評価するように、ジョブ・システムに指示することもできます。
そのようにする唯一のケースは、ジョブが動作するターゲットのセットが、ジョブ実行時まで正確にわからない場合です(たとえば、execution-timeパラメータ・ソースを使用して計算される場合)。execution-time権限ディレクティブは、すべてのexecution-timeパラメータ・ソースが評価された後で評価されます。
例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つのターゲット(ジョブ・パラメータbackup_dbに名前が格納されているデータベース、およびジョブのターゲット・リストの最初の2つのターゲット)上で、LOCK1という名前の名前付きターゲット・ロックも取得します。最後に、GLOBALLOCK1という名前のグローバル・ロックを取得します。action属性は、そのセクション内でいかなるロックも取得できない場合に(なんらかの他の実行がロックを持っているため)、実行に対してジョブ・システムが行う必要のある処置を指定します。可能な値はsuspend(すべてのロックが解放され、実行の状態がSuspended:Lockに変更されます)とabort(実行は終了します)です。実行とロックについては、次の点を指摘できます。
実行によってロックの取得が試行されるのは、実行の開始時のみです(ただし、この設定はネストされたジョブを使用して上書きできます)。
1つの実行が複数のロックを取得できます。ロックは常に、指定された順序で取得されます。そのため、間違った順序でロックを取得しようとすると、複数の実行の間でデッドロックが発生する可能性があります。
ターゲット・ロックは常に、<targetList>タグに指定された順序で、ターゲット上で取得されます。
ターゲット・リスト内のターゲットがnullまたは存在しない場合、実行は終了します。
すでに保持しているロックを取得しようとした場合、実行は成功します。
ロックを取得できない場合(通常、他の実行によってそのロックが保持されているため)、その実行は一時停止するか終了するかを選択できます。一時停止を選択した場合、すでに取得したすべてのロックが解放され、実行が一時停止中/ロックの状態になります。
実行が終わると(完了、失敗、または停止)、実行が保持していたすべてのロックが解放されます。解放されたロックそれぞれについて、待機中の実行が複数ある場合がありますが、それらは時刻でソートされ、最も古いリクエストがロックを取得します。
lockInfoセクションを持つ複数のジョブが相互にネストされている場合、ネストされたジョブのロックは、実行の開始時ではなく、ネストされたジョブが最初に実行されたときに取得されます。ロックを使用できない場合、親実行のいくつかのステップがすでに実行されている可能性はありますが、その後で親実行は一時停止または終了します。
lockInfo例1
この例では、HOTBACKUPおよびCOLDBACKUPと呼ばれる2つのジョブ・タイプが、それぞれホット・バックアップとコールド・バックアップをデータベース上で実行します。相違点は、コールド・バックアップはデータベースを停止させるが、ホット・バックアップは稼働中のままにするという点です。ホット・バックアップだけは一度に1つしか実行できないため、他のホット・バックアップやコールド・バックアップを排除する必要があります。
コールド・バックアップが実行されている場合、他のジョブ・タイプは実行できません(実行の一部としてデータベースが停止されるため)。SQLANALYZEと呼ばれる第3のジョブ・タイプはスケジュール済メンテナンス・アクティビティを実行し、その結果としてデータベース・チューニング・パラメータが変更されます(2つのSQLANALYZEジョブを同時に実行することはできません)。
表8-5 に、ジョブ・タイプ間の非互換性を示します。「X」は、ジョブ・タイプに互換性がないことを示します。「OK」は、ジョブ・タイプに互換性があることを示します。
表8-5 ジョブ・タイプの非互換性
| ジョブ・タイプ | HOTBACKUP | COLDBACKUP | SQLANALYZE |
|---|---|---|---|
HOTBACKUP |
X |
X |
OK |
COLDBACKUP |
X |
X |
X |
SQLANALYZE |
OK |
X |
X |
次のコードの例に、3つのジョブ・タイプのlockInfoセクションを示します。コールド・バックアップでは、データベースの排他ターゲット・ロックが取得されます。ホット・バックアップ・ジョブでは、排他ロックは取得されず、名前付きロックBACKUP_LOCKのみが取得されます。同様に、SQLANALYZEジョブでは、SQLANALYZE_LOCKという名前付きターゲット・ロックが取得されます。
ジョブの対象となるデータベースが、ジョブのターゲット・リストの最初のターゲットであると仮定すると、2つのジョブのlockセクションは、次のようになります。
<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分析ジョブが終了します。
lockInfo例2
PATCHCHECKと呼ばれるジョブ・タイプは、パッチ・ステージング領域を定期的にチェックし、新しくステージングされたパッチに関する情報を管理リポジトリにダウンロードします。そのようなジョブは2つ同時に実行できませんが、ジョブはいかなるターゲットにも関連付けられていません。解決策は、ジョブ・タイプがグローバル・ロックを取得することです。
<jobType name="PATCHCHECK">
<lockInfo>
<lock type="global" name="PATCHCHECK_LOCK" />
</lockInfo>
........ Rest of the job type follows
</jobType>
lockInfo例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が失敗したとします。S3は実行され(S2への依存関係がないため)、成功します。ただしステップセットmainのstepsetStatusがS2に設定されているため、ジョブは失敗します。
ジョブが再起動されると、S1のrestartModeがalwaysに設定されているため、S1は、最初のときも完了しましたが、再実行されます。
ステップS2は、ソース実行で失敗したため、再スケジュールされて実行されます。S2が実行された後、ステップ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は、そのステップセットのステータスがS2ではなくS1によって決まる(stepsetStatusディレクティブによる)ため、やはり正常に完了しています。PS1がスケジュールされ、P1が失敗し、P2とP3が正常に実行されたとします。このジョブが再スケジュールされると、ステップS2は再実行されません(ステップセットSS1が正常に完了したため)。ステップ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が失敗したとします。ジョブが再起動されると、ステップセットSS1全体が再起動されます(restartModeがalwaysに設定されているため)。これは、ステップS1とS2が連続してスケジュールされていて、実行されることを意味します。これでステップセットPS1が再起動され、restartModeが指定されていない(デフォルトで常にfailure)ため、失敗した箇所から再起動されます(この場合、失敗したステップP2とP3は再実行されますが、P1は再実行されません)。
Enterprise Manager Cloud Consoleの「ジョブ・アクティビティ」または「ジョブ・ライブラリ」のいずれかのページから新規のジョブ・タイプにアクセスできるようにするには、次の特定のXMLタグ属性を変更する必要があります。
「ジョブ・アクティビティ」ページにジョブ・タイプを表示するには、以下の例に示すように、useDefaultCreateUIをtrueに設定します。
<displayInfo useDefaultCreateUI="true"/>
「ジョブ・ライブラリ」ページにジョブ・タイプを表示するには、useDefaultCreateUI属性を設定するだけでなく、編集可能属性jobtypeをtrueに設定する必要もあります。
<jobtype name="jobType1" editable="true">
useDefaultCreateUIがtrueで、editableがfalseの場合、ジョブ・タイプは「ジョブ・アクティビティ」ページにのみ表示され、「ジョブ・ライブラリ」ページには表示されません。つまり、ジョブ定義は編集できないということです。
図8-1に、useDefaultCreateUI属性をtrueに設定すると、ジョブを作成するユーザーは、「ジョブの作成」メニューから新しく追加されたジョブ・タイプを選択できることを示します。
図8-1 「ジョブ・アクティビティ」ページで使用できるジョブ・タイプ
ジョブ・タイプを「ジョブ・アクティビティ」ページから使用できるようにすると、ユーザーは新規に追加されたジョブ・タイプを使用してジョブを作成する際に、デフォルトの「ジョブの作成」ユーザー・インタフェースにアクセスできます。
次の例に示すように、displayInfoタグは、</stepset>タグの後、ジョブ定義ファイル末尾の</jobtype>タグの前にある、ジョブ定義ファイルの任意の箇所に追加できます。
<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に設定する必要もあります。これにより、新しく追加されたジョブ・タイプが、「ライブラリ・ジョブの作成」メニューから選択できるオプションになります。
次の例に示すように、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
この例では、4つのステップ、S1、S2、S3およびS4を定義するjobType1と呼ばれるジョブ・タイプを記述しています。それは、S1とS2を順次シリアルに実行します。ステップS2が成功した場合のみステップS3を実行し、S2が失敗した場合のみ、ステップS4を実行します。すべてのステップが反復サブセットの範囲内で実行され、そのためこれらのアクションが、タイプ・データベースのジョブ・ターゲット・リストにあるすべてのターゲット上で並列に実行されます。
注意:
これらの例では、パラメータ、%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のステータスがジョブのステータスに影響することはありません。
例: 4つのステップを定義するジョブ・タイプ
<jobtype name="jobType1" editable="true" version="1.0">
<credentials>
<credential usage="defaultHostCred" authTargetType="host"
defaultCredentialSet="DBHostCreds"/>
<credential usage="defaultDBCred" authTargetType="oracle_database"
credentialTypes="DBCreds"
defaultCredentialSet="DBCredsNormal"/>
</credentials>
<stepset ID="main" type="iterativeParallel" iterate_param="job_target_types" iterate_param_filter="oracle_database" >
<step ID="s1" command="remoteOp"">
<credList>
<cred usage="defaultHostCred" reference="defaultHostCred"/>
</credList>
<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>
</paramList>
</step>
<step ID="s2" command="remoteOp"">
<credList>
<cred usage="defaultHostCred" reference="defaultHostCred"/>
</credList>
<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>
</paramList>
</step>
<step ID="s3" successOf="s2" command="remoteOp">
<credList>
<cred usage="defaultHostCred" reference="defaultHostCred"/>
<cred usage="defaultDBCred" reference="defaultDBCred">
<map toParam="db_username" credColumn="DBUserName"/>
<map toParam="db_passwd" credColumn="DBPassword"/>
<map toParam="db_alias" credColumn="DBRole"/>
</cred>
</credList>
<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>
</paramList>
</step>
<step ID="s4" failureOf="s2" command="remoteOp">
<credList>
<cred usage="defaultHostCred" reference="defaultHostCred"/>
</credList>
<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>
</paramList>
</step>
</stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobtype>
例2
この例では、(パラレル・ステップセットss1内で)並列的に実行されるS1とS2の2つのステップ、およびS1とS2の両方が正常に実行された場合のみ実行される3つ目のステップS3を持つジョブ・タイプを記述しています。これを実現するために、同じくパラレル・ステップセットss1を含むシリアル・ステップセット(main)の中に、ステップS3が配置されています。このジョブ・タイプは複数ノード・ジョブです。この例では、コマンドへのパラメータ内で%job_target_name%[1]、%job_target_name%[2]が使用されています。反復ステップセット以外のステップセットでジョブ・ターゲットを参照できる唯一の方法は、(順序付けされた)ターゲット配列内でのそのジョブ・ターゲットの位置を使用することです。
%job_target_name%[1]は第1ターゲット、%job_target_name%[2]は第2ターゲット、以下同様になります。ほとんどの複数ノード・ジョブは、ターゲットの順序が同じであることを前提としています。たとえば、クローン・ジョブでは、ソース・データベースを最初のターゲット、およびターゲット・データベースを2番目のターゲットにすることが前提になる場合があります。このジョブは、次のいずれかが発生した場合に失敗します。
パラレル・ステップセットSS1が失敗した(S1またはS2のどちらか、もしくは両方が失敗した)
S1とS2の両方が成功したがS3が失敗した
ジョブ・タイプ自体がエージェントにバインドされていることを宣言しています。これは、(第1ターゲットまたは第2ターゲットに対応する)どちらかの管理エージェントが停止した場合に、ジョブが一時停止/エージェント停止の状態に設定されることを意味します。
例: 3番目のステップに続く2つのステップを定義するジョブ・タイプ
<jobtype name="jobType2" version="1.0" agentBound="true" >
<stepset ID="main" type="serial" editable="true">
<!-- All steps in this stepset ss1 execute in parallel -->
<credentials>
<credential usage="hostCreds" authTargetType="host"
defaultCredentialSet="HostCredsNormal"/>
</credentials>
<stepset ID="ss1" type="parallel" >
<step ID="s1" command="remoteOp" >
<credList>
<cred usage="defaultHostCred" reference="defaultHostCred"/>
</credList>
<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>
</paramList>
</step>
<step ID="s2" command="remoteOp" >
<credList>
<cred usage="defaultHostCred" reference="hostCreds"/>
</credList>
<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>
</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="remoteOp" >
...
</step>
</stepset>
<displayInfo useDefaultCreateUI="true"/>
</jobtype>
例3
この例では、タイプjobType1およびjobType2のジョブを順次実行する、jobType3と呼ばれる新しいジョブ・タイプを定義します。タイプjobType2のjob2ジョブは、第1のジョブが失敗する場合のみ実行されます。もう1つのジョブを実行するには、ターゲット・リストとparamリストを渡す必要があります。targetListタグにはallTargetsというパラメータがあり、trueに設定されると、ターゲット・リスト全体をこのジョブに渡します。allTargetsをfalseに設定すると、ジョブ・タイプは、そのターゲットのサブセットを他のジョブ・タイプに渡すかどうかを選択できます。
この例で、jobType3は、タイプjobType1のジョブのインスタンスにはそのターゲットすべてを渡しますが、タイプjobType2のジョブ・インスタンスには、そのターゲット・リストの最初の2つのターゲットのみを(その順序で)渡します。パラメータに関して似た機能を実行する、allParamsと呼ばれるもう1つの属性(paramListに関連付けられています)があります。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> </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> </paramList> </job> </stepset> <displayInfo useDefaultCreateUI="true"/> </jobType>
例4
「ファイルに変数を生成するジョブ・タイプの定義」の例は、generateFileコマンドの使用方法を示しています。一連のスクリプトを実行しようとしていて、そのすべてで、実行時にのみわかるなんらかの環境変数を設定する共有ファイルをソースとする必要があるとします。これを実現する1つの方法は、一意の名前を持つファイル内で変数を生成することです。それ以降のすべてのスクリプトは、コマンド・ライン引数の1つとしてこのファイル名を渡され、それを読み取って、必要な環境変数またはシェル変数を設定します。
このジョブの最初のステップS1は、generateFileコマンドを使用して、app-home/execution-id.envというファイルを生成します。ジョブの実行IDは常に一意であるため、ファイル名も確実に一意になります。3つの環境変数、ENVVAR1、ENVVAR2およびENVVAR3が生成され、それぞれ、ジョブ・パラメータparam1、param2およびparam3の値に設定されます。これらのパラメータは、ジョブ発行時に、正しい値に設定される必要があります。
%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コマンドを使用して管理エージェント上に一時ファイルを書き込む場合、処理の後でクリーンアップすることが重要です。この例では、クリーンアップは明示的に別のステップとして行われていますが、リモート・ホスト上で実行するスクリプトのいずれかによって実行することもできます。
また、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>
<credentials>
<credential usage="hostCreds" authTargetType="host"
defaultCredentialSet="HostCredsNormal"/>
</credentials>
<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=contents">
<![CDATA[#!/bin/ksh
export ENVVAR1=%param1% export ENVVAR2=%param2% export ENVVAR3=%param3%
]]>
</param>
</paramList>
</step>
<step ID="s2" command="remoteOp" >
<credList>
<cred usage="defaultHostCred" reference="hostCreds"/>
</credList>
<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>
</paramList>
</step>
<step ID="s3" command="remoteOp" >
<credList>
<cred usage="defaultHostCred" reference="hostCreds"/>
</credList>
<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>
</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つのパラメータが必要です。データベース・リソースを最大限に活用するために、できるかぎりバインド・パラメータを使用する必要があります。
例: SQL文およびPL/SQLプロシージャを実行するジョブ・タイプの定義
<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
この例は、スイッチ・ステップセットの使用例です。このジョブの主要なステップセットは、switchVarNameがstepTypeという名前のジョブ・パラメータである、スイッチ・ステップセットです。このパラメータが持つことができる値(switchCaseVal)はsimpleStep、parallel、およびOSJobで、最終的にそれぞれ、ステップSWITCHSIMPLESTEP、パラレル・ステップセットSWITCHPARALLELSTEP、またはネストされたジョブJ1を選択することになります。
<jobType version="1.0" name="SwitchSetJob" editable="true"> <stepset ID="main" type="switch" switchVarName="stepType" > <credentials> <credential usage="hostCreds" authTargetType="host" defaultCredentialSet="HostCredsNormal"/> </credentials> <step ID="SWITCHSIMPLESTEP" switchCaseVal="simpleStep" command="remoteOp"> <credList> <cred usage="defaultHostCred" reference="hostCreds"/> </credList><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> </paramList> </step> <stepset ID="SWITCHPARALLELSTEP" type="parallel" switchCaseVal="parallelStep"> <step ID="P11" command="remoteOp" > <credList> <cred usage="defaultHostCred" reference="hostCreds"/> </credList> <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> </paramList> </step> <step ID="P12" command="remoteOp" > <credList> <cred usage="defaultHostCred" reference="hostCreds"/> </credList> <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> </paramList> </step> </stepset> <job ID="J1" type="OSCommandSerial" switchCaseVal="OSJob" > <paramList> <param name="command">%command%</param> <param name="args">%args%</param> </paramList> <targetList> <target name="%job_target_names%[1]" type="%job_target_types%[1]" /> </targetList> </job> </stepset> <displayInfo useDefaultCreateUI="true"/> </jobType>
例7
この例は、次のジョブ・タイプについて、第1ターゲットに対する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>
例8
次に、ジョブ・タイプ指定内のネストされたジョブに資格証明が渡されるシナリオの例を示します。
<jobType version="1.0" name="SampleJobType001" singleTarget="true" editable="true"
defaultTargetType="host" targetTypes="all">
<credentials>
<credential usage="osCreds" authTargetType="host"
defaultCredentialSet="HostCredsNormal" credentialTypes="HostCreds">
<displayName nlsid="LABEL_NAME">OS Credentials</displayName>
<description nlsid="LABEL_DESC">Please enter credentials.</description>
</credential>
</credentials>
<stepset ID="main" type="serial">
<step ID="Step" command="remoteOp">
<credList>
<cred usage="defaultHostCred" reference="osCreds" />
</credList>
<paramList>
<param name="targetName">%job_target_names%[1]</param>
<param name="targetType">%job_target_types%[1]</param>
<param name="remoteCommand">/bin/sleep</param>
<param name="args">1</param>
</paramList>
</step>
<job ID="Nested_Job" type="OSCommand">
<credList>
<cred usage="defaultHostCred" reference="osCreds" />
</credList>
<targetList allTargets="true" />
<paramList>
<param name="command">/bin/sleep</param>
<param name="args">1</param>
</paramList>
</job>
</stepset>
</jobType>
この項では、ジョブ・タイプを設計する場合に検討すべき問題を簡単に説明します。これらの問題は、ジョブ・タイプおよび全体的なジョブ・システムのパフォーマンスに影響を与える場合があります。
パラメータ・ソースの使用については、次の問題が重要です。
パラメータ・ソースは、管理リポジトリや資格証明表など、既知のソースから必要なパラメータを取得する場合に便利です。パラメータ・ソースは、どこかに格納されている情報をフェッチする、クイック問合せのみに使用する必要があります。
一般的に、ジョブの実行時に評価されるパラメータ・ソースは、ジョブ・ディスパッチャのスループットに影響するため、慎重に使用する必要があります。実行時のパラメータのフェッチを避けられない場合もありますが、実行時または発行時のどちらにパラメータがフェッチされても構わない場合は、evaluateAtSubmissionをfalseに設定してください。
SQL問合せを実行してパラメータを取得する場合(SQLパラメータ・ソースを使用)は、通常のパフォーマンス向上ガイドラインが適用されます。これには、必要に応じて索引のみを使用し、大きな表の結合を避けることが含まれます。
新しいジョブ・タイプをメタデータ・プラグインとともにパッケージ化するには、次の実装ガイドラインを厳守する必要があります。
メタデータ・プラグインでパッケージ化される新規ジョブ・タイプには2つの新規ファイルがあります。
ジョブ・タイプ定義XMLファイル: プラグイン・デプロイメント時に、新規ジョブ・タイプを定義するためにジョブ・システムで使用されます。各ジョブ・タイプにつき、1つのXMLファイルがあります。
ジョブ・タイプ・スクリプト・ファイル: プラグイン・デプロイメント時に、選択された管理エージェントにインストールされます。単一のスクリプトが異なるジョブの間で共有される場合があります。
次の2つのプロパティを、ジョブ・タイプ定義XMLファイルの先頭行でtrueに設定する必要があります。
agentBound
singleTarget
次はその例です。
<jobType version="1.0" name="PotatoUpDown" singleTarget="true" agentBound="true" targetTypes="potatoserver_os">
プラグインを使用してパッケージ化されるジョブ・タイプでは、新しいジョブ・タイプに対するJavaの使用がサポートされないため、新しいジョブ・タイプはagentBoundとなり、管理エージェント(ジョブ・タイプ・スクリプト・ファイル)に渡されるスクリプトを介して作業を実行します。ジョブ・タイプ定義XMLファイルにはジョブ・タイプ・スクリプト・ファイルへの参照が含まれ、ジョブがEnterprise Managerコンソールから実行される際は常に、管理エージェントでそのファイルを実行します。
ジョブ・タイプ定義XMLファイルを作成し、ターゲット・タイプ定義ファイルの変更が終了したら、その他のターゲット・タイプと同様にそのファイルをOracleプラグイン・アーカイブ(OPAR)に追加します。詳細は、「プラグインの検証、パッケージ化およびデプロイ」を参照してください。
