ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド
11g リリース1(11.1.1)
B63036-01
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

10 エンタープライズ・デプロイメントの管理

この章では、トポロジの設定後に実行できる操作について説明します。実行できる操作には、エンタープライズ・デプロイメントの監視、スケーリング、バックアップなどがあります。

この章の内容は次のとおりです。

10.1 Oracle Business Intelligenceの起動と停止

Oracle Business Intelligenceを起動するには、常に管理対象サーバー、システム・コンポーネントの順に起動する必要があります。また、管理対象サーバーを再起動したときは、システム・コンポーネントも再起動する必要があります。

詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceの起動と停止に関する項を参照してください。

この項の内容は次のとおりです。

10.1.1 Oracle Business Intelligence管理対象サーバーの起動と停止

次の手順に従って、Oracle Business Intelligence管理対象サーバーを停止、起動または再起動します。

  1. Oracle WebLogic Server管理コンソールにログインします。

  2. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

  3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

  4. 管理するOracle Business Intelligence管理対象サーバーを選択します(たとえば、bi_server1、bi_server2など)。

  5. 次のいずれかの処理を実行します。

    • 管理対象サーバーを停止するには、「停止」をクリックします。

    • 管理対象サーバーを起動するには、「起動」をクリックします。

    • 管理対象サーバーを再起動するには、まず「停止」をクリックし、サーバーが完全に停止するまで待機します。サーバーが完全に停止したら、管理対象サーバーをもう一度選択し、「起動」をクリックします。

10.1.2 Oracle Business Intelligenceシステム・コンポーネントの起動と停止

次の手順に従って、Oracle Business Intelligenceシステム・コンポーネントを停止、起動または再起動します。

  1. Oracle Enterprise Manager Fusion Middleware Controlにログインします。

  2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

  3. 「coreapplication」をクリックします。

  4. 「Business Intelligence概要」ページで、「停止」、「起動」または「再起動」をクリックします。

10.2 エンタープライズ・デプロイメントの監視

Oracle Business Intelligenceトポロジの監視の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のサービス・レベルの監視に関する項を参照してください。

また、ログのローテーションおよび管理など、Oracle Business Intelligenceのログ・ファイルの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceでの問題の診断と解決に関する項を参照してください。

10.3 エンタープライズ・デプロイメントのスケーリング

Oracle Business Intelligenceエンタープライズ・トポロジを、次のようにスケール・アップまたはスケール・アウトできます。

この項の内容は、次のとおりです。


注意:

I/PMによって使用されているSOAサブシステムをスケール・アウトおよびスケール・アップするには、SOAエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。

10.3.1 Oracle Business Intelligenceトポロジのスケール・アップ

この手順では、ノードが2つあり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがあるエンタープライズ・トポロジを前提にします。トポロジをスケール・アップするには、いずれかの既存ノードで実行されているシステム・コンポーネントの数を増やします。

特定のノードで複数の管理対象サーバーを実行する必要はありません。

Oracle Business Intelligenceエンタープライズ・トポロジをスケール・アップする手順は次のとおりです。

  1. Fusion Middleware Controlにログインします。

  2. 「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。

  3. 「coreapplication」をクリックします。

  4. 「容量管理」をクリックしてから、「スケーラビリティ」をクリックします。

  5. 「構成をロックして編集」をクリックします。

  6. 矢印キーを使用して、「BIサーバー」、「Presentation Server」または「JavaHost」の数を変更します。

  7. 「適用」をクリックしてから、「変更のアクティブ化」をクリックします。

  8. 「概要」をクリックしてから、「再起動」をクリックします。

10.3.2 Oracle Business Intelligenceトポロジのスケール・アウト

トポロジをスケール・アウトする場合、トポロジの新しいノード(APPHOST3)に新しい管理対象サーバーとシステム・コンポーネント・セットを追加します。この手順では、ノードが2つあり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがあるエンタープライズ・トポロジを前提にします。

前提条件

