ヘッダーをスキップ

Oracle Application Server 高可用性ガイド
10g リリース2（10.1.2）
B15817-04
目次
目次		 索引
索引

戻る 次へ

A
高可用性のトラブルシューティング

この付録では、Oracle Application Serverを高可用性構成で配置および管理するときに発生する問題と、それらの解決方法を説明します。この付録の項目は次のとおりです。

A.1 OracleAS Cold Failover Clusterの構成のトラブルシューティング

この項では、OracleAS Cold Failover Clusterの構成の一般的な障害と解決策について説明します。この項の項目は次のとおりです。

A.1.1 OracleAS Web Cacheがフェイルオーバーしない

障害

OracleAS Cold Failover Cluster環境でOracleAS Web Cacheがフェイルオーバーしません（つまり、スタンバイ・ノードで起動されません）。ログ・ファイルに次のエラーが書き込まれます。

[26/Apr/2005:14:36:08 -0700] [error 13079] [ecid: -] No matching CACHE
element found in webcache.xml for current hostname (hostname) and
ORACLE_HOME (/path/to/oracle/home)
解決策

OracleAS Cold Failover Cluster環境でOracleAS Web Cacheをフェイルオーバーさせるには、次の手順を実行する必要があります。

OracleAS Web Cacheクラスタの詳細は、『Oracle Application Server Web Cache管理者ガイド』の第10章「キャッシュ・クラスタの設定」を参照してください。

A.1.2 OracleAS Cold Failover Cluster環境で、オンライン・データベースのバックアップとリストアを実行できない

オンライン・データベースのバックアップとリストアに伴う問題を示します。この情報はOracleAS Cold Failover Cluster環境に関連するものです。

障害

依存関係が原因でInfrastructureデータベースのオンライン・リカバリを実行できません。クラスタ・アドミニストレータがBackup and Recovery Toolのリカバリ・フェーズ中にデータベースの停止および起動を試みています。

解決策1

正常なリカバリを実行するには、次の手順を実行します。

  1. クラスタ・アドミニストレータを使用して、すべてのリソースをオフラインにします（Windowsの場合はOracle Fail Safeを使用します）。

  2. Infrastructureデータベースの正常な停止を実行します。

  3. 次のコマンドを使用して、データベース・サービスのみを起動します。

    net start OracleService<SID>

  4. Backup and Recovery Toolを実行して、データベースのリカバリを実行します。

解決策2

Windowsの場合、リカバリを実行するには、次の手順を実行します。

  1. Oracle Fail Safeで、「クラスタ・リソース」の下の「データベース」タブの「ASDB（DBリソース）」を選択します。

  2. 「データベース・ポーリング」で、ドロップダウン・リストから「無効」を選択します。

  3. Backup and Recovery Toolを使用して、Infrastructureデータベースのオンライン・リストアを実行します。

Backup and Recovery Toolがデータベースを停止および起動しているわずかの間、データベースにはアクセスできなくなります。データベースが起動すると、中間層およびInfrastructureのコンポーネントによってアクセス可能になります。

A.1.3 リストアするデータベースに接続できない（Windows）

Microsoftクラスタ アドミニストレータを使用してアイドル状態のOracleAS Metadata Repositoryデータベースを停止した後に、そのデータベースに接続してリストアすることはできません。

障害

Microsoftクラスタ アドミニストレータを使用してOracleAS Metadata Repositoryデータベースを停止すると、Microsoftクラスタ アドミニストレータが厳密かつ迅速に中断を行い、データベース・サービスが停止します。停止後は、データベースに接続できません。

この障害を再現する手順は次のとおりです。

  1. テスト用のOracleAS Metadata Repositoryにアクセスします。

  2. データベース・ファイルを破損させます（注: ts$表は変更しないでください）。

  3. SQL問合せを発行してデータベースが破損していることを確認します。

  4. Microsoftクラスタ アドミニストレータを使用して、データベースがオンラインであることを確認します。

  5. Oracle Fail Safe Managerを使用して、データベース・ポーリングを無効化します。

  6. Microsoftクラスタ アドミニストレータを使用して、データベースをオフラインにします。データベースと依存関係があるので、OPMNとApplication Server Controlコンソールもオフラインになります。

  7. sysdbaとして接続を試みます。接続は失敗するはずです。

