| Oracle® Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド 11gリリース1（11.1.1） B55900-02 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド 11gリリース1（11.1.1） B55900-02 |
|
戻る |
次へ |
この章では、トポロジを設定した後に実行できる操作について説明します。この操作には、トポロジの監視、スケーリングおよびバックアップがあります。
この章の項目は次のとおりです。
トポロジの監視方法の詳細は、『Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter』の第15章を参照してください。
UMSドライバの構成情報は、SOAクラスタに自動的には伝播されません。したがって、ユーザーが次の作業を行う必要があります。
UMSドライバの構成情報を、そのドライバを使用するEDGトポロジ内のすべてのサーバーに適用します。
サーバーの移行機能を使用すると、サーバーは別のノードのドメイン・ディレクトリに移動します。UMSドライバ構成は、フェイルオーバー・ノード内であらかじめ作成しておく必要があります。UMSドライバ構成ファイルの場所は次のとおりです。
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/servers/<server_name>/tmp/_WL_user/<ums_driver_name>/*/configuration/driverconfig.xml
（「*」はデプロイメント時にランダムに生成されるディレクトリ名、たとえば「3682yq」を表します）。
フェイルオーバーに備えてファイルを作成するには、強制的にサーバー移行を実行してファイルをソース・ノードからコピーしてください。
これまでに行った変更を有効にする（変更後の構成情報をドライバに読み取らせる）ためにドライバを再起動する必要があります。ドライバを再起動する手順は次のとおりです。
Oracle WebLogic管理コンソールにログオンします。
ナビゲーション・ツリーの環境ノードを開きます。
「デプロイメント」をクリックします。
ドライバを選択します。
「停止」→「作業完了時」をクリックし、操作を確定します。
ドライバの状態が「準備完了」に変化するまで待ちます（必要に応じて、管理コンソール・ページを更新する）。
ドライバをもう一度選択して「起動」→「すべての要求を処理」をクリックし、操作を確定します。
ドライバのプロパティが保持されていることを、Oracle Enterprise Manager Fusion Middleware Controlで確認してください。
エンタープライズ・トポロジは、スケールアウトまたはスケールアップできます。トポロジのスケールアップとは、1つ以上の管理対象サーバーをすでに実行しているノードに新しい管理対象サーバーを追加することです。トポロジのスケールアウトとは、新しいノードに新しい管理対象サーバーを追加することです。
この項の項目は次のとおりです。
この場合は、WebCenterコンポーネントを使用して構成されている管理対象サーバーまたはWSM-PMを含む管理対象サーバーを実行するノードがすでに存在します。このノードには、共有記憶域内にWebLogic ServerホームとOracle Fusion Middleware WebCenterホームが存在します。
新しいOracle WebCenterサーバーとWLS_WSMサーバーの作成には、既存のインストール（WebLogic Serverホーム、Oracle Fusion Middlewareホームおよびドメイン・ディレクトリ）を使用できます。WLSバイナリまたはWebCenterバイナリを新しい場所にインストールしたり、圧縮と解凍を実行する必要はありません。
トポロジをスケールアップする手順は次のとおりです。
管理コンソールを使用して、WLS_Spaces1、WLS_Portlet1、WLS_Services1またはWLS_WSM1を新しい管理対象サーバーにクローニングします。クローニング元の管理対象サーバーとして選択できるのは、新しい管理対象サーバーを実行するノード上にすでに存在しているサーバーです。
管理対象サーバーのクローンを作成する手順は次のとおりです。
管理コンソールから、「環境」→「サーバー」を選択します。
クローニングする管理対象サーバー（WLS_Spaces1やWLS_Portlet1など）を選択します。
「クローン」を選択します。
新しい管理対象サーバー(SERVER_NAME)nに名前を付けます。このnは、新しい管理対象サーバーを識別する番号です。
リスニング・アドレスには、この新しい管理対象サーバーで使用するホスト名またはIPを指定します。
スケールアウトされている管理対象サーバーがWLS_Servicesの場合、次の追加手順を実行します。
管理対象サーバーを最低でも1回は起動し、Oracle Wikiの管理対象サーバー用のデプロイメント・ディレクトリを作成します。その後、管理対象サーバーを停止します。
第6.14項「マルチキャストからユニキャストへのディスカッション・フォーラムの変換」の手順に従って、JiveサーバーがJiveクラスタのメンバーになるように構成します。次の起動パラメータを使用します。
-Dtangosol.coherence.wka1=Host1 -Dtangosol.coherence.wka2=Host2 -Dtangosol.coherence.localhost=Host1 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
Host1は、新しい管理対象サーバーが作成されたホストであり、Host2は、クラスタ内のその他のホストです。
クラスタ内の新しいメンバーを使用してOracle HTTP Serverモジュールを再構成します。Oracle HTTP Serverの構成を参照してください。
新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します（第6.13項「Javaオブジェクト・キャッシュの設定」を参照）。
トポロジのスケールアウトでは、Oracle WebCenterアプリケーション、WSM-PMまたはその両方を使用して構成された新しい管理対象サーバーを新しいノードに追加します。
この項の手順を実行する前に、次の要件が満たされていることを確認してください。
トポロジ内に、Oracle WebCenterアプリケーション、WSM-PMまたはその両方を使用して構成された管理対象サーバーを実行している既存のノードが存在する。
新しいノードがWebLogic ServerおよびOracle WebCenter用の既存のホーム・ディレクトリにアクセスできる。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerのバイナリやWebCenterのバイナリを新しい場所にインストールする必要はありませんが、新しいノードでpackとunpackを実行してドメインの構成をブートストラップする必要はあります。
トポロジをスケールアウトする手順は次のとおりです。
新しいノード上に、既存のミドルウェア・ホーム（WebCenterインストールとドメイン・ディレクトリが存在する）をマウントします。ドメイン内の他のノードと同様、新しいノードからこのディレクトリにアクセスできることを確認してください。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリにアタッチするには、次のコマンドを実行します。
SOAHOSTn>cd ORACLE_HOME/ SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_14_R27.6.4-18
ミドルウェア・ホーム・リストを更新するには、$HOME/bea/beahomelistファイルを作成し（別のWebLogicインストールがノード内に存在する場合は、このファイルを編集）、MW_HOMEをこのファイルに追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノード用の新しいマシンを作成し、このマシンをドメインに追加します。
マシンのノード・マネージャのアドレスを更新し、スケールアウトに使用しているノードのIPをマッピングします。
管理コンソールを使用して、WLS_Spaces1/WLS_Portlet1/WLS_Services1/WLS_WSM1を新しい管理対象サーバーにクローニングし、WLS_(SERVER_TYPE)nと名付けます。このnは番号です。
ここでの手順は、管理対象サーバーが実行されていなかったノードnに新しいサーバーを追加することを想定しています。
管理対象サーバーのリスニング・アドレスに、新しい管理対象サーバーに使用するホスト名またはIPを割り当てます。
スケールアウトされている管理対象サーバーがWLS_Servicesの場合、次の追加手順を実行します。
管理対象サーバーを最低でも1回は起動し、Oracle Wikiの管理対象サーバー用のデプロイメント・ディレクトリを作成します。その後、管理対象サーバーを停止します。
第6.14項「マルチキャストからユニキャストへのディスカッション・フォーラムの変換」の手順に従って、JiveサーバーがJiveクラスタのメンバーになるように構成します。次の起動パラメータを使用します。
-Dtangosol.coherence.wka1=Host1 -Dtangosol.coherence.wka2=Host2 -Dtangosol.coherence.localhost=Host1 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
Host1は、新しい管理対象サーバーが作成されたホストであり、Host2は、クラスタ内のその他のホストです。
クラスタ内の新しいメンバーを使用してOracle HTTP Serverモジュールを再構成します（Oracle HTTP Serverの構成を参照）。
新しいノードでノード・マネージャを起動します。既存のノードの共有記憶域にあるインストールを使用してノード・マネージャを起動しますが、その際に新しいノードのホスト名をパラメータとして渡します。
NEW_NODE> WL_HOME/server/bin/startNodeManager <new_node_ip>
第4.1.1項「Oracle WebLogic Serverのインストール」に示されているパスを使用する場合、WL_HOMEはORACLE_BASE/wlsになります。
追加した新しい管理対象サーバーを管理コンソールから起動し、テストします。
新たに作成した管理対象サーバー上のアプリケーションにアクセスします（http://HOST:port/webcenterまたはhttp://host:port/wsm-pm）。このアプリケーションが正常に機能している必要があります。
新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します（第6.13項「Javaオブジェクト・キャッシュの設定」を参照）。
各Content Serverノードは、共有記憶域の<content_server_dir>/binにあるクラスタ・インストーラを使用してインストールされます。
別のContent Serverノードのインストール
新しいノード（SOAHOSTn）で次のコマンドを実行します（全体を1行で指定）。
Installer -set-ClusterNodeIntradocDir=<ocs-stub> -set-ClusterNodeName=<nodename> -set-ClusterNodeAddress=<ip_of_node> -set-ClusterBinDirRule=<local|shared> ConfigureClusterNode ConfigureAdminClusterNode
<nodename>には、SOAHOSTnを指定します。
<stellent-stub>には、ローカル・ディレクトリ（/u01/app/oracle/product/ucmなど）を使用します。
Set-ClusterBinDirRuleには、localを指定します。
インストール後の手順
ノードを設定した後は、次の行を<stellent-stub>/binディレクトリと<stellent-stub>/admin/etcディレクトリのintradoc.cfgファイルに追加します。
DisableSharedCacheChecking=true ClusterNodeName=<nodename> ClusterGroup=<cluster_name> SocketServerAddress=<server_IP_address>
<nodename>はノードの識別子です。
<cluster_name>はクラスタの識別子です。
すべてのノードには別々のノード名が必要ですが、クラスタ・グループ名は同じである必要があります。たとえば、SOAHOSTnの行は次のようになります。
DisableSharedCacheChecking=true ClusterNodeName=SOAHOSTn ClusterGroup=ucmcluster SocketServerAddress=<IP_of_SOAHOSTn>
サーバーの起動
各ノードで<ocs-stub>/binにあるバイナリを使用して、Oracle Content Serverと管理サーバーを起動します。
ログ・ファイルとPIDファイルが<ocs-stub>/admin/etcディレクトリと<ocs-stub>/etcディレクトリに作成されていることを確認します。
ロード・バランサの構成
ロード・バランサは、この新しいホストに対してもソケット・ロード・バランサとして機能するように再構成する必要があります。これは、Oracle HTTP ServerおよびWebCenterからのソケット接続を確立するために使用されます。例:
ロード・バランサ上の仮想ホスト: wcinternal.mycompany.com:9054
マッピング先: WCHOST1:9054、WCHOST2:9054、SOAHOSTn:9054
ロード・バランシング・メソッド: ラウンド・ロビン
表11-1は、11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクトを示しています。
表11-1 11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象である静的アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ORACLEホーム（DB） |
RACデータベース・ホスト: CUSTDBHOST1およびCUSTDBHOST2 |
ユーザー定義 |
ディレクトリ層 |
|
MWホーム（SOAおよびWC） |
SOAHOST1およびSOAHOST2: SOA WCHOST1およびWCHOST2: WC |
すべてのホスト上のMW_HOME |
アプリケーション層 |
|
Oracleホーム（OHS） |
WEBHOST1およびWEBHOST2 |
ORACLE_BASE/admin/<instance_name> |
Web層 |
|
Oracleホーム（OCS） |
WCHOST1およびWCHOST2 |
共有ディスク上: /share/oracle/ucm 各ホスト: ORACLE_HOME/ucmにあるローカル・ファイル |
アプリケーション層 |
|
インストール関連ファイル |
OraInventory、<user_home>/bea/beahomelist、oraInst.loc、oratab |
表11-2は、11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクトを示しています。
表11-2 11gのOracle WebCenterエンタープライズ・デプロイメントのバックアップ対象であるランタイム・アーティファクト
| タイプ | ホスト | 場所 | 層 |
|---|---|---|---|
|
ドメイン・ホーム |
SOAHOST1 SOAHOST2 WCHOST1 WCHOST2 |
ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> |
アプリケーション層 |
|
アプリケーション・アーティファクト（earおよびwarファイル） |
SOAHOST1 SOAHOST2 WCHOST1 WCHOST2 |
管理コンソールですべてのデプロイメントを確認し、すべてのアプリケーション・アーティファクトを取得する |
アプリケーション層 |
|
OHSインスタンス・ホーム |
WEBHOST1およびWEBHOST2 |
WEBHOST1上: ORACLE_HOME/ohs_1/instances/instance1 WEBHOST2上: ORACLE_HOME/ohs_2/instances/instance2 |
Web層 |
|
OHS OCS構成ファイル |
WEBHOST1およびWEBHOST2 |
各ホストの/share/oracle/ucm（ローカル・ファイル・システム） |
Web層 |
|
RACデータベース |
CUSTDBHOST1およびCUSTDBHOST2 |
ユーザー定義 |
ディレクトリ層 |
|
OCSコンテンツ・リポジトリ |
データベース・ベース |
ディレクトリ層 |
Oracle Fusion Middlewareのコンポーネントのバックアップとリカバリの詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。
|
注意: ORACLE_HOMEのバックアップは、B2B設定の一部であるXEngine構成が変更されたときに実行する必要があります。対象のファイルは、ORACLE_HOME/soa/thirdparty/edifecs/XEngineにあります。ORACLE_HOMEをバックアップするには、次のコマンドを実行してください。
SOAHOST1> tar -cvpf fmwhomeback.tar MW_HOME
|
この項の項目は次のとおりです。
問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。
<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/soadomain/aserver/soadomain/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を削除します。
問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。
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
解決方法: このエラーが発生するのは、サーバーの起動パラメータが管理コンソールで変更された場合です。この場合は、構成を変更しようとしていたサーバーの起動構成の一部であるユーザー名/パスワードの情報を管理コンソールで指定するか、<password-encrypted></password-encrypted>エントリをconfig.xmlファイルから削除してください（管理サーバーの再起動が必要）。
問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しましたが、そのURLの1つに誤記がありました。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。
解決方法: 同じapp_domain名を指定してOAM構成ツールを実行したときは、既存ポリシーへの新しいURLの追加のみが行われます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログオンして、「ポリシー・ドメイン」をクリックし、作成済のポリシー・ドメイン（SOA_EDG）をクリックし、「リソース」タブで誤ったURLを削除します。
問題: WebCenter Spaces内でページを作成しているときに、そのページにポートレットを追加した後でデータベース・フェイルオーバーが発生すると、次のメッセージを表示するエラー・コンポーネントがページに追加される場合があります。
"Error" "Portlet unavailable"
このメッセージは、ページをリフレッシュしたり、いったんログアウトしてページを再表示してもなくなりません。
解決方法: この問題を解決するには、該当のコンポーネントを削除してからもう一度追加します。
問題: Oracle WebLogic管理コンソールにアクセスするためにOHSおよびLBRを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。
解決方法: この問題は、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、管理コンソールがその変更を反映しようとすると発生します。変更内容によっては、管理サーバーのリスニング・アドレスにリダイレクトすることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをsoa.mycompany.com/console/console.portalに変更すれば、管理コンソールのホーム・ページに直接アクセスできます。
|
注意: この項で説明する変更の追跡を無効にしている場合、この問題は発生しません。 |
問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります（アクティブ化の実行場所であるコンテキスト・メニューには戻らない）。
解決方法: これは、OAM SSOが構成済のときに発生する現象で、管理サーバーによってリダイレクトが実行された結果です。このリダイレクトにかかわらず、アクティブ化は完了します。必要であれば、ユーザーは手動で目的のコンテキスト・メニューに戻ることができます。
問題: Javaオブジェクト・キャッシュ（OWSM、WebCenter Spaces管理対象サーバーなど）を使用している管理対象サーバーの起動に失敗します。次のエラーがログに表示されます。
J2EE JOC-058 distributed cache initialization failure J2EE JOC-043 base exception: J2EE JOC-803 unexpected EOF during read.
解決方法: JOCが取得しようとしているポートと同じポートを別のプロセスが使用しています。このプロセスを停止するか、または推奨ポート範囲内の別のポートを使用するようにこのクラスタのJOCを再構成します。
問題: soa-createUDD.pyスクリプトに渡されたパラメータに誤りがあるか、別の誤りによってSOAクラスタまたはBAMクラスタのJMS構成で障害が発生しています。
解決方法: soa-createUDD.pyを使用して、構成をリストアします。
SOAクラスタがOracle Fusion Middleware構成ウィザードから作成された後でsoa-createUDD.pyスクリプトを実行しているときに、なんらかの誤りが生じた（誤ったオプションが使用された、ターゲットが変更された、またはモジュールが間違って削除された）場合。このような状況では、soa-createUDD.pyスクリプトを使用し、次の手順で適切なJMS構成をリストアできます。
既存のSOA JMSリソース（SOAインフラストラクチャ・システムが所有するJMSモジュール）を削除します。
soa-createUDD.pyを再実行します。このスクリプトは、SOA用に作成されたJMSサーバーが保持され、SOA用の共通分散送り先を使用するために必要な宛先とサブデプロイメント・モジュールが作成されることを想定しています。この場合、オプション--soaclusterを指定してスクリプトが実行される必要があります。スクリプトを再実行後、WebLogic Server管理コンソールから次のアーティファクト（ドメイン構造、サービス、メッセージング、JMSモジュール）が存在することを確認します。
SOAJMSModuleUDDs ---->SOAJMSSubDM targeted to SOAJMSServer_auto_1 and SOAJMSServer_auto_2 UMSJMSSystemResource ---->UMSJMSSubDMSOA targeted to UMSJMSServer_auto_1 and UMSJMSServer_auto_2
この項の項目は次のとおりです。
EDG本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters（RAC）の場合、データベース接続はOracle RACのVIPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのように構成できない場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルの*SQLNET.EXPIRE_TIME=n*パラメータを設定してください。nは分単位の数値です。この値を、ネットワーク・デバイス（つまりファイアウォール）の既知のタイムアウト値よりも小さくしてください。RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。
Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middleware 11gで追加された新しいサービスです。これは、ミドルウェア製品ファミリの集中監査フレームワークです。このフレームワークでは、Oracle Platform Security Services（OPSS）やOracle Web Servicesなどのプラットフォーム・コンポーネントに対して監査サービスが提供されます。また、Oracle固有のJavaEEコンポーネントをはじめ、様々なJavaEEアプリケーションのフレームワークとしても機能します。また、このようなJavaEEアプリケーションで、アプリケーション固有の監査イベントを作成できます。ミドルウェアのOracleコンポーネントのうちJavaEE以外のもの、たとえばCやJavaSEのコンポーネントについても、JavaEEアプリケーションと同様、エンドツーエンドのフレームワーク構造を実現します。
図11-1は、Oracle Fusion Middleware監査フレームワーク・アーキテクチャの概要図です。
Oracle Fusion Middleware監査フレームワークを構成する主なコンポーネントは次のとおりです。
Oracle Fusion Middleware監査フレームワークに統合される監査対応コンポーネント用のAPIです。実行時にアプリケーションからこのAPIを呼び出すと、アプリケーション・コード内で発生した特定のイベントに関する必要な情報の監査を行うことができます。監査対象のイベントのコンテキストを示すために、イベントの詳細情報、たとえばユーザー名や属性を、この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の事前定義済レポートとして公開されます。このレポートでは、監査データを様々な条件に基づいてドリルダウンできます。次に例を示します。
ユーザー名
時間範囲
アプリケーション・タイプ
実行コンテキスト識別子（ECID）
Oracle Fusion Middleware監査フレームワークの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』の「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。
Oracle Fusion Middleware監査フレームワークのリポジトリを構成する方法については、『Oracle Fusion Middlewareセキュリティ・ガイド』の「監査の構成と管理」を参照してください。
EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成は含まれません。バスストップ・ファイルへの監査データの出力、および監査ローダーの構成は、製品をインストールした後に実行できるようになります。最大の懸念事項は、監査データが格納される監査データベース・リポジトリです。監査データはサイズが大きく、過去のデータが蓄積されていくため、他のミドルウェア・コンポーネントの運用ストアとは別に、専用のデータベースを用意することを強くお薦めします。