この項の手順を実行する前に、次の要件が満たされていることを確認してください。

  • Oracle Business Intelligenceの管理対象サーバーが稼働している既存ノードがトポロジ内に存在していること。

  • 新しいノード(APPHOST3)が、Oracle WebLogic ServerとOracle Business Intelligence用の既存のホーム・ディレクトリにアクセスできます。

  • ORACLE_HOMEまたはWL_HOMEが、異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して共有記憶域内のインストールを「追加」する場合は、ORACLE_HOME/oui/bin/attachHome.shを使用します。WL_HOMEを追加または削除してMiddlewareホーム・リストを更新する場合は、MW_HOME/.homeファイルを編集します。詳細は、第10.3.2.1項「Oracle Business Intelligenceのスケール・アウト手順」を参照してください。

  • 新しいノードから共有記憶域のすべてのディレクトリにアクセス可能であることを保証する必要があります。第2.3.2項「異なるディレクトリの推奨場所」で一覧表示されているすべての共有ディレクトリ(スケール・アウトされた管理対象サーバーのORACLE_INSTANCEディレクトリとドメイン・ディレクトリを除く)に、すべてのノードからアクセスできることを確認します。

    また、ホスト名検証証明書が保持されているアイデンティティ・キーストアとトラスト・キーストアに共有記憶域を使用している場合、共有記憶域ディレクトリがスケール・アウトされたノード(APPHOST3)からアクセスできることを確認します。それらのキーストアにローカル・ディレクトリを使用している場合、第7.3項「ノード・マネージャのホスト名検証証明書の有効化」の手順に従って、スケール・アウトされたノードにローカルのアイデンティティ・キーストアを作成および構成します。

    たとえば、次の各ディレクトリをマウントします。

    • トランザクション・ログ・ディレクトリ

    • JMS永続ストア

    • グローバル・キャッシュ

    • BI Presentation Catalog

    • BIリポジトリの公開ディレクトリ

    • BI Publisherカタログ

    • BI Publisher構成キーストア(certs)

    • MW_HOME

10.3.2.1 Oracle Business Intelligenceのスケール・アウト手順

APPHOST3でOracle Business Intelligenceをスケール・アウトするには、次の手順を実行します。

  1. APPHOST3で、Oracle Business Intelligenceのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

  2. 共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。

    APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/
APPHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_<version>

    Middlewareホーム・リストを更新するには、MW_HOME/.homeファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。

  3. 第6.1項「APPHOST2でのBIシステムのスケール・アウト」の手順に従って、いずれかの共有Oracleホームから構成アシスタントを実行します。

  4. 第6.2項「システム・コンポーネントのスケール・アウト」の手順に従って、APPHOST3でシステム・コンポーネントをスケール・アウトします。

  5. 第6.4項「bi_server2管理対象サーバーの構成」の手順に従って、リスニング・アドレスの設定およびホスト名検証の無効化を行い、bi_server3管理対象サーバーを構成します。

  6. 第6.5.3.5項「Oracle BI Publisher用のJMSの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。

  7. 第6.5.4項「Oracle BI for Microsoft Officeの追加の構成タスク」の説明に従って、APPHOST3でOracle BI for Microsoft Officeを構成します。

  8. 第6.6項「トランザクション・リカバリ用デフォルト永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。

  9. 第5.10.2項「bi_servern管理対象サーバー用のOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1に対してOracle HTTP Serverを構成します。

  10. APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第10.1項「Oracle Business Intelligenceの起動と停止」を参照してください。

  11. 以降の説明に従って、新しいノードのサーバー移行を設定します。

  12. 構成を検証するには、次のURLにアクセスします。

    • http://APPHOST3VHN1:9704/analyticsにアクセスして、bi_server3のステータスを確認します。

    • http://APPHOST3VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。

      注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。

    • http://APPHOST3VHN1:9704/xmlpserverにアクセスして、Oracle BI Publisherアプリケーションのステータスを確認します。

    • http://APPHOST3VHN1:9704/uiにアクセスして、Oracle Real-Time Decisionsアプリケーションのステータスを確認します。

  13. ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第7章「ノード・マネージャの設定」を参照してください。

10.4 バックアップとリカバリの実行

Oracle Business Intelligenceのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Business Intelligenceのバックアップおよびリカバリに関する推奨事項に関する項を参照してください。

10.5 エンタープライズ・デプロイメントのパッチ適用

Oracle Business Intelligenceのパッチ適用の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceシステムのパッチ適用に関する項を参照してください。

10.6 トラブルシューティング

この項の内容は次のとおりです。

10.6.1 BIアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する

問題: ロード・バランサ・アドレスを使用して、Oracle Business Intelligenceアプリケーション(Oracle BI Presentation Services、Oracle BI Publisher、Oracle Real-Time Decisionsなど)にアクセスしようとすると、Webブラウザで「ページが見つかりません」という404エラー・メッセージが表示されます。このエラーは断続的に表示され、管理コンソールでは、BI Serverが「実行中」と表示されます。