解決策

Oracle Fail Safe Managerを使用して、データベースを停止します。これを行うには、次の手順を実行します。

  1. Oracle Fail Safe Managerで、「ASDB」リソース（変更していない場合のデフォルト）を右クリックし、「即時」を選択します。

  2. Windowsの「コントロール パネル」の「サービス」でデータベース・サービスを起動します。

  3. sysdbaとしてデータベースに接続します。接続は成功するはずです。

A.2 OracleAS Cluster（Identity Management）の構成のトラブルシューティング

この項では、OracleAS Cluster（Identity Management）の構成の一般的な障害と解決策について説明します。この項の項目は次のとおりです。

マルチマスター・レプリケーションおよびその他のOracle Internet Directoryの機能に関連する障害と解決策は、『Oracle Internet Directory管理者ガイド』のトラブルシューティングに関する項を参照してください。

A.2.1 OracleAS Single Sign-Onへのログインに長時間かかる

障害

OracleAS Single Sign-OnとOracle Internet Directoryをファイアウォールの反対側で実行していて（OracleAS Single Sign-Onをファイアウォールの外側で実行し、Oracle Internet Directoryをファイアウォールの内側で実行）、構成済のタイムアウト時間の経過後にアイドル接続を切断またはリサイクルするようにファイアウォールが構成されている場合、OracleAS Single Sign-Onのログインに長い時間がかかることがあります。

解決策
  1. OracleAS Single Sign-On接続のタイムアウトを、ファイアウォールやロード・バランサのタイムアウト値より小さい値に設定します。OracleAS Single Sign-Onサーバーによって、指定した値より長い時間アイドルになっている接続は削除されます。

    この値（分単位）は、ORACLE_HOME/sso/conf/policy.propertiesファイルのconnectionIdleTimeoutパラメータを使用して指定します。たとえば、次のように指定すると、タイムアウト値は20分になります。OracleAS Single Sign-Onサーバーによって、20分より長い時間アイドルになっている接続は削除されます。

    connectionIdleTimeout = 20

    新しい値を有効にするために、OracleAS Single Sign-Onサーバーを実行しているOC4Jサーバー（OC4J_SECURITY）を再起動します。

  2. ORACLE_HOME/network/admin/sqlnet.oraファイルのSQLNET.EXPIRE_TIMEパラメータで、データベース接続のタイムアウトを設定します。この値も、ファイアウォールやロード・バランサのタイムアウト値より小さい値に設定します。

    このパラメータでは、データベース・サーバーからクライアント（OracleAS Single Sign-Onサーバー）へプローブ・パケットを送信する頻度を指定します。このプローブ・パケットの定期的な動作により、OracleAS Single Sign-Onサーバーからデータベースへの接続をアクティブな状態に保つことができます。

    この値は分単位で指定します。次の例では、データベース・サーバーからクライアントへ、20分間隔でプローブ・パケットが送信されます。

    SQLNET.EXPIRE_TIME = 20

    新しい値を有効にするために、データベースを再起動します。

説明: 接続が一定の時間アイドルになると、ファイアウォールまたはロード・バランサによってOracle Internet Directoryおよびデータベースへの接続が削除される場合があります。ファイアウォールまたはロード・バランサで接続が削除されても、OracleAS Single Sign-Onサーバーへtcpクローズ通知が送信されない場合があります。その場合、OracleAS Single Sign-Onサーバーでは接続が無効になっていることが認識されず、この接続を使用したOracle Internet Directoryまたはデータベースの操作が試行されます。OracleAS Single Sign-Onサーバーはレスポンスを受信しないと、次の接続を試行します。最終的に、プール内のすべての接続を試行してから、Oracle Internet Directoryまたはデータベースへの新しい接続が行われます。

OracleAS Single Sign-Onサーバーおよびデータベースのタイムアウトをファイアウォールやロード・バランサのタイムアウトより小さい値に設定すると、接続を確実に有効にすることができます。

A.2.2

A.2.3 1つのノードでOracle Internet Directoryが起動しない

障害

