| Oracle® Fusion Middlewareリリース・ノート 11g リリース1(11.1.1) for Linux x86 B55924-04 |
|
 前 |
 次 |
この章では、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を一度ログアウトしてからログインしなおし、エージェントを再作成します。
Oracle Access Manager 11gを使用してSSOを構成するには、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の「管理コンソールのシングル・サインオンの構成」の章の説明に従って、パッチ10094106を適用する必要があります。
このパッチを適用しない場合、有効な資格証明でOracle WebLogic Serverにデプロイされている保護アプリケーションへアクセスしようとしたときに、「404 Not Found」エラーが表示されることがあります。
この問題は、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 Managementアップグレード・ガイド』のOracle Single Sign-On環境のアップグレードに関する項を参照してください。
この手順によって、新規の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)」を選択します。
「停止」をクリックします。
アプリケーションの停止後、「起動」をクリックします。
Oracle Bug#11847070
フェイルオーバーが発生した場合、タスクの承認中に「タスクの承認」を2回目にクリックしたときにNULLポインタ例外エラー・ウィンドウが表示される場合があります。(NULLポインタ例外エラー・ウィンドウはフェイルオーバー中は常に表示されます。)NULLポインタ例外ウィンドウによって、プロセスが中断されることはなく、承認を完了します。
この項では、構成に関する問題およびその回避方法について説明します。内容は次のとおりです。
6.2.3項「ロード・バランサのCookie永続性の設定によってWindowsプラットフォームのPortalへのアクセス時に断続的なタイムアウトが発生する問題」
6.2.7項「Oracle 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プロパティの値をオペレーティング・システム・レベルでより小さい値に設定します。
|
注意: tcp_keepalive_intervalプロパティに小さい値を設定すると、ネットワーク上にプローブ・パケットが頻繁に送出され、システム速度が低下する可能性があります。そのため、このプロパティの値は、システム要件に基づいて適切に設定してください。 |
たとえば、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=orcl.us.oracle.com)(INSTANCE_NAME=orcl1)))
この結果、データソース構成は次のようになります。
<url>jdbc:oracle:thin:@(DESCRIPTION=(enable=broken)(ADDRESS_LIST=(ADDRESS=(PRO
TOCOL=TCP)(HOST=node1-vip.us.oracle.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl.us.oracle.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 Identity Manager構成を実行する場合、java.io.FileNotFoundException: soaconfigplan.xml (Permission deniedのエラーが表示され、Oracle Identity Manager構成が失敗することがあります。
この問題の回避方法:
ファイル/tmp/oaconfigplan.xmlを削除します。
構成を再開します(OH/bin/config.sh)。
Oracle Access Manager構成では、コマンドラインの/.../*など、複雑なリソース定義の使用はサポートされていません。かわりに、複雑なリソースは、コマンドラインで指定されるuri_fileに含まれます。
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ファイルが存在することを確認します。
Oracle JMSアダプタがクラスタ内の複数のサーバーと通信する場合、アダプタの通信ファクトリのプロパティFactoryPropertiesに使用可能なサーバーがリストされている必要があります。サーバーがリストされない場合、ランダムな1サーバーとの接続が確立されます。そのサーバーが停止しても、追加のメッセージは処理されません。
eis/wls/Queueなど、使用するアダプタのJCA接続ファクトリの確認には、次の必須プロパティが含まれます。
Oracle WebLogic Serverコンソールにログインします。コンソールにアクセスするには、http://servername:portnumber/consoleにナビゲートします。
「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
右ペインの「デプロイメントのサマリー」でJMSAdapterをクリックします。
「Configuration」タブをクリックします。
「アウトバウンド接続プール」タブをクリックしてoracle.tip.adapter.jms.IJmsConnectionFactoryを開き、構成済の接続ファクトリを表示します。
使用中の特定のインスタンス(例: eis/wls/Queue)をクリックします。接続ファクトリの「アウトバウンド接続のプロパティ」が開きます。
「ロックと編集」をクリックします。
FactoryPropertiesフィールドで(「プロパティ」値の該当するセルをクリックして)、次を入力します。
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory; java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic1
「入力」をクリックし、変更内容を保存してアクティブ化します。
コンソールでデプロイメントを更新します。
「デプロイメント」をクリックしてJMSアダプタを選択します。
「ロックして編集」をクリックし、「更新」をクリックします。
新規デプロイメント・プランの変更(デプロイメント・プランはこのオプションで指定)を含め、このアプリケーションの「更新」を選択し、共有記憶域の場所に保存されたデプロイメント・プランを選択すると、クラスタ内のすべてのサーバーは、このプランにアクセス可能になります。
「終了」をクリックして変更内容をアクティブ化します。
Identity Managementデプロイメントでは、仮想ホストをリスニングするよう管理サーバーを構成した場合、ネットワーク・カードが複数あるハードウェア構成で、Oracle Access Manager管理対象サーバーが起動しないことがあります。ログ・ファイルに、Coherenceクラスタを結合できないことに関連するエラーが表示されることがあります。この場合、Oracle Access ManagerのCoherenceホストを仮想IPアドレスから、管理サーバーが稼働しているローカル・ホストに変更します。
次の手順を実行します。
管理サーバー・ホスト上でファイルDOMAIN_HOME/config/fmwconfig/oam-config.xmlを検索します。(このファイルのバックアップ・コピーを作成します。)
次のエントリを検索します。
<Setting Name="Instance" Type="htf:map">
<Setting Name="AdminServer" Type="htf:map">
この定義ブロックで、次のようなエントリを検索します。
<Setting Name="CoherenceConfiguration" Type="htf:map">
<Setting Name="LocalHost" Type="htf:map">
<Setting Name="Key" Type="xsd:string">oam.coherence.localhost</Setting>
<Setting Name="Value" Type="xsd:string">ADMINVHN.mycompany.com</Setting>
</Setting>
ADMINVHNを次のようなローカル・ホスト名に更新します。
<Setting Name="CoherenceConfiguration" Type="htf:map">
<Setting Name="LocalHost" Type="htf:map">
<Setting Name="Key" Type="xsd:string">oam.coherence.localhost</Setting>
<Setting Name="Value"Type="xsd:string">IDMHOST1.mycompany.com</Setting>
</Setting>
ファイルを保存し、管理サーバーとOAM管理対象サーバーを再起動します。
後で別のホストへの管理サーバーのフェイルオーバーが発生した場合、現在のサーバーのあるホストにこのエントリを更新します。次に、すべてのOAM管理対象サーバーを停止し、管理サーバーとOAM管理対象サーバーを再起動します。
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
このエラーは、NFSシステムでストア上のロックが解放されていないため発生します。WebLogic Serverは、同じWebLogic Serverの2つのインスタンスが偶然起動した場合にデータ破損が発生しないように、JMSデータおよびトランザクション・ログを格納しているファイルに対するロックを保持します。NFSストレージ・デバイスは、マシン障害を適切なタイミングで認識できないため、ロックを解放しません。このため、予期しないマシン障害とそれに続く再起動の後に、WebLogic Serverが以前ロックされたファイルに対するロックを取得しようとしても、失敗する可能性があります。ストレージ・デバイスでNFSにマウントされたディレクトリに格納されているファイルのロックに関する追加情報は、使用しているストレージ・ベンダーのドキュメントを参照してください。
現在のNFS環境でロックの動作を調整することに無理がある場合、次のいずれかの解決策を使用してログとデータ・ファイルのロックを解除してください。
解決策1
ロックされている永続ストア・ファイルのコピーを作成し、そのコピーを後続の操作に使用して、手動でログ・ファイルおよび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ファイルが作成されます。この場合、すべてのファイルをコピーし、その名前を変更する必要があります。
解決策2
WebLogic Server管理コンソールを使用して、デフォルト・ファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストアおよび診断ファイル・ストアに対するWebLogicのファイル・ロック・メカニズムを無効化することもできます。次の項の手順に従ってください。
|
警告: この解決策では、WebLogicのロック機能が無効化されるため、通常は自動的なサーバーの再起動とフェイルオーバーに成功します。ただし、このオプションを使用する場合は、慎重に行ってください。WebLogicのファイル・ロック機能は、不適切な同時実行シナリオにおいて発生する可能性のある重大なファイル破損を防止する目的で設計されています。ファイル・ストアを使用するサーバーがサーバー移行用に構成されている場合、必ずデータベースに基づいたリース・オプションを構成してください。これにより、データベース表を使用した追加のロック・メカニズムが強制的に適用され、同じWebLogic Serverの複数のインスタンスが自動的に再起動しなくなります。人為的エラーを回避し、任意の時点でサーバーのただ1つのインスタンスを手動で起動するため、追加の手続き型の予防措置を実施する必要があります。同様に、特別な予防措置を実行して、同じディレクトリを参照する同じ名前の1つのストアを複数のドメインが保持しないようにする必要があります。 |
デフォルト・ファイル・ストアのファイル・ロックの無効化
WebLogic Server管理コンソールを使用してデフォルト・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「環境」ノードを開いて「サーバー」を選択します。
「サーバーのサマリー」リストで、変更するサーバーを選択します。
「構成」→「サービス」タブを選択します。
「デフォルト・ストア」セクションを下にスクロールし、「詳細」をクリックします。
下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。
生成されるconfig.xmlのエントリは、次のようになります。
<server>
<name>examplesServer</name>
...
<default-file-store>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
</default-file-store>
</server>
カスタム・ファイル・ストアのファイル・ロックの無効化
WebLogic Server管理コンソールを使用して、カスタム・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「サービス」ノードを開いて「永続ストア」を選択します。
「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。
カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックして詳細なストア設定を表示します。
下にスクロールして、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
カスタム・ファイル・ストアが使用中の場合、変更を反映するにはサーバーを再起動する必要があります。
生成されるconfig.xmlのエントリは、次のようになります。
<file-store>
<name>CustomFileStore-0</name>
<directory>C:\custom-file-store</directory>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
<target>examplesServer</target>
</file-store>
JMSページング・ファイル・ストアのファイル・ロックの無効化
WebLogic Server管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「サービス」ノードを開き、次に「メッセージング」ノードを開いて「JMSサーバー」を選択します。
「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。
JMSサーバーの「構成」→「全般」タブで、下にスクロールして「ページング・ファイル・ロックの有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。
生成されるconfig.xmlファイルのエントリは、次のようになります。
<jms-server>
<name>examplesJMSServer</name>
<target>examplesServer</target>
<persistent-store>exampleJDBCStore</persistent-store>
...
<paging-file-locking-enabled>false</paging-file-locking-enabled>
...
</jms-server>
診断ファイル・ストアのファイル・ロックの無効化
WebLogic Server管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効化するには、次の手順を実行します。
必要に応じて、管理コンソールの(左上隅の)「チェンジ・センター」で、「ロックして編集」をクリックしてドメインの編集ロックを取得します。
「ドメイン構造」ツリーで、「診断」ノードを開いて「アーカイブ」を選択します。
「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。
「<サーバー名>の設定」ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。
「保存」をクリックします。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。
変更したサーバーを再起動して変更を反映します。
生成されるconfig.xmlファイルは、次のようになります。
<server>
<name>examplesServer</name>
...
<server-diagnostic-config>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-store-file-locking-enabled>false</diagnostic-store-file-locking-
enabled>
<diagnostic-data-archive-type>FileStoreArchive</diagnostic-data-archive-type>
<data-retirement-enabled>true</data-retirement-enabled>
<preferred-store-size-limit>100</preferred-store-size-limit>
<store-size-check-period>1</store-size-check-period>
</server-diagnostic-config>
</server>
この項では、ドキュメントの訂正箇所を示します。次のトピックが含まれています。
6.4.3項「Oracle Fusion Middleware Oracle Identity Managementのエンタープライズ・デプロイメント・ガイドの訂正箇所」
6.4.4項「Oracle Fusion Middleware Oracle Business Intelligenceのエンタープライズ・デプロイメント・ガイドの訂正箇所」
この項には、『Oracle Fusion Middleware高可用性ガイド』の訂正箇所が含まれます。
内容は次のとおりです。
Oracle Fusion Middleware 11gドキュメント・セットの複数のマニュアルには、Oracle Fusion Middlewareシステムの要件、前提条件、仕様および動作保証情報に関する情報が含まれます。
Oracle Fusion Middlewareシステムの要件、前提条件、仕様および動作保証情報に関する最新情報は、Oracle Technology Networkの次のドキュメントを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
このドキュメントには、ハードウェアとソフトウェアの要件、最小ディスク領域とメモリーの要件、および必要なシステム・ライブラリ、パッケージまたはパッチに関する情報が含まれます。
Oracle Fusion Middlewareの動作保証情報は、次のURLを参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
このドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品に関する情報が含まれます。
この項には、『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』の訂正箇所が含まれます。
次のトピックが含まれています。
『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』のディスカッション・フォーラム接続の構成に関する項では、EMからWebCenterに対するディスカッション・サーバー接続の作成に関する項へのリンクが欠落しています。
『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』のマルチキャストからユニキャストへのディスカッション・フォーラムの変換に関する項では、手順3から次の情報が欠落しています。
手順3: WLS_Services2で、次のようにWCHost1をWCHost2に、WCHost2をWCHost1に置き換えて手順1と2を繰り返します。
-Dtangosol.coherence.wka1=WCHost2 -Dtangosol.coherence.wka2=WCHost1 -Dtangosol.coherence.localhost=WCHost2 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』に含まれる、EMからWebCenterに対するディスカッション・サーバー接続の作成に関する項の手順に関連するディスカッション・サーバー接続の追加プロパティの詳細は、Oracle Fusion Middleware Oracle WebCenterの管理者ガイドのFusion Middleware Controlを使用したディスカッション・サーバーの登録に関する項を参照してください。
この項には、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の訂正箇所が含まれます。
次のトピックが含まれています。
『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の2010年11月版では、WebLogic管理サーバーを制御するノード・マネージャの起動の前に、-DDomainRegistrationEnabled=trueを設定する必要があることが記載されていません。次に例を示します。
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の2010年11月の版では、第11章のOracle Virtual Directoryでのドメイン拡張に関する項は空白です。この手順は無視してください。
このドキュメントのFusion Applicationsのバージョンでは、第7章「Oracle Internet Directoryでのドメインの拡張」で最初のOracle Internet Directoryインスタンスの構成に関する項、および追加のOracle Internet Directoryインスタンスの構成に関する項のステップがありません。次のステップを、ここに示すステップの前に追加する必要があります。「「構成」画面で、複数の構成アシスタントが連続して開始されます。このプロセスは、時間がかかることがあります。構成プロセスが終了するまで待機します。」
LinuxシステムおよびUNIXシステムの場合、oracleRoot.shスクリプトの実行を求めるダイアログ・ボックスが表示されます。Shellウィンドウを開いて次の行を変更し、スクリプトを編集します。
fi# This command path is not already provided in the existing root.sh
次のように2行に変更します。
fi # This command path is not already provided in the existing root.sh
ファイルを保存し、oracleRoot.shスクリプトをrootユーザーとして実行します。
Oracle Bug#12898815
Oracle Bug#12904922
9.5項「Oracle Virtual DirectoryリスナーSSL NIOの無効化」のステップ2で数行が不足しています。ステップ2は次のようになります。
ファイルを編集します。
ORACLE_INSTANCE/config/OVD/component/listener.os_xml
次のようなLDAP SSLリスナーのセクションを特定します。
<ldap version="20" id="LDAP SSL Endpoint"> <port>7501</port> <host>0.0.0.0</host> ......... ......... <ssl enabled="true"> <protocols>SSLv3</protocols> <cipherSuites> ....... ....... <tcpNoDelay>true</tcpNoDelay> <readTimeout>180000</readTimeout> </socketOptions> </ldap>
このセクションを次のように修正します。
<ldap version="20" id="LDAP SSL Endpoint"> <port>7501</port> <host>0.0.0.0</host> ......... ......... <ssl enabled="true"> <protocols>SSLv3,TLSv1,SSLv2Hello</protocols> <cipherSuites includeAnonCiphers="true"> ...... ...... <tcpNoDelay>true</tcpNoDelay> <readTimeout>180000</readTimeout> </socketOptions> <useNIO>false</useNIO> </ldap>
この項には、Oracle Fusion Middleware Oracle Business Intelligenceのエンタープライズ・デプロイメント・ガイドの訂正箇所が含まれます。
次のトピックが含まれています。
6.4.4.1項「BI Publisher構成フォルダの場所の設定後に実行する必要のある追加手順」
6.4.4.2項「共有Oracle BIプレゼンテーション・カタログの場所の設定に関する項の訂正」
共有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 Coherenceの構成に関する項に、次のような注意が含まれます。
|
注意: デプロイメントに使用されるCoherenceクラスタでは、デフォルトでポート8088を使用します。このポートは、-Dtangosol.coherence.wkan.port起動パラメータを指定することで変更できます。 |
この注意は、正しくは次のようになります。
|
注意: デプロイメントに使用されるCoherenceクラスタでは、デフォルトでポート8088を使用します。このポートは、-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localport起動パラメータで異なるポート(8089など)を指定することで変更できます。次に例を示します。
WLS_SOA1(次の内容を引数フィールドに改行なしの単一行として入力): -Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 WLS_SOA2(次の内容を引数フィールドに改行なしの単一行として入力): -Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 |
一部のエンタープライズ・デプロイメント・ガイドには、サーバー移行をテストする方法について説明する1つ以上の項が含まれます。
サーバー移行のテストに関するすべての項の最後に次の注意が記載される必要があります。
|
注意: サーバーの移行後にサーバーを元のノードまたはマシンにフェイルバックするには、Oracle WebLogic管理コンソールで管理対象サーバーを停止し、その後再起動します。管理対象サーバーは、適切なノード・マネージャによって、最初に割り当てられていたマシン上で起動されます。 |
一部のエンタープライズ・デプロイメント・ガイドには、サーバー移行の構成時にリース用として使用されるデータソースを更新する方法について説明する1つ以上の項が含まれます。
サーバー移行の構成の一部としてリース用のデータソースを更新する方法に関する指示に、次のテキストが記載されています。
「グローバル・トランザクションのサポート」の「1フェーズ・コミット」を使用し、データベースのサービス名を指定します。
正しいテキストは次のとおりです。
データソースでは、グローバル・トランザクションのサポートは必要ありません。したがって、データソースに関しては、どのタイプの分散トランザクション・エミュレーション(参加)・アルゴリズムも使用せずに(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」あるいは「1フェーズ・コミット」オプションを選択せずに)、データベースのサービス名を指定します。
『Oracle Fusion Middleware高可用性ガイド』の分析の構成に関する項には、分析コレクタ・クラスタを構成する必要性が記載されています。実際には、コレクタ自体を構成する必要はありません。かわりに、この項の手順では、分析コレクタと通信するためのOracle WebCenter Spacesサーバーの構成方法について説明しています。
また、Oracle Fusion Middleware 11g リリース(11.1.1.4.0)では、WebCenterイベントの収集で、クラスタ化された分析コレクタはサポートされていません。
『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で修正されました。 |
