10gリリース3（10.1.3.2.0）
E05048-01
 目次 |
 索引 |
| Oracle Application Server 高可用性ガイド 10gリリース3（10.1.3.2.0） E05048-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の管理リカバリを使用しません。
アーカイブ・ログ・ファイルは手動で適用する必要があります。これらの作業の実行に必要な手順については、第5章「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を起動できないのは、構成に誤りがあることが考えられます。これは、10.1.2.x環境にのみ当てはまり、10.1.3.x環境には当てはまりません。
OracleAS Disaster Recoveryの同期では、スタンドアロンのOracleAS Web Cacheインストールが同期化されません。
標準のOracle Application Serverの完全なCDイメージを使用して、OracleAS Web Cacheコンポーネントをインストールします。
マシンの物理的なホスト名が変更された後も、スタンバイ・サイトの中間層インストールで間違ったホスト名が使用されている問題について説明します。
物理的なホスト名の変更に加えて、/etc/hostsファイルにも、物理的なホスト名を最初のエントリとして入力する必要があります。そうしないと、インストーラーが間違ったホスト名を使用してしまいます。
/etc/hostsファイルに物理的なホスト名を最初のエントリとして入力します。詳細は、第5.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システムでは、多くのOracle Application Serverインスタンスまたは多くのサード・パーティ・ソフトウェア、あるいはこれら両方がシステムにインストールされているために、システムPATH環境変数が1024文字の制限を超過していると、OracleAS GuardサーバーはOPMNの外部で起動され、システムがディレクトリ・パスを解決できないため、asgctlのstartupコマンドの実行に失敗する場合があります。
多くのOracle Application Serverインスタンスまたは多くのサード・パーティ・ソフトウェア、あるいはこれら両方がインストールされている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
OracleAS Guardクライアントからasgctlのadd instanceコマンドを使用するときは、そのOracleAS Guardクライアントが、トポロジに配置済のシステムから実行されている必要があります。
たとえば、既存のトポロジに追加予定のOracleAS GuardサーバーにOracleAS Guardクライアントが接続されているときは、次のエラーが返されます。
ASG_IAS-15785: ERROR: The topology is missing the instance that exists in the home where the ASG server is running. You must first discover or add the instance in home ASGCTL>
トポロジにインスタンスを追加するには、トポロジに配置済のシステムからOracleAS Guardクライアントを使用して、asgctlのadd instanceコマンドを実行します。
OracleAS Guardのadd instanceコマンドを使用してOracle RACインスタンスをトポロジに追加する際、ユーザー指定の識別子が見つからない場合に、OracleAS Guardから不適切なエラー・メッセージが返されます。ユーザーがOracleインスタンスSIDではなくデータベース名を入力した場合、問題は発生しません。
現在、OracleAS Guardがユーザー指定のデータベース識別子をoratabエントリ（UNIXの場合）またはシステム・レジストリ・サービス（Windowsの場合）で見つけられない場合、次のASG_SYSTEM-100メッセージとそれに続いて既存のASG_DUF-3554メッセージの両方がコンソールに表示されます。
UNIXシステムの場合:
ASG_SYSTEM-100: An Oracle database is identified by its database unique name (db_name) ASG_DUF-3554: The Oracle home that contains SID <user specified identifier> cannot be found
Windowsシステムの場合:
ASG_SYSTEM-100: An Oracle database is identified by its system identifier (SID) ASG_DUF-3554: The Oracle home that contains SID <user specified identifier> cannot be found
上述のメッセージが表示された場合、データベース名でなくOracleインスタンスSIDを入力してください。
スタンバイ・サイトのデータベースを起動し実行している場合は、asgctlのcreate standby databaseコマンドを発行する前に停止することをお薦めします。
スタンバイ・サイトのデータベースを停止せずにasgctlのcreate standby databaseコマンドを実行すると、次のエラーが返されます。
ASG_DGA-12500: Standby database instance "<instance_name>" already exists on host "<hostname>"
スタンバイ・サイトのデータベースが起動し実行している場合は、asgctlのcreate standby databaseコマンドを発行する前に停止します。
Windowsプラットフォームの場合、スタンバイ・システムにJDKをインストールする際に、jarユーティリティを含むディレクトリをPATHに追加する必要があります。
スタンバイ・システムにJDKをインストールする際にjarユーティリティを含むディレクトリをPATHに追加しない場合、スタンドアロン・システムのASGはjar.exeユーティリティにアクセスできなくなり、次のエラーがクローニング時に返されます。
standbynode: -->ASG_SYSTEM-100: operable program or batch file. standbynode: -->ASG_DUF-4040: Error executing the external program or script. The error code is "1" standbynode: -->ASG_IAS-15690: Error running the restore script standbynode: -->ASG_IAS-15698: Error during backup topology operation - copy step standbynode: -->ASG_DUF-3027: Error while executing Clone Instance at step - unpack step.
このエラーが返されたら、スタンバイ・システムのPATHにjarユーティリティを追加してからASGサーバーを再起動します。
データベースがすでに物理スタンバイ状態にある場合、不適切なエラーが返されます。
すでに「物理スタンバイ」状態のデータベースからasgctlのcreate standby database操作を実行しようとすると、エラーora-01671が発生します。正しくは、このエラーが返されるのではなく、スタンバイ・データベースがすでに実行中であることを示す適切なエラー・メッセージが表示されます。
エラーを無視します。
asgctlのshutdown topologyコマンドは、データベース以外のインスタンスのみを処理します。
repCA環境でOracleAS Guardがインスタンスを検出し、repCa型データベースであると判断すると、そのインスタンスはshutdown topology操作で無視されます。repCA型データベースはOracleAS Guard外で管理されるとみなされます。したがって、MRCAデータベースがトポロジに追加された環境内では、データベースはasgctlのshutdown topologyコマンドで処理されません。
asgctlのshutdown topologyコマンドではない別の方法で、repCA型データベースを停止します。
正しいユーザー名およびパスワードを入力して接続しようとしても、認証エラーが発生します。
ユーザーがOracleAS Guardサーバーに接続し、正しいユーザー名およびパスワードが入力されていても認証エラーが表示されます。
<ORACLE_HOME>/dsaディレクトリのdsa.confファイルで次のフラグを設定し、操作を再度実行します。
_realm_override=1
asgctlのfailover操作の実行後は、create standby databaseコマンドでリモート・ホストにスタンバイ・データベースを作成してからinstantiate topology操作を実行してください。
asgctlのfailover操作の直後にasgctlのinstantiate topology操作を実行しようとすると、「ORA-01665: 制御ファイルがスタンバイ制御ファイルではありません」というエラー・メッセージが返されます。
この問題の回避策は、asgctlのcreate standby databaseコマンドを最初に実行して、リモート・ホストにスタンバイ・データベースを作成することです。
OracleAS GuardをOracle RAC環境で実行する場合は、OracleAS Guardの操作時に1つのOracle RACインスタンスのみが稼動するようにしてください。
OracleAS Guardの操作時に複数のOracle RACインスタンスが稼動していると、プライマリ・データベースが複数のインスタンスにマウントされているというエラーが発生し、停止できません。次のエラーが表示されます。
ASGCTL> create standby database orcl1 on stanb06v3 . . . This operation requires the database to be shutdown. Do you want to continue? Yes or No y Database must be mounted exclusive stanb06v1: -->ASG_DUF-4950: An error occurred on host "stanb06v1" with IP "141.86.22.32" and port "7890" stanb06v1: -->ASG_DUF-3514: Failed to stop database orcl1.us.oracle.com. stanb06v1: -->ASG_DGA-13002: Error during Create Physical Standby: Prepare-primary processing. stanb06v1: -->ASG_DUF-3027: Error while executing Creating physical standby database - prepare phase at step - primary processing step.
OracleAS Guardの操作時には、1つのOracle RACインスタンスのみを稼動してください。
データベースが常駐しているソース・プライマリ・ノード以外のノードから、ASGクライアントによってcreate standby databaseコマンドが開始された場合、このコマンドは失敗します。
たとえば、本番データベースからスタンバイ・データベースにcreate standbyコマンドを実行するとします。ここで、prodnode1がプライマリ・サイト・データベースのノード名で、standbynode1がそのスタンバイ・データベースのノード名であるとします。ASGCTL shellは常にprodnode1で起動および接続される必要があります。standbynode1からASGCTL shellを実行し、prodnode1に接続した場合、create standbyコマンドは失敗します。
プライマリ・サイトのデータベースが常駐するプライマリ（ソース）ノードからcreate standbyコマンドを実行します。
RAC-RAC Linux環境のsync topologyコマンドによって、欠落アーカイブ・ログのエラーが返されます。
RAC-RAC Linux環境でのsync topologyコマンドが失敗し、次のような欠落アーカイブ・ログのエラーが返されます。
ASG_SYSTEM_-100: Please resolve missing archived logs and try again.
tnspingを使用してスタンバイ・ノードにpingを試行します。スタンバイ・ノードにpingできない場合は、そのノードのリスナーを停止し再起動してからtnspingを再試行します。
フェイルオーバーの後に警告がデータベースのアラート・ログに表示されます。
新規プライマリ・データベースがそのリモート・データベース・インスタンスへのtnspingに失敗した場合、このフェイルオーバーの後に次の警告がデータベースのアラート・ログに表示されます。
Errors in file c:¥oracle¥product¥10.2.0¥admin¥orcl¥udump¥orcl1_rfs_1816.trc: ORA-16009: remote archive log destination must be a STANDBY database . Fri Sep 08 09:11:13 2006 Errors in file c:¥oracle¥product¥10.2.0¥admin¥orcl¥bdump¥orcl1_arc1_496.trc: ORA-16009: remote archive log destination must be a STANDBY database . Fri Sep 08 09:11:13 2006 PING[ARC1]: Heartbeat failed to connect to standby 'orcl1_remote1'. Error is 16009. Fri Sep 08 09:11:50 2006 Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[67]: Assigned to RFS process 628 RFS[67]: Database mount ID mismatch [0x4342404d:0x4341ffb0] Fri Sep 08 09:11:50 2006 Errors in file c:¥oracle¥product¥10.2.0¥admin¥orcl¥udump¥orcl1_rfs_628.trc: ORA-16009: remote archive log destination must be a STANDBY database . Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[68]: Assigned to RFS process 2488 RFS[68]: Database mount ID mismatch [0x4342404d:0x4341ffb0] Fri Sep 08 09:12:05 2006 Errors in file c:¥oracle¥product¥10.2.0¥admin¥orcl¥udump¥orcl1_rfs_2488.trc: ORA-16009: remote archive log destination must be a STANDBY database . Fri Sep 08 09:12:14 2006 Errors in file c:¥oracle¥product¥10.2.0¥admin¥orcl¥bdump¥orcl1_arc1_496.trc: ORA-16009: remote archive log destination must be a STANDBY database
アラート・ログのこれらのエラー・メッセージを回避するには、次のコマンドを使用して、log_archive_dest_2パラメータをNULLにします。
alter system set log_archive_dest_2='SERVICE=null LGWR ASYNC REOPEN=60'; alter system set log_archive_dest_state_2='defer';
一部のデータベース・ストレージ・オプションが使用されている場合、ASG_ORACLE-300: ORA-01276エラーでcreate standby databaseコマンドが失敗します。
データベース・ストレージ・オプションでOMF（Oracle Managed Files）またはASM（Automatic Storage Management）が使用されている場合、ASG_ORACLE-300: ORA-01276エラーでcreate standby databaseコマンドが失敗します。
create standby databaseコマンドを実行する前に、DBCAを使用してプライマリ・サイト上に別のストレージ・オプションを使用し新しいデータベース・インスタンスを作成します。
既存のデータベースを上書きしようとすると、エラー・メッセージが表示されます。
create standbyコマンドを実行し、既存のデータベースを上書きすると、次のエラー・メッセージが表示されます。
Checking whether standby instance already exists proddnode1: -->ASG_DUF-4950: An error occurred on host "proddnode1" with IP "a.b.c.d" and port "7891" standbynode1: -->ASG_DUF-4950: An error occurred on host "standbynode1" with IP "e.f.g.h" and port "7891" standbynode1: -->ASG_DGA-12500: Standby database instance "db102" already exists on host "standbynode1". standbynode1: -->ASG_DGA-13001: Error during Create Physical Standby: Prepare-check standby. standbynode1: -->ASG_DUF-3027: Error while executing Creating physical standby database - prepare phase at step - check standby step.
スタンバイ・サイトのデータベースに関するエントリを削除するため、Windowsではoradim -delete -sid <DBSID>コマンドを使用します。また、UNIXプラットフォームではoratabからデータベース・エントリを削除します。その後、create standby databaseを再度実行し、既存のデータベースを正常に上書きします。
add instanceコマンドを使用してOracle RACのデータベース・インスタンスをトポロジに追加する場合、使用するデータベースの名前はLinuxシステム上とWindowsシステム上で異なります。Linuxシステムの場合、oratabエントリがホームの検出に使用され、データベース名（dbn）を使用して行われます。Windowsシステムの場合、システム・レジストリがホームの検出に使用されますが、dbnではなくデータベースID（dbid）がレジストリにあるので、dbidが使用されます。そのため、WindowsシステムでインスタンスをOracle RACデータベースであるトポロジに追加する場合、Oracle RACのデータベース・インスタンスの参照にはデータベース名ではなくデータベースのSID名を使用する必要があります。
Oracle RACデータベースをWindowsにインストールした場合、Oracle RAC DBnameまたはグローバルDBnameはレジストリまたはoratabに格納されません。そのため、Windowsシステムでこの問題に対処するには、次のようにします。asgctlのadd instanceコマンドを使用する場合、必ずRACデータベースのOracleインスタンスSIDを使用し、スタンバイ・データベースの作成、トポロジのインスタンス化、トポロジの同期、トポロジのスイッチオーバーなどのOracle Disaster Recoveryサイクルの残りの操作を続行します。次に例を示します。
asgctl> add instance <InstanceSID of Oracle RAC> on <virtualhost> asgctl> add instance orcl1 on asinfra.us.oracle.com
asgctlコマンドでは、Oracle RACデータベースのOracleインスタンスSIDを使用します。
プライマリ・サイトに存在するのと同じTEMPディレクトリ構造を、スタンバイ・サイトに設定する必要があります。
プライマリ・サイトに存在するのと同じTEMPディレクトリ構造をスタンバイ・サイトに設定しないと、DCMは適切に動作しません。OracleAS Guardのverify操作では、この問題を検出しません。
プライマリ・サイトおよびスタンバイ・サイトの両方に同じTEMPディレクトリを維持します。スタンバイ・サイトの環境変数を作成する際には、各スタンバイ・ピア環境が本番ホームのレプリカであることを確認します。忘れられるまたは見落とされることの多い領域は、TEMPディレクトリです。
OracleAS GuardがWindows上でcreate standby databaseコマンドを発行するときに、ターゲット・スタンバイ・データベース環境がクリーン・アップされていない場合、エラーが発生します。
OracleAS GuardがWindows上でcreate standby databaseコマンドを発行するときに、ターゲット・スタンバイ・データベース環境がクリーン・アップされていない場合、次のエラーが発生します。
ASG_DGA-12500: Standby database instance "db25" already exists on host <hostame>
前回のスタンバイの設定がなんらかのシステム上の理由で失敗したか、既存のスタンバイ・データベースを再確立する操作のために、ターゲット環境がクリーンされていない場合があります。
次のコマンドを使用して、環境をクリーン・アップします。
oradim -delete -sid db25
環境のクリーン・アップ後に、asgctlのcreate standby databaseコマンドを再発行できます。
プライマリ・サイトのトポロジに複数のノードがある場合は、Oracle Application Serverの各層のインスタンス名は、プライマリ・サイトの全ノードのすべてのホームで一意である必要があります。
Oracle Application Serverの各層のインスタンス名が、プライマリ・サイトの全ノードのすべてのホームで一意でない場合、すでに追加したインスタンスと同じ名前を使用して2つ目のインスタンスに対するadd instanceコマンドを実行する際に、次のエラーが返されます。
ASGCTL> add instance ohs on primaryhost1 ASGCTL> add instance ohs on primaryhost2 host2: -->ASG_IAS-15782: Error: Instance "ohs" already exists in the topology ASGCTL>
Oracle Application Serverの各層の名前が、プライマリ・サイトの全ノードのすべてのホームで一意であることを確認します。
「Java SSO構成」ページの「インスタンスおよびプロパティ」タブに、誤解を招くようなメッセージが表示されます。
Application Server Controlを使用してJava Single Sign-On（Java SSO）を構成する際にJava SSOアプリケーションがクラスタ内で稼動していない場合、「Java SSO構成」ページの上部に次のメッセージが表示されます。
There are no active Java SSO applications in the cluster. At least one Java SSO application (javasso) must be running before you can configure Java SSO.
しかし、「Java SSO構成」ページの「インスタンスおよびプロパティ」タブには、次の誤解を招くようなメッセージも表示されます。
Java SSO is configured for this cluster.
「Java SSO構成」ページの上部にエラー・メッセージが表示される際には、「インスタンスおよびプロパティ」タブのメッセージを無視します。実際には、クラスタ内で少なくとも1つのJava SSOアプリケーション・インスタンスが稼動されないと、Java SSOは構成できません。
詳細は、『Oracle Application Server Containers for J2EEセキュリティ・ガイド』のOC4J Java Single Sign-Onに関する項を参照してください。
スタンバイ・データベースのTNS別名のエントリにドメインが含まれていると、トポロジのインスタンス化に失敗します。
スタンバイ・データベースのTNS別名のエントリにドメインが含まれていると、次のエラーが返されます。
ORCL.ORACLE.COM = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = standbynode.oracle.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ORCL.ORACLE.COM) ) ) . ASG_ORACLE-300: ORA-12514: TNS:listener does not currently know of service @ requested in connect descriptor
インスタンス化コマンドを実行する前に、スタンバイ・データベースのsqlnet.oraにあるNAMES.DEFAULT_DOMAINパラメータに正しいドメインを追加します。
Windowsオペレーティング・システムでcreate standby databaseコマンドを実行すると、エラーが返されます。
create standby databaseコマンドでは、SPFILEがスタンバイ・サイトのORACLE_HOME/databaseではなく、ORACLE_HOME/dbsディレクトリに作成されます。その結果、スタンバイ・サイトでデータベースを起動する際に、ORACLE_HOME/dbsのSPFILEではなくpfileが使用されます。ロールの切替えのためにスタンバイ・サイトからcreate standbyコマンドを再度実行すると、データベースではSPFILEが使用されていないため、コマンドが失敗します。
stanbynode1: -->ASG_DUF-4950: An error occurred on host "stada26" with IP "140.87.5. @ 102" and port "7892" standbynode1: -->ASG_ORACLE-300: ORA-32001: write to SPFILE requested but no SPFILE specified at startup standbynode1: -->ASG_DUF-3700: Failed in SQL*Plus executing SQL statement: alter sys tem set db_file_name_convert= 'C:¥WORK¥ORADATA¥ASDB01','C:¥WORK¥ORADATA¥ASDB01' SCOPE=SPFILE /* ASG_DGA */;. standbynode1: -->ASG_DGA-13010: Error during Create Physical Standby: Finish-configure primary. standbynode1: -->ASG_DUF-3027: Error while executing Creating physical standby database - finish phase at step - finish step. ASG_ORACLE-300: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
Windowsの場合は、create standby databaseコマンドを実行した後で、スタンバイ・データベース・サイトのSPFILEをORACLE_HOME/dbsからORACLE_HOME/databaseにコピーします。
スイッチオーバー操作後に手動でRACデータベースを起動すると、ORA-09925エラーが表示されます。
ASGスイッチオーバー操作後にRACデータベース・インスタンスの一部を手動で起動すると、次のエラーが表示されます。
SQL> startup; ORA-09925: Unable to create audit trail file Linux Error: 2: No such file or directory Additional information: 9925
初期化ファイルのaudit_file_destパラメータで指定されているディレクトリが存在することを確認します。
次に例を示します。
mkdir <ORACLE_HOME>/admin/<dbname>/admin
この項では、高可用性構成の中間層コンポーネントの一般的な障害と解決策について説明します。この項の項目は次のとおりです。
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 © 2007, Oracle. All Rights Reserved. |
|