OracleAS Cluster（Identity Management）内のノード間の時間に250秒を超える時差がある場合、Oracle Internet Directoryモニター（oidmon）によって、時間が遅い方のノードのOracle Internet Directoryが停止されます。たとえば、ノードAの時間がノードBの時間より250秒進んでいる場合は、oidmonによって、ノードBのOracle Internet Directoryプロセスが停止されます。これは、すべてのノードのoidmonプロセスで、10秒ごとにデータベースが更新して、他のノードに動作中であること通知するためです。250秒間応答がないノードは、他のノードからは障害のあるノードとして扱われます。

解決策

すべてのノードの時差を250秒以内になるように同期させます。

A.2.4 Oracle Internet Directoryに接続できず、Oracle Internet Directoryを再起動できない

障害

この問題は、Windows 2000プラットフォームにのみ該当します。この問題には次の2つの現象があります。

現象1: TCPポート監視を使用してOracle Internet Directoryポートを監視するようにロード・バランサを構成している場合に、最大接続数に達したことを示すエラーがOracle Internet Directoryログ・ファイルに記録されることがあります。これは、クライアントがOracle Internet Directoryに接続できないことを示します。

現象2: Oracle Internet Directoryが終了した場合に、再起動できません。再起動しようとすると、システム・アイドル・プロセスですでに使用中のためOracle Internet Directoryがポートにアクセスできないというメッセージが表示されます。Oracle Internet Directoryは、ポートに排他的にアクセスする必要があります。

解決策

この問題は、Oracle Internet DirectoryのポートでTCPポートを監視するアプリケーション（この場合はロード・バランサ）が原因で発生します。TCPポート監視では、アプリケーションによってOracle Internet Directoryポートへの接続および切断が行われます。Windows 2000では接続が適切に終了されず、このために最大接続数に達します。

回避策は、Oracle Internet DirectoryのポートでTCPポート監視を使用しないことです。かわりに、LDAPまたはHTTPポート監視を使用してください。

A.2.5 インストール時にCluster Configuration Assistantが失敗する

Cluster Configuration Assistantを使用したコンポーネントのクラスタリング時に発生する障害について説明します。

障害

Oracle Identity Managementの分散構成のインストール時には、OracleAS Single Sign-OnおよびOracle Delegated Administration Servicesコンポーネントが他のOracle Identity Managementコンポーネントとは異なる、専用の2つのノードにインストールされます。Cluster Configuration Assistantは、作成された2つのOracleAS Single Sign-On/Oracle Delegated Administration Servicesインスタンスのクラスタリングを試みます。しかし、エラー・メッセージ「使用不可コンポーネントを含むインスタンスは、クラスタに追加できません。」が表示されます。このメッセージは、Enterprise Managerが、無効化されたコンポーネントを持つインスタンスをクラスタリングできないために表示されます。

解決策

Cluster Configuration Assistantに障害が発生した場合は、インストール後にインスタンスをクラスタリングできます。この場合、インスタンスをクラスタリングするには、Application Server Controlコンソールではなくdcmctl joinclusterコマンドを使用する必要があります。Application Server Controlコンソールは、無効化されたコンポーネントを持つインスタンスをクラスタリングできないため、使用できません。この状況では、ホームOC4Jインスタンスが無効化されます。

A.2.6 高可用性Infrastructureのインストール時にOracle Ultra Search Configuration AssistantをOracle Internet Directoryに接続できない

高可用性Infrastructureのインストール時、Oracle Ultra Search Configuration Assistantを、「仮想ホスト名アドレッシング」画面に示された仮想ホスト名のポート3060でOracle Internet Directoryインスタンスに接続できない問題について説明します。

障害

Infrastructureのインストール時に仮想ホスト名によるアドレス指定を使用する場合に、起こしがちな間違いです。ロード・バランサの仮想サーバー名が入力され、この名前を認識するようにロード・バランサが正しく設定されています。しかし、Infrastructureノードはこの名前を解決するように正しく設定されていません。このため、InfrastructureノードのOracle Ultra Search Configuration Assistantをロード・バランサの仮想サーバー名に接続しようとすると、Configuration Assistantはロード・バランサを見つけることができません。

解決策

解決策は、Infrastructureマシンに、ロード・バランサの仮想サーバー名の名前解決を正しく設定することです。この手順は、プラットフォームによって異なります。正確な手順については、オペレーティング・システムのマニュアルを参照してください。UNIXでは、通常、/etc/hostsファイルを編集し、このファイルが名前解決に使用されていることを/etc/nsswitch.confファイルの編集によって確認します。Windowsでは、通常、C:¥WINDOWS¥system32¥drivers¥etc¥hostsファイルを編集します。

