| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-04 |
|
前 |
次 |
この章では、Oracle Business Intelligenceトポロジの構成後に実行可能なオペレーションについて説明します。これには、エンタープライズ・デプロイメントの監視、スケーリングおよびバックアップが含まれます。
この章には次のトピックが含まれます:
Oracle Business Intelligenceエンタープライズ・デプロイメントの構成後に、この章の情報を使用してこのデプロイメントを管理します。この章には、デプロイメントの起動、停止、監視およびパッチ適用など、通常のオペレーションに関する項目が含まれています。
ある時点で、トポロジをスケール・アップまたはスケール・アウトして拡張することが必要になる場合もあります。この作業の詳細は、第13.4項「エンタープライズ・デプロイメントのスケーリング」を参照してください。
構成の変更前後にはトポロジをバックアップします。詳細は、第13.6項「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。
また、この章の第13.9項「エンタープライズ・デプロイメントのトラブルシューティング」では、トポロジの構成後に発生する可能性がある既知の問題に対する解決方法も紹介しています。
Oracle Business Intelligenceを起動するには、常に管理対象サーバー、システム・コンポーネントの順に起動する必要があります。また、管理対象サーバーを再起動したときは、システム・コンポーネントも再起動する必要があります。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceの起動と停止に関する項を参照してください。
この項の内容は次のとおりです。
Oracle Business Intelligence管理対象サーバーを停止、起動または再起動する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
管理するOracle Business Intelligence管理対象サーバーを選択します(たとえば、bi_server1、bi_server2など)。
次のいずれかの処理を実行します。
管理対象サーバーを停止するには、「停止」をクリックします。
管理対象サーバーを起動するには、「起動」をクリックします。
管理対象サーバーを再起動するには、まず「停止」をクリックし、サーバーが完全に停止するまで待機します。サーバーが完全に停止したら、管理対象サーバーをもう一度選択し、「起動」をクリックします。
Oracle Business Intelligenceのシステム・コンポーネントを停止、起動または再起動する手順は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「Business Intelligence概要」ページで、「停止」、「起動」または「再起動」をクリックします。
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での問題の診断と解決に関する項を参照してください。
Oracle Business Intelligenceエンタープライズ・トポロジを、次のようにスケール・アップまたはスケール・アウトできます。
トポロジをスケール・アップする際は、エンタープライズ・トポロジ内のいずれかの既存ノードに新たなシステム・コンポーネントを追加します。
トポロジをスケール・アウトするには、管理対象サーバーおよびシステム・コンポーネントのセットとともに新しいノードをトポロジに追加します。
この項には次のトピックが含まれます:
|
注意: I/PMによって使用されているSOAサブシステムをスケール・アウトおよびスケール・アップするには、SOAエンタープライズ・デプロイメント・トポロジのドキュメントを参照してください。 |
この手順では、ノードが2つあり各ノードに管理対象サーバーとフル・セットのシステム・コンポーネントがあるエンタープライズ・トポロジを前提にします。トポロジをスケール・アップするには、いずれかの既存ノードで実行されているシステム・コンポーネントの数を増やします。
特定のノードで複数の管理対象サーバーを実行する必要はありません。
Oracle Business Intelligenceエンタープライズ・トポロジをスケール・アップする手順は次のとおりです。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「容量管理」をクリックしてから、「スケーラビリティ」をクリックします。
「構成をロックして編集」をクリックします。
矢印キーを使用して、「BIサーバー」、プレゼンテーション・サービスまたは「JavaHost」の数を変更します。
「適用」をクリックしてから、「変更のアクティブ化」をクリックします。
「概要」をクリックしてから、「再起動」をクリックします。
トポロジをスケール・アウトする場合、トポロジの新しいノード(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を使用します。Middlewareホーム・リストを更新し、WL_HOMEの追加と削除を行うには、MW_HOME/.homeファイルを編集します。第13.4.2.1項「Oracle Business Intelligenceのスケール・アウト手順」を参照してください。
新しいノードから共有記憶域のすべてのディレクトリにアクセス可能であることを保証する必要があります。第4.3.4項「推奨ディレクトリの場所」にリストされているすべての共有ディレクトリがすべてのノードで利用可能なことを確認します。ただし、ORACLE_INSTANCEディレクトリとスケール・アウトされた管理対象サーバーのドメイン・ディレクトリは対象外とします。
また、ホスト名検証証明書が保持されているアイデンティティ・キーストアとトラスト・キーストアに共有記憶域を使用している場合、共有記憶域ディレクトリがスケール・アウトされたノード(APPHOST3)からアクセスできることを確認します。キーストアにローカル・ディレクトリを使用している場合、第10.3項「ノード・マネージャのホスト名検証証明書の有効化」の手順に従って、スケール・アウトされたノードにローカルのアイデンティティ・キーストアを作成および構成します。
たとえば、次の各ディレクトリをマウントします。
トランザクション・ログ・ディレクトリ
JMS永続ストア
グローバル・キャッシュ
BI Presentation Catalog
BIリポジトリの公開ディレクトリ
BI Publisherカタログ
BI Publisher構成キーストア(certs)
MW_HOME
APPHOST3上でOracle Business Intelligenceをスケール・アウトする手順は次のとおりです。
APPHOST3で、Oracle Business Intelligenceのインストールと(必要に応じ、他のノードで管理対象サーバー用ドメイン・ディレクトリが共有記憶域にある場合)ドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。
APPHOST3> cd ORACLE_COMMON_HOME/oui/bin/ APPHOST3> ./attachHome.sh -jreLoc MW_HOME/jdk
Middlewareホーム・リストを更新するには、MW_HOME/.homeファイルを作成(または別のWebLogicインストールがノード内に存在する場合は、編集)して、そのファイルにORACLE_BASE/product/fmwを追加します。
第9.3項「APPHOST2でのOracle Business Intelligenceシステムのスケール・アウト」の手順に従い、共有Oracleホームの1つから構成アシスタントを実行します。
|
注意: 構成アシスタントを実行する前に、最初の2つのノードと同じディレクトリに、適切なバージョンのJDKがインストールされていることを確認します。適切なJDKがインストールされていないと、構成アシスタントは起動しない可能性があります。 |
第9.3.2項「システム・コンポーネントのスケール・アウト」の手順に従い、APPHOST3でシステム・コンポーネントをスケール・アウトします。
第9.4項「bi_server2管理対象サーバーの構成」の手順に従い、リスニング・アドレスの設定とホスト名検証の無効化を行うことによって、bi_server3管理対象サーバーを構成します。
第9.5.3.4項「BI Publisher用のJMSの構成」の説明に従って、BI Publisher用のJMSを構成します。
第 9.6.1項「トランザクション・リカバリ用デフォルト永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。
第8.4.1項「管理サーバーとbi_servern管理対象サーバーについてのOracle HTTP Serverの構成」の手順を使用して、APPHOST3VHN1に対してOracle HTTP Serverを構成します。
APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第13.2項「Oracle Business Intelligenceの起動と停止」を参照してください。
第9.5.2.2項「システム・プロパティの「サーバーの起動」タブへの追加」の説明に従って、Oracle RTDの「サーバーの起動」タブにシステム・プロパティを追加します。
次の各項の説明に従って、新しいノードでサーバーの移行を構成します。
構成を検証するには、次のURLにアクセスします。
http://APPHOST3VHN1:9704/analyticsにアクセスして、bi_server3のステータスを確認します。
http://APPHOST3VHN1:9704/wsm-pmにアクセスして、Web Services Managerのステータスを確認します。ポリシー・マネージャの検証をクリックします。データで使用できるポリシーとアサーション・テンプレートのリストが表示されます。
注意: ポリシーやアサーション・テンプレートが表示されない場合、構成は正しくありません。
http://APPHOST3VHN1:9704/xmlpserverにアクセスして、BI Publisherアプリケーションのステータスを確認します。
http://APPHOST3VHN1:9704/uiにアクセスして、Oracle RTDアプリケーションのステータスを確認します。
http://APPHOST3VHN1:9704/mapviewerにアクセスして、MapViewerのステータスを確認します。
http://APPHOST3VHN1:9704/aps/Essbaseにアクセスして、Oracle Essbaseアプリケーションのステータスを確認します。
http://APPHOST3VHN1:9704/aps/SmartViewにアクセスして、Smart Viewアプリケーションのステータスを確認します。
http://APPHOST3VHN1:9704/workspaceにアクセスして、Workspaceアプリケーションのステータスを確認します。
http://APPHOST3VHN1:9704/hrにアクセスして、Financial Reportingアプリケーションのステータスを確認します。
http://APPHOST3VHN1:9704/calcmgr/index.htmにアクセスして、Calculation Managerアプリケーションのステータスを確認します。
ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。この検証では、管理サーバーおよびその他のサーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。詳細は、第10章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照してください。
ノードで障害が発生した場合は、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをAPPHOST1からAPPHOST2にフェイルオーバーする方法を説明します。項目は次のとおりです。
次の前提条件があることに留意してください。
管理サーバーを、任意のアドレスではなくADMINVHN上でリスニングするように構成します。
管理サーバーはAPPHOST1からAPPHOST2にフェイルオーバーし、これら2つのノードには次のIPが割り当てられています。
APPHOST1: 100.200.140.165
APPHOST2: 100.200.140.205
ADMINVHN: 100.200.140.206。これは管理サーバーを実行している場所のVIPであり、ethX:Yに割り当てられており、APPHOST1とAPPHOST2からアクセスできます。
APPHOST1の管理サーバーの実行場所であるドメイン・ディレクトリは共有記憶域にあり、APPHOST2からもマウントされています。
Oracle WebLogic ServerとOracle Fusion MiddlewareコンポーネントがAPPHOST2にインストールされています(つまり、APPHOST1に存在するORACLE_HOMEとMW_HOMEのパスと同じパスがAPPHOST2でも使用可能です)。
手順
管理サーバーを別のノード(APPHOST2)にフェイルオーバーする手順は次のとおりです。
管理サーバーが実行されている場合は停止します。
次の手順を使用して、IPアドレスを2番目のノードに移行します。
APPHOST1上で次のコマンドをroot権限で実行します(X:YはADMINVHNで現在使用しているインタフェース)。
APPHOST1> /sbin/ifconfig ethX:Y down
次のコマンドをAPPHOST2上で実行します。
APPHOST2> /sbin/ifconfig interface:index IP_address netmask netmask
例:
APPHOST2> /sbin/ifconfig eth0:1 10.200.140.206 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースは、APPHOST2で使用可能なネットワーク構成と一致している必要があります。 |
arpingを使用し、ルーティング表を更新します。例:
APPHOST2> /sbin/arping -b -A -c 3 -I eth0 100.200.140.206
第8.3.3項「APPHOST1での管理サーバーの起動」の手順3の説明に従って、APPHOST2上でノード・マネージャを起動します。
第8.3.3項「APPHOST1での管理サーバーの起動」の手順4の説明に従って、APPHOST2上で管理サーバーを起動します。
次の方法でAPPHOST2上の管理サーバーにアクセスできることをテストします。
http://ADMINVHN:7001/consoleの管理コンソールにアクセスできることを確認します。
http://ADMINVHN:7001/emのFusion Middleware Controlコンポーネントにアクセスしステータスを検証できることを確認します。
第8.4.5項「Oracle HTTP Serverを使用したアクセスの検証」で説明されている手順を実行します。この目的は、APPHOST2で実行している管理サーバーにもアクセスできることを確認することです。
この手順では、管理サーバーをフェイルバックできることを確認します。フェイルバックとは、APPHOST2で実行している管理サーバーを停止し、APPHOST1で再び管理サーバーを実行することです。ADMINVHNをAPPHOST1ノードにフェイルバックする手順は次のとおりです。
管理サーバーが実行されていないことを確認してください。
次のコマンドをAPPHOST2上でrootとして実行します。
APPHOST2> /sbin/ifconfig ethX:Y down
次のコマンドをAPPHOST1上で実行します。
APPHOST1> /sbin/ifconfig interface:index IP_Address netmask netmask
例:
APPHOST1> /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
|
注意: 使用するネットマスクとインタフェースは、APPHOST1で使用可能なネットワーク構成と一致している必要があります。 |
arpingを使用し、ルーティング表を更新します。例:
APPHOST1> /sbin/arping -b -A -c 3 -I ethZ 100.200.140.206
第8.3.3項「APPHOST1での管理サーバーの起動」の手順4の説明に従って、APPHOST1上で管理サーバーを再び起動します。
http://ADMINVHN:7001/consoleの管理コンソールにアクセスできることをテストします。
http://ADMINVHN:7001/emのFusion Middleware Controlコンポーネントにアクセスしステータスを検証できることを確認します。
管理サーバーのフェイルオーバーで問題が発生する場合の追加情報は、第13.9.2項「手動フェイルオーバー後に管理サーバーの起動に失敗する」を参照してください。
Oracle Business Intelligenceのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Business Intelligenceのバックアップおよびリカバリに関する推奨事項に関する項を参照してください。
Oracle Business Intelligenceのパッチ適用の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceシステムのパッチ適用に関する項を参照してください。
EDG本番デプロイメントでは、かなりの部分にファイアウォールが使用されています。データベース接続はファイアウォールを介して行われるため、データベース接続がタイムアウトしないようにファイアウォールを構成することをお薦めします。Oracle Real Application Clusters(RAC)の場合、データベース接続はOracle RACのVIPとデータベース・リスナー・ポートに対して行われます。このような接続がタイムアウトしないように、ファイアウォールが構成されている必要があります。そのような構成が不可能な場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルにある*SQLNET.EXPIRE_TIME=n*というパラメータを設定します(nは分単位の時間)。この値を、ネットワーク・デバイス(つまりファイアウォール)の既知のタイムアウト値よりも小さくしてください。Oracle RACの場合、このパラメータをすべてのOracleホーム・ディレクトリで設定してください。
この項には次のトピックが含まれます:
問題: ロード・バランサ・アドレスを使用して、Oracle Business Intelligenceアプリケーション(Oracle BI Presentation Services、Oracle BI Publisher、Oracle RTDなど)にアクセスしようとすると、Webブラウザで「ページが見つかりません」という404エラー・メッセージが表示されます。エラーは断続的に発生し、管理コンソールではOracle Business Intelligenceの管理対象サーバーのステータスは「実行中」と表示されます。
解決方法: Oracle Business Intelligenceの管理対象サーバーが実行中であっても、そのサーバー内のアプリケーションの状態が「アクティブ」ではなく、「管理」や「準備完了」である場合があります。管理対象サーバーが実行中でも、アプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、影響を受けるアプリケーションの状態を調べてください。状態は「アクティブ」になっている必要があります。管理対象サーバーの出力ログにそのアプリケーションに関するエラーがないことを確認し、管理コンソールの「デプロイメント」ページでアプリケーションを起動してください。
問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。
<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を削除します。
問題: サーバーの起動構成を変更した後で、管理コンソールで変更をアクティブ化しようとすると失敗します。「変更のアクティブ化」をクリックすると、管理コンソールに次のように表示されます。
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
解決方法: これは、管理コンソールでサーバーの起動パラメータが変更された場合に発生する可能性があります。この場合、管理コンソールで、構成を変更した特定のサーバーのサーバー起動構成でユーザー名とパスワードの情報を指定します。
問題: ローカルのノード・マネージャによる再起動試行回数が最大数に達した後で、フェイルオーバー・ノードのノード・マネージャが再起動を試行しますが、サーバーは起動しません。ノード・マネージャの出力情報には、サーバーがフェイルオーバーしたことが報告されます。ノード・マネージャがbi_server管理対象サーバーの移行を試行した後でも、このサーバーが使用するVIPがフェイルオーバー・ノード内で有効化されていません(フェイルオーバー・ノードでifconfigを実行しても、どのインタフェースのVIPも報告されません)。コマンド「sudo ifconfig $INTERFACE $ADDRESS $NETMASK」を実行しても、そのIPはフェイルオーバー・ノード内で有効化されません。
解決方法: sudo実行の権限と構成により、パスワード入力は要求されません。パスワード入力を要求しなくてもsudoが動作するようにsudoが構成されていることを、システム管理者に確認してください。
問題: サーバー移行は正常に実行されますが(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アドレスです。
問題: OAM構成ツールを使用して、複数のURLをまとめてOracle Access Managerのポリシーに追加しました。しかし、そのURLの1つに誤記がありました。正しいURLを指定してOAM構成ツールをもう一度実行すると、処理は正常に完了しますが、ポリシー・マネージャには誤ったURLが依然として表示されます。
解決方法: 同じapp_domain名を指定して実行した場合にのみ、OAM構成ツールにより既存のポリシーに新しいURLが追加されます。特定のURLを削除するには、OAMのポリシー・マネージャ・コンソールを使用してください。OAMのアクセス管理サイトにログオンして、「ポリシー・ドメイン」をクリックし、作成済のポリシー・ドメイン(bifoundation_domain)をクリックします。「リソース」タブをクリックし、誤ったURLを削除します。
問題: 管理コンソールにアクセスするためにOracle HTTP ServerおよびLBRを構成した後で、なんらかの変更のアクティブ化を行うと、管理コンソールのログイン画面にリダイレクトされます。
解決方法: これは、ユーザーがポート、チャネルおよびセキュリティの設定を変更するときに、コンソールがその変更を反映しようとすると発生します。変更内容によっては、コンソールが管理サーバーのリスニング・アドレスにリダイレクトされることがあります。このリダイレクトにかかわらず、アクティブ化は完了します。ユーザーは再度ログインする必要はなく、URLをadmin.mycompany.com/console/console.portalに変更すれば、管理コンソールのホーム・ページに直接アクセスできます。
|
注意: この項で説明されている変更の追跡を無効にしてある場合は、この問題は発生しません。 |
問題: OAMを構成した後でなんらかの変更をアクティブ化すると、管理コンソールのホーム・ページにリダイレクトされるようになります(アクティブ化の実行場所であるコンテキスト・メニューには戻りません)。
解決方法: これは、OAM SSOが構成され、管理コンソールが構成の変更を反映するように設定されている場合に発生することが予想されます(リダイレクトはなんらかの変更をアクティブ化する際に管理コンソールによって実行されます)。このリダイレクトにかかわらず、アクティブ化は完了します。連続して変更を行ってもリダイレクトされないようにするには、管理コンソールにアクセスして、「プリファレンス」→「共有プリファレンス」を選択し、「構成変更の追跡」チェック・ボックスの選択を解除します。
問題: Javaオブジェクト・キャッシュ(OWSM管理対象サーバーなど)を使用している管理対象サーバーの起動に失敗します。次のエラーがログに表示されます。
J2EE JOC-058 distributed cache initialization failure J2EE JOC-043 base exception: J2EE JOC-803 unexpected EOF during read.
解決方法: JOCが取得しようとしているポートを別のプロセスが使用しています。そのプロセスを停止するか、このクラスタのJOCを再構成して、推奨されるポート範囲内で別のポートを使用するようにします。
問題: 管理対象サーバーでメモリー不足が発生します。
解決方法: Java仮想マシンに割り当てられているメモリー・ヒープのサイズを少なくとも1GBに増やします。
管理コンソールにログインします。
「環境」をクリックし、「サーバー」をクリックします。
管理対象サーバー名をクリックします。
「構成」タブを開きます。
2列目にある「サーバーの起動」タブを開きます。
「引数」ボックスでメモリー・パラメータを追加します。例:
-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m
|
注意: メモリー・パラメータ要件は、各種のJVM(Sun、JRockitなど)ごとに異なる可能性があります。 |
構成の変更を保存します。
実行されているすべての管理対象サーバーを再起動します。
BI Publisherの「スケジューラ診断」ページに、クラスタ内のすべてのインスタンスではなく、1つのJMSインスタンスのみが表示される場合があります。この問題はおそらくクロックが同期していないことが原因です。クラスタ内のすべてのノードでクロックを同期させることの重要性の詳細は、第2.5項「クロックの同期」を参照してください。
BI Publisherが実行されている管理対象サーバーを停止する前に、実行中のすべてのBI Publisherジョブの完了を待機するか、または「レポート・ジョブ履歴」ページを使用して未完了のジョブを取り消すことがベスト・プラクティスです(必須ではありません)。それ以外の場合は、停止により一部のジョブが誤って実行状態のまま残る可能性があります。
JMSインスタンスがBI Publisherスケジューラ・クラスタにないことがまれにあります。この問題を解決するには、Oracle WebLogic Server管理コンソールからBI Publisherアプリケーションを再起動します。
BI Publisherアプリケーションを再起動する手順は次のとおりです。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。
「bipublisher(11.1.1)」を選択します。
「停止」をクリックします。
アプリケーションが停止したら、「開始」をクリックします。
WebLogicドメインの管理アカウントでAdministrators(デフォルト)以外のグループ名を使用している場合は、すべてのノードでMapViewer weblogic.xmlファイルを更新し、実際のグループ名が含まれるようにする必要があります。
MapViewerのweblogic.xmlファイルをカスタム・グループ名で更新する手順は次のとおりです。
次のディレクトリで、MapViewerのweblogic.xmlファイルを編集用に開きます。
ORACLE_HOME/bifoundation/jee/mapviewer.ear/web.war/WEB-INF
このweblogic.xmlファイルで次の行を検索します。
<security-role-assignment> <role-name>map_admin_role</role-name> <principal-name>Administrators</principal-name> </security-role-assignment> <security-role-assignment> <role-name>secure_maps_role</role-name> <principal-name>Administrators</principal-name> </security-role-assignment>
表示されている2つのAdministratorsを実際の管理者グループ名で置き換えます(たとえば、BIAdministratorsなど)。例:
<security-role-assignment> <role-name>map_admin_role</role-name> <principal-name>BIAdministrators</principal-name> </security-role-assignment> <security-role-assignment> <role-name>secure_maps_role</role-name> <principal-name>BIAdministrators</principal-name> </security-role-assignment>
ファイルを保存して閉じます。
MapViewerアプリケーションを次のように再起動します。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。
mapviewer(11.1.1)を選択します。
「停止」をクリックします。
アプリケーションが停止したら、「起動」をクリックします。
この手順をすべてのノードで繰り返します。