解決方法: BI管理対象サーバーが実行中であっても、そのサーバー内のアプリケーションの状態が「アクティブ」ではなく、「管理」や「準備完了」である場合があります。BI Serverが実行中でも、アプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、影響を受けるアプリケーションの状態を調べてください。状態は「アクティブ」になっている必要があります。BI Serverの出力ログにそのアプリケーションに関するエラーがないことを確認し、管理コンソールの「デプロイメント」ページでアプリケーションを起動してください。

10.6.2 手動フェイルオーバー後に管理サーバーの起動に失敗する

問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。

<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/edg_domain/aserver/edg_domain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

解決方法: ノードの障害発生後にノードを復旧させるときに、ドメイン・ディレクトリに共有記憶域が使用されている場合、ロック・クリーンアップの失敗が原因で、管理サーバーのログにこのエラーが記録されることがあります。このエラーを解決するには、ファイルORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lokを削除します。

10.6.3 管理コンソールで変更をアクティブ化するときにエラーが発生する

問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。

An error occurred during activation of changes, please see the log for details.
 [Management:141190]The commit phase of the configuration update failed with an exception:
In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean

解決方法: これは、管理コンソールでサーバーの起動パラメータが変更された場合に発生する可能性があります。この場合、管理コンソールで、構成を変更した特定のサーバーのサーバー起動構成でユーザー名/パスワード情報を指定します。

10.6.4 サーバー移行後にbi_server管理対象サーバーがフェイルオーバーしない

問題: ローカルのノード・マネージャによる再起動試行回数が最大数に達した後で、フェイルオーバー・ノードのノード・マネージャが再起動を試行しますが、サーバーは起動しません。ノード・マネージャの出力情報には、サーバーがフェイルオーバーしたことが報告されます。ノード・マネージャがbi_server管理対象サーバーの移行を試行した後でも、このサーバーが使用するVIPがフェイルオーバー・ノード内で有効化されていません(フェイルオーバー・ノードでifconfigを実行しても、どのインタフェースのVIPも報告されない)。コマンド「sudo ifconfig $INTERFACE $ADDRESS $NETMASK」を実行しても、そのIPはフェイルオーバー・ノード内で有効化されません。

解決方法: sudo実行時にパスワード入力を要求するような権限と構成を設定しないでください。パスワード入力を要求しなくてもsudoが動作するようにsudoが構成されていることを、システム管理者に確認してください。

10.6.5 サーバー移行後にbi_server管理対象サーバーにブラウザからアクセスできない

問題: サーバー移行は正常に実行されますが(bi_server管理対象サーバーがフェイルオーバー・ノード内で再起動される)、Virtual_Hostname:9704/analytics URLにWebブラウザからアクセスできません。元のホストではすでにサーバーが強制終了(kill)されており、フェイルオーバー・ノードのノード・マネージャでは、VIPが移行済でサーバーが起動していることが報告されます。bi_server管理対象サーバーが使用するVIPに対して、クライアントのノード(ブラウザが使用されているノード)からpingを実行しても応答がありません。

解決方法: ARPキャッシュを更新するためにarpingコマンドがノード・マネージャによって実行されましたが、この更新が適切にブロードキャストされませんでした。この場合、そのノードが外部ノードからは到達不能になります。nodemanager.propertiesファイルを更新してMACBroadcastを追加するか、次のように手動でarpingを実行してください。

/sbin/arping -b -q -c 3 -A -I INTERFACE ADDRESS > $NullDevice 2>&1

ここで、INTERFACEは、仮想IPが有効化されているネットワーク・インタフェース、ADDRESSは仮想IPアドレスです。

10.6.6 OAM構成ツール実行時にURLが削除されない

問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しましたが、そのURLの1つに誤記がありました。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。

解決方法: 同じapp_domain名を指定してOAM構成ツールを実行すると、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログオンして、「ポリシー・ドメイン」をクリックし、作成済のポリシー・ドメイン(bifoundation_domain)をクリックします。「リソース」タブをクリックして、誤ったURLを削除します。

10.6.7 変更をアクティブ化した後でユーザーがログイン画面にリダイレクトされる

問題: 管理コンソールにアクセスするためにOracle HTTP ServerおよびLBRを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。