A.2.7 「opmnctl stopall」後にodisrvプロセスがフェイルオーバーしない

ノード間のodisrvプロセス・フェイルオーバーの問題について説明します。

障害

任意のOracleAS Cluster（Identity Management）ソリューションで、opmnctl stopallが実行されて、そのノード上にあるOPMN管理対象プロセスがすべて停止しても、odisrvは2次ノードで自動的に起動しません。opmnctl stopallは、実際のノード障害ではなく正常な管理停止であるためです。実際のノード障害では、元のodisrvプロセスで問題が検出されると、残りのノードでodisrvが起動します。

解決策

OracleAS Cluster（Identity Management）で計画されたメンテナンスを実行する場合は、oidctlコマンドを使用して、odisrvを明示的に停止および起動します。

odisrvが実行されているノードで、次のコマンドを使用してodisrvを停止します。

ORACLE_HOME/bin/oidctl connect=<dbConnect> server=odisrv inst=1 stop

残りのアクティブ・ノードで、次のコマンドを使用してodisrvを起動します。

ORACLE_HOME/bin/oidctl connect=<dbConnect> server=odisrv instance=1
     flags="host=OIDhost port=OIDport" start

A.2.8 すべてのノードのシステム時間が同期化されていない場合にOracleAS Cluster（Identity Management）構成で予期しない動作が発生する

すべてのOracleAS Cluster（Identity Management）ノードのシステム時間が同期化されていない場合、予期しない動作が発生します。

障害

OracleAS Cluster（Identity Management）構成では、各ノードのOracle Internet Directory Monitor（OIDMON）が、10秒毎にディレクトリ・データベースをメタデータで更新します。それと同時に、データベースに問合せを行い、他のすべてのディレクトリ・サーバーが実行されていることを確認します。

OIDMONがデータベースを250秒間更新しなかった場合、他のノードは、そのノードに障害が発生したとみなします。ノードのシステム・クロックが他のノードと250秒以上の差異で設定されていると、更新の遅れとして誤認識されます。このとき、他のノードの１つにあるOIDMONが、フェイルオーバー操作を開始します。これにより、障害が発生したノードで実行されているプロセスが他のノードのローカルで起動されます。このプロセスを起動したノードでは、障害が発生したノードで進行中だった操作の処理を続行します。

例として、ノードAとノードBが構成されているOracleAS Cluster（Identity Management）があるとします。ノードBのシステム・クロックは、ノードAのシステム・クロックより300秒遅れています。ノードBはディレクトリ・データベースにあるメタデータ（システム・クロック値を含む）を更新します。ノードAは、データベースに対してアクティブなOracle Internet Directoryサーバーを問い合せて、ノードBの時間値が300秒なので、ノードBに障害が発生したと判断します。ノードAはその後、ノードBで実行されているすべてのOracle Internet Directoryサーバー・プロセスをローカルで起動することにより、フェイルオーバー操作を開始します。

解決策

OracleAS Cluster（Identity Management）構成内のすべてのノードのシステム・クロック値を、グリニッジ標準時間を使用して同期化し、ノード間で250秒以上の差異が発生しないようにします。

『Oracle Internet Directory管理者ガイド』のラックマウント型ディレクトリ・サーバー構成についての章を参照してください。

A.2.9 ロード・バランサに間違った名前が指定された

クラスタリングされたOracle Application Serverインスタンスの前面にロード・バランサが配置されている場合に、そのインスタンスの構成ファイルに正しいロード・バランサの仮想サーバー名が指定されないことがあります。

障害

ロード・バランサがフロントエンドに配置されたOracle Application Serverインスタンスのクラスタでは、クラスタへの再リダイレクトにはロード・バランサの仮想サーバー名が含まれていないことがあります。サーブレットまたはJSPによって作成された動的ページでも、正しいロード・バランサの仮想サーバー名を使用していない場合があります。どちらの場合も、ローカル・ホスト名が代用されることがほとんどです。

使用するロード・バランサの仮想サーバー名を正しく指定するには、各インスタンスのhttpd.confおよびdefault-web-site.xmlファイルを変更する必要があります。

