| Oracle® Fusion Middlewareリリース・ノート 11gリリース1(11.1.1) for Linux x86-64 B55934-08 |
|
 前 |
 次 |
この章では、Oracle Fusion Middlewareの高可用性とエンタープライズ・デプロイメントに関連する問題について説明します。次のトピックが含まれます:
|
注意: この章では、高可用性、またはエンタープライズ・デプロイメントを目的としたOracle Fusion Middleware製品の構成時に発生する可能性のある問題について説明します。 使用中の製品固有の問題については、この文書内で、その製品固有のリリース・ノートの章を参照してください。 |
この項では、一般的な問題および回避策について説明します。次のトピックが含まれます:
6.1.4項「I/PMからUCMに大量のアップロードが発生する場合にホスト名ベースのフィルタのかわりに必要になることのあるIPベースのフィルタの使用」
6.1.7項「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
コールド・フェイルオーバー・クラスタ(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を追加します。
アクティブ/アクティブのOracle SOAクラスタでノード障害が発生した場合、受信アクティビティのリクエスト/レスポンス操作のタイムアウト設定は、あるノードから他の1つ以上のノードに伝播されません。これらのアクティビティがスケジュールされていたサーバーで障害が発生した場合、サーバーの再起動時にスケジューラで各アクティビティを再スケジュールする必要があります。
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サーバーを再起動します。
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 BI Publisherでレポートを作成し、そのレポートを保存する前に管理対象サーバーがフェイルオーバーされると、そのフェイルオーバーはシームレスでなくなる可能性があります。たとえば、レポートを保存しようとすると、システムが応答しなくなることがあります。
この問題が発生したら、「ホーム」や「カタログ」などのヘッダー・リンクの1つをクリックして、Oracle BI Publisherのログイン・ページに移動します。その後、ログインしてレポートを再度作成および保存します。
Oracle Business Intelligence Webインタフェースでエージェントを作成し、そのエージェントを保存する前に管理対象サーバーがフェイルオーバーされると、エージェントの保存時にエラーが発生します。
この問題を回避するには、Oracle Business Intelligenceを一度ログアウトしてからログインしなおし、エージェントを再作成します。
この問題は、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クラスタ上で、次のシナリオはサポートされません。
mid-process receiveを持つ同期BPELプロセス
非同期サービスをコールする同期BPELプロセス。
同期プロセスからのコールバック。
この項では、構成に関する問題およびその回避策について説明します。次のトピックが含まれます:
6.2.13項「Oracle Business Intelligence管理対象サーバーのスケール・アウト後のサーバー起動パラメータ未設定」
6.2.19項「RACマルチ・データソースで構成する場合、最初に定義されたRACインスタンスはドメインの起動時に使用可能である必要がある」
一部の環境では、コンポーネントが再起動またはフェイルオーバーされた直後に、そのコンポーネントの間違ったステータスが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インスタンスはコンシューマとしてリカバリできません。
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 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 Configuration Assistantを使用して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 Configuration Assistantに戻り、過去の「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ファイルが作成されます。この場合、すべてのファイルをコピーし、その名前を変更する必要があります。
この項では、ドキュメントの訂正箇所を示します。次のトピックが含まれます:
この項には、『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月の版では、第11章の第8.1.1項「Oracle Virtual Directoryでのドメイン拡張」は空白です。この手順は無視してください。
『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
これにより、ローカルemagentが有効になり、仮想IPアドレスを使用してWebLogic管理サーバーと通信できます。そのコマンドを実行したら、次のタスクも実行する必要があります。
次のコマンドを発行して、エージェントにその構成を再ロードさせます。
./emctl reload
次のコマンドを使用して、エージェントが正しいアップロードURLを使用しているかチェックします。
./emctl status agent
表2-3「推奨ディレクトリ構造」では、「共有記憶域」列のいくつかの値が欠落しています。次の表エントリは、正しくは「共有記憶域」列を「Yes」とする必要があります。これは、ディレクトリを共有記憶域上に配置する必要があることを示します。
IAM_ORACLE_HOME
ASERVER_DOMAIN_HOME
ASERVER_APP_HOME
