ヘッダーをスキップ

Oracle Application Server 高可用性ガイド
10gリリース3(10.1.3.2.0)

E05048-01
目次
目次
索引
索引

戻る 次へ

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

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

A.1 OracleAS Disaster Recoveryトポロジのトラブルシューティング

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

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

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

障害

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

解決策

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

A.1.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.1.3 dcmctl resyncInstance -force -scriptの手順でスイッチオーバー操作に失敗する

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変数を利用できるようになります。

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

スタンバイ・サイトでOracleAS Web Cacheを起動できないのは、構成に誤りがあることが考えられます。これは、10.1.2.x環境にのみ当てはまり、10.1.3.x環境には当てはまりません。

障害

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

解決策

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

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

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

障害

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

解決策

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

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

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

障害

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

検証操作は、中間層インスタンスを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.1.7 ファームの同期操作でエラー・メッセージが返される

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.1.8 WindowsシステムでPATH環境変数が1024文字を超過している場合にasgctlのstartupコマンドの実行に失敗する場合がある

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

A.1.9 リモート・クライアントからインスタンスを追加すると、リモート・インスタンスではなくローカル・インスタンスに追加される

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コマンドを実行します。

A.1.10 ユーザー指定のデータベース識別子が見つからない場合、OracleAS Guardから不適切なメッセージが返される

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を入力してください。

A.1.11 asgctlのcreate standby databaseコマンドを発行する前に、スタンバイ・サイトのデータベース・インスタンスを停止する必要がある

スタンバイ・サイトのデータベースを起動し実行している場合は、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コマンドを発行する前に停止します。

A.1.12 Windowsでの障害時リカバリ・クローニングに関する既知の問題

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サーバーを再起動します。

A.1.13 Oracle RAC-非Oracle RAC環境で、データベースがすでに物理スタンバイ状態にある場合、asgctlのcreate standby database操作が不適切なエラーを返す

データベースがすでに物理スタンバイ状態にある場合、不適切なエラーが返されます。

障害

すでに「物理スタンバイ」状態のデータベースからasgctlのcreate standby database操作を実行しようとすると、エラーora-01671が発生します。正しくは、このエラーが返されるのではなく、スタンバイ・データベースがすでに実行中であることを示す適切なエラー・メッセージが表示されます。

解決策

エラーを無視します。

A.1.14 asgctlのshutdown topologyコマンドではrepCa型データベースであると検出されたMRCAデータベースが停止しない

asgctlのshutdown topologyコマンドは、データベース以外のインスタンスのみを処理します。

障害

repCA環境でOracleAS Guardがインスタンスを検出し、repCa型データベースであると判断すると、そのインスタンスはshutdown topology操作で無視されます。repCA型データベースはOracleAS Guard外で管理されるとみなされます。したがって、MRCAデータベースがトポロジに追加された環境内では、データベースはasgctlのshutdown topologyコマンドで処理されません。

解決策

asgctlのshutdown topologyコマンドではない別の方法で、repCA型データベースを停止します。

A.1.15 OracleAS Guardサーバーへの接続で認証エラーが返される場合がある

正しいユーザー名およびパスワードを入力して接続しようとしても、認証エラーが発生します。

障害

ユーザーがOracleAS Guardサーバーに接続し、正しいユーザー名およびパスワードが入力されていても認証エラーが表示されます。


注意

このDSA構成ファイル・パラメータは、OracleAS Guardリリース情報のreadme.txtファイルのOracleAS Guard構成ファイル・パラメータに関する項で記述されていないことに注意してください。 


解決策

<ORACLE_HOME>/dsaディレクトリのdsa.confファイルで次のフラグを設定し、操作を再度実行します。

_realm_override=1

A.1.16 failover操作の実行後にノード全体でinstantiate topologyを実行すると、ORA-01665エラーが発生する

asgctlのfailover操作の実行後は、create standby databaseコマンドでリモート・ホストにスタンバイ・データベースを作成してからinstantiate topology操作を実行してください。

障害

asgctlのfailover操作の直後にasgctlのinstantiate topology操作を実行しようとすると、「ORA-01665: 制御ファイルがスタンバイ制御ファイルではありません」というエラー・メッセージが返されます。

解決策