解決方法: これは、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、コンソールがその変更を反映しようとすると発生します。変更内容によっては、コンソールが管理サーバーのリスニング・アドレスにリダイレクトされることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをadmin.mycompany.com/console/console.portalに変更すれば、管理コンソールのホーム・ページに直接アクセスできます。


注意:

この項で説明されている変更の追跡を無効にしてある場合は、この問題は発生しません。

10.6.8 変更をアクティブ化した後でユーザーがホーム・ページにリダイレクトされる

問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻らない)。

解決方法: これは、OAM SSOが構成され、管理コンソールが構成の変更を反映するように設定されている場合に発生することが予想されます(リダイレクトはなんらかの変更をアクティブ化する際に管理コンソールによって実行されます)。このリダイレクトにかかわらず、アクティブ化は完了します。連続して変更を行ってもリダイレクトされないようにするには、管理コンソールにアクセスして、「プリファレンス」→「共有プリファレンス」を選択し、「構成変更の追跡」チェック・ボックスの選択を解除します。

10.6.9 構成されたJOCポートがすでに使用中

問題: Javaオブジェクト・キャッシュ(OWSM管理対象サーバーなど)を使用している管理対象サーバーの起動に失敗します。次のエラーがログに表示されます。

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

解決方法: JOCが取得しようとしているポートを別のプロセスが使用しています。そのプロセスを停止するか、このクラスタのJOCを再構成して、推奨されるポート範囲内で別のポートを使用するようにします。

10.6.10 管理対象サーバーのメモリー不足の問題

問題: 管理対象サーバーでメモリー不足が発生します。

解決方法: Java VMに割り当てられているメモリー・ヒープのサイズを少なくとも1GBに増やします。

  1. 管理コンソールにログインします。

  2. 「環境」をクリックし、「サーバー」をクリックします。

  3. 管理対象サーバー名をクリックします。

  4. 「構成」タブを開きます。

  5. 2列目にある「サーバーの起動」タブを開きます。

  6. 「引数」ボックスでメモリー・パラメータを追加します。例:

    -Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m

    注意:

    メモリー・パラメータ要件は、各種のJVM(Sun、JRockitなど)ごとに異なる可能性があります。

  7. 構成の変更を保存します。

  8. 実行されているすべての管理対象サーバーを再起動します。

10.6.11 Oracle BI Publisherの「スケジューラ診断」ページでJMSインスタンスが欠落している

Oracle BI Publisherの「スケジューラ診断」ページに、クラスタ内のすべてのインスタンスではなく、1つのJMSインスタンスのみが表示される場合があります。この問題はおそらくクロックが同期していないことが原因です。クラスタ内のすべてのノードでクロックを同期させることの重要性の詳細は、第2.4項「クロックの同期」を参照してください。

10.6.12 管理対象サーバーの停止後にOracle BI Publisherのジョブが不整合な状態になる

Oracle BI Publisherが実行されている管理対象サーバーを停止する前に、実行中のすべてのOracle BI Publisherジョブの完了を待機するか、または「レポート・ジョブ履歴」ページを使用して未完了のジョブを取り消すことがベスト・プラクティスです(必須ではありません)。それ以外の場合は、停止により一部のジョブが誤って実行状態のまま残る可能性があります。

10.6.13 Oracle BI PublisherクラスタでJMSインスタンスが失敗する

まれにOracle BI Publisher SchedulerクラスタでJMSインスタンスが欠落していることがあります。この問題を解決するには、Oracle WebLogic Server管理コンソールからOracle BI Publisherアプリケーションを再起動します。

BI Publisherアプリケーションを再起動するには:

  1. 管理コンソールにログインします。

  2. 「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。

  3. 「bipublisher(11.1.1)」を選択します。

  4. 「停止」をクリックします。

  5. アプリケーションが停止したら、「開始」をクリックします。

10.7 他の推奨事項

この項の内容は次のとおりです。

10.7.1 SQLNet接続のタイムアウト防止

EDG本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters(RAC)の場合、データベース接続はOracle RACのVIPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのように構成できない場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルの*SQLNET.EXPIRE_TIME=n*パラメータを設定してください。nは分単位の数値です。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。