解決策

Oracle Application Serverの各インスタンスで、次の手順を実行します。

  1. Oracle HTTP Serverに対して、次の手順を実行します。

    1. 次のコマンドを使用して、Oracle HTTP Serverを停止します。

      opmnctl stopproc ias_component=HTTP_Server

    2. Oracle HTTP Serverのhttpd.conf ファイルで、ServerNameディレクティブの値をロード・バランサの仮想サーバー名に変更します。たとえば、localhost（ローカル・ホスト）にしている場合は、ロード・バランサの仮想サーバー名に変更します。

    3. 同じhttpd.confファイルで、Portディレクティブの値を、ロード・バランサで受信リクエスト用に構成されたポートの番号に変更します。たとえば、指定されたポート番号が7777の場合、それをロード・バランサで構成されたポート80に変更します。

    4. 次のコマンドを実行して、DCMリポジトリを前述の変更で更新します。

      dcmctl updateConfig -ct ohs

    5. 次のコマンドでOracle HTTP Serverを起動します。

      opmnctl startproc ias_component=HTTP_Server

  2. OC4Jに対して、次の手順を実行します。

    1. 次のコマンドを使用して、各OracleASインスタンスのOC4Jプロセスを停止します。

      opmnctl stopproc ias_component=OC4J

    2. 次の行を追加するようにファイルdefault-web-site.xmlを編集します。

      <frontend host="load_balancer_name" port="port_number" />

      load_balancer_nameをロード・バランサの仮想サーバー名に、port_numberを受信リクエスト用に構成されたポート番号に置き換えます（これらの値は前述のhttpd.confに入力した値と類似しています）。

    3. 次のコマンドを実行して、DCMリポジトリをdefault-web-site.xmlファイルに行った変更で更新します。

      dcmctl updateconfig -ct oc4j

    4. 次のコマンドでOC4Jインスタンスを起動します。

      opmnctl startproc ias_component=OC4J

A.3 OracleAS Disaster Recoveryの構成のトラブルシューティング

この項では、OracleAS Disaster Recoveryの構成の一般的な障害と解決策について説明します。この項の項目は次のとおりです。

A.3.1 スタンバイ・サイトが同期化されない

OracleAS Disaster Recoveryスタンバイ・サイトのOracleAS Metadata Repositoryが、プライマリ・サイトのOracleAS Metadata Repositoryと同期化されない問題について説明します。

障害

OracleAS Disaster Recoveryソリューションでは、手動による構成と、プライマリ・サイトからスタンバイ・サイトへのデータ・ファイルの転送が必要です。また、データ・ファイル（アーカイブ・データベース・ログ・ファイル）は、スタンバイ・サイトで自動的に適用されません。つまり、OracleAS Disaster RecoveryはOracle Data Guardの管理リカバリを使用しません。

解決策

アーカイブ・ログ・ファイルは手動で適用する必要があります。これらの作業の実行に必要な手順については、第13章「OracleAS Disaster Recovery」を参照してください。

A.3.2 フェイルオーバーまたはスイッチオーバー後にスタンバイ・インスタンスの起動に失敗する

スタンバイ・インスタンスが、フェイルオーバーまたはスイッチオーバー操作の後に起動しない問題について説明します。

障害

IPアドレスはインスタンスの構成で使用されます。OracleAS Disaster Recoveryの設定では、本番サイトとスタンバイ・サイトのピア・インスタンスに、同一のIPアドレスは必要ありません。OracleAS Disaster Recoveryの同期では、本番サイトとスタンバイ・サイト間のIPアドレスの不一致が調整されません。したがって、構成で明示的なIPアドレスxxx.xx.xxx.xxを使用する場合、同期化後のスタンバイの構成は機能しません。

解決策

明示的なIPアドレスの使用を避けます。たとえば、OracleAS Web CacheおよびOracle HTTP Serverの構成では、リスニング・アドレスとしてIPアドレスのかわりにANYまたはホスト名を使用します。

A.3.3 スタンバイ・サイトでスタンドアロンのOracleAS Web Cacheインストールを起動できない

スタンバイ・サイトでOracleAS Web Cacheを起動できないのは、フェイルオーバーまたはスイッチオーバー後のスタンドアロンOracleAS Web Cacheの構成に誤りがあることが考えられます。

