Oracle® Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド 11g リリース1(11.1.1) B63036-03 |
|
前 |
次 |
この章では、Oracle Business Intelligenceトポロジの設定後に実行可能なオペレーションについて説明します。これには、エンタープライズ・デプロイメントの監視、スケーリングおよびバックアップが含まれます。
この章には次のトピックが含まれます:
Oracle Business Intelligenceエンタープライズ・デプロイメントの構成後に、この章の情報を使用してこのデプロイメントを管理します。この章には、デプロイメントの起動、停止、監視およびパッチ適用など、通常のオペレーションに関する項目が含まれています。
一部の項目では、トポロジをスケールアップまたはスケール・アウトして拡張することが必要な場合もあります。この作業の詳細は、第13.4項「エンタープライズ・デプロイメントのスケーリング」を参照してください。
構成の変更前後にはトポロジをバックアップします。詳細は、第13.5項「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。
また、この章には、第13.8項「エンタープライズ・デプロイメントのトラブルシューティング」でトポロジを構成した場合に発生する可能性がある既知の問題に対し、解決方法が記載されています。
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サーバー」、「Presentation Server」または「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.1項「推奨ディレクトリの場所」にリストされているすべての共有ディレクトリがすべてのノードで利用可能なことを確認します。ただし、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 ORACLE_BASE/product/fmw/jrockit_version
Middlewareホーム・リストを更新するには、MW_HOME
/.home
ファイルを作成(または別のWebLogicインストールがノード内に存在する場合は、編集)して、そのファイルにORACLE_BASE
/product/fmw
を追加します。
第9.3項「APPHOST2でのOracle Business Intelligenceシステムのスケール・アウト」の手順に従い、共有Oracleホームの1つから構成アシスタントを実行します。
第9.3.2項「システム・コンポーネントのスケール・アウト」の手順に従い、APPHOST3でシステム・コンポーネントをスケール・アウトします。
第9.4項「bi_server2管理対象サーバーの構成」の手順に従い、リスニング・アドレスの設定とホスト名検証の無効化を行うことによって、bi_server3管理対象サーバーを構成します。
第9.5.3.4項「Oracle BI Publisher用のJMSの構成」の説明に従って、Oracle BI Publisher用のJMSを構成します。
第9.5.4項「Oracle BI for Microsoft Officeの追加の構成タスク」の説明に従って、APPHOST3でOracle BI for Microsoft Officeを構成します。
第 9.6.1項「トランザクション・リカバリ用デフォルト永続ストアの構成」の説明に従って、bi_server3のデフォルト永続ストアの場所を設定します。
第8.4.2項「bi_servern管理対象サーバー用のOracle HTTP Serverの構成」の手順に従って、APPHOST3VHN1にOracle HTTP Serverを構成します。
APPHOST3で実行しているシステム・コンポーネントとbi_server3管理対象サーバーを起動します。詳細は、第13.2項「Oracle Business Intelligenceの起動と停止」を参照してください。
以降の説明に従って、新しいノードのサーバー移行を設定します。
構成を検証するには、次の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アプリケーションのステータスを確認します。
ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。管理サーバーや他のサーバーとの通信では異なるアドレスの証明書を使用することが必要です。詳細は、第10章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照してください。
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ホーム・ディレクトリで設定してください。
この項の内容は次のとおりです。
第13.8.1項「BIアプリケーションにロード・バランサ経由でアクセスしたときに「ページが見つかりません」というエラーが発生する」
第13.8.11項「Oracle BI Publisherの「スケジューラ診断」ページでJMSインスタンスが欠落している」
問題: ロード・バランサ・アドレスを使用して、Oracle Business Intelligenceアプリケーション(Oracle BI Presentation Services、Oracle BI Publisher、Oracle Real-Time Decisionsなど)にアクセスしようとすると、Webブラウザで「ページが見つかりません」という404エラー・メッセージが表示されます。このエラーは断続的に表示され、管理コンソールでは、BI Serverが「実行中」と表示されます。
解決方法: BI管理対象サーバーが実行中であっても、そのサーバー内のアプリケーションの状態が「アクティブ」ではなく、「管理」や「準備完了」である場合があります。BI Serverが実行中でも、アプリケーションが使用不可になることもあります。管理コンソールの「デプロイメント」ページで、影響を受けるアプリケーションの状態を調べてください。状態は「アクティブ」になっている必要があります。BI Serverの出力ログにそのアプリケーションに関するエラーがないことを確認し、管理コンソールの「デプロイメント」ページでアプリケーションを起動してください。
問題: 管理サーバー・ノードに障害が発生して別のノードへの手動フェイルオーバーが実行された後で、管理サーバーの起動に失敗します。管理サーバーの出力ログには、次のように報告されます。
<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 VMに割り当てられているメモリー・ヒープのサイズを少なくとも1GBに増やします。
管理コンソールにログインします。
「環境」をクリックし、「サーバー」をクリックします。
管理対象サーバー名をクリックします。
「構成」タブを開きます。
2列目にある「サーバーの起動」タブを開きます。
「引数」ボックスでメモリー・パラメータを追加します。例:
-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m
注意: メモリー・パラメータ要件は、各種のJVM(Sun、JRockitなど)ごとに異なる可能性があります。 |
構成の変更を保存します。
実行されているすべての管理対象サーバーを再起動します。
Oracle BI Publisherの「スケジューラ診断」ページに、クラスタ内のすべてのインスタンスではなく、1つのJMSインスタンスのみが表示される場合があります。この問題はおそらくクロックが同期していないことが原因です。クラスタ内のすべてのノードでクロックを同期させることの重要性の詳細は、第2.4項「クロックの同期」を参照してください。
Oracle BI Publisherが実行されている管理対象サーバーを停止する前に、実行中のすべてのOracle BI Publisherジョブの完了を待機するか、または「レポート・ジョブ履歴」ページを使用して未完了のジョブを取り消すことがベスト・プラクティスです(必須ではありません)。それ以外の場合は、停止により一部のジョブが誤って実行状態のまま残る可能性があります。
まれにOracle BI Publisher SchedulerクラスタでJMSインスタンスが欠落していることがあります。この問題を解決するには、Oracle WebLogic Server管理コンソールからOracle BI Publisherアプリケーションを再起動します。
BI Publisherアプリケーションを再起動するには:
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。
「bipublisher(11.1.1)」を選択します。
「停止」をクリックします。
アプリケーションが停止したら、「開始」をクリックします。
WebLogicドメインの管理アカウントでAdministrators(デフォルト)以外のグループ名を使用している場合は、すべてのノードでMapViewer weblogic.xmlファイルを更新し、実際のグループ名が含まれるようにする必要があります。
カスタム・グループ名で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)を選択します。
「停止」をクリックします。
アプリケーションが停止したら、「起動」をクリックします。
この手順をすべてのノードで繰り返します。