| Oracle® Fusion Middlewareリリース・ノート 11gリリース1 (11.1.1) for Microsoft Windows (32-Bit) B55923-08 |
|
 前 |
 次 |
| Oracle® Fusion Middlewareリリース・ノート 11gリリース1 (11.1.1) for Microsoft Windows (32-Bit) B55923-08 |
|
前 |
次 |
この章では、Oracle Fusion Middlewareの高可用性とエンタープライズ・デプロイメントに関連する問題について説明します。次のトピックが含まれています。
|
注意: この章では、高可用性、またはエンタープライズ・デプロイメントを目的としたOracle Fusion Middleware製品の構成時に発生する可能性のある問題について説明します。 使用中の製品固有の問題については、この文書内で、その製品固有のリリース・ノートの章を参照してください。 |
この項では、一般的な問題および回避策について説明します。次のトピックが含まれています。
6.1.8項「WindowsではASCRSを使用してOracle Databaseコンソール・サービスのデータベース・リソースを作成できない問題」
6.1.13項「SOAクラスタで発生することのある無害なSQLIntegrityConstraintViolationException」
6.1.15項「I/PMからUCMに大量のアップロードが発生する場合にホスト名ベースのフィルタのかわりに必要になることのあるIPベースのフィルタの使用」
6.1.16項「フェイルオーバー中に「アクション」ドロップダウン・メニューを使用した場合にワークリスト・アプリケーションで例外がスローされる問題」
6.1.18項「11.2 Oracle RACデータベースでAQ通知およびサーバー側TAFの設定に使用するsrvctl」
6.1.19項「Oracle RACのフェイルオーバー時にOracle I/PMの入力ファイルが正常に処理されない問題」
6.1.21項「Oracle BI Publisherの管理対象サーバーのフェイルオーバー時にレイアウト・ビューにロード失敗エラーが表示される問題」
6.1.22項「Oracle BI Publisherジョブのスケジュールで管理対象サーバーのフェイルオーバー後に表示されるポップアップ・ウィンドウ」
6.1.23項「Oracle Business Intelligenceの管理対象サーバーのフェイルオーバー時にエージェントを保存できない問題」
SOAエンタープライズ・デプロイメント・トポロジおよびWebCenterエンタープライズ・デプロイメント・トポロジのアプリケーション層は、匿名RMI接続に対して保護することを強くお薦めします。構成済サブセットの外部からの中間層に対するRMIアクセスを防止するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプに含まれる接続フィルタの構成に関するトピックの手順に従ってください。次に記載する部分を除くすべての手順を実行してください。
デフォルト接続フィルタを構成する手順は実行しないでください。カスタム接続フィルタを構成する手順を実行します。
「接続フィルタ・ルール」フィールドで、中間層サブネットからサーバーに対するすべてのプロトコル・アクセスを許可し、サブネット外からはHTTP(S)アクセスのみを許可します。次に例を示します。
nnn.nnn.0.0/nnn.nnn.0.0 * * allow 0.0.0.0/0 * * allow t3 t3s
Oracle Fusion Middlewareでは、管理対象サーバーのクラスタに対するOracle HTTP Serverルーティングに関して、mod_wls_ohsのみがサポートされ、mod_wlはサポートされません。
Oracle Fusion Middlewareの高可用性デプロイメントでは、『Oracle Fusion Middleware高可用性ガイド』およびOracle Fusion Middlewareのエンタープライズ・デプロイメント・ガイドに記載されている構成手順のみを使用することを強くお薦めします。
フェイルオーバー時に、「SOAコンポーザ」ダイアログ・ボックスを操作中で、接続サーバーが停止している場合、「Target Unreachable, 'messageData' returned null」などのエラーが返されます。
「SOAコンポーザ」での操作を続けるには、新規ブラウザ・ウィンドウを開き、「SOAコンポーザ」に移動します。
コールド・フェイルオーバー・クラスタ(CFC)環境で、Fusion Middleware Controlの「Webサービス・ポリシー」ページにアクセスすると、次の例外が表示されます。
Unable to connect to Oracle WSM Policy Manager. Cannot locate policy manager query/update service. Policy manager service look up did not find a valid service.
これを回避するには、次のいずれかのオプションを実行します。
SSL証明書の別名となる仮想ホスト名を作成し、キーストアに追加します。
startWeblogic.shまたはstartWeblogic.cmdファイルのJAVA_OPTIONSパラメータに-Dweblogic.security.SSL.ignoreHostnameVerification=trueを追加します。
相互にミラー化されている2つ以上のOracle Identity Federationサーバーがあり、フロントエンドにロード・バランサがある高可用性環境でSSLを設定する場合、次の2つの方法があります。
SSL接続がユーザーとロード・バランサの間をつなぐように、ロード・バランサでSSLを構成します。この場合、ロード・バランサによって使用されるキーストアおよび証明書には、ロード・バランサのアドレスを参照するCNが含まれます。
ロード・バランサとWLS/Oracle Identity Federation間の通信では、SSLの使用は任意です(SSLを使用する場合、Oracle WebLogic Serverでは、キーストアおよび証明書がロード・バランサによって信頼されているかぎり、どのキーストアや証明書でも使用できます)。
Oracle Identity FederationサーバーでSSLが構成されているため、SSL接続はユーザーとOracle Identity Federationサーバー間のものです。この場合、ユーザーがロード・バランサのホスト名を使用して接続するため、Oracle WebLogic Server/Oracle Identity Federationのキーストアおよび証明書のCNはロード・バランサのアドレスを参照する必要があり、証明書CNがロード・バランサのアドレスと一致している必要があります。
つまり、ユーザーに接続されるSSLエンドポイント(ロード・バランサまたはOracle WebLogic Server/Oracle Identity Federation)のキーストアおよび証明書には、ロード・バランサのホスト名に設定されたCNが含まれる必要があります。ユーザーは、そのアドレスを使用してOracle Identity Federationに接続するためです。
高可用性環境では、オンライン・ヘルプの使用中に環境内のいずれかのマシンでフェイルオーバーが発生すると、アプリケーションのフェイルオーバー時にオンライン・ヘルプのコンテキストが失われる可能性があります。
たとえば、フェイルオーバー前に選択されていたトピックがオンライン・ヘルプの目次から欠落する可能性や、最後のオンライン・ヘルプの検索結果が失われる可能性があります。
データは失われていないため、フェイルオーバー後の次のオンライン・ヘルプ・リクエストは、適切に処理されます。
Oracle Fusion Middleware 11gリリース1 (11.1.1)のパッチ・セット2では、Application Server Cluster Ready Services (ASCRS)に新機能が追加されており、ユーザーは、Oracle Databaseコンソール・サービスのASCRSデータベース・リソースを作成できます。ASCRSを使用してASCRSデータベース・リソースを作成する方法の詳細は、『Oracle Fusion Middleware高可用性ガイド』の「Cluster Ready Servicesの使用方法」の章にあるOracle Databaseリソースの作成に関する項を参照してください。
UNIXではOracle DatabaseコンソールでCFCを有効化できるため、この機能はUNIXで使用できます。
ただし、Windowsでは、Oracle Databaseコンソール・サービスでCFCがサポートされません。そのため、Windowsでは、ASCRSを使用してOracle Databaseコンソール・サービスのデータベース・リソースを作成できません。
Oracle RACインスタンスのフェイルオーバー時にワークリスト構成UIまたはSOAコンポーザ・アプリケーションを通じて(ヒューマン・ワークフローまたはBPELで使用される)ルールセットを更新すると、新規ルールのメタデータがデータベースに登録されないことがあります。この場合、手動で再試行する必要があります。ただし、古いバージョンのメタデータは、エラーなしで使用を継続できます。
Oracle RACインスタンスのフェイルオーバー時に大量のルールを含むタスクが再デプロイされる場合、状況によってはエンド・ユーザーが手動で再試行する必要があります。
アクティブ/アクティブのOracle SOAクラスタでノード障害が発生した場合、受信アクティビティのリクエスト/レスポンス操作のタイムアウト設定は、あるノードから他の1つ以上のノードに伝播されません。これらのアクティビティがスケジュールされていたサーバーで障害が発生した場合、サーバーの再起動時にスケジューラで各アクティビティを再スケジュールする必要があります。
WLS LDAPストアに基づくローカル・ファイルと外部LDAPストアの再関連付けを行ってから、現在の環境でスケール・アウトおよびスケール・アップ操作を実行すると、その操作は失敗します。この障害を回避するには、スケール・アップまたはスケール・アウト操作を実行する前に次の手順を実行します。
DOMAIN_HOME/binディレクトリにあるsetDomainEnv.shファイルを編集し、ファイルに-Dcommon.components.home=${COMMON_COMPONENTS_HOME}および-Djrf.version=11.1.1という変数を追加します。
これらの変数をEXTRA_JAVA_PROPERTIESに追加します。例:
EXTRA_JAVA_PROPERTIES="-Ddomain.home=${DOMAIN_HOME}
-Dcommon.components.home=${COMMON_COMPONENTS_HOME} -Djrf.version=11.1.1
.
.
.
ファイルを保存して、引き続きスケール・アウトまたはスケール・アップ操作を実行します。
SOAクラスタで次のSQLIntegrityConstraintViolationExceptionが発生することがあります。
[TopLink Warning]: 2010.04.11 14:26:53.941--UnitOfWork(275924841)--Exception [TOPLINK-4002] (Oracle TopLink - 11g Release 1 (11.1.1.3.0): Internal Exception: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (JYIPS2RC4B49_SOAINFRA.SYS_C0035333) violated . . .
これは不具合ではありません。クラスタ環境では、同じグループのメッセージが両方のノードに送信されると、一方のノードが最初のメッセージの例外に該当するとバインドされます。アプリケーションではこの例外が把握され、正しく処理されます。どの機能も中断されません。
この例外は、サーバーを再起動して既存のグループに対するメッセージを送信した後に、単一ノードで発生する可能性もあります。また、この例外は、一番最初のメッセージで発生します。
つまり、この例外はアプリケーションのデザイン内のものであり、機能には影響しません。このため、この例外はSOA診断ログで重大なものとして記録されません。
ただし、Toplinkでは、この例外はサーバー・ログに記録されます。
特定のWebLogicクラスタ・プロセスのクラッシュ・シナリオでは、WS-ATリカバリの結果、スレッドがスタックしてサーバーが警告状態になります。このような場合、WS-ATデータ・リカバリは、ログに失敗状態を示すメッセージが記録されても成功しますが、これはコミット確認がこのシナリオでは適切に処理されないためです(この問題は、シナリオにトランザクションのロールバックが含まれる場合は発生しません)。サーバーはこの警告状態で動作し続けることが可能ですが、スレッドはトランザクション破棄のタイムアウト(デフォルトで24時間)に到達するまでスタックのままです。この問題を回避するには、サーバーを再起動してスタック・スレッドを削除し、警告状態を解消します。この問題のパッチは、Oracleサポートから取得できます。
Oracle Fusion Middleware Oracle Enterprise Content Management Suiteのエンタープライズ・デプロイメント・ガイドに含まれる、UCMの許可ホストのリストに対するI/PMサーバーのリスニング・アドレスの追加に関する項および『Oracle Fusion Middleware高可用性ガイド』に含まれる、UCMの許可ホストのリストに対するI/PMサーバーのリスニング・アドレスの追加に関する項では、Oracle UCMの許可ホストのリストに対し、Oracle I/PM管理対象サーバーのリスニング・アドレスのホスト名に基づくフィルタを追加する方法について説明しています。
Oracle UCMでホスト名ベースのフィルタ(config.cfgファイル)を使用する場合、Oracle I/PMからOracle UCMへのドキュメントの大量アップロードが発生するシステムでは、待機時間やパフォーマンスが大幅に悪化する可能性があります。この問題の原因は、Oracle I/PMサーバーからの接続を許可するためにOracle UCMで必要とされるDNSの逆引き参照です。障害保護に対応したシステムを構成する場合や、異なるホストにリストアする場合、ホスト名ベースのフィルタを使用することをお薦めします(ホスト名ベースのフィルタを使用すると、使用される構成がIPに依存しなくなるため)。ただし、アップロードのパフォーマンスを改善する必要がある場合は、かわりにIPベースのフィルタを使用できます。これを行うには:
/u01/app/oracle/admin/domainName/ucm_cluster/config/config.cfgファイルを編集し、次の部分を削除するかコメント・アウトします。
SocketHostNameSecurityFilter=localhost|localhost.mydomain.com|ecmhost1vhn1|ecmhost2vhn1 AlwaysReverseLookupForHost=Yes
WLS_IPM1およびWLS_IPM2管理対象サーバー(それぞれECMHOST1VHN1およびECMHOST2VHN1)のIPアドレス(リスニング・アドレス)を次のようにSocketHostAddressSecurityFilterパラメータ・リストに追加します。
SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1|X.X.X.X|Y.Y.Y.
ここで、X.X.X.XおよびY.Y.Y.Yは、それぞれWLS_IPM1とWLS_IPM2のリスニング・アドレスです。127.0.0.1も、この例のように追加する必要があります。
UCMサーバーを再起動します。
フェイルオーバーの進行中に、Oracle Business Process Management Suiteのワークリスト・アプリケーションの「アクション」ドロップダウン・メニューを使用してタスクにアクションを実行すると、次のような例外がスローされることがあります。
<oracle.adf.view.rich.component.fragment.UIXInclude> <ADF_FACES-10020> <Tear
down of include component context failed due to an unhandled e
xception.
java.util.NoSuchElementException
at java.util.ArrayDeque.removeFirst(ArrayDeque.java:251)
at java.util.ArrayDeque.pop(ArrayDeque.java:480)
at
oracle.adfinternal.view.faces.context.ApplicationContextManagerImpl.popContext
Change(ApplicationContextManagerImpl.java:66)
.
.
.
この場合、タスクの承認または却下は処理されません。
この問題を回避するには、次のいずれかのアプローチを使用します。
「アクション」ドロップダウン・メニューを使用してタスクにアクションを実行するかわりに、タスク・フォームを使用してアクションを実行します。
エラー・メッセージの確認後にリフレッシュを実行します。その後、「アクション」ドロップダウン・メニューを使用してアクションを再度実行します。
SOAクラスタのOracle SOAワークリスト・アプリケーションでClassCastExceptionsが発生することがあります(java.lang.ClassCastException: oracle.adf.model.dcframe.DataControlFrameImplがログに記録されます)。その結果、ワークリスト・アプリケーションの状態をクラスタ内の他の管理対象サーバーにレプリケートできなくなる可能性があります。ワークリスト・アプリケーションおよび対応するユーザー・セッションは、例外のスロー後も使用できますが、クラスタ内の他のサーバーに対するフェイルオーバーは、すべて失敗します。
この問題の回避策はありません。
この問題を解決するには、Oracle Bug#9561444のパッチをダウンロードして問題を解決します。次の手順を実行します。
パッチを取得するには、次のURLにあるMy Oracle Support(以前のOracleMetalink)にログインします。
「パッチと更新版」タブをクリックします。
「パッチ検索」セクションで、「パッチIDまたは番号」フィールドに9561444を入力し、プラットフォーム・フィールドの次のフィールドに現在のプラットフォームを入力します。
「検索」をクリックします。
「パッチ検索」ページで「パッチID」列のパッチ番号をクリックします。この操作により、ページ・コンテンツが変更され、パッチの詳細情報が表示されます。
「ダウンロード」をクリックしてパッチをダウンロードします。
11.2 Oracle RACデータベースの既知の問題のため、AQ通知およびサーバー側TAFを設定する場合、srvctlを使用する必要があります。DBMS_SQLパッケージを使用しても、正常に動作しません。
次に、srvctlの使用例を示します。
srvctl modify service -d orcl -s orclSVC -e SELECT -m BASIC -w 5 -z 5 -q TRUE
この例の変数の意味は次のとおりです。
orcl - データベース名
orclSVC - ミドルウェア・コンポーネントに使用されるサービス名
SELECT - フェイルオーバー・タイプ
BASIC - フェイルオーバー方式
5 - フェイルオーバー遅延
5 - フェイルオーバー再試行
TRUE - AQ HA通知をTRUEに設定
このコマンドの使用方法の詳細は、Oracle 11.2 Oracle Databaseのドキュメントを参照してください。
Oracle RACインスタンスのフェイルオーバー時に、Oracle I/PMおよびOracle UCMのファイル処理で一部のファイルがUCMに適切にロードされないことがあります。
Oracle I/PMで処理される着信ファイルは、入力フォルダに配置されます。Oracle I/PMは、入力フォルダのファイルを処理し、Oracle RACデータベースを基盤とするOracle UCMにそれらのファイルを配置します。状況によっては、Oracle RACインスタンスに障害が発生したときに再試行が正常に実行されないことがあり、その場合、着信ファイルは処理されません。これらの未処理のファイルは、エラー・フォルダに配置されます。未処理のファイルは、手動で入力フォルダに戻し、処理することが可能です。
Oracle BI Publisherでレポートを作成し、そのレポートを保存する前に管理対象サーバーがフェイルオーバーされると、そのフェイルオーバーはシームレスでなくなる可能性があります。たとえば、レポートを保存しようとすると、システムが応答しなくなることがあります。
この問題が発生したら、「ホーム」や「カタログ」などのヘッダー・リンクの1つをクリックして、Oracle BI Publisherのログイン・ページに移動します。その後、ログインしてレポートを再度作成および保存します。
管理対象サーバーのフェイルオーバー時に、Oracle BI Publisherのレイアウト・エディタでWebベースのレイアウトを開いたり作成したりすると、次のエラーが表示されることがあります。
Failed to load: object_name
Please contact the system administrator.
この問題を回避するには、メッセージを閉じ、「ホーム」や「カタログ」などのヘッダー・リンクの1つをクリックしてログイン・ページに移動します。
Oracle BI Publisherでジョブをスケジュールする場合、管理対象サーバーのフェイルオーバー後、「発行」をクリックすると、ログイン・ページのHTMLソースが記載された大きなポップアップ・ウィンドウが表示されます。
この問題を回避するには、メッセージ・ウィンドウを閉じ、「ホーム」や「カタログ」などのヘッダー・リンクの1つをクリックしてログイン・ページに移動します。レポート・ジョブを再作成する必要があります。
Oracle Business Intelligence Webインタフェースでエージェントを作成し、そのエージェントを保存する前に管理対象サーバーがフェイルオーバーされると、エージェントの保存時にエラーが発生します。
この問題を回避するには、Oracle Business Intelligenceを一度ログアウトしてからログインしなおし、エージェントを再作成します。
Windowsにおいて、Oracle Business Intelligenceクラスタで仮想IPを有効化してサーバー全体の移行を設定した後、分析機能またはBusiness Intelligence Publisherにアクセスしようとすると、そのアクセス試行は失敗し、次のエラー・メッセージが返されます。
Unable to Sign In An error occurred during authentication. Try again later or contact your system administrator.
この問題を回避するには、次の操作を実行します。
すべての管理対象サーバーのsetDomainEnv.cmdファイルで、oracle.bi.management.config.urlStrategyプロパティの値をASK_WEBLOGICに設定します。たとえば、setDomainEnv.cmdファイルで次のようにエントリを作成します。
# This extra property causes WebLogic to look at the localhost instead of the # virtual IP set EXTRA_JAVA_PROPERTIES=%EXTRA_JAVA_PROPERTIES% -Doracle.bi.management.config.urlStrategy=ASK_WEBLOGIC
ASK_WEBLOGICプロパティを指定する前述の2つの行は、setDomainEnv.cmdファイルでは1つの行に記述する必要があることに注意してください。
この問題は、Oracle Single-Sign On 10gからOracle Access Manager 11gへアップグレードしたOracle Portal、Forms、ReportsおよびDiscoverer 11g環境での認証で発生します。
最初にOracle Portal、Forms、ReportsおよびDiscoverer 10gがOracle Access Managerにアップグレードされた環境で、続けてOracle Portal、Forms、ReportsおよびDiscoverer 11gのインストールを実行する場合、満たす必要のある要件がいくつかあります。
後続のOracle Portal、Forms、ReportsおよびDiscoverer 11gのそれぞれのインストールにおいて、元のOracle Single Sign-On 10gインスタンスを保持し、Oracle Portal、Forms、ReportsおよびDiscoverer 11gの追加インストールの実行中、新規Oracle Access Manager 11gインスタンスに加え、元のインスタンスをアクティブに実行する必要があります。
これはOracle Portal、Forms、ReportsおよびDiscoverer 11gがOracle Access Manager 11gに対して直接インストールできないために必要になります。
後続の従来どおりのインストールを完了した後、Oracle Single Sign-On 10gからOracle Access Manager 11gへのアップグレード手順を再度実行する必要があります。アップグレード・ロードマップなどの詳細は、Oracle Fusion Middleware Oracle Identity and Access Managementアップグレード・ガイドを参照してください。
この手順によって、新規のOracle Portal、Forms、ReportsおよびDiscoverer 11gインスタンスがOracle Access Manager 11gにアップグレードされます。
このような考慮事項は、Oracle Single Sign-On 10gからOracle Access Manager 11gに最初にアップグレードした後、環境に追加、またはインストールした複数のOracle Portal、Forms、ReportsおよびDiscoverer 11g中間層のある環境にのみ適用されます。
JMSインスタンスがBI Publisherスケジューラ・クラスタにないことがまれにあります。
この問題を解決するには、BI PublisherアプリケーションをWebLogic Server管理コンソールから再起動します。
BI Publisherアプリケーションを再起動するには:
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「デプロイメント」をクリックします。
「bipublisher(11.1.1)」を選択します。
「停止」をクリックします。
アプリケーションの停止後、「起動」をクリックします。
SOA RAC環境でシングルトン・サーバーのRACフェイルオーバーが発生している場合、EMでリカバリ可能に見える未配信のレコードのリカバリは失敗します。
SOAクラスタでは、次のシナリオはサポートされていません。
中間プロセスのreceiveを含む同期BPELプロセス。
非同期サービスをコールする同期BPELプロセス。
同期プロセスからのコールバック。
この項では、構成に関する問題およびその回避策について説明します。次のトピックが含まれています。
6.2.3項「ロード・バランサのCookie永続性の設定によってWindowsプラットフォームのPortalへのアクセス時に断続的なタイムアウトが発生する問題」
6.2.7項「Oracle RACフェイルオーバーで作成されるリカバリ不可能な重複ヒューマン・ワークフロー・インスタンス」
6.2.18項「Oracle Business Intelligence管理対象サーバーのスケール・アウト後のサーバー起動パラメータ未設定」
6.2.24項「RACマルチ・データソースを使用して構成する場合、最初に定義したRACインスタンスはドメイン起動時に使用できる必要がある」
クラスタ環境では、各ノードは、インバウンド再試行用にメモリー内に独自のHasmapを維持します。jca.retry.countプロパティは、インバウンド再試行機能で3と指定されます。ただし、ノードごとに3回試行されます。結果として、クラスタ環境に2つのノードがある場合、合計再試行回数は6になります。
クラスタ内のすべてのマシンは、同じタイムゾーンに存在する必要があります。WANクラスタは、Oracle Fusion Middlewareの高可用性ではサポートされません。同じタイムゾーンのマシンであっても、コマンドラインで起動されると問題が発生する可能性があります。サーバーの起動には、ノード・マネージャを使用することをお薦めします。
Oracle Portalのアクティブ/アクティブ設定では、ロード・バランサのCookie永続性は要求されません。Windowsに対するPortalデプロイメントにおいて、特定のハードウェア・ロード・バランサでCookie永続性をアクティブCookie挿入に不注意で設定すると、Oracle Portalへのアクセス時に断続的なタイムアウトが発生します。
一部の環境では、コンポーネントが再起動またはフェイルオーバーされた直後に、そのコンポーネントの間違ったステータスがOracle WebLogic Fusion Middleware Controlに表示されることがあります。
スケール・アウトされたクラスタ環境で、大量のBPELインスタンスがデータベースに蓄積されると、データベースのパフォーマンスが低下し、MANY THREADS STUCK FOR 600+ SECONDSというエラーが生成されます。
このエラーを回避するには、データベースから古いBPELインスタンスを削除してください。
XA以外の環境では、ローカル・トランザクションにおいて、メッセージがインバウンド・アダプタからエンドポイントまでただ1回のみ配信されることがMQSeriesアダプタにより保証されません。この場合、インバウンド・メッセージがエンドポイントにパブリッシュされ、トランザクションがコミットされる前にSOAサーバーが停止すると、インバウンド・メッセージはロールバックされ、同じメッセージが再度デキューされてエンドポイントにパブリッシュされます。これにより、アウトバウンド・キューに余分なメッセージが作成されます。
XA環境では、MQメッセージは失われませんが、一貫性のない状態であるためキュー・マネージャによって保留されます。保留メッセージを取得するには、キュー・マネージャを再起動します。
Oracle Human WorkflowがトランザクションをコミットするとすぐにBPELに制御が戻され、それとほぼ同時にBPELがトランザクションをコミットします。このウィンドウ間でOracle RACインスタンスが停止すると、フェイルオーバー時にメッセージが再試行され、それがタスクの重複の原因になる場合があります。重複タスクを示す方法は2通りあり、worklistappに表示されるか、リカバリ不可能なBPELインスタンスが作成されます。このBPELインスタンスは「BPELリカバリ」に表示されます。このタスクはすでに完了しているため、このBPELインスタンスはコンシューマとしてリカバリできません。
次の情報は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の第10章「トポロジの管理」に記載されています。
管理サーバーのノードを計画的に停止する(管理サーバーのマシンを再起動またはシャットダウンする)場合、管理サーバー自体が停止する前に、OS NFSサービスが無効化されることがあります。これによって、(OSレベルでのサービス構成に応じて)管理サーバーのドメイン・ディレクトリでファイルが不足していることが検出され、他のノードでのドメイン・ディレクトリの削除がトリガーされることがあります。このため、フレームワークでは、domain_dir/fmwconfig/の一部のファイルが削除されることがあります。この動作は、通常、マシンの異常、電力喪失、マシンの故障などの計画外停止時間では確認されません。このような動作を回避するには、再起動を実行する前に管理サーバーを停止するか、適切なOS構成を使用してサービスの順序を設定し、管理サーバーのプロセスよりも優先順位を低くすることでNFSサービスを無効化します。サービス順序の対応する必須構成については、使用しているOSの管理ドキュメントを参照してください。
SOA B2B TCP/IPプロトコルでは、高可用性フェイルオーバーはサポートされません。このことは、主にHL7 over MLLPを使用したデプロイメントに影響します。クラスタ環境のインバウンド通信では、すべてのB2Bサーバーがアクティブであり、インバウンド・トラフィックに公開されたアドレスは、ロード・バランサの仮想サーバーです。また、アクティブな管理対象サーバーが使用できなくなる停止時間には、永続TCP/IP接続が失われ、クライアントは接続を再確立する必要があります。
複数のネットワーク・カードが搭載されたサーバーにOracle WebLogic Serverをインストールする場合、必ず管理サーバーのリスニング・アドレスを指定してください。使用するアドレスは、管理サーバー通信での使用を希望するネットワーク・カードのDNS名またはIPアドレスである必要があります。
リスニング・アドレスを設定するには:
Oracle WebLogic Server管理コンソールで、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「管理サーバー」をクリックします。
「チェンジ・センター」の「ロックして編集」をクリックして編集を可能にします。
リスニング・アドレスを入力します。
「保存」をクリックします。
「チェンジ・センター」の「変更のアクティブ化」をクリックします。
Oracle RACでの一部のSOAデプロイメントでは、Oracle RAC構成における個別データソースの即時利用可能な構成に加えてパラメータを設定する必要があります。追加パラメータは次のとおりです。
データソースごとにoracle.jdbc.ReadTimeout=300000プロパティ(300000ミリ秒)を追加します。
ReadTimeoutパラメータの実際の値は、他の考慮事項に応じて変化する可能性があります。
ネットワークの信頼性が低い場合、サーバーの接続が突然切断されても、クライアントでは頻繁に発生する切断を検出するのが困難です。デフォルトでは、Linux上で稼働するクライアントは、突然の切断を検出するのに7200秒(2時間)かかります。この値は、tcp_keepalive_timeプロパティの値と同じです。切断をより迅速に検出するようアプリケーションを構成するには、tcp_keepalive_time、tcp_keepalive_intervalおよびtcp_keepalive_probesプロパティの値をオペレーティング・システム・レベルでより小さい値に設定します。
|
注意:
|
たとえば、WebLogic Server管理対象サーバーが稼働するシステムでtcp_keepalive_time=600を設定します。
また、接続記述子のDESCRIPTION句にENABLE=BROKENパラメータを指定する必要があります。例:
dbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PRO TOCOL=TCP)(HOST=node1-vip.mycompany.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_ NAME=example.com)(INSTANCE_NAME=orcl1)))
この結果、データソース構成は次のようになります。
<url>jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PRO
TOCOL=TCP)(HOST=node1-vip.us.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=example.com)(INSTANCE_NAME=orcl1)))</url>
<driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
<properties>
<property>
<name>oracle.jdbc.ReadTimeout</name>
<value>300000</value>
</property>
<property>
<name>user</name>
<value>jmsuser</value>
</property>
<property>
<name>oracle.net.CONNECT_TIMEOUT</name>
<value>10000</value>
</property>
</properties>
Oracle B2B高可用性(HA)環境では、メッセージ順序付けおよびMLLPはサポートされません。
Oracle FMW資格証明ストアでは、トランスポート・プロトコルについて定義するユーザー名とパスワードが保持されます。このような資格証明にデフォルトのファイル・ストアを使用すると、ユーザー名とパスワードを変更しても、ノード間に伝播されません。『Oracle Fusion Middleware高可用性ガイド』および『Oracle Fusion Middlewareエンタープライズ・デプロイメント・ガイド』で必須として説明されているとおり、これらの資格証明をクラスタ内のノード間で同期させるには、セントラルLDAPを使用する必要があります。
Oracle Identity Navigatorの保護されたリソースを作成するには、oamadminアカウントを使用してhttp://admin.mycompany.com/oamconsoleにあるOracle Access Managerコンソールにログインします。次の手順を実行します。
ナビゲーション・ウィンドウで、「アプリケーション・ドメイン」→「IDMDomainAgent」を展開します。
「リソース」をクリックします。
「参照」タブの下にあるツールバーの「作成」をクリックします。
次の情報を入力します。
タイプ: http
ホスト識別子: IDMDomain
リソースURL: /oinav
「適用」をクリックします。
ナビゲーション・ウィンドウで、「アプリケーション・ドメイン」→「IDMDomainAgent」→「認証ポリシー」を展開します。
「保護された上位レベル・ポリシー」をクリックします。
「参照」タブの下にあるツールバーの「編集」をクリックします。
「リソース」ボックスで、「+」をクリックします。
リストからリソース「/oinav」を選択します。
「適用」をクリックします。
ナビゲーション・ウィンドウで、「アプリケーション・ドメイン」→「IDMDomainAgent」→「認可ポリシー」を展開します。
「保護されたリソース・ポリシー」をクリックします。
「参照」タブの下にあるツールバーの「編集」をクリックします。
「リソース」ボックスで、「+」をクリックします。
リストからリソース「/oinav」を選択します。
「適用」をクリックします。
Oracle Fusion Middleware高可用性の構成でフロントエンド・ホストを構成する場合は、ドメイン名を含めたホストの完全名を使用することをお薦めします。ホスト名のみでなく、ホストの完全名を使用します。
たとえば、myhostが高可用性構成のフロントエンド・ホストの名前の場合、DNSまたはローカル・ホスト名解決ファイルが定義するもの(例: /etc/hosts)として、フロントエンド・ホストURLをmyhost.mycompany.comなどの完全修飾ホスト名に設定します。
管理対象サーバーwls_ods(x)は、次の状況では中断ステータスになる場合があります。
データソースのデータベース接続が誤っているか、不完全です。
ホストがデータベースの完全修飾ホストではありません。
管理対象サーバーwls_ods(x)のステータスを修正するには:
データソースで、データベース接続が正しく、ドメインで完全であることを確認します。
データソースでは、データベースのホスト名がドメインで完全修飾ホスト名であることを確認します。
「テスト」ボタンを選択して接続を確認します。
システム・コンポーネントのスケール・アウトのプロセスでは、Fusion Middleware Controlの「容量管理」ページの「可用性」タブで「プライマリ/セカンダリ構成」セクションがブラウザで非表示になることがあります。この問題はMicrosoft Internet Explorerバージョン7.0.5730.11を使用してスケール・アウト・プロセスを実行すると発生します。
この問題を回避するには、スケール・アウトにMicrosoft Internet Explorerバージョン7.0.5730.11ではなく、Google Chromeなど別のブラウザを使用します。
Oracle Business Intelligenceのスケール・アウト後、サーバー起動パラメータが正しく設定されていません。この問題を回避するには、BI管理対象サーバーのスケール・アウトのためのサーバー起動パラメータを、次を含むように更新します。
-Dserver.group=obi arguments
Oracle HTTP Server 11gのOracleインスタンスを、NAS、NFS、SANストレージなどの共有記憶域に構成する場合、共有ドライブではなく、ローカル・ドライブにロック・ファイルが作成されていることを確認する必要があります。これを行わないと、Oracle HTTP Serverでパフォーマンスの問題が生じることがあります。次のステップを実行して、ローカル・ファイル・システムのLockFileディレクティブを示すようにします。
WEBHOST1およびWEBHOST2でOHSインスタンスを停止します。
テキスト・エディタでファイルORACLE_INSTANCE/config/OHS/ohs_name/httpd.confを開きます。
httpd.confファイルのpreforkおよびworker MPMの両方の構成ブロックで構成されているLockFileディレクティブを検索します。これは次のようになります。
LockFileORACLE_INSTANCE/diagnostics/logs/COMPONENT_TYPE/COMPONENT_NAME/http_lock
該当するMPM構成のLockFileディレクティブを、次のようにローカル・ファイル・システムを示すように変更します。
LockFile /local_disk/path/http_lock
Oracle HTTP Serverを再起動します。
LockFileディレクティブによって指定されたディレクトリにhttp_lockファイルが存在することを確認します。
高可用性Classic環境には通常、Classic OHSインスタンスの前面にロード・バランサがあります。OAM 11gを使用してクラシック・インスタンスを構成する場合、構成ウィザードは自動的にOSSOエージェントを構成します。OSSOエージェントには、個別のClassic OHSインスタンスURLが含まれます。2つのClassicインスタンスで構成される高可用性クラスタでは、構成ウィザードが自動的に2つのOSSOエージェントを構成します。各OSSOエージェントには、1つのClassic WebtierインスタンスURLのURL情報が含まれます。
高可用性クラスタでは、ロード・バランサURLを指し示すOSSOエージェントを再作成する必要があります。
ロード・バランサURLを指し示すOSSOエージェントを再作成するには:
OAMコンソールから、「新規OSSOエージェント」をクリックしてOSSOウィザード・アプリケーションを開きます。
次の情報を入力します。
名前: 名前を入力します。
トークン・バージョン: デフォルト設定のv3.0を使用します。
ベースURL: ロード・バランサURL(http://haqaedg04.us.example.com:7788など)を入力します。
管理者ID: 空白のままにします。
管理者情報: 空白のままにします。
ホスト識別子: 「名前」フィールドからデフォルト値を保持します。
ポリシーの自動作成: この設定を選択して有効にします。
新規OSSOエージェントのosso.confファイルをOAMサーバーからClassic Webインスタンスのconfigディレクトリにコピーします。
構成ウィザードでGridLinkデータソースを作成する場合、データベースのサービス名が小文字のみを使用しており、修飾されたドメイン名であることを確認する必要があります。たとえば、<mydbservice>.us.example.comと入力します。「サービス名」フィールドは、「GridLink RACコンポーネント・スキーマの構成」画面にあります。
|
注意: Oracle RACサービス名は、データベースに定義されていますが、固定名ではありません。データベース・ドメイン名( |
リクエストの転送に関連するOracle RTDの問題のために、フロントエンドURLは、Oracle RTDを含むデプロイメントのバックエンドURLと同じである必要があります。Oracle RTDのフロントエンドURLを設定するには、Oracle Business Intelligence EDGタスク・フローに示された点の次の手順にリストされた手順を実行します。
bi_server1管理対象サーバーのリスニング・アドレスの設定に関する項にリストされた手順の実行後、次のように、bi_server1管理対象サーバーのフロントエンドURLを設定します。
管理コンソールにログインします。
チェンジ・センターで、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server1」を選択します。bi_server1の設定ページが表示されます。
「プロトコル」タブをクリックします。
「HTTP」タブをクリックします。
「フロントエンド・ホスト」フィールドをAPPHOST1VHN1 (使用するbi_server1リスニング・アドレス)に設定します。
「保存」をクリックし、「変更のアクティブ化」をクリックします。
bi_server2管理対象サーバーのリスニング・アドレスの設定に関する項にリストされた手順の実行後、次のように、bi_server2管理対象サーバーのフロントエンドURLを設定します。
管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で「bi_server2」を選択します。bi_server2の設定ページが表示されます。
「プロトコル」タブをクリックします。
「HTTP」タブをクリックします。
「フロントエンド・ホスト」フィールドをAPPHOST2VHN1 (使用するbi_server2リスニング・アドレス)に設定します。
「保存」をクリックし、「変更のアクティブ化」をクリックします。
Oracle Business Intelligence構成アシスタントを使用してBIシステムをスケール・アウトしているときに、次のエラーが発生します。
INST-08075: Weblogic Server 10.3.6.0がインストールされましたが、Weblogic Server TemporaryがBIドメインで使用されます。
このエラーを回避するには、次の手順を実行します。
編集のためにMW_HOME/registry.xmlを開きます。
次の行を探します。
<component name="WebLogic Server" version="10.3.6.0" InstallDir="ORACLE_BASE/fmw/wlserver_10.3">
この行を次の行に変更します。
<component name="WebLogic Server" version="Temporary" InstallDir="ORACLE_BASE/fmw/wlserver_10.3"
ファイルを保存し、閉じます。
Oracle Business Intelligence構成アシスタントに戻り、過去の「BIシステムのスケール・アウトの詳細」画面を続行します。
registry.xmlのエントリをversion="10.3.6.0"に戻します。
OPSSのRACデータソースを構成する場合、Oracle GridLinkデータソース・タイプを使用することをお薦めします。RACマルチ・データソースを使用する場合、最初のドメイン起動中にマルチ・データソース定義にリストされている最初のRACインスタンスを使用可能にする必要があります。リストされている最初のRACインスタンスを使用しないと、構成は失敗します。
JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再起動の動作を確認することを強くお薦めします。NFSの実装に応じて、フェイルオーバーおよび再起動後に異なる問題が発生する可能性があります。
サーバーの再起動の動作を確認するには、WebLogic Serverの実行時に、それらのサーバーをホストするノードを異常停止させます。
サーバーをサーバー移行用に構成した場合、サーバーは、フェイルオーバー期間の経過後にフェイルオーバー・ノードで自動的に起動します。
サーバーをサーバー移行用に構成しなかった場合、ノードが完全に再起動した後に同じホスト上のWebLogic Serverを手動で再起動できます。
予期しないしマシン障害後にOracle WebLogic Serverが再起動しない場合、サーバー・ログ・ファイルに次のエラー・エントリが表示されます。
<MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent
store "_WLS_server_soa1" could not be deployed:
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file
"_WLS_SERVER_SOA1000000.DAT"
at weblogic.store.io.file.Heap.open(Heap.java:168)
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88)
...
java.io.IOException: Error from fcntl() for file locking, Resource
temporarily unavailable, errno=11
このエラーは、NFSv3システムでファイル・ストアに対するロックが解放されていないときに発生します。WebLogic Serverは、同じ管理対象サーバーの2つのインスタンスが偶然起動した場合にデータ破損が発生しないように、JMSデータおよびトランザクション・ログを格納しているファイルに対するロックを保持します。NFSv3ストレージ・デバイスはロック所有者を追跡しないため、ロック所有者がクラッシュした場合、NFSはロックを無期限に保持します。このため、予期しないマシン障害とそれに続く再起動の後に、WebLogic Serverがロックを取得しようとしても、失敗する可能性があります。
現在のNFS環境でロックの動作を調整することに無理がある場合、次のいずれかの解決策を使用してログとデータ・ファイルのロックを解除してください。
WebLogic Server管理コンソールを使用して、デフォルト・ファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストアおよび診断ファイル・ストアに対するWebLogicのファイル・ロック・メカニズムを無効にします。そのためには、『Oracle Fusion Middleware高可用性ガイド』のNFSでのファイル・ストアの使用に関する考慮事項に関する項を参照してください。
ロックされている永続ストア・ファイルのコピーを作成し、そのコピーを後続の操作に使用して、手動でログ・ファイルおよびJMSデータ・ファイルのロックを解除し、サーバーを起動します。次の「手動によるログおよびデータ・ファイルのロック解除」を参照してください。
手動によるログおよびデータ・ファイルのロック解除
ロックされている永続ストア・ファイルのコピーを作成し、そのコピーを後続の操作に使用して、手動でログ・ファイルおよびJMSデータ・ファイルのロックを解除し、サーバーを起動します。ロックされている永続ストア・ファイルのコピーを作成するには、そのファイルの名前を変更し、それをコピーして元の名前に戻します。次のサンプル・ステップでは、トランザクション・ログが/shared/tlogsディレクトリに格納され、JMSデータが/shared/jmsディレクトリに格納されていると仮定します。
cd /shared/tlogs mv _WLS_SOA_SERVER1000000.DAT _WLS_SOA_SERVER1000000.DAT.old cp _WLS_SOA_SERVER1000000.DAT.old _WLS_SOA_SERVER1000000.DAT cd /shared/jms mv SOAJMSFILESTORE_AUTO_1000000.DAT SOAJMSFILESTORE_AUTO_1000000.DAT.old cp SOAJMSFILESTORE_AUTO_1000000.DAT.old SOAJMSFILESTORE_AUTO_1000000.DAT mv UMSJMSFILESTORE_AUTO_1000000.DAT UMSJMSFILESTORE_AUTO_1000000.DAT.old cp UMSJMSFILESTORE_AUTO_1000000.DAT.old UMSJMSFILESTORE_AUTO_1000000.DAT
この解決策では、WebLogicのファイル・ロック・メカニズムにより、同じサーバーの複数のインスタンスが偶然起動した場合に発生する可能性のあるデータ破損からの保護が引き続き提供されます。ただし、サーバーは、予期しないマシン障害の後に手動で再起動する必要があります。ファイル・ストアでは、大量のデータを格納する場合、連続した番号が付けられた複数の.DATファイルが作成されます。この場合、すべてのファイルをコピーし、その名前を変更する必要があります。
この項では、ドキュメントの訂正箇所を示します。次のトピックが含まれています。
6.4.2項「『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の訂正箇所」
6.4.3項「『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の訂正箇所」
この項には、『Oracle Fusion Middleware高可用性ガイド』の訂正箇所が含まれます。
次のトピックが含まれています。
Oracle Fusion Middleware 11gドキュメント・セットの複数のマニュアルには、Oracle Fusion Middlewareシステムの要件、前提条件、仕様および動作保証情報に関する情報が含まれます。これらのトピックの最新情報は、Oracle Technology Networkの次のドキュメントを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。これには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報も含まれます。
第5章「Oracle SOA Suiteの高可用性の構成」で、行<Location /DefaultToDoTaskFlow/>は、正しくはmod_wl_ohs.confファイルの<Location /workflow/DefaultToDoTaskFlow/>です。この行のインスタンスは、5.3.13項および5.14.15項にあります。
この項には、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の訂正箇所が含まれます。
次のトピックが含まれています。
6.4.2.5項「Oracle WebLogic Serverのユーザーおよびグループの作成手順におけるLDIFファイル・エラー」
6.4.2.6項「Oracle Internet DirectoryまたはOracle Virtual Directoryでドメインを拡張するときの追加のemctlコマンドの実行」
『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の2010年11月の版では、WebLogic管理サーバーを制御するノード・マネージャの起動の前に、-DDomainRegistrationEnabled=trueを設定する必要があることが記載されていません。例:
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の2010年11月の版では、第8章「Oracle Virtual Directoryでのドメイン拡張」の8.1.1項が空白です。この手順は無視してください。
『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』11gリリース1 (11.1.1.5) (原本部品番号E12035-07)の4.5.5項「Oracle Identity Managementのインストール」は、次のように再編成される必要があります。
「Oracle Fusion Middleware 11g Oracle Identity Managementインストーラの開始」から始まる内容は、4.5.5.1項「Oracle Identity Management 11.1.1.2のインストール」のサブセクション中に存在する必要があります。
4.5.6項「Oracle Identity Management用Oracleホームの11.1.1.2から11.1.1.5へのアップグレード」は4.5.5.2項になります。
1.6項「このガイドの使用」にはエラーがあります。これらは次のように修正する必要があります。
手順11は次のようになります。
Oracle Access Managerを使用している場合は、第12章「Oracle Access Manager 11gでのドメインの拡張」の手順に従います。
手順11から18は項ではなく章を参照する必要があります。
11.4.4項「Oracle WebLogic Serverのユーザーおよびグループの作成」の手順2aのLDIFファイルには、いくつか改行が抜けています。正しくは次のようになります。
dn: cn=orclFAUserReadPrivilegeGroup,cn=Groups,dc=mycompany,dc=com changetype: modify add: uniquemember uniquemember: cn=IDROUser,cn=Users,dc=mycompany,dc=com
「Oracle Internet Directoryでのドメインの拡張」の章と「Oracle Virtual Directoryでのドメインの拡張」の章で、コマンド
./emctl switchOMS ReposURL
の実行を指示され、ローカル要素を有効にして仮想IPアドレスを使用してWebLogic管理サーバーと通信します。このコマンドを実行した後、次のタスクも実行する必要があります。
次のコマンドを発行して、エージェントでその構成を強制的に再ロードします。
./emctl reload
次のコマンドを使用して、このエージェントが正しいアップロードURLを使用していることを確認します。
./emctl status agent
表2-3「推奨ディレクトリ構造」の共有記憶域列は一部の値が欠落しています。次の表エントリの共有記憶域列には「はい」の値があり、これらのディレクトリが共有記憶域にある必要があることを示す必要があります。
IAM_ORACLE_HOME
ASERVER_DOMAIN_HOME
ASERVER_APP_HOME
この項には、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の訂正箇所が含まれます。
次のトピックが含まれています。
6.4.3.1項「BI Publisher構成フォルダの場所の設定後に実行する必要のある追加手順」
6.4.3.2項「共有Oracle BIプレゼンテーション・カタログの場所の設定に関する項の訂正」
6.4.3.3項「共有Oracle BIリポジトリの場所の設定に関する項の訂正」
6.4.3.4項「10.1.1.1をロード・バランサのソースIPアドレスで置き換える」
共有Oracle BI Publisher構成フォルダの場所の設定に関する項の記載に従って、構成フォルダの場所を指定する際にOracle BI Publisherを再起動した後、Oracle BI PublisherのXML構成ファイルを管理対象サーバーから管理サーバーの場所にコピーする必要があります。Oracle BI Publisherでは、管理対象サーバーの再起動時に、管理対象サーバーの構成ディレクトリではなく管理サーバーの集中管理された場所からその構成を読み取ります。
これを行うには、APPHOST1で、xmlp-server-config.xmlファイルをコピーします。コピー元:
ORACLE_BASE/admin/domain_name/mserver/domain_name/config/bipublisher
コピー先:
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/bipublisher
『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の共有Oracle BIプレゼンテーション・カタログの場所の設定に関する項は、次の項で置き換える必要があります。
各プレゼンテーション・サービス・インスタンスでは、Fusion Middleware Controlで指定されたカタログの場所からOracle BIプレゼンテーション・カタログをロードします。
次の手順を実行してください。
既存の(ローカルに公開された)Oracle BIプレゼンテーション・カタログを共有の場所にコピーします。ローカルに公開されたカタログの例は、次のとおりです。
ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/ coreapplication_obipsn/catalog/SampleAppLite
Fusion Middleware Controlで「カタログの場所」を指定する前に、この手順を実行する必要があります。
共有カタログとしてこの項の例に記載されているSampleAppLiteカタログを使用する場合、必ずそのカタログをAPPHOST1からコピーしてください。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウの「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「デプロイメント」をクリックし、次に「リポジトリ」をクリックします。
「構成をロックして編集」をクリックします。
共有Oracle BIプレゼンテーション・カタログの「カタログの場所」を指定します。
Windows環境では、UNCパス名を指定します。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の共有Oracle BIリポジトリの場所の設定に関する項は、次の項に置き換えられる必要があります。
RPD公開ディレクトリの指定
Oracle BIリポジトリのリポジトリ公開ディレクトリを指定します。この場所は、オンライン・リポジトリの変更をクラスタに伝播するために使用します。
Oracle Enterprise Manager Fusion Middleware Controlで次の手順を実行します。
Fusion Middleware Controlにログインします。
「Farm_domain_name」ウィンドウで、「Business Intelligence」ノードを開きます。
「coreapplication」をクリックします。
「デプロイメント」をクリックし、次に「リポジトリ」をクリックします。
「構成をロックして編集」をクリックします。
「リポジトリの共有」を選択し、Oracle BIリポジトリの「RPD公開ディレクトリ」を指定します。
Windows環境では、UNCパス名を指定する必要があります。
「適用」をクリックします。
「変更のアクティブ化」をクリックします。
12.3.4.2項「OAM11gRequestファイルの更新」に示した例のファイルで、ValListMemberパラメータ(10.1.1.1)にリストされたIPアドレスはロード・バランサのソースIPで置き換えてください。
この項では、複数のエンタープライズ・デプロイメント・ガイドに関連する訂正箇所について説明します。リリース・ノートに次の訂正箇所の問題が記載されているすべてのエンタープライズ・デプロイメント・ガイドは、そのリリース・ノートの指定どおりに更新される必要があります。
次のトピックがあります。
『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の第2章「データベースおよび環境の事前構成」の表2-2に、Oracle Business Intelligenceトポロジで使用するポートがリストされています。次の追加情報は、表の「データベース・アクセス」のある行の上に含まれます。
タイプ: BIサーバーおよびBI Publisher JDBCデータソースへのデータベース・アクセス
ファイアウォール: FW1
ポートおよびポート範囲: リスナーへのクライアント接続のためのリスニング・ポート
プロトコル/アプリケーション: SQL*Net
インバウンド/アウトバウンド: 両方
その他の考慮事項およびタイムアウトのガイドライン: タイムアウトはすべてのデータベース内容と、BIに使用するプロセス・モデルのタイプに基づいています。
|
注意: この問題は、『Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のリビジョンE15722-03(原本部品番号)で修正されました。 |