障害

OracleAS Disaster Recoveryの同期では、スタンドアロンのOracleAS Web Cacheインストールが同期化されません。

解決策

標準のOracle Application Serverの完全なCDイメージを使用して、OracleAS Web Cacheコンポーネントをインストールします。

A.3.4 スタンバイ・サイトの中間層インストールで間違ったホスト名が使用されている

マシンの物理的なホスト名が変更された後も、スタンバイ・サイトの中間層インストールで間違ったホスト名が使用されている問題について説明します。

障害

物理的なホスト名の変更に加えて、/etc/hostsファイルにも、物理的なホスト名を最初のエントリとして入力する必要があります。このファイルの変更に失敗すると、インストーラーが間違ったホスト名を使用してしまいます。

解決策

/etc/hostsファイルに物理的なホスト名を最初のエントリとして入力します。詳細は、第13.2.2項「ホスト名解決の構成」を参照してください。

A.3.5 スタンバイ・ファームのファーム検証操作に失敗する

スタンバイ・ファームのファーム検証操作を実行すると、中間層マシンのインスタンスが見つからず、スタンバイ・ファームが本番のファームと対称性がないことを示すエラー・メッセージが表示され、失敗します。

障害

スタンバイ・ファームのファーム検証操作では、本番およびスタンバイ・ファームが互いに対称で、一貫性があり、障害時リカバリの要件に一致していることが検証されます。

検証操作は、中間層インスタンスをmid_tier.<physical_hostname>ではなくmid_tier.<hostname>とみなすため、失敗します。インストール時に設定した環境変数_CLUSTER_NETWORK_NAME_に問題があると考えることもできます。ただし、この状況では違います。_CLUSTER_NETWORK_NAME_環境変数設定のチェックで、このエントリが正しいことがわかっています。一方、/etc/hostsファイルのコンテンツのチェックで、問題になっている中間層のエントリが正しくないことがわかります。つまり、すべての中間層インストールは、/etc/hostsファイルの2番目の列からホスト名を取得します。

たとえば、次の使用例を想定します。

/etc/hostsファイルのチェックにより、次のエントリが示されます。

123.45.67.890 examp1 node1.us.oracle.com node1 infra

ias.propertiesおよびファームが次のように表示され、検証操作が失敗します。

IASname=midtier_inst.examp1

/etc/hostsファイルは、実際は次のようにする必要があります。

123.45.67.890 node1.us.oracle.com node1 infra

ias.propertiesおよびファームが次のようになり、検証操作が成功します。

IASname=midtier_inst.node1.us.oracle.com
解決策

/etc/hostsファイルの2番目の列のエントリをチェックし、前述で説明した、問題になっている中間層ノードのホスト名と一致するように変更します。

A.3.6 ファームの同期操作でエラー・メッセージが返される

sync farm to操作を実行すると、「ASDBに接続できません」というエラー・メッセージが返される問題について説明します。

障害

事前にasdbデータベース接続を確立する必要がある操作の実行で、ときどき管理者がasgctlコマンドライン・ユーティリティを使用したプライマリ・データベースの設定を忘れることがあります。このようなsync farm to操作の使用例を次に示します。

