| Oracle® Enterprise Manager Cloud Control拡張プログラマーズ・リファレンス 12cリリース4 (12.1.0.4) B70762-06 |
|
 前 |
 次 |
ITインフラストラクチャを効果的に管理するには、ITエンティティ間の関係に関する知識が必要です。ITIL (Information Technology Infrastructure Library)で説明されているようなベスト・プラクティスは、このような関係の取得と使用に依存します。Enterprise Manager Cloud Control 12cは、サポートされるこの種の関係を拡張し、これらの関係を保守できる宣言的なメカニズムを追加しています。関係に基づいてシステム内のエンティティのメンバーシップも決定します。正確な関係に基づいて、次のような様々なEnterprise Managerアプリケーションおよびコンポーネントで顧客の使用をサポートできます。
依存性分析。
たとえば、ホストのシャットダウンの(アプリケーションとインフラストラクチャに対する)影響を理解します。
トポロジ・ビューア。
変更管理。
たとえば、クローン・データベースのソースの追跡。
問題を分析および特定するためにアプリケーション・コンポーネント間の相互依存関係を知る必要のあるエンドツーエンドのパフォーマンス分析。
VMリソースの割当て方法の変更など、関係の変更追跡。
この章の内容は次のとおりです。
プラグイン開発者は、管理対象エンティティ・タイプに適用されるアソシエーション・タイプを定義し、適切なアソシエーション(アソシエーション・インスタンス)が存在することを確認する必要があります。
管理可能エンティティとは、Enterprise Managerが管理できるエンティティです。これは、エンティティがCloud Controlアプリケーションでエンド・ユーザーになんらかの形式で公開され、適切に定義された属性とセマンティクスを持つことを意味します。
プラグイン開発者は、導出されたアソシエーションについて、次の手順に従う必要があります。
所有する管理対象エンティティ(ME)に対して表す必要のあるすべてのアソシエーションを識別します。
一般に、これには所有するMEと他の任意のME間の包含または依存のアソシエーションが含まれます。識別されたアソシエーションの種類ごとに、関連するMEタイプの所有者と協力して、そのタイプのアソシエーション・インスタンスを最新に保つ責任を持つ担当者を決定することが必要な場合があります。一部のアソシエーション(特に、hosted_byとmanaged_by)は、Enterprise Managerによって自動的に保守されるため、これらに対してアソシエーション導出ルールを使用する必要はありません。
Enterprise Managerに付属の即時利用可能なアソシエーション・タイプのセットについて理解し、最も適切なタイプを使用します。
詳細は、第11.2.1項「即時利用可能なアソシエーション・タイプについて」を参照してください。
アソシエーション導出ルールを使用して、リポジトリに存在する構成データに基づいて存在する必要のあるアソシエーションを(宣言的に)記述します。
ルールは、構成収集によってトリガーされます(ターゲット・プロパティの変更も構成収集として扱われます)。
詳細は、第11.3.1項「アソシエーション導出ルールの構文とセマンティクスの使用」を参照してください。
MEタイプのアソシエーションは他のプラグインのMEタイプに関係することが多いため、アソシエーションのメンテナンスについて他のMEの所有者と協力する必要があります。
ルールをパッケージ化するプラグインを決定します。ルールをインストールする前にすべてのターゲット・タイプおよびそれらのECMメタデータが存在するようにするために、ルールを所有するプラグインでは、他のすべての必要なプラグインを前提条件として指定する必要があります。
第11.3.10項「アクティブ化式について」で説明するように、必要なすべてのターゲット・タイプが存在することを保証できない場合は、高度なアクティブ化式を使用できます。ルールのトリガーは、トリガーで指定されたターゲット・タイプを定義するプラグインに存在する必要があります。ただし、プラグインのインストール前にターゲット・タイプが存在することがわかっている場合、トリガーはルールとともに存在できます。
この章では、次の内容を十分に理解していると想定します。
アソシエーション・タイプの概要、アソシエーション・タイプ階層、アソシエーション・タイプに対して許可される管理可能エンティティ・タイプのペアの概念、順方向および(抽象に対する)具体アソシエーション・タイプ、およびEnterprise Managerの即時利用可能なアソシエーション・タイプのセマンティクス。
ターゲット・モデル、ターゲット・プロパティおよびターゲット・コンポーネント。
構成データとしてのターゲット・プロパティの処理を含む、エンタープライズ構成管理構成収集。
プラグインとそのXMLファイルのパッケージ化の方法を含む、プラグイン開発の概要。
トポロジ・ビューア(アソシエーションを表示するため)。
Enterprise Managerでは、関係の概念は内部的にアソシエーションと呼ばれます。アソシエーション(アソシエーション・インスタンス)は、2つの管理対象エンティティ間の関係を表し、ソース、宛先、アソシエーション・タイプの3つの値を指定します。たとえば、"database1 exposed_by listener1"では、database1がソース、listener1が宛先、"exposed_by"がアソシエーション・タイプです。
ここでは、アソシエーション・タイプを定義する簡潔で宣言的な手段を提供するアソシエーション導出ルールについて説明します。アソシエーション導出(アソシエーションの存在は収集されたデータから導出されるため、このように呼ばれます)は、ターゲットから収集したデータに基づいて開発者がアソシエーション・インスタンスを作成および削除できるメカニズムを提供します。
アソシエーション導出は、構成収集を使用して収集されてEnterprise Managerリポジトリに存在するデータに基づきます。アソシエーション導出メカニズムでは、アソシエーションと収集された構成データの整合性を保ち、(アクセスできるデータが少ないエージェント・ロジックによるのではなく)すべての既知のデータに基づいてアソシエーションを集中的に決定できます。
Enterprise Managerは、ほとんどのプラグイン開発者のニーズを満たす必要のあるアソシエーション・タイプの共通セットを提供しているため、これらのアソシエーション・タイプに精通し、適宜使用することをお薦めします。
カーディナリティでは、全体的なアソシエーション・タイプのカーディナリティを指定します。allowed_pairs (制約)では、重複するカーディナリティを指定できず、より特定的なカーディナリティを指定できます。抽象アソシエーション・タイプに対しては、アソシエーション・インスタンスを作成できません。
次の図に、コア・アソシエーション・タイプの階層を示します。即時利用可能なアソシエーション・タイプの詳細は、付録A「即時利用可能なアソシエーション」を参照してください。
アソシエーション導出を使用するには、次の手順を実行します。
ターゲット構成の収集後に実行するロジックを指定します。
ロジックは、ソースで管理されるエンティティGUID、アソシエーション・タイプ、および宛先で管理されるエンティティGUIDを指定する3重形式でアソシエーション・インスタンスのセットを導出します。たとえば、oracle_listenerタイプのターゲットのアソシエーション導出ロジックは、リスナーとリスニング対象の各データベース間のアソシエーションを表す3つの項目を返すことができます。
3つの項目の導出に使用されるロジックを含むSELECT文を作成および実行します。
返される各行には、アソシエーション・タイプ、ソースおよび宛先の列が含まれ、存在する必要のあるアソシエーションを表します。
エンタープライズ構成管理スナップショット・タイプに対する導出ロジックを登録します。
すべてのスナップショットの収集後に、登録されたロジックが呼び出されます。ロジックへの入力は、データが収集されるターゲットのGUIDです。
ターゲットTのスナップショットSのアソシエーション導出ロジックが実行されると、導出されたアソシエーションは、ターゲットTのスナップショットSについて以前に導出されたアソシエーションを置き換えます。たとえば、アソシエーションA1およびA2が昨日収集され、本日はA1のみ収集される場合、A2は実際上削除されます。
Enterprise Managerにアソシエーションを追加する1つのオプションは、ターゲットとそれらの間のアソシエーションを検出する検出スクリプトを提供することであり、検出スクリプトは、選択したエージェント・セットで実行するようにエンドユーザーによってスケジュールされます。このタイプのスクリプトで検出されたターゲットとアソシエーションは自動的に昇格され、Enterprise Managerに自動的に追加されます。このアプローチは、プラグインで管理されるため特定のターゲットの識別情報がわかっている(つまり、アソシエーションの両方の側にターゲットを作成する)ターゲット間のアソシエーションに役立ちます。これらのアソシエーションがプラグインに含まれない他のターゲットに対するものである場合は、通常、導出されたアソシエーション・ルールを使用して"外部"ターゲットの特定方法を指定します。
スクリプトで検出された情報をフィルタするためにエンドユーザーまたは管理者との対話が必要な場合、またはEnterprise Managerがすでに認識している他の情報と比較するために一定量の後処理が必要な場合は、ガイドされた検出プロセスを使用できます。
このアプローチは、Enterprise Managerエージェントによって実行できる検出スクリプトを提供するという点で、前の項で説明した自動検出アプローチと似ています。その検出スクリプトは、任意の数の関連ターゲットおよびそれらの間のアソシエーションを返すことができます。違いは、ガイドされた検出の場合、エンドユーザーが検出スクリプトの実行を駆動し、返される結果を処理するために対話するユーザー・インタフェースを提供することです。この処理は、検出スクリプトから出力を取得し、さらにフィルタ処理するか、エンドユーザーに提示してエンドユーザーが重要な情報を追加できるようにすることができます。
ガイドされた検出は、ターゲット・サービスを使用してEnterprise Managerシステムと対話し、Enterprise Managerがすでに認識しているターゲットに関する情報を取得して、検出されたターゲットのトポロジに対する増分更新を実行することもできます。このアプローチは、作成されるアソシエーションが、プラグインで管理されるため特定のターゲットの識別情報がわかっているターゲット間アソシエーションの場合にも使用されます。つまり、アソシエーションの両方の側にターゲットを作成しますが、これらのアソシエーションをEnterprise Managerに追加する前に追加の介入が必要です。
このアプローチは、システム・ターゲットとそのメンバー間のシステム・メンバーシップ・アソシエーションの作成にのみ使用されます。システム・トポロジを形成するにはシステム・ターゲットとそのメンバー間に存在するアソシエーションのタイプに関する知識が必要であるため、システム・ターゲットとそのメンバーシップは、通常、1つのプラグインのすべてです。
システム・ステンシルは、システム・メンバーシップの形成時に考慮する必要のあるアソシエーション・パスのセットを定義します。この方法で、プラグインは複雑なアソシエーション・パスを探索して、システムのメンバーとして扱う必要のあるターゲットを特定できます。これは、システム・メンバーが他の"ネイティブ"アソシエーションによってシステム・ターゲットに直接関連付けられていない場合に重要です。
プラグインに、システムとして扱うターゲット・タイプが含まれない場合、このアプローチは無視できます。
アソシエーションの作成のこのアプローチは、アソシエーションの宛先ターゲットがプラグインの一部ではないが、Enterprise Managerによって管理されることがわかっている場合に特に適しています。たとえば、ターゲットの構成に、ターゲット操作に関連する情報の格納に使用されたOracleデータベース(アプリケーション・ストアなど)への接続が含まれていることを想定します。ターゲットの構成には、使用するデータベースに関する情報(おそらく、host-port-sidやhost-serviceなど、接続関連の詳細)があります。
Enterprise Managerがデータベースを管理する場合に、エンドユーザーがこの関係を参照して探索し、そのデータベースに関する他の情報を取得して管理できるように(適切かつ許可される場合)、ターゲットとEnterprise Managerのデータベース間のこのアソシエーションを表す必要があります。
Enterprise Managerがデータベースを管理しているかどうかはわからず、持っている識別情報はEnterprise Managerデータベース・ターゲット名ではなく接続情報であるため、ターゲットの構成内の接続情報をEnterprise Managerのデータベースの接続情報にマップする導出ルールを作成できます。
このアプローチは、プラグインの一部であるターゲットと一部の外部ターゲット(特に、Oracle Fusion MiddlewareやOracle Databaseなどの一部のEnterprise Managerスタック・コンポーネント)間にこのタイプのアソシエーションを作成する場合に非常に役立ちます。
Enterprise Manager Cloud Control 12cは、Enterprise Managerコンポーネントによるアソシエーションの使用を拡張し、全体的なアソシエーション・フレームワークを強化しています。トポロジ・ビューアなど、アソシエーションの新しいコンシューマを導入しています。
アソシエーション・フレームワークの強化には、構成データとしてのアソシエーションの処理が含まれます。変更追跡や保存されたスナップショットなどのエンタープライズ構成管理機能は、アソシエーションおよび従来の構成データに適用されるようになりました。アソシエーションは、ソースと宛先のターゲット・コンポーネントに加えて、ターゲットGUIDを指定できるようになりました。
次の各項では、導出ルールの使用と管理の詳細な手順を示します。
次の各項では、名前、問合せ、トリガー、データベース・オブジェクトなど、ルール問合せで参照できるルールの内容について説明します。
名前
ルールは、すべてのプラグインで一意である必要のある一意のルール名で識別されます。適切な接頭辞を使用して、名前の重複を回避することをお薦めします。たとえば、会社のシンボルまたは名前の後にプラグイン名を指定します。
問合せ
ルールの主要構成要素は、アソシエーションのセットを識別するルール問合せです。問合せで返される各行は、アソシエーションを表します。SQLは、次の名前とタイプを持つ4つの列を返す必要があります。
assoc_type
(VARCHAR2(64)): アソシエーション・タイプ
source_me_guid
(RAW(16)): 管理対象エンティティのGUID
dest_me_guid
(RAW(16)): 管理対象エンティティのGUID
derivation_target_guid, derivation_target_guid2, derivation_target_guid3
(RAW(16))
多くの場合に不要ですが、アソシエーションの導出に関連するターゲット(ソースまたは宛先以外)を識別する1つ以上のオプションのターゲットGUID列があります。
これらはターゲット・コンポーネントIDであってはならず、ターゲットGUIDである必要があります。
列は順番に使用する必要があります。
つまり、derivation_target_guid2を返す問合せはderivation_target_guidも返す必要があります。derivation_target_guid3を返す問合せは、derivation_target_guid列とderivation_target_guid2列も返す必要があります。
導出ターゲットGUIDが必要な一部のケースは、ターゲットの収集が他の2つのターゲット間のアソシエーションを決定するケースで示されます。たとえば、Siebel Enterprise Systemに対する収集によって、そのメンバー・ターゲット間のアソシエーションが決定されます。
この場合、導出ターゲットGUIDはSiebel Enterprise SystemターゲットのターゲットGUIDですが、ソースと宛先は他のターゲットです。Oracle E-Business SuiteとOracle WebLogic Serverでも同様のケースが存在し、構成情報がOracle WebLogic Serverドメイン管理サーバーなどの単一ソースから収集され、ドメイン・メンバー間のアソシエーションの導出に使用されます。
問合せで返される各行では、有効なアソシエーション・インスタンスを指定する必要があり、具体(抽象ではない)順方向(逆方向ではない)アソシエーション・タイプを使用する必要があります。有効なアソシエーション・インスタンスは、指定されたアソシエーション・タイプに対して有効な管理対象エンティティを指定する必要があります。たとえば、hosted_byアソシエーションでは、ホスト・ターゲットである宛先を指定する必要があります。逆アソシエーション・タイプを返してはなりません。たとえば、hosted_byの逆であり、エラーとしてログに記録されるhost_forは使用しないでください。
ルール問合せはアソシエーションのリポジトリ全体のセットを返しますが、アソシエーションは一度に1つのターゲットのために増分的に移入されます。ルールが評価される場合、単一ターゲットの観点から評価されます。評価時に、フレームワークは問合せを外部問合せでラップします。例:
"SELECT … FROM <query> WHERE derivation_target_guid = <initiatingTarget> AND …"
|
注意: フレームワークは問合せを自身の問合せでラップするときに重複を排除するため、ルール問合せに(一番外側のレベルで)DISTINCTキーワードを指定する必要はありません。問合せサイズは2000文字以下にする必要があります。(これは将来のリリースで4000文字に拡張される予定です)。 |
ルール問合せで参照されるDBオブジェクト
セキュリティ上の理由から、SYSMAN_ROユーザーがルール問合せを実行します。したがって、このユーザーがアクセスできるオブジェクトだけを参照できます。プラグインの外部で作成されたオブジェクトの場合は、MGMT$の接頭辞の付いたビューなど、プラグイン・レベルで拡張開発キット(EDK)によって公開されているビューを参照できます。
プラグインで作成されたオブジェクトの場合は、ターゲット・タイプの収集用のエンタープライズ構成管理フレームワークで自動生成されるCM$ビューを参照できます。DA_接頭辞の付いたビューおよびDA_接頭辞の付いたインボーカ権限のあるパッケージも参照できます。
問合せの実行時までに存在することが確実な場合(たとえば、対応するトリガーが起動される場合 - 次を参照)を除き、問合せはアソシエーションに依存してはなりません。構成が到着して対応するアソシエーションが導出される順序は任意であるため、導出されたアソシエーションでは、実行の順序は決定的ではありません。使用できるアソシエーションの例は、ターゲット検出時に出現する、導出されたアソシエーションではないhosted_byアソシエーションです。
トリガー
通常、トリガーはルール問合せに加えて提供されます。トリガーは、変更するとルール問合せによって返されたアソシエーションに影響する可能性のある表を指定します。ルール問合せは複数の表のデータを参照することが多く、ターゲットのデータに対する変更は問合せで返されるアソシエーション行に影響する可能性があるため、一般には複数のトリガーがあります。
2つのターゲットのうち1つが変更されない場合のように、2つのトリガーが常に必要とはかぎりません。たとえば、ターゲットの1つの(固定の) IDプロパティに基づいて宛先を決定するアソシエーション・ルールは、ソース・ターゲットの構成に対する変更の影響のみ受けます。その場合も、2つのトリガーを指定することが理想です。ソースの後に宛先ターゲットが出現することがあり、この出現が原因で新規アソシエーションが即時に作成される場合は、トリガーが必要です。
トリガーは次の項目を指定します。
スナップショット表
(新規データのアップロードによる)表に対する変更はトリガーを起動します。トリガーを不必要に起動するとパフォーマンスに影響するため、アソシエーションのセットに影響する表のみ含める必要があります。表は、ターゲット・タイプ、スナップショット・タイプおよび表名で識別されます。
列IDフラグ
これは、ソース、宛先、または導出ターゲットGUIDを使用して、新規にアップロードされた構成データの影響を受けるアソシエーションを識別する必要があるかどうかを示します。つまり、列の値に応じて、ソース、宛先または導出ターゲットのアソシエーションは、トリガー表のデータが変更されたときにそのターゲットに対して計算された新規アソシエーション・セットで置き換えられます。可能な値は、source、destination、derivationTarget、derivationTarget2、derivationTarget3などです。
トリガーが起動すると、アソシエーション導出フレームワークは、指定されたターゲットが(フラグに応じて)ソース、宛先または導出である現在存在するすべてのアソシエーションを新規に計算されたアソシエーションで実際上置き換えます。新規アソシエーション・セットを計算するために、ルール問合せはターゲットIDにバインドされた対応する列で実行されます。この簡略化した説明は、アソシエーションの存在理由がこの単一ルールだけであることを想定しており、ターゲット・コンポーネントの場合には若干変更されます。
たとえば、ルール問合せはリスナー構成表とデータベース構成表のデータにアクセスし、<database> exposed by <listener>という形式のアソシエーションを返します。データベースの構成表に対する変更は、データベースがアソシエーションのソースである行に影響することがあるため、1つのトリガーではデータベース構成表とソースの列IDフラグを指定します。同様に、リスナーの構成表に対する変更は、リスナーがアソシエーションの宛先である行に影響することがあるため、2番目のトリガーではリスナー構成表と宛先の列IDフラグを指定します。
複数のルールをスナップショット表に対してトリガーできる場合、トリガーの実行順序は決定的ではありません。つまり、開発者は順序を想定できません。
トリガーで指定された表名(TN)は、実際には実表、ビューまたはシノニムの名前であることがあります。どの場合も、TNの基礎となる表が識別されます。トリガーは、エンタープライズ構成管理表である表ごとに作成されます。
ルールを作成または更新するには、ルール(またはルールのセット)を定義するXMLメタデータ・ファイルを編集し、それをリポジトリにインポートします。メタデータのインポートは、リポジトリの作成またはアップグレード時に実行されます。プラグインの追加、アップグレードまたは削除時にも実行されます。
図式的に、各ルールの次の情報をファイルに指定します。
名前
問合せ
次のものを持つ0からnのトリガー
完全修飾スナップショット・タイプ(ターゲット・タイプを含む)。
そのスナップショットのメトリック表(このような表を参照するビューまたはシノニム)
通常、このビューはルール問合せで使用されます。
列フラグ(source、destination、derivationTarget、derivationTarget2またはderivationTarget3)。
オプションの詳細(ターゲット・プロパティに基づくトリガーのターゲット・プロパティ名の指定に使用されます)。
XMLセマンティクスは、以前の状態にかかわらず、ルールとそのトリガーの最新状態を記述するように設計されています。したがって、ルールとそのトリガーがプラグインに対してどのように指定されているかを知るために、特定のルールの最新のXML指定のみ必要です。さらに、1つのプラグインが別のプラグインのトリガーに直接影響を与えることはできません。ただし、ルールが削除されると、他のプラグインからルールを参照しているトリガーは使用できなくなります。
次に、ルール問合せ指定のセマンティクスを概説します。
空でない問合せは、追加する必要があるか、必要に応じて同じプラグインで登録されたルールの以前のルール問合せを上書きする必要があることを意味します。
問合せを指定しないことは、ルール問合せが同じプラグインによって登録され、変更がない場合に、ルールを削除することを意味します。
ルールの場所
ルールRとその問合せがプラグインP内のファイルFに配置されると、対応するXMLルール要素はそのファイルまたはそのプラグインから削除できなくなります(ただし、その属性とサブ要素は変更できます)。ルールRは常にプラグインPによって所有されます。ルールを削除する必要がある場合、ルールRが削除されたことを示す、問合せサブ要素を持たないルール要素がファイルFに残る必要があります。ルールRを別のファイルまたはプラグインに移動することが重要な場合は、ルールの名前を(たとえばR2に)変更し、ファイルFで上記の構文を使用してルールRを削除し、新しい場所にR2を追加します。これにより、事実上Rが削除され、新しいルールR2が作成されます。
ルールRを所有するプラグインPを慎重に選択して、ルール問合せに必要なすべてのターゲット・タイプがプラグインPのインストール時に存在するようにする必要があります。ルールRは、Enterprise Managerに常に存在するターゲット・タイプ(たとえばホスト)、プラグインPで定義されているターゲット・タイプ、またはプラグインPの前提条件であるプラグインで定義されたターゲット・タイプに依存する必要があります。このようなプラグインを選択できない場合は、後で説明するアクティブ化式の高度な機能の使用を検討してください。
トリガー仕様セマンティクス
トリガー仕様セマンティクスに関しては、同じプラグイン内のトリガーを新しく指定したトリガーのセットで置換する必要があります。または、新規に指定したセットが空の場合は既存のトリガーの削除のみ行うことができます。
トリガーの場所
通常、トリガーは同じプラグイン内のルール定義の一部として定義されます。このため、ルールを変更すると、対応するトリガーも必要に応じて変更されることがあります。ただし、トリガーのターゲット・タイプを定義しているプラグインにトリガーを配置することが望ましい場合またはそれのみ可能な場合があります。たとえば、ターゲットとそれに対応するOracleホーム・ターゲット間のアソシエーションを計算するルールは、可能なすべてのターゲット・タイプおよび対応するトリガーをリストできません。
かわりに、ルールを使用するターゲット・タイプを所有しているプラグインは、関連するターゲット・タイプのトリガーを指定します。したがって、oracle_iasターゲット・タイプを所有するプラグインにはこのルールのトリガーがあり、トリガーのターゲット・タイプとしてoracle_iasがリストされています。このようなトリガーは、対応するプラグインとともに変更または削除されます。
ルールのXMLがoracle_iasを所有するプラグインのファイルFにリストされた後、(ルールのトリガーのみ指定する場合でも)別のファイルに移動できません。ここでの例では、ルール問合せ自体は、Oracleホーム・ターゲット・タイプにのみ依存し、他の特定のターゲット・タイプには依存しないため、ターゲット・タイプに固有ではありません。したがって、ルールはプラグイン(oracle_iasプラグインなど)より前にインストールされたプラグインPに定義されています。このため、トリガーは、Enterprise Managerにインポートされると、すでに存在するルールを探します。
次の点を考慮する必要があります。
特定のプラグインに対して最大1つのファイルに指定されたルールとそのトリガーが常に必要です。
たとえば、ルールのトリガーの一部(異なるプラグインP1で定義)がプラグインP2の2つのファイルで指定されている場合、2番目のファイルをインポートすると、最初のファイルで指定されたトリガーが上書きされます。2つのファイルのインポート順序は保証されません。
異なるプラグインによって登録されたルールに対して問合せが指定されると、エラーが発生します。
つまり、ルール問合せを指定していないプラグインは、そのコンテキストで新しいトリガーのセットのみ指定でき、問合せを上書きできません。事実上、1つのプラグインのみがルール問合せを所有します。
存在しないか(ルール問合せを指定しないことで)削除されているルールに対するトリガー仕様がある場合は、エラーが発生します。
特定のルールに対してすべてのプラグインのすべてのトリガーを効果的に無効にするために、プラグイン作成者は、前述の構文を使用してルールを削除できます。必要に応じて、作成者は異なる名前のルールを置換として作成することもできます。
以前のリリースでルール問合せを指定したプラグインで、トリガーを置換しルール問合せを置換しない場合は、次のプラグイン・バージョンで同じ問合せを再び指定し、新しいトリガーのセットを指定します。
|
注意: パフォーマンスについては、同じ問合せテキストを指定すると、フレームワークは問合せのすべてのアソシエーションを再計算する必要がないため、アップグレードのパフォーマンスが最大化されます。 |
ルール定義の構文は次のとおりです。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="YesNo">
<xs:annotation><xs:documentation>
Type definition for the Yes/No atribute value.
</xs:documentation></xs:annotation>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="Y"/>
<xs:enumeration value="N"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="NameDef">
<xs:restriction base="xs:string">
<xs:pattern value="[A-Za-z][A-Za-z0-9_]*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="TriggerKind">
<xs:restriction base="xs:string">
<xs:enumeration value="C"/>
<xs:enumeration value="H"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ColumnID">
<xs:restriction base="xs:string">
<xs:enumeration value="source"/>
<xs:enumeration value="destination"/>
<xs:enumeration value="derivationTarget"/>
<xs:enumeration value="derivationTarget2"/>
<xs:enumeration value="derivationTarget3"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="RuleContentWFlags">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="source_comp" type="YesNo" use="optional">
<xs:annotation> <xs:documentation>
Can source entity be a target component? Default: No
</xs:documentation> </xs:annotation>
</xs:attribute>
<xs:attribute name="dest_comp" type="YesNo" use="optional">
<xs:annotation> <xs:documentation>
Can destination entity be a target component? Default: No
</xs:documentation> </xs:annotation>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="RuleType">
<xs:annotation> <xs:documentation>
Rule definition.
</xs:documentation> </xs:annotation>
<xs:sequence minOccurs="0">
<xs:choice>
<xs:element name="query" type="RuleContentWFlags" minOccurs="0"
maxOccurs="1">
<xs:annotation> <xs:documentation>
Query that returns 1 row per association. Must return
columns named ASSOC_TYPE, SOURCE_ME_GUID, DEST_ME_GUID, and
optionally, one or more of DERIVATION_TARGET_GUID,
DERIVATION_TARGET_GUID2, DERIVATION_TARGET_GUID3.
Returning DERIVATION_TARGET_GUID[N] column
implies the query also returns DERIVATION_TARGET_GUID and all
DERIVATION_TARGET_GUID[K] for all K between 2 and N.
</xs:documentation> </xs:annotation>
</xs:element>
</xs:choice>
<xs:element name="trigger" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="targetType" type="xs:string" minOccurs="1"
maxOccurs="1"/>
<xs:element name="snapshotType" type="xs:string" minOccurs="0"
maxOccurs="1"/>
<xs:element name="table" type="xs:string" minOccurs="0"
maxOccurs="1">
<xs:annotation> <xs:documentation>
Name of an ECM table or more likely a view whose query
relies on ECM snapshot table(s). The table(s), when
uploaded,
should trigger evaluation of the rule. (The fully
qualified name includes target type and snapshot
type.)
</xs:documentation> </xs:annotation>
</xs:element>
<xs:element name="idColumn" type="ColumnID" minOccurs="1"
maxOccurs="1">
<xs:annotation> <xs:documentation>
Indicates whether source, destination, or a derivation
target
should be used to identify associations affected by the
newly
uploaded configuration data. In other words, depending on
this
column value, associations for the source, destination, or
a derivation target will be replaced with new set of
associations computed for that target, when the trigger
table data changes.
ColumnID type definition contains allowed values.
</xs:documentation> </xs:annotation>
</xs:element>
<xs:element name="details" type="xs:string" minOccurs="0"
maxOccurs="1">
<xs:annotation> <xs:documentation>
Additional details for the trigger. Currently used for
target properties table, in which case, it contains comma
separated list of property names that should fire the
trigger. Absence
of property names indicates that any property change would
fire the trigger (for the given target type).
Note: white space is ignored.
</xs:documentation> </xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="kind" type="TriggerKind" use="optional">
<xs:annotation> <xs:documentation>
Kind of the trigger. "C" (configuration load trigger) by
default.
Other allowed value: "H" (host change trigger)
</xs:documentation> </xs:annotation>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="name" type="NameDef" use="required">
<xs:annotation> <xs:documentation>
Name of rule, which must be unique. Recommendation: Use a
prefix that identifies your plugin.
</xs:documentation> </xs:annotation>
</xs:attribute>
<xs:attribute name="activation_expr" type="xs:string" use="optional">
<xs:annotation> <xs:documentation>
Optional activation expression. If not present or empty, implies
that the rule is always active. Else, the value is a Boolean
activation expression which must produce true if and only if
the rule should be active.
The expression can use (case insensitive) "AND", "OR", and
parenthesis. Operands of the expression are target types.
Each occurrence of a target type evaluates to "true" if
and only if the target type is present in EM.
Note that a number of target types do not need to be listed in
the expression because they are always going to be present
whenever the rule is installed and present in EM installation.
These include:
- target types installed with the plugin where the rule resides
(i.e. target types in the plugin which owns the rule)
- target types in other plugins on which the plugin owning
the rule depends
- target types always installed with EM (like host)
Thus, in many cases, if this option is used, a single target
type, as in example 1 below, may suffice.
Examples:
(1) "oracle_ovm"
This simple expression implies that the rule should be
active only if oracle_ovm target type is installed at EM
(in addition to any other target types that are already known
to be present when this rule is installed).
(2) "oracle_ovm and (oracle_oam_cluster or oracle_oim_cluster)"
This expression implies that the rule should be active only if
oracle_ovm target type is present and either oracle_oam_cluster or
oracle_oim_cluster is also present.
</xs:documentation> </xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:element name="Rules">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="Rule" type="RuleType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
例:
<?xml version="1.0" encoding="UTF-8"?>
<Rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Rule name="ora_listensFor">
<query>
SELECT ...
fill in query
</query>
<trigger>
<targetType>oracle_database</targetType>
<snapshotType>db_config</snapshotType>
<table>CM$DB_CONFIG_TABLE</table>
<idColumn>destination</idColumn>
</trigger>
</Rule>
</Rules>
次のアルゴリズムは、トリガーが問合せQ、およびソース、宛先または導出ターゲットGUIDの列名に対応するフラグFCを指定するルールRのセマンティクスの簡略化された形式を示します。
スナップショット表に対する更新をGUIDがt_guidのターゲットtに対してアップロードする場合は、変更された表を指定するトリガーごとに次の文を実行します。
DELETE FROM MGMT_ASSOC_INSTANCES WHERE <FC> = t_guid AND RULE_ID = R INSERT INTO MGMT_ASSOC_INSTANCES (SELECT a.*, R FROM (<Q>) a WHERE <FC> = t_guid )
実際の実装は、次の理由で上記の例と異なります。
実際の実装では、同じアソシエーションの削除と追加では不十分であるため、この操作を行いません。
かわりに、現在のセットと新しいセットを比較し、必要な場合にのみ変更します。さらに、実際のdelete文では、ターゲットのターゲット・コンポーネントを指定するアソシエーションも削除されます。
アソシエーションは複数の起点によってアサートされることがあります。
これは、コンテンツがMGMT_ASSOC_INSTANCES表にロールアップされる起点表を使用して管理されます。
検証テストは様々なポイントで実行されます。
たとえば、提供されているソースおよび宛先MEに対してアソシエーション・タイプが有効であることがテストされます。
導出ルールの評価は頻繁に行われることがあるため、ルール問合せのパフォーマンスが低いと問題になることがあります。ルールの作成者は、必要な索引が存在することを確認し、各トリガーに対して生成された特定の問合せに基づいて問合せのパフォーマンスをテストする必要があります。
具体的には、各トリガーは異なる問合せの実行の原因となるため、トリガーごとにルール問合せのテストを実行する必要があります。ルール問合せが値を返す方法は、トリガーに応じて特定のターゲット・グローバル一意識別子(GUID)にバインドされます。
これらのバインドを使用する索引が必要です。さらに、問合せは、外部から問合せへのバインドのプッシュを妨げない方法で記述する必要があります。
次の各項では、問合せとトリガーに通常見られる正規パターンについて概説します。問合せとトリガーがこれらのパターンに従っているかどうかを確認し、従っていない場合はその理由を文書化します(このようなケースは通常、経験則による例外を表すため)。
問合せパターン
次に、一般的な問合せパターンを概説します。
導出ターゲットは、このようなターゲットのECM構成を使用して他の2つのエンティティ間のアソシエーションを導出するときに、null以外である必要があります。
導出ターゲットを使用する既知のケースの1つは、データベース・システムとのアソシエーションです。データベース・インスタンス・ターゲットは構成を提供し、アソシエーションは対応するデータベース・システム・ターゲットで行われます。このような場合、ターゲット・インスタンスは対応するデータベース・システム・ターゲットへのアソシエーションの導出ターゲットとして機能する必要があります。
問合せは、CM$などのオブジェクト、エンタープライズ構成管理データにアクセスする他のビュー、またはMGMT_TARGETSなどのターゲット情報にアクセスするビューにのみアクセスする必要があります。
アクセスできるオブジェクトの詳細は、第11.3.1項「アソシエーション導出ルールの構文とセマンティクスの使用」を参照してください。
アソシエーション・タイプは順方向および具体である必要があります。
トリガー・パターン
次に、一般的なトリガー・パターンを概説します。
多くの場合、トリガーの数は、FROM句のターゲット・エンティティ以外のビューの数と同じです。つまり、mgmt_targets、mgmt_target_properties、mgmt$target、mgmt$target_propertiesなどのビューは無視されます。
各エンタープライズ構成管理ビューは、1つのトリガーに対応します。1つの例外は、表を複数のターゲット・タイプ(たとえば、oracle_databaseとrac_databaseなど)からトリガーできる場合です。この場合、同じエンタープライズ構成管理ビューに対して複数のトリガーを指定できます。
トリガーの表名は、トリガーのターゲット・タイプおよびスナップショット・タイプで指定されたスナップショットのエンタープライズ構成管理メタデータ表に基づく必要があります。
通常は、ルール問合せのFROM句のオブジェクトの1つ(たとえば、CM$ビュー)である必要があります。
トリガーで指定されたビューは、問合せでターゲット(またはターゲット・コンポーネント)エンティティと(おそらく間接的に)結合されます。
エンティティIDは、SELECT句でソース、宛先、または導出ターゲットとして返されます。idColumnがこれと一致します。
たとえば、ターゲットAとBの間のアソシエーションはcm$Aconfig表とcm$Bconfig表の間の結合に依存し、cm$Aconfig表のデータはターゲットAから取得され、cm$Bconfig表のデータはターゲットBから取得されます。cm$Aconfig表のトリガーはターゲットA (たとえばソース)と一致するidColumnを持ち、cm$Bconfig表のトリガーはターゲットBのGUIDが返される場所(たとえば宛先)と一致するidColumnを持ちます。
トリガー・ターゲット・タイプは、idColumnで指定された列の問合せで返されるターゲットのターゲット・タイプと一致する必要があります。
より一般的には、ルール問合せで返されるターゲットのターゲット・タイプは、トリガー・ターゲット・タイプのサブタイプまたはターゲット・コンポーネントにすることができます。
トリガーがターゲットのプロパティに依存する場合、特定のプロパティ名は詳細タグで識別する必要があります。
問題を診断し、アソシエーションがどのように導出されたかを理解するために、フレームワークはデバッグ・モードでアソシエーションがどのように導出されたかに関する情報を記録します。デバッグの詳細は、第11.3.11項「トラブルシューティングとデバッグ」を参照してください。追加の健全性(エラー)チェックも含まれます。たとえば、1つのテストは、導出ターゲットGUIDが実際の現在のターゲットのGUIDであることをチェックします。
次の例には、適切な運用を示すためのターゲット・プロパティの使用方法が含まれますが、ターゲット・プロパティに依存することはお薦めしません。かわりに、ECM表を使用して構成データを適切にモデル化する必要があります。詳細は、第11.7.2項「ターゲット・プロパティを使用するときのガイドラインはありますか」を参照してください。
これらの例を確認するときに、次の概念を覚えておくと便利です。
すべてのターゲット・タイプに、orcl_tp_configというエンタープライズ構成管理スナップショット・タイプがあります。
これには、必要に応じてトリガーで使用する必要のあるGC$TARGET_PROPERTIESビューによって参照されるスナップショット表が含まれます。ターゲット・プロパティの現在のデータには、MGMT_TARGET_PROPERTIESおよびMGMT$TARGET_PROPERTIES EDKオブジェクトを通じてアクセスできます。
すべてのエンタープライズ構成管理スナップショット表には、デフォルトで、現在の構成データにアクセスするためのビューがあります。
その名前は、表の名前に接頭辞CM$が付きます。ほとんどのルール問合せは、CM$ビューを通じて構成表を参照します。
'deployed_on'アソシエーション・タイプを使用して、ホスト・ターゲットが仮想マシン・ターゲットにデプロイされているという事実を表します。
次の問合せは、MACアドレスの一致に基づいて、ホストと関連仮想マシン間のすべてのアソシエーションを返します。トリガーは、対応する構成ビュー(MACアドレスを含む)が変更されるたびにルールをトリガーするように定義されています。次に説明するルールは、仮想マシンを定義するプラグインに存在します(ホスト・ターゲット・タイプはどのEMインストールにも存在することが保証されます)。両方のトリガーをルールに含めることができ、どちらも仮想マシンを定義しているプラグインに属します。
<Rule name="...">
<query>
select 'deployed_on' as assoc_type,
host.target_guid as source_me_guid,
guest.cm_target_guid as dest_me_guid
from mgmt$hw_nic host,
cm$vt_vm_vnic guest
where guest.mac_address = host.mac_address_std
</query>
<trigger>
<targetType>host</targetType>
<snapshotType>ll_host_config</snapshotType>
<table>MGMT$HW_NIC</table>
<idColumn>source</idColumn>
</trigger>
<trigger>
<targetType>oracle_vm_guest</targetType>
<snapshotType>ovm_guest_config</snapshotType>
<table>CM$VT_VM_VNIC</table>
<idColumn>destination</idColumn>
</trigger>
</Rule>
Oracleホーム・ターゲット・タイプには、Oracleホームが存在するディレクトリの名前を含むINSTALL_LOCATIONターゲット・プロパティが含まれます。Oracleホームにインストールされるすべてのターゲット・タイプについて、INSTALL_LOCATIONと同じ値を指定するOracleHomeターゲット・プロパティがあります。ターゲットのOracleHome値がINSTALL_LOCATION値と一致し、両方のターゲットが同じホストに存在する場合は、installed_atアソシエーションが存在します。
ターゲットのOracleHomeとホームのINSTALL_LOCATIONの両方が変更の対象となります。ホームまたはターゲットに一致する、ターゲットまたはホームも作成できます。ただし、ターゲットのホストの値は固定です。
問合せ
Oracleホーム・ターゲットとそれらにインストールされているターゲット間のすべてのアソシエーションを返します。
<Rule name="...">
<query>
select 'installed_at' as assoc_type,
t.target_guid as source_me_guid,
o.target_guid as dest_me_guid
from mgmt_targets t,
mgmt_targets o,
mgmt_target_properties tp,
mgmt_target_properties op
where o.target_type = 'oracle_home' and
t.host_name = o.host_name and
tp.target_guid = t.target_guid and
tp.property_name = 'OracleHome' and
op.target_guid = o.target_guid and
op.property_name = 'INSTALL_LOCATION' and
tp.property_value = op.property_value
</query>
<trigger>
<targetType>oracle_home</targetType>
<snapshotType>orcl_tp_config</snapshotType>
<table>GC$TARGET_PROPERTIES</table>
<idColumn>destination</idColumn>
<details>INSTALL_LOCATION</details>
</trigger>
</Rule>
トリガー2
同じルールに対する次のトリガーは、oracle_databaseターゲット・タイプを定義するプラグインに存在します。
<Rule name="...">
<trigger>
<targetType>oracle_database</targetType>
<snapshotType>orcl_tp_config</snapshotType>
<table>GC$TARGET_PROPERTIES</table>
<idColumn>source</idColumn>
<details>OracleHome</details>
</trigger>
</Rule>
トリガー3-n
これはトリガー2と同じですが、OracleHomeプロパティを持つ別のターゲット・タイプのみ持ちます。これらのトリガーは、対応するターゲット・タイプを定義するプラグインとともに存在します。このトリガーは、Oracle_Homeプロパティを持つ別のターゲット・タイプを使用することを除き、トリガー2と同じ特性を持ちます。
exposed_byアソシエーション・タイプを使用して、データベースがリスナーによってアプリケーションに公開されているという事実を表します。このアソシエーションを作成できる1つの方法は、リスナーが構成されるポートに基づきます。
問合せ
ポートが一致する同じマシン上のデータベースとリスナー間のすべてのアソシエーションを返します。どちらのトリガーも、OracleデータベースおよびOracleリスナー・ターゲット・タイプを定義するプラグインのルールとともに存在できます。
<Rule name="...">
<query>
select 'exposed_by' AS assoc_type,
oradb.target_guid AS source_me_guid,
oralsnr_ports.cm_target_guid AS dest_me_guid
from mgmt_targets oradb,
mgmt_target_properties oradbprops1,
mgmt_target_properties oradbprops2,
cm$listener_ports oralsnr_ports
where oradb.target_type = 'oracle_database'
and oradb.target_guid = oradbprops1.target_guid
and oradbprops1.property_name = 'MachineName'
and oradbprops1.property_value = oralsnr_ports.machine_name
and oradbprops1.target_guid = oradbprops2.target_guid
and oradbprops2.property_name = 'Port'
and oradbprops2.property_value = oralsnr_ports.listener_port
</query>
<trigger>
<targetType>oracle_database</targetType>
<snapshotType>orcl_tp_config</snapshotType>
<table>GC$TARGET_PROPERTIES</table>
<idColumn>source</idColumn>
<details>MachineName</details>
</trigger>
<trigger>
<targetType>oracle_listener</targetType>
<snapshotType>listener_config</snapshotType>
<table>CM$LISTENER_PORTS</table>
<idColumn>destination</idColumn>
</trigger>
</Rule>
ME/アソシエーション・モデルを決定し、ルールを記述したら、次のような実装に進みます。
まだ存在しないエンタープライズ構成管理構成データがルールに必要な場合は、新しいエンタープライズ構成管理メトリックを追加するか、既存のメトリックを拡張します。
必要に応じて、新しいエンタープライズ構成管理表または列を追加する必要があります。デフォルトの収集スケジュールで<Schedule OFFSET_TYPE="INCREMENTAL">を指定する必要もあります。そうしないと、構成のロードが遅延し、たとえば新規に検出されたターゲットが30分以上アソシエーションを取得しないことがあります。
アソシエーション・タイプ・フレームワークには、特定のアソシエーション・タイプによって関連付けることのできるターゲット・タイプを指定する許可されたペアの概念があります。それぞれのアソシエーション・タイプに対して許可されたペアとしてリストされていないMEタイプ間にアソシエーションを作成する場合は、必要なペアを追加します。
1つ以上のファイルを作成して、アソシエーション導出ルールを定義します。XSDに準拠していないなどの構文エラーは、Java例外として渡されます。JDeveloperまたは別のツールを使用して、有効なドキュメントを作成したことを確認できます。
次のコマンドを使用してインポートすることにより、ルール・ファイルをテストします。
emctl register oms metadata -sysman_pwd sysman -pluginId <your.plugin.id> -service derivedAssocs -file <fileName>
有効性テストが実行されるため、診断を行うことができます。
ファイルをプラグインにパッケージ化します。
これらは、リポジトリ作成時またはアップグレード時にメタデータ・フレームワークで定義された変換に従ってインポートされるように配置します。プラグインの一部である場合は、次のような場所にファイルを配置します。
<stage_dir/plugin_dist>/oms/metadata/derivedAssoc
指定したすべてのルール・トリガーを調べるケースで導出ルールをテストします。
1つのオプションは、エンタープライズ構成管理構成データのアップロードを開始し、アソシエーションが正しく確立されていることを確認することです。また、ルールをトリガーするPL/SQLプロシージャを直接呼び出すことができます。
DECLARE
temp GC$DERIV_ASSOC_CHANGE_LIST := GC$DERIV_ASSOC_CHANGE_LIST();
BEGIN
GC$ECM_CONFIG.run_assoc_deriv_rule(
p_target_guid => hextoraw('CC70BC294B82E7E9A95DFC257CFA6459'), --
Updated target/ME guid
p_rule_name => '...', -- your rule name
p_column_flag => 'D', -- column flag specifying the
perspective from which to fire the rule. Possible values:
S|D|T|U|V (implying source,destination, derivation target,
derivation target 2, or derivation target 3, respectively)
p_change_list => temp);
COMMIT;
-- examine p_change_list if needed
END;
|
注意: 第11.4項「パフォーマンスの確認」で説明するように、問合せの対応する出力がバインドされた後で、各トリガーの問合せのパフォーマンスをテストします。インポート・ユーティリティを使用して、ルールを変更して再試行します。 |
このリリースでは、ターゲットのホスト名を変更するときに、新しい種類のトリガーがサポートされています。問合せがmgmt_targets表のhost_name列に依存している場合は、トリガーが役立ちます。トリガーは、ターゲットの再配置などにより、host_name列が変更されると起動されます。
トリガー構文には、値H(ホスト変更トリガーを表す)を持つtrigger要素のkind属性を指定します。トリガー・サブ要素は、トリガーによって適用されるターゲット・タイプ、およびルールを評価するためのパースペクティブを特定するidColumnを指定します。idColumnで使用可能な値は、通常のトリガーの値と同じです。
例:
<trigger kind="H"> <targetType>oracle_database</targetType> <idColumn>source</idColumn> </trigger>
これは、oracle_databaseターゲットのhost_name列が変更されるたびに、ルール(トリガーを一部として含んでいる)をソース・パースペクティブから再評価する必要があることを指定しています。
一般に、ホスト変更トリガーには、通常のトリガーと同じルールが適用されますが、その中には適用可能なトリガー・パターンがあります(たとえば、トリガー・パターン4は、問合せによってidColumnに対応する列が戻される場合に、この列がtargetType要素のタイプまたはサブタイプである必要があることを示します)。ファイルおよびプラグインにおけるトリガーのライフサイクルおよび通常のトリガーの配置に関連するルールは、ホスト名変更トリガーにも適用されます。
この機能は、Enterprise Manager 12c PS1プラットフォーム・リリースから使用できます。前に説明したように、ルールは通常、ルール問合せに必要なすべてのターゲットがルールのインストール時までに存在することを必要とするプラグインによって所有されます。ただし、ルール問合せに必要な2つ以上のプラグインが独立しており、プラグインの1つが存在し、他のプラグインが存在しない場合がまれにあります。つまり、両方のプラグインのターゲット・タイプの構成表とデータに依存する特定のルール問合せに対して、1つのプラグインが別のプラグインの前提条件であることは指定できない場合があります。
このような場合は、ルールをいつアクティブにする必要があるかを示すアクティブ化式をルールに指定できます。ルールは依然として(最大で)単一のプラグインによって所有され、ルール問合せは将来ルールの変更または削除を担当する1つのプラグインでのみ指定できます。ただし、必要なすべてのターゲット・タイプがシステムに存在するのでないかぎり、ルールを非アクティブにできます。
構文については、ルールの問合せが指定されているRule要素の属性を使用してアクティブ化式を指定します。
<Rule name="..." activation_expr="..."> ...
通常、activation_expr属性が存在しない場合は、ルールを常にアクティブにする必要があることを意味します。存在する場合、その値は、ルールをアクティブにする必要がある場合にのみtrueを生成する必要のあるBoolean式です。式では、(大文字と小文字を区別しない) "AND"、"OR"およびカッコを使用できます。式のオペランドはターゲット・タイプです。ターゲット・タイプがEnterprise Managerに存在する場合にのみ、ターゲット・タイプの各オカレンスは"true"と評価されます。
いくつかのターゲット・タイプは、Enterprise Managerのインストールでルールがインストールされて存在する場合は常に存在するため、式にリストする必要はありません。これには次のものがあります。
ルールが存在するプラグインとともにインストールされるターゲット・タイプ(ルールを所有するプラグインのターゲット・タイプ)。
ルールを所有しているプラグインが依存する他のプラグイン内のターゲット・タイプ。
常にEnterprise Managerとともにインストールされるターゲット・タイプ(ホストなど)。
したがって多くの場合、アクティブ化式が使用されるときに、次の例1で説明するように単一のターゲット・タイプで十分です。
例1: oracle_ovm
この単純な式は、(このルールのインストール時に存在することがすでにわかっている他のターゲット・タイプに加えて) oracle_ovmターゲット・タイプがインストールされる場合にのみルールがアクティブになる必要があることを意味します。
この種のアクティブ化式は、(たとえば) oracle_ovmおよびoracle_xyzターゲット・タイプの構成表に依存する問合せを持つルールにあると予想できます。これらのターゲット・タイプが異なる独立したプラグインに属すると想定すると、oracle_xyzターゲット・タイプを所有するプラグインにルールが配置されている場合に、そのアクティブ化式はoracle_ovmになります。
例2: oracle_ovm and (oracle_oam_cluster or oracle_oim_cluster)
この式は、oracle_ovmターゲット・タイプが存在し、oracle_oam_clusterまたはoracle_oim_clusterも存在する場合にのみルールがアクティブになる必要があることを意味します。
アクティブ化式はルールのアクティブ化の前のチェックがなくエラーになりやすいため、非常に慎重に例外的に使用する必要があります。たとえば、ターゲット・タイプの入力ミスや論理式エラーがあると、ルールが決してアクティブにならないことや、正しいケースでアクティブ化されないことがあります。Enterprise Managerは、式内の不明なターゲット・タイプが将来インストールされる可能性があると想定するため、ターゲット・タイプの有効性をチェックできません。
次に、アクティブ化式機能が他の導出されたアソシエーション機能と相互作用する方法を説明します。
ルールXMLの新規リリース時に、ルール問合せが変更されておらず、アクティブ化式が変更されている場合、アクティブ化式が更新され、必要に応じてルールがアクティブ化または非アクティブ化されます。ルールがアクティブ化または非アクティブ化されている場合、ルールのアソシエーション・インスタンスはそれぞれ再評価または削除されます。
(たとえばプラグインのインストールまたはアンインストールにより) Enterprise Managerがターゲット・タイプを追加または削除すると、Oracleは関連するアクティブ化式を再評価し、それに従って対応するルールをアクティブ化または非アクティブ化します。
ターゲット・タイプの追加は、対応するターゲットおよびそのアソシエーションまたはデータが追加される前に実行されます。ターゲット・タイプの削除は、ターゲット・インスタンスおよびそのアソシエーションが削除された後に行われます。したがって、影響を受けるルールの対応するアソシエーション・インスタンスは再評価しません。ターゲット・タイプの追加によりルールがアクティブ化されるまで、このようなルールに対してアソシエーションは存在しません。
同様に、ターゲット・タイプを削除したためルールが非アクティブ化された場合は、そのターゲット・タイプのすべてのターゲットが削除されるため、アソシエーションも削除されます。このロジックは、式のターゲット・タイプがソース、宛先または導出ターゲットの1つのターゲット・タイプである場合を含め、すべての既知のケースに適用されます。このため、ターゲット・タイプの追加または削除時にルールの再評価は行われません。
隔離機能とアクティブ化式には違いがあります。隔離機能は、オフにするルール評価を決定するためにエンドユーザーまたは管理者によって制御されます。一方、アクティブ化式は、ルールの作成者および特定のEnterprise Manager設定によって制御されます(たとえば、関連するターゲット・タイプの存在または不在)。
一度もアクティブ化されていないルールは隔離できません。そうでない場合、他のすべての組合せがサポートされます。たとえば、隔離されたルールが非アクティブ化され、アクティブ化式を使用して再びアクティブ化された場合は、隔離されたままになります。
同様に、アクティブなルールが管理者によって隔離され、後でターゲット・タイプの削除が原因で非アクティブになった場合、アクティブ化された場合にアソシエーションの計算が開始されるように、管理者は隔離を解除できます。
ルールが削除されると、ルールのアクティブ化式とそのアクティブ化ステータスは無視されます。つまり、ルールは非アクティブな場合でも削除できます。
次の機能は、Enterprise Manager 12c PS2プラットフォーム・リリースから使用できます。この拡張機能によって、ターゲット・タイプ式の一部として、ターゲット・タイプ・バージョンを指定できます。つまり、アクティブ化式の一部としてoracle_ovmなどのターゲット・タイプをリストできるだけでなく、ターゲット・タイプ指定の後の大カッコ内にバージョン情報を含めることもできます。これが便利なのは、たとえば、ターゲット・タイプ・メタデータの特定のバージョン(MetaVerとも呼びます)を記述する表が定義されている場合です。このような場合、特定のバージョン以上のターゲット・タイプがインストールされているときにのみ、その表に依存するルールがアクティブになるように指定できます。
一般にサポートされているバージョン指定には次の4種類があります。
target_type[version]、たとえば"oracle_ovm[3.7]"
指定したバージョンのターゲット・タイプが存在する場合にのみ、式のこの部分がtrueと示されます。前の例では、oracle_ovmターゲット・タイプのバージョン3.7がインストールされていない場合、他のバージョンのoracle_ovmが存在したとしても、式はfalseと評価されます。
target_type[version1-version2]、たとえば"oracle_ovm[3.7-5.2]"
指定したバージョン範囲(指定した2つのバージョンを含む)に該当するバージョンのターゲット・タイプが存在する場合のみ、式のこの部分がtrueと示されます。したがって前の例では、バージョン3.7、3.8、4.5、5.0または5.2のoracle_ovmターゲット・タイプが存在する場合に、この式がtrueになります。
これに対し、インストールされているoracle_ovmターゲット・タイプのバージョンが、3.7から5.2の範囲に該当しない場合、"oracle_ovm[3.7-5.2]"はfalseと評価されます。
target_type[version-]、たとえば"oracle_ovm[3.7-]"
ターゲット・タイプのバージョンが、指定したバージョン以上の場合にのみ、式のこの部分がtrueと示されます。これは最も一般的に使用されるバリエーションであり、通常は、指定したバージョンが、ルール問合せで使用される表がターゲット・タイプ・コレクションに導入されるバージョンになります。前の例では、バージョン3.7以上のターゲット・タイプoracle_ovmがEnterprise Managerにインストールされている場合のみ、式がtrueと評価されます。
"target_type[-version]、たとえば"oracle_ovm[-5.2]"
ターゲット・タイプのバージョンが、指定したバージョン以下の場合のみ、式のこの部分がtrueと示されます。したがって前の例では、バージョン5.2以下のターゲット・タイプoracle_ovmがEnterprise Managerにインストールされている場合にのみ、式がtrueと評価されます。
|
注意: ターゲット・タイプと左大カッコの間にスペースはありません。バージョン指定は任意です。すべてのバージョンのターゲット・タイプが式のこの部分を満たすことを暗に示す、ターゲット・タイプ指定を使用することができます。 |
例:
"oracle_ovm[3.7-] and (oracle_oam_cluster or oracle_oim_cluster[-2.5] or oracle_oim_cluster[2.8-])"
この式では、ルールがアクティブになるのは、バージョン3.7以上のoracle_ovmターゲット・タイプが存在し、さらに任意のバージョンのoracle_oam_cluster、バージョン2.5以下のoracle_oim_cluster、バージョン2.8以上のoracle_oim_clusterのいずれかが存在する場合であることを示しています。
トリガーの起動に使用する構成収集を開始することでデバッグを開始できます。これらの収集は、ターゲットが最初に使用されるとき、またはトリガーで指定されている表またはビューに含まれる構成データを変更するたびに行われます。管理エージェントを再起動してデータを再収集できます。トリガーが起動されるかどうかを確認する前に、構成表のデータが期待どおりに変更されていることを確認します。
ルール問合せで、開発Enterprise Managerリポジトリに必要なすべてのアソシエーションが生成されることを確認します。
最後に、GC$ECM_CONFIG.RUN_ASSOC_DERIV_RULE PL/SQL APIを手動で実行して、構成変更時にルールを起動した場合と同様に、必要なアソシエーションを手動で作成します。
期待するアソシエーションが作成されない場合は、次のことを行います。
問合せを手動で実行し、正しいターゲットにソースまたは宛先のGUIDをバインドする際、必要なアソシエーションが生成されるようにします。
この項で指定されている関連するエラー表でエラーを確認します。
これで問題が解決しない場合、プロセスが失敗している理由を把握する必要があります。次のいずれかになります。
構成収集が収集されていない
構成収集がトリガーで指定された場所で変更されていない
トリガーの起動でエラーが発生した
起動したトリガーが必要なアソシエーションを生成しない
キューのバックログのため、トリガーの起動アクションが処理されていない
トラブルシューティングのヒント
次のリストに、アソシエーションが作成されない問題調査する方法のヒントを示します。
環境内でルールがアクティブで隔離されていないことを確認します。
select r.rule_name, q.column_flag, r.is_active,
case when q.quarantined_time is null
then 'No' else 'Yes' end as is_quarantined
from mgmt_deriv_rules r, mgmt_deriv_rule_queries q
where r.rule_id = q.rule_id and r.rule_name = your_rule_name;
導出されたアソシエーション関連のエラーが管理リポジトリにあるかどうかを確認します。
select * from mgmt_system_error_log where module_name = 'EM.deriv' order by occur_date desc
関連していないように思われる結果が多すぎる場合、結果を限定するためにオプションで、"and error_msg like '%<your rule name>%'"条件を追加したり、アソシエーションに関連した他のサブストリングを使用したりできます。
たとえば、「ORA-20624: 指定したアソシエーションは制約アソシエーション・タイプと一致しません」を含んだメッセージが表示された場合、これは、このアソシエーション・タイプおよびソース/宛先ターゲット・タイプに許可されているタイプ・ペアがリポジトリに登録されていなかったことを示しています。
問題を再現できる場合は、追加のログをオンにし、次のいずれかを呼び出します。
EMDW_LOG.SET_TRACE_LEVEL('EM.deriv', EMDW_LOG.LINFO); COMMIT;
EMDW_LOG.SET_TRACE_LEVEL('EM.deriv', EMDW_LOG.LDEBUG); COMMIT;
DEBUGは非常に冗長であり、使用される問合せを含みます。
|
注意:
|
ログを表示します。
ログはEMDW_TRACE_DATA表で実行されます。この問合せを使用してログを表示します。
SELECT log_timestamp, TRIM(log_message) FROM emdw_trace_data WHERE module = 'EM.deriv' ORDER BY log_timestamp ASC
|
注意: "log_message like"および"log_message like '%<your rule name>%'"条件などを追加することで、結果を減らすことができます。 |
ログをチェックして、適切なルールがトリガーされていることを確認します。
"Resulting action list:"行に続く、ルールと列フラグS|D|T|U|Vを指定する各アクションの行を探します。
起動する必要があるトリガーおよび必要なアソシエーションを作成する必要があるターゲットを決定します。たとえば、どのトリガーが変更され、最新のものはどれなのかを確認するために、トリガーを起動するスナップショットに関して、MGMT$ECM_CURRENT_SNAPSHOTSビューでsaved_timestampを確認します。
次に、キューのバックログによってトリガーが起動されなかったのかを確認します。これは、実行キューでバックログが発生する可能性の高い大規模なサイトにあてはまります。
再試行アクションの導出されたアソシエーション・キューを確認します。
select * from em_deriv_retry_actions
where is_pending = 'T'
and rule_id = (select rule_id from mgmt_deriv_rules
where rule_name = <'<your rule name>')
and target_guid in (list of hextoraw(<target_guid on both ends of your
missing associations - or just the target you found
should have triggered the evaluation>);
この文が行を返す場合、トリガーの評価はバックログのために保留中のままになります。
ターゲット・プロパティに依存するトリガーがある場合、ターゲット・プロパティ・キューを確認して、指定されたターゲット・プロパティの更新のためにシステムがすべてのフォローアップ・アクションを処理したかどうかを確認します。
select * from EM_TPROPS_PENDING
where target_guid = hextoraw(<target guid of the target with changed
target property>);
この問合せは、トリガーが起動されていないキュー内のすべての未処理のターゲット・プロパティを返します。
ルール問合せをテストします(前述の箇条書きで説明したようにデバッグがオンの場合)。
emdw_trace_data表で、After query:という行の直後で実行されている問合せのバリエーションを探します。:xをHEXTORAW(target guid)で置換して、それを実行してみます。GUIDは、ログの最初の方にあるvvvvvvvvvvv RUN_SNAPSHOT_RULES行に見つかります。
これは、指定したルールとターゲットの収集に基づいて存在する必要のある各アソシエーションの行を返します。そうでない場合は、正しくない問合せを入力したりトリガーに不適切なフラグを指定したりしていないことを確認します。
最後の行でバリエーションを試すことができます。例:
WHERE source_me_guid = :y WHERE dest_me_guid = :y WHERE derivation_target_guid[N] = :y
ルール問合せをログに記録すると、ログは変更する必要のあるMGMT_ASSOC_INST_ORIGINS表の行に続いてMGMT_ASSOC_INSTANCESの実際のアソシエーション行を反映します。
アソシエーション・インスタンスがMGMT_ASSOC_INST_ORIGINSに存在することを確認します。
その場合は、DERIVATION_RULE_ID列にリストされている導出されたアソシエーション・ルールがそのアソシエーションの存在を正常にアサートしました。何かがアソシエーションの作成を妨げています。アソシエーション・タイプが正しく、許可されるタイプのペアがアソシエーション・フレームワークに登録されていますか。例外がスローされましたか。
提供するルールは、定義するトリガーおよび対応する構成表の変更頻度に応じて頻繁に起動されることがあります。頻繁にトリガーされるルールのパフォーマンスが低いと、OMS全体の操作に悪影響を及ぼすことがあります。
ルール問合せは、より特定的な問合せにマップされます。実行される問合せは、トリガーの列フラグ(source、destination、またはderivationTarget[N]列)によって決まります。前述のように、ルール問合せ<Q>は次の形式の問合せにマップされます。
SELECT a.*, FROM (<Q>) a WHERE <FC> = ?
パラメータは、エンタープライズ構成管理収集がトリガーを起動したターゲットのGUIDで、<FC>はトリガーで指定された問合せのsource/destination/derivationTarget[N]列です。
見てわかるように、全体の問合せ(<Q>)は、返されるターゲットGUIDの1つに基づいてフィルタされます。これは、問合せ計画が一般にそのターゲットのデータから開始し、そこから結合を実行することを意味します。問合せ計画は、<FC> = ?条件を完全にプッシュし、この条件を使用して評価を開始する必要があります。通常、問合せ計画は、最も深いレベルで前述のバインディングを実行し、索引付けされた検索から始まる残りのデータのところに移動する数多くのネストされたループを含んでいます。一般に、潜在的に大きいデータ表(つまり、ハッシュ結合)の全表スキャンはありません。
第11.3.7.3項「リスナーとデータベース」の例を考えてみます。最初のトリガーが起動すると、問合せはデータベース・ターゲットをバインドし、関連付けられているリスナー・ターゲットを探します。Enterprise Managerリポジトリがアソシエーション(たとえば、リスナー・ターゲット)の相手側を検索できる唯一の方法は、machine_name列とlistener_port列上のcm$listener_ports oralsnr_ports結合を介したものです。ビューcm$listener_portsの下の表が大きくなることがある場合、ルールの作成者は、表の全表スキャンを実行するかわりに迅速にリスナー・ターゲットを突き止めるために、これらの2つの列から始まる索引を用意する必要があります。
各トリガーについて、サポート索引が存在することを確認し、前述のように問合せでそれらを囲んだ後で問合せのパフォーマンスをテストする必要があります。ただし、たとえばsource列フラグのトリガーが複数ある場合、生成される問合せは両方の問合せで同じであるため、パフォーマンスを1回のみテストすれば十分です。
カスタム構成仕様(CCS)に精通していない場合は、この注意事項をスキップしてください。CCS表は様々なデータを収容できるように汎用的であるため、問合せのパフォーマンスがよくない傾向があります。一方、適切にモデル化されたECM表は、収集されるデータに固有であり、導出されたアソシエーション計算コードなどのクリティカルなコード・パスに対して適切に実行できます。したがって、導出されたアソシエーション・ルールにはCCSで収集されたデータを使用しない必要があります。かわりに、導出されたアソシエーションに必要なデータは、標準のECM収集を使用して個別に収集します。
複数のルールで同じアソシエーションを導出できますが、通常はこのようなオーバーラップ・ルールの作成を回避する必要があります。ここでは、アソシエーションが複数のルールによって導出された場合に何が起きるかについて説明し、これを回避するタイミングと方法に関する提案を示します。
複数のルールが同じアソシエーションを導出する場合、そのアソシエーションは各ルールによって導出されなくなるまで存在し続けます。
これが目的の動作である場合があります。たとえば、2つのアプリケーション・ターゲット・タイプそれぞれが、実行されるOracle WebLogic Serverとアクセスするデータベースの両方を認識しているとします。この認識に基づいて、それぞれにOracle WebLogic Serverとデータベース間のアソシエーションを導出する方法があります。どちらかのルールがアソシエーションを導出すると、そのアソシエーションが現実に存在します。両方のルールがアソシエーションを導出しなくなった場合にのみ、アソシエーションが存在しなくなったことが保証されます。
"ルールによって導出される場合に存在"セマンティクスは、意図したものでないことがあります。データベースとOracleホーム間のinstalled_onアソシエーションに対して定義できる2つのルールについて考えます。どちらも同じデータにアクセスしますが、一方はOracleホームに対するプロパティ変更によってトリガーされ、もう一方はデータベースに対する変更によってトリガーされます。どちらかのルールによって関係がなくなったと判断されたらすぐに、アソシエーションを削除する必要があります。このような場合は、2つのトリガーがある単一のルールを使用する必要があります。
このような場合に1つのルールのみ作成するように注意しなかったとします。この誤りは重大ではなく、結局のところアソシエーションはすぐに削除されると考える可能性があります。しかしそうではなく、不要なアソシエーションが無限に存在する可能性があります。前述の例で、アソシエーションが2つのルールを使用して導出され、データベースがアップグレードされ、そのOracleHomeプロパティが変更されたとします。古いホームとのアソシエーションは削除される必要がありますが、もう一方のルールが起動されるまで削除は行われません。ただし、Oracleホーム・ターゲットについては何も変更されていないため、そのルールはトリガーされず、アソシエーションが残ります。実際に、1つのターゲットのみ変更され、他のターゲットは長期にわたって変更されないことがよくあります。
経験則として、特定の表セットのデータに基づくアソシエーションは、複数のトリガーを持つ単一のルールを使用して導出する必要があります。
アソシエーションをアサートする別の理由が存在しないかぎり、1つのルールのみ使用する必要があります。このような場合、導出ルールによって返されるアソシエーションを分解する必要があります。これを記述する別の方法は、これらのアソシエーションに対して、すべてのルール問合せで返されるすべての行のセットで重複を指定しないことです。アソシエーションは、ソース、宛先およびアソシエーション・タイプで識別されます。このため、この3つの値の組合せは一意である必要があります。
コンポジット・ターゲットまたはシステム・ターゲットの作成時に考慮する必要のあるアソシエーションのタイプがいくつかあり、これらのアソシエーションをEnterprise Managerに追加する方法がいくつかあります。次に、これらの各タイプのアソシエーション、Enterprise Managerフレームワークでそれらを使用する方法、およびそれらを作成する典型的なアプローチについて説明します。
最初の重要なアソシエーション・タイプは"contains"アソシエーションです。このアソシエーション・タイプは、通常、コンポジット・ターゲットとその各メンバーの間に追加されます。コンポジット・ターゲットのターゲット・ナビゲータ(ツリー)を移入するには、このアソシエーションが存在する必要があります。コンポジットのメンバーである("contains"アソシエーションを通じて関連付けられた)ターゲットのセットは、TargetクラスのgetCompositeMembers()メソッドを使用して取得できます。
これらの包含アソシエーションは、検出時に、完全に自動化されたアプローチを使用するかガイドされた検出プロセスを通じて作成されることが最も多くなります。どちらの場合も、プラグインで提供される検出スクリプトを使用して、コンポジットとそのメンバー間の包含アソシエーションのセットを識別します。その他の非包含アソシエーションも検出されることがありますが、これらはコンポジットのメンバーシップに影響せず、ターゲット・ナビゲータのコンテンツにも影響しません。
コンポジット・ターゲットもシステムとして扱われる場合は、システム・ステンシルに、この方法で作成された包含アソシエーションのタイプを表すルール・パスを含めることを強くお薦めします。これにより、ターゲット・ナビゲータとシステム・メンバーシップにメンバー・ターゲットが一貫して表示されます。
包含アソシエーションの検出に加えて、コンポジット・トポロジのメンバー間の他のアソシエーション・タイプを表すことが必要な場合があります。これらのアソシエーションは、ターゲット管理者にとってのみ意味があり、他の操作を実行するためにプラグイン・コードで使用されることがあります。
これらのアソシエーションは、通常は検出スクリプトを使用して、完全に自動化されたアプローチの一部として、またはガイドされた検出プロセスを通じて作成されます。
システム・メンバーシップは、システム・ステンシルに基づくEnterprise Managerフレームワークによって構築されます。このステンシルは、システム・メンバーの識別時に考慮する必要のあるネイティブ・アソシエーションのセットを定義します。これらのネイティブ・アソシエーションは、通常は包含またはその他の非コンポジット・アソシエーションです。
システム・ステンシルの評価中にこれらのアソシエーションが見つかった場合、宛先ターゲットはシステム・メンバーとして追加されます。
これまでに説明したすべてのアソシエーションは、同じプラグインの一部であると想定されるターゲット間のアソシエーションであるため、検出およびUIを含むプラグイン・コードには、これらのターゲットの構成とトポロジに関する詳細で直接的な知識があります。
一方、ターゲット構成に、アプリケーションまたはターゲットのバッキング・ストアとして使用されるOracleデータベースなど、プラグインに含まれない他のターゲットへのアソシエーションが含まれる場合があります。ターゲットの構成には、使用するデータベースに関する情報(おそらく、host-port-sidやhost-serviceなど、接続関連の詳細)があります。
Enterprise Managerがデータベースを管理する場合に、エンドユーザーがこの関係を参照して探索し、そのデータベースに関する他の情報を取得して管理できるように(適切かつ許可される場合)、ターゲットとEnterprise Managerのデータベース間のこのアソシエーションを表す必要があります。
Enterprise Managerがデータベースを管理しているかどうかはわからず、持っている識別情報はEnterprise Managerデータベース・ターゲット名ではなく接続情報であるため、ターゲットの構成内の接続情報をEnterprise Managerのデータベースの接続情報にマップする導出ルールを作成できます。
ターゲットとアソシエーションの作成および削除は様々なソース(自動化された検出、ガイドされた検出、導出されたアソシエーション・ルール、システム・ステンシル・ルールなど)から開始できるため、Enterprise Managerのコンポジット・エンティティがそのエンティティの現実と同期していないように見えることがあります。プラグイン開発者として、これを認識し、エンドユーザーに提示する情報で可能なかぎりそれを考慮することが重要です。
発生する可能性のある典型的な状況の1つは、ターゲットの検出が行われること、構成情報が収集されること、およびこれに続いて導出ルールとしてのアソシエーションの変更がEnterprise Managerアソシエーション・フレームワークによって処理されることです。このシナリオでは、ユーザーは最初に、検出時に追加されたアソシエーションを含むエンティティのトポロジを参照します。ただし、導出ルールによって作成された追加のアソシエーションは、後になるまで表示されません。
ここでは、最もよくある3つの質問に回答します。
ほとんどの場合、問合せはCM$ビューを使用して構成(エンタープライズ構成管理)表のみ参照し、トリガーもこれを参照します。参照できるオブジェクトの完全なリストは、第11.3.1項「アソシエーション導出ルールの構文とセマンティクスの使用」を参照してください。他の表も参照する場合、およびデータがエンタープライズ構成管理表の変更に関係なく変更される可能性がある場合は、必要に応じてアソシエーションを更新できないことがあります。表に対する変更がルール評価をトリガーする必要のある、エンタープライズ構成管理表以外の表が参照されるユースケースがある場合は、オラクル社の担当者に連絡してください。表が配置されるコンポーネントも考慮する必要があります。ルールで参照される表がEnterprise ManagerコアEDKの一部でない場合、プラグインではその表のプラグインに対する依存関係を考慮する必要があります。たとえば、プラグイン依存性メカニズムを使用して、参照するオブジェクトがリポジトリにすでに存在することを確認する必要があります。
ターゲット・プロパティは構成データとして扱われ、各ターゲット・タイプに移入されるエンタープライズ構成管理スナップショット表があります。この表のデータを使用する際には注意する必要があります。
多くのターゲット・プロパティは検出時に設定され、決して変更されません。
名前/値のペア・データの問合せは扱いにくい場合があり、データがより構造化されている他の表の問合せより時間がかかることがあります。
ターゲット・プロパティ表とエンタープライズ構成管理スナップショット表の両方のデータを使用可能な場合は、後者を使用する必要があります。
構成データのコレクションを追加する必要がある場合は、ターゲット・プロパティ表の新しい行としてではなく、エンタープライズ構成管理表でそれを行う必要があります。
一般に、ターゲット・プロパティの使用は避ける必要があり、データは標準のECMメカニズムを使用して収集およびモデル化する必要があります。
ただし、たとえば追加できるエンタープライズ構成管理コレクションがターゲットにない場合は、ルールでターゲットのプロパティを参照することが必要な場合があります。このようなターゲットへのアソシエーションを作成する場合は、それを識別する方法が必要です(たとえば、ルールはそのターゲット・プロパティを参照する必要があります)。
ターゲット・プロパティを使用する必要がある場合は、ルール問合せでMGMT_TARGET_PROPERTIESを参照する必要があります。ビューが必要な結合をすでに実行している場合は、ルール問合せでMGMT$TARGET_PROPERTIESを参照することもできます。ただし、トリガーでは、orcl_tp_configスナップショット・タイプにGC$TARGET_PROPERTIESビューを使用する必要があります。
MGMT_TARGET_PROPERTIESの方が効率的であるため問合せではこれを使用する必要がありますが、GC$ビューで使用可能でないプロパティがいくつか含まれることがあります。トリガーは、GC$ビューのプロパティ変更に基づいてのみ使用できます。たとえば、GC$ビューには、Enterprise Managerに適切に登録されているプロパティのみ含まれます。
これは、オーバーラップ・アソシエーションの別の例です(詳細は、第11.5項「オーバーラップ・アソシエーションの使用」を参照)。たとえば、ターゲットT1とT2の間のアソシエーションを検出する検出ロジックと、同じアソシエーションを導出するルールがある場合があります。同じアソシエーションを作成するために2つのロジック・セットを作成しないことをお薦めします。この場合は、次のことが推奨されます。
アソシエーションが変更される可能性があるため導出ルールが必要な場合は、導出ルールのみ作成する必要があります。
検出されたアソシエーションが、ソースまたは宛先が削除されるまで変更されない場合、アソシエーションの検出は適切であり、より単純または効率的な場合があります。
2つのロジック・セットを作成して同じアソシエーションを作成する場合は(検出ロジックと導出ルール)、検出されたアソシエーションが残り、導出ロジックはそのアソシエーションの存在もアサートします。後でルール評価でアソシエーションが存在しなくなったと判断された場合、ルールのアサーションは削除されますが、アソシエーションは検出されたアソシエーションを手動で削除するまで存在し続けます。