この問題の回避策は、asgctlのcreate standby databaseコマンドを最初に実行して、リモート・ホストにスタンバイ・データベースを作成することです。

A.1.17 Oracle RACの複数のインスタンスが実行中であるとOracleAS Guardはデータベースを停止できない

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インスタンスのみを稼動してください。

A.1.18 別のASGCTLシェルで開始された場合に、スタンバイの作成が失敗する

データベースが常駐しているソース・プライマリ・ノード以外のノードから、ASGクライアントによってcreate standby databaseコマンドが開始された場合、このコマンドは失敗します。

障害

たとえば、本番データベースからスタンバイ・データベースにcreate standbyコマンドを実行するとします。ここで、prodnode1がプライマリ・サイト・データベースのノード名で、standbynode1がそのスタンバイ・データベースのノード名であるとします。ASGCTL shellは常にprodnode1で起動および接続される必要があります。standbynode1からASGCTL shellを実行し、prodnode1に接続した場合、create standbyコマンドは失敗します。

解決策

プライマリ・サイトのデータベースが常駐するプライマリ(ソース)ノードからcreate standbyコマンドを実行します。

A.1.19 欠落アーカイブ・ログの解決

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を再試行します。

A.1.20 フェイルオーバー後にハートビートの失敗がアラート・ログに表示される

フェイルオーバーの後に警告がデータベースのアラート・ログに表示されます。

障害

新規プライマリ・データベースがそのリモート・データベース・インスタンスへの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';

A.1.21 データベースでOMFストレージまたはASMストレージが使用されている場合に、スタンバイ・データベースの作成に失敗する

一部のデータベース・ストレージ・オプションが使用されている場合、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を使用してプライマリ・サイト上に別のストレージ・オプションを使用し新しいデータベース・インスタンスを作成します。

A.1.22 スタンバイの作成中に、データベースがすでに存在しているというエラーが発生する

既存のデータベースを上書きしようとすると、エラー・メッセージが表示されます。

障害

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を再度実行し、既存のデータベースを正常に上書きします。

A.1.23 Oracle RACデータベースをトポロジに追加しようとすると、OracleAS Guardのadd instanceコマンドが失敗する

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を使用します。

A.1.24 OracleAS Guardのasgctl verify操作ではTEMPディレクトリがチェックされない

プライマリ・サイトに存在するのと同じTEMPディレクトリ構造を、スタンバイ・サイトに設定する必要があります。

障害

プライマリ・サイトに存在するのと同じTEMPディレクトリ構造をスタンバイ・サイトに設定しないと、DCMは適切に動作しません。OracleAS Guardのverify操作では、この問題を検出しません。

解決策

プライマリ・サイトおよびスタンバイ・サイトの両方に同じTEMPディレクトリを維持します。スタンバイ・サイトの環境変数を作成する際には、各スタンバイ・ピア環境が本番ホームのレプリカであることを確認します。忘れられるまたは見落とされることの多い領域は、TEMPディレクトリです。

A.1.25 create standby database操作がWindowsでASG_DGA-12500エラー・メッセージを表示して失敗する

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コマンドを再発行できます。

A.1.26 トポロジ内のホスト間でインスタンス名を一意にする必要がある

プライマリ・サイトのトポロジに複数のノードがある場合は、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の各層の名前が、プライマリ・サイトの全ノードのすべてのホームで一意であることを確認します。

A.1.27 JSSOページに誤解を招くようなメッセージが表示される

「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に関する項を参照してください。

A.1.28 TNS別名にドメインが含まれていると、トポロジのインスタンス化に失敗する

スタンバイ・データベースの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パラメータに正しいドメインを追加します。

A.1.29 create standby databaseの実行時にORA-32001エラーが発生する

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コマンドを実行した後で、スタンバイ・データベース・サイトのSPFILEORACLE_HOME/dbsからORACLE_HOME/databaseにコピーします。

A.1.30 スイッチオーバー後に手動でRACデータベースを起動するとORA-09925エラーが発生する

スイッチオーバー操作後に手動で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 

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

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

A.2.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.2.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.ConnectionYESまたはDEFAULTに、Dedicated.RMIcontextFALSEに設定してください。

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

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

関連項目

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

 


戻る 次へ
Oracle
Copyright © 2007, Oracle.

All Rights Reserved.
目次
目次
索引
索引