ASGCTL> connect asg hsunnab13 ias_admin/iastest2
Successfully connected to hsunnab13:7890
ASGCTL>  
.
.
.
<Other asgctl operations may follow, such as verify farm, dump farm, 
<and show operation history, and so forth that do not require the connection
<to the asdb database to be established or a time span may elapse of no activity
<and the administrator may miss performing this vital command.
.
.
.
ASGCTL> sync farm to usunnaa11
prodinfra(asr1012): Syncronizing each instance in the farm to standby farm
prodinfra: -->ASG_ORACLE-300: ORA-01031: insufficient privileges
prodinfra: -->ASG_DUF-3700: Failed in SQL*Plus executing SQL statement:  connect 
null/******@asdb.us.oracle.com as sysdba;.
prodinfra: -->ASG_DUF-3502: Failed to connect to database asdb.us.oracle.com.
prodinfra: -->ASG_DUF-3504: Failed to start database asdb.us.oracle.com.
prodinfra: -->ASG_DUF-3027: Error while executing Syncronizing each instance in the 
farm to standby farm at step - init step.
解決策

asgctl set primary databaseコマンドを実行します。このコマンドは、sync farm to操作を実行するために、asdbデータベースを開くのに必要な接続パラメータを設定します。現在の接続セッションでプライマリ・データベースが指定されていない場合、set primary databaseコマンドを、instantiate farm toコマンドおよびswitchover farm toコマンドの前に実行する必要があります。

A.4 中間層コンポーネントのトラブルシューティング

この項では、高可用性構成の中間層コンポーネントの一般的な障害と解決策について説明します。この項の項目は次のとおりです。

A.4.1 OracleAS Cluster（OC4J-EJB）での複数のNICの使用

障害

NIC（ネットワーク・インタフェース・カード）が2つ搭載されているコンピュータでOracleAS Cluster（OC4J-EJB）を実行しており、一方のNICをネットワーク接続に、もう一方のNICをクラスタ内の他のノードへの接続に使用している場合に、マルチキャスト・メッセージが正常に送受信されないことがあります。これは、セッション情報がクラスタ内のノード間でレプリケートされないことを意味します。

図A-1    NICを2つ搭載したコンピュータで動作しているOracleAS Cluster（OC4J-EJB）


画像の説明

解決策

oc4j.multicast.bindInterfaceパラメータを、ノード上のもう一方のNICの名前またはIPアドレスに設定して、OC4Jインスタンスを起動する必要があります。

たとえば、図A-1に示す値を使用して、これらのパラメータでOC4Jインスタンスを起動します。

ノード1では、次のパラメータで起動するようにOC4Jインスタンスを構成します。

-Doc4j.multicast.bindInterface=123.45.67.21

ノード2では、次のパラメータで起動するようにOC4Jインスタンスを構成します。

-Doc4j.multicast.bindInterface=123.45.67.22

このパラメータと値は、Application Server Controlコンソールの「サーバー・プロパティ」ページ、「コマンドライン・オプション」セクションの「Javaオプション」フィールドで指定します（図A-2）。

図A-2    Application Server Controlコンソールの「サーバー・プロパティ」ページ


画像の説明

A.4.2 「opmn:」URL接頭辞を使用するとパフォーマンスが遅くなる

障害

Context.PROVIDER_URLプロパティでopmn:の接頭辞を使用するアプリケーションがある場合に、InitialContextメソッドのパフォーマンスが遅くなることがあります。

次のサンプル・コードでは、PROVIDER_URLが、opmn:接頭辞を含むURLに設定されます。

Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "opmn:ormi://hostname:port/cmpapp");
// ... set other properties ...
Context context = new InitialContext(env);

PROVIDER_URLで指定されているホストが停止している場合、アプリケーションはOPMNに対してネットワーク接続を行って別のホストを検索する必要があります。ネットワーク経由でのOPMNへの接続には時間がかかります。

解決策

別のホストを見つけるためにOPMNに対して別のネットワーク接続を行うことを避けるには、OPMNから最初に返された値をキャッシュし、キャッシュ内の値をアプリケーションで使用できるように、oracle.j2ee.naming.cache.timeoutプロパティを設定します。

次のサンプル・コードを実行すると、oracle.j2ee.naming.cache.timeoutプロパティが設定されます。

Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "opmn:ormi://hostname:port/cmpapp");

// set the cache value
env.put("oracle.j2ee.naming.cache.timeout", "30");

// ... set other properties ...

Context context = new InitialContext(env);

表A-1は、有効なoracle.j2ee.naming.cache.timeoutプロパティ値を示しています。

表A-1    oracle.j2ee.naming.cache.timeoutプロパティの値 
値  意味 

-1 

キャッシュなし。 

0 

リフレッシュなしで1回だけキャッシュ。 

1以上 

ここで指定した秒数を経過すると、キャッシュをリフレッシュできます。ただしこれは自動ではありません。リフレッシュは、「new InitialContext()」を再度起動した場合にのみ行われます。

このプロパティを設定しない場合のデフォルト値は60です。 

このプロパティを設定しても、最初のnew InitialContext()コールではある程度の遅延が見られますが、その後のコールでは、OPMNにネットワーク接続せずにキャッシュからデータを取得するため、速度が増します。

パフォーマンスを最適にするために、さらにDedicated.ConnectionをYESまたはDEFAULTに、Dedicated.RMIcontextをFALSEに設定してください。

A.5 バックアップとリカバリのトラブルシューティング

A.5.1 OracleAS Metadata Repositoryを別のホストにリストアできない

Backup and Recovery Toolを使用して、あるホストから別のホストへOracleAS Metadata Repositoryをバックアップおよびリストアするとき、新しいホストのORACLE SIDが、古いホストのORACLE SIDと異なる場合には失敗します。

障害

Backup and Recovery Toolが、異なるORACLE SID値に対して動作しません。

ORACLE SIDの不一致によってリストアが失敗したときに表示されるエラー・メッセージの例を次に示します。

2つのノードAおよびBがあるとします。Backup and Recovery Toolを使用してマシンAのOracleAS Metadata Repositoryをバックアップします。同じツールを使用してマシンBでのリストアを試みた場合、次のメッセージが表示されます。

Oracle instance started
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00579: the following error occurred at 09/08/2003 16:29:15
RMAN-06003: ORACLE error from target database: ORA-01103: database name 'M16REP1' in controlfile is not 'M16MR2'
RMAN-06097: text of failing SQL statement: alter database mount
RMAN-06099: error occurred in source file: krmk.pc, line: 4124

「M16REP1」はバックアップされたデータベースのORACLE SIDです。

解決策

現在はありません。異なるORACLE SIDのデータベースに対するOracleAS Metadata Repositoryのリストアは、現在サポートされていません。

A.6 Real Application Clustersのトラブルシューティング

A.6.1 Oracle Ultra Search Webクローラがフェイルオーバーしない

クラスタ・ファイル・システムを使用しないReal Application Clustersでは、Oracle Ultra Search Webクローラが、使用可能なノードにフェイルオーバーしません。

障害

現在、Oracle Ultra Search Webクローラは、Real Application Clusterの1つのノードのみから実行されるように構成されています。そのノード（またはデータベース）が停止しても、Webクローラは使用可能なノードで起動しません。この状況は、非クラスタ・ファイル・システムのReal Application Clustersで起こります。

解決策

Real Application Clustersでクラスタ・ファイル・システムを使用している場合、Oracle Ultra Searchクローラは、任意のReal Application Clustersノードから起動可能です。この場合、1つ以上のノードが実行されている必要があります。

クラスタ・ファイル・システムが使用されていない場合、Oracle Ultra Searchクローラは、常に特定のノードで実行されます。そのノードが動作を停止した場合は、wk0reconfig.sqlスクリプトを実行してOracle Ultra Searchを別のReal Application Clustersノードに移動する必要があります。スクリプトは、次のように実行します。

> sqlplus wksys/wksys_passwd 
SQL> ORACLE_HOME/ultrasearch/admin/wk0reconfig.sql <instance_name> <connect_url>

ここで、<instance_name>は、Oracle Ultra Searchがクローリングに使用するReal Application Clustersインスタンスの名前です。この名前は、データベースに接続した後に、次のSQL文を使用することによって取得できます。

SELECT instance_name FROM v$instance

<connect_url> は、特定のインスタンスのみへの接続を保証するJDBC接続文字列で、次のようになります。

(DESCRIPTION=
  (ADDRESS_LIST=
    (ADDRESS=(PROTOCOL=TCP)
      (HOST=<nodename>)
      (PORT=<listener_port>)))
  (CONNECT_DATA=(SERVICE_NAME=<service_name>)))

Oracle Ultra Searchを、あるReal Application Clustersノードから別のノードに切り替えると、キャッシュのコンテンツが破棄されます。インスタンスを切り替えると、キャッシュの再移入のためにドキュメントの再クロールが強制されます。

A.7 その他の問題の場合

前述の項で説明した情報では十分でない場合は、Oracle MetaLink（http://metalink.oracle.com）を参照してください。問題の解決策が見つからない場合は、サービス・リクエストをログに記録してください。

関連項目

  • Oracle Application Serverのリリース・ノート（Oracle Technology NetworkのWebサイト: http://www.oracle.com/technology/
    documentation/index.htmlで入手できます）

 

戻る 次へ
Oracle
Copyright © 2005, 2007 Oracle.
All Rights Reserved.
目次
目次		 索引
索引