10gリリース3（10.1.3.1.0）
B31835-01
 目次 |
 索引 |
| Oracle Application Server 高可用性ガイド 10gリリース3（10.1.3.1.0） B31835-01 |
|
この付録では、Oracle Application Serverを高可用性構成で配置および管理するときに発生する問題と、それらの解決方法を説明します。この付録の項は次のとおりです。
この項では、OracleAS Disaster Recoveryの構成の一般的な障害と解決策について説明します。この項の項目は次のとおりです。
OracleAS Disaster Recoveryスタンバイ・サイトのOracleAS Metadata Repositoryが、プライマリ・サイトのOracleAS Metadata Repositoryと同期化されない問題について説明します。
OracleAS Disaster Recoveryソリューションでは、手動による構成と、プライマリ・サイトからスタンバイ・サイトへのデータ・ファイルの転送が必要です。また、データ・ファイル（アーカイブ・データベース・ログ・ファイル）は、スタンバイ・サイトで自動的に適用されません。つまり、OracleAS Disaster RecoveryはOracle Data Guardの管理リカバリを使用しません。
アーカイブ・ログ・ファイルは手動で適用する必要があります。これらの作業の実行に必要な手順については、第6章「OracleAS Disaster Recovery」を参照してください。
スタンバイ・インスタンスが、フェイルオーバーまたはスイッチオーバー操作の後に起動しない問題について説明します。
IPアドレスはインスタンスの構成で使用されます。OracleAS Disaster Recoveryの設定では、本番サイトとスタンバイ・サイトのピア・インスタンスに、同一のIPアドレスは必要ありません。OracleAS Disaster Recoveryの同期では、本番サイトとスタンバイ・サイト間のIPアドレスの不一致が調整されません。したがって、構成で明示的なIPアドレスxxx.xx.xxx.xxを使用する場合、同期化後のスタンバイの構成は機能しません。
明示的なIPアドレスの使用を避けます。たとえば、OracleAS Web CacheおよびOracle HTTP Serverの構成では、リスニング・アドレスとしてIPアドレスのかわりにANYまたはホスト名を使用します。
OracleAS Disaster Recoveryのasgctl switchover操作では、プライマリ・サイトとスタンバイ・サイトの両方のopmn.xmlファイルでTMP変数を同じ値に定義する必要があります。
OracleAS Disaster Recoveryのスイッチオーバーがdcmctl resyncInstance -force -scriptの手順で失敗し、ディレクトリが見つからないことを示すメッセージが表示されます。
スイッチオーバー操作中に、opmn.xmlファイルがプライマリ・サイトからスタンバイ・サイトにコピーされます。このため、TMP変数はプライマリ・サイトとスタンバイ・サイトの両方のopmn.xmlファイルで同じ値に定義する必要があります。そうしないと、スイッチオーバー操作に失敗します。asgctl switchover操作を実行する前に、両方のサイトのopmn.xmlファイルでTMP変数が同じ値に定義されており、同じディレクトリ構造に解決されることを確認してください。
たとえば、次のコードは、WindowsおよびUNIX環境でのTMP変数のサンプル定義を示しています。
Example in Windows Environment: ------------------------------- . . . <ias-instance id="infraprod.iasha28.us.oracle.com"> <environment> <variable id="TMP" value="C:¥DOCUME~1¥ntregres¥LOCALS~1¥Temp"/> </environment> . . . Example in Unix Environment: ---------------------------- . . . <ias-instance id="infraprod.iasha28.us.oracle.com"> <environment> <variable id="TMP" value="/tmp"/> </environment> . . .
この問題の回避策は、プライマリ・サイトのopmn.xmlファイルのTMP変数値を変更し、dcmctl update config操作を実行し、asgctl switchover操作を実行することです。この方法によれば、中間層を再インストールしなくても、変更したTMP変数を利用できるようになります。
スタンバイ・サイトでOracleAS Web Cacheを起動できないのは、フェイルオーバーまたはスイッチオーバー後のスタンドアロンOracleAS Web Cacheの構成に誤りがあることが考えられます。
OracleAS Disaster Recoveryの同期では、スタンドアロンのOracleAS Web Cacheインストールが同期化されません。
標準のOracle Application Serverの完全なCDイメージを使用して、OracleAS Web Cacheコンポーネントをインストールします。
マシンの物理的なホスト名が変更された後も、スタンバイ・サイトの中間層インストールで間違ったホスト名が使用されている問題について説明します。
物理的なホスト名の変更に加えて、/etc/hostsファイルにも、物理的なホスト名を最初のエントリとして入力する必要があります。このファイルの変更に失敗すると、インストーラーが間違ったホスト名を使用してしまいます。
/etc/hostsファイルに物理的なホスト名を最初のエントリとして入力します。詳細は、第6.2.2項「ホスト名解決の構成」を参照してください。
スタンバイ・ファームのファーム検証操作を実行すると、中間層マシンのインスタンスが見つからず、スタンバイ・ファームが本番のファームと対称性がないことを示すエラー・メッセージが表示され、失敗します。
スタンバイ・ファームのファーム検証操作では、本番およびスタンバイ・ファームが互いに対称で、一貫性があり、障害時リカバリの要件に一致していることが検証されます。
検証操作は、中間層インスタンスをmid_tier.<physical_hostname>ではなくmid_tier.<hostname>とみなすため、失敗します。インストール時に設定した環境変数_CLUSTER_NETWORK_NAME_に問題があると考えることもできます。ただし、この状況では違います。_CLUSTER_NETWORK_NAME_環境変数設定のチェックで、このエントリが正しいことがわかっています。一方、/etc/hostsファイルのコンテンツのチェックで、問題になっている中間層のエントリが正しくないことがわかります。つまり、すべての中間層インストールは、/etc/hostsファイルの2番目の列からホスト名を取得します。
たとえば、次の使用例を想定します。
examp1およびexamp2の2つの環境を使用しています。
examp1およびexamp2にホストinfraとしてインストールしています。
examp1およびexamp2にホストnode1としてインストールしています。
duf.jarおよびbackup_restoreファイルで更新されています。
asgctl）を起動しています。
connect asg、set primary、dump farmのasgctl操作を実行しています。
standby farmに、asgctl verify farmの操作を実行しました。しかし、インスタンスをmid_tier.node1.us.oracle.comではなくmid-tier.examp1とみなすため失敗します。
/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番目の列のエントリをチェックし、前述で説明した、問題になっている中間層ノードのホスト名と一致するように変更します。
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コマンドの前に実行する必要があります。
Windowsシステムでは、多くのOracleASインスタンスまたは多くのサード・パーティ・ソフトウェア、あるいはこれら両方がシステムにインストールされているために、システムPATH環境変数が1024文字の制限を超過していると、OracleAS GuardサーバーはOPMNの外部で起動され、システムがディレクトリ・パスを解決できないため、asgctl startupコマンドの実行に失敗する場合があります。
多くのOracleASインスタンスまたは多くのサード・パーティ・ソフトウェア、あるいはこれら両方がインストールされているWindowsシステムでは、OPMNの外部で実行されるasgctl startupコマンドによって、特定のファイルのダイナミック・リンク・ライブラリorawsec9.dllが見つからないことを示すポップアップ・エラーに続いて、DufExceptionが返されることがあります。次に、例を示します。
C:¥product¥10.1.3¥OC4J_1¥dsa¥bin> asgctl startup <<Popup Error:>> The dynamic link library *orawsec9.dll* could not be found. <<The exception:>> oracle.duf.DufException at oracle.duf.DufOsBase.constructInstance(DufOsBase.java:1331) at oracle.duf.DufOsBase.getDufOs(DufOsBase.java:122) at oracle.duf.DufHomeMgr.getCurrentHomePath(DufHomeMgr.java:582) at oracle.duf.dufclient.DufClient.main(DufClient.java:132) stado42: -->ASG_SYSTEM-100: oracle.duf.DufException -----------------------------------------------------------------------------
ただし、このdllはORACLE_HOME¥binディレクトリに存在しません。
このエラーは、OracleAS Guardスタンドアロン・キットでは発生しません。ファイルorawsec9.dllはORACLE_HOME¥dsa¥binフォルダに存在するためです。
回避策は、必要なパス情報を使用してシステムPATH変数を手動で編集するか、関連する%PATH%変数を指定してコマンド・プロンプトのPATHを手動で上書きすることです。次に、例を示します。
C:¥set PATH=C:¥product¥10.1.3¥OracleAS_OC4J_2¥bin; C:¥product¥10.1.3¥OracleAS_OHS1¥jre¥1.4.2¥bin¥client; C:¥product¥10.1.3¥OracleAS_OHS1¥jre¥1.4.2¥bin; C:¥product¥10.1.3¥OracleAS_OHS1¥bin;C:¥product¥10.1.3¥OC4J_1¥bin C:¥product¥10.1.3¥OC4J_1¥dsa¥bin> asgctl startup
この項では、高可用性構成の中間層コンポーネントの一般的な障害と解決策について説明します。この項の項目は次のとおりです。
NIC（ネットワーク・インタフェース・カード）が2つ搭載されているコンピュータでOracleAS Cluster（OC4J-EJB）を実行しており、一方のNICをネットワーク接続に、もう一方のNICをクラスタ内の他のノードへの接続に使用している場合に、マルチキャスト・メッセージが正常に送受信されないことがあります。これは、セッション情報がクラスタ内のノード間でレプリケートされないことを意味します。
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）。
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プロパティ値を示しています。
| 値 | 意味 |
|---|---|
|
|
キャッシュなし。 |
|
|
リフレッシュなしで1回だけキャッシュ。 |
|
|
ここで指定した秒数を経過すると、キャッシュをリフレッシュできます。ただしこれは自動ではありません。リフレッシュは、「 このプロパティを設定しない場合のデフォルト値は60です。 |
このプロパティを設定しても、最初のnew InitialContext()コールではある程度の遅延が見られますが、その後のコールでは、OPMNにネットワーク接続せずにキャッシュからデータを取得するため、速度が増します。
パフォーマンスを最適にするために、さらにDedicated.ConnectionをYESまたはDEFAULTに、Dedicated.RMIcontextをFALSEに設定してください。
前述の項で説明した情報では十分でない場合は、Oracle MetaLink（http://metalink.oracle.com）を参照してください。問題の解決策が見つからない場合は、サービス・リクエストをログに記録してください。
|
 Copyright © 2006, Oracle. All Rights Reserved. |
|