10.7.2 監査

Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middleware 11gで追加された新しいサービスです。これは、ミドルウェア製品ファミリの集中監査フレームワークです。このフレームワークでは、Oracle Platform Security Services(OPSS)やOracle Web Servicesなどのプラットフォーム・コンポーネントに対して監査サービスが提供されます。また、Oracle固有のJavaEEコンポーネントをはじめ、様々なJavaEEアプリケーションのフレームワークとしても機能します。また、このようなJavaEEアプリケーションで、アプリケーション固有の監査イベントを作成できます。ミドルウェアのOracleコンポーネントのうちJavaEE以外のもの、たとえばCやJavaSEのコンポーネントについても、JavaEEアプリケーションと同様、エンドツーエンドのフレームワーク構造を実現します。

図10-1は、Oracle Fusion Middleware監査フレームワーク・アーキテクチャの概要図です。

図10-1 監査イベント・フロー

図10-1の説明が続きます
「図10-1 監査イベント・フロー」の説明

Oracle Fusion Middleware監査フレームワークを構成する主なコンポーネントは次のとおりです。

  • 監査API: このAPIは、Oracle Fusion Middleware監査フレームワークと統合される監査対応の任意のコンポーネントのために、監査フレームワークによって提供されます。アプリケーションは実行時、これらのAPIを適宜コールして、アプリケーション・コード内で発生する特定のイベントに関して必要な情報を監査する場合もあります。アプリケーションはこのインタフェースにより、監視対象イベントのコンテキストの提供に必要な、ユーザー名やその他属性などのイベント詳細を指定できます。

  • 監査のイベントと構成:Oracle Fusion Middleware監査フレームワークでは、アプリケーションの監査イベントに簡単にマッピングできる一連の汎用イベントが提供されます。それらの汎用イベントには、認証などの共通のイベントも含まれています。また、アプリケーションはこのフレームワークにより、アプリケーションに固有なイベントを定義することもできます。

    このイベント定義および構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成の更新は、Enterprise Manager(UI)およびWLST(コマンドライン・ツール)から実行できます。

  • 監査バスストップ: バスストップとは、監査リポジトリにプッシュされる前の監査データが格納されるローカル・ファイルです。データベース・リポジトリが1つも構成されていない場合は、このバスストップ・ファイルをファイルベースの監査リポジトリとして使用できます。バスストップ・ファイルは単純なテキスト・ファイルであり、特定の監査イベントの検索も簡単に実行できます。データベース・リポジトリがある場合、バスストップはコンポーネントと監査リポジトリの間の中間ファイルになります。ローカル・ファイルは、構成したアップロード間隔に基づいて、定期的に監査リポジトリにアップロードされます。

  • 監査ローダー: その名のとおり、監査ローダーの機能は、監査バスストップのファイルを監査リポジトリにロードすることです。プラットフォームおよびJavaEEアプリケーションの監査の場合、JavaEEコンテナ起動時に監査ローダーも起動されます。システム・コンポーネントの場合、監査ローダーは定期的に生成されるプロセスになります。

  • 監査リポジトリ: 監査リポジトリに格納されるのは、事前定義されたOracle Fusion Middleware監査フレームワークのスキーマです。これは、リポジトリ作成ユーティリティ(RCU)によって作成されます。構成が完了すると、すべての監査ローダーがリポジトリを認識し、そのリポジトリに定期的にデータをアップロードするようになります。監査データは監査リポジトリ内に蓄積されるため、時間とともに増加します。監査リポジトリには、他のアプリケーションが使用している運用データベースではなく、監査専用のスタンドアロンのRDBMSを使用するのが理想的です。高可用性構成の場合は、Oracle Real Application Clusters(RAC)データベースを監査データ・ストアとして使用することをお薦めします。

  • Oracle Business Intelligence Publisher: 監査リポジトリ内のデータは、Oracle Business Intelligence Publisherの事前定義済レポートとして公開されます。このレポートでは、監査データを様々な条件に基づいてドリルダウンできます。例:

    • ユーザー名

    • 時間範囲

    • アプリケーション・タイプ

    • 実行コンテキストID(ECID)

Oracle Fusion Middleware監査フレームワークのその他の概要は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle Fusion Middleware監査フレームワークの概要」の章を参照してください。

Oracle Fusion Middleware監査フレームワークのリポジトリの構成方法の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成と管理」の章を参照してください。

EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成は含まれません。バスストップ・ファイルへの監査データの出力、および監査ローダーの構成は、製品をインストールした後に実行できるようになります。最大の懸念事項は、監査データが格納される監査データベース・リポジトリです。監査データはサイズが大きく、過去のデータが蓄積されていくため、他のミドルウェア・コンポーネントの運用ストアとは別に、専用のデータベースを用意することを強くお薦めします。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引