Oracle Application Serverリリース・ノート 10g(10.1.4.0.1) for Microsoft Windows(64-bit)on Intel Itanium B31752-05 |
|
戻る |
次へ |
この章では、OracleAS Disaster Recoveryソリューションを使用する高可用性トポロジに関連した問題について説明します。この章の内容は次のとおりです。
この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。
4.1.3項「OracleAS Guardリリース10.1.2.1.1はOracle RACデータベースで使用できない」
4.1.4項「OracleAS Guardでユーザー指定の識別子を検索できない場合、不適切なエラー・メッセージが表示される」
OracleAS Guardキット10.1.2.2.1スタンドアロン・インストール・キットを使用して、OracleAS Guardのリリース10.1.2.2.1へのアップグレードをお薦めします。インストール・キットは、次のURLにあるOracle Technology Networkで入手できます。
現在、asgctlのトポロジのクローニング操作のセマンティックでは、OracleASホームの外部にあるデータベースをクローニングしません。そのため、いくつかのインフラストラクチャ・インストール・タイプを使用してOracleASホームにインストールされたデフォルトのデータベースのみクローニングされます。asgctlのcreate standby databaseコマンドは、Oracle Data Guardに精通していないユーザーが使用します。
このリリースに同梱されているOracleAS Guardのリリースは10.1.2.1.1です。このOracleAS Guardリリースは、Oracle RACデータベースでは使用できません。その他すべての目的について、このOracleAS GuardリリースはOracleで完全にサポートされています。
Oracle RACデータベースでOracleAS Guardを使用する場合は、OracleAS Guardのリリース10.1.2.2スタンドアロン版をこのリリースとともに使用することをお薦めします。OracleAS Guardリリース10.1.2.2(説明書付き)は、OracleAS Guardスタンドアロン・インストールとしてオラクル社のOTNからダウンロードできます。詳しい説明は、Oracleサポートに問い合せてください。
OracleAS Guardでユーザー指定の識別子を検索できない場合、不適切なエラー・メッセージが返されます。OracleインスタンスSIDではなくデータベース名を入力した場合、これが問題であるとは指摘されません。
OracleAS Guardで、ユーザー指定のデータベース識別子に対応するシステム・レジストリ・サービスを検出できない場合、次のASG_SYSTEM-100メッセージが既存のASG_DUF-3554メッセージより優先され、両方のメッセージがコンソールに表示されます。
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
この項では、構成の問題およびその回避方法について説明します。内容は次のとおりです。
4.2.2項「repCaタイプのデータベースであると検出されたMRCAデータベースがasgctlのshutdown topologyコマンドで停止しない」
4.2.5項「本番サイトとスタンバイ・サイトで同じASGポートを使用してclone instance操作の問題を回避する」
4.2.7項「プライマリ・ホストとスタンバイ・ホストでOracleホームの数が異なるとASGクローニングがサポートされない」
4.2.9項「TNSNAMES.ORAファイル内のエントリにドメイン名がないとDisaster Recoveryで問題が生じる」
プライマリ・サイトに存在するものと同じTEMPディレクトリ構造をスタンバイ・サイトに設定する必要があります。設定しないとDCMが適切に機能しません。OracleAS Guardの検証操作では、この問題が検出されません。
この問題の回避方法は、高可用性の管理者がプライマリ・サイトとスタンバイ・サイトの両方で同じTEMPディレクトリを維持することです。スタンバイ・サイトの環境変数を作成するとき、各スタンバイ・ピアの環境が本番ホームのレプリカであることを確認します。TEMPディレクトリの設定は、忘れたり見落としたりしがちです。
asgctlのshutdown topologyコマンドはデータベース以外のインスタンスのみを処理します。そのため、repCA環境でOracleAS Guardがインスタンスを検出し、repCaタイプのデータベースであると判定した場合、このインスタンスはトポロジの停止操作で無視されます。repCAタイプのデータベースはOracleAS Guardの外部で管理されているとみなされます。
Disaster Recoveryトポロジでは、プライマリ・サイトとスタンバイ・サイトでデータベース・ピアのSIDが同じである必要があります。
データベースの初期化パラメータは、すべて大文字で表記します。
次の例では、アーカイブ・ログの保存先パラメータに使用されるserviceというデータベース初期化パラメータがすべて大文字(SERVICE)で表記されています。
log_archive_dest_2="SERVICE=SIDM valid_for=(online_logfiles,primary_role) db_unique_name=SIDM"
一方、次の例では、アーカイブ・ログの保存先パラメータに使用されるserviceというデータベース初期化パラメータが小文字(service)で表記されています。
log_archive_dest_2="service=SIDM valid_for=(online_logfiles,primary_role) db_unique_name="SIDM"
データベース初期化パラメータがすべて大文字で表記されていない場合、instantiate topology
またはsync topology
操作で次のようなエラー・メッセージが出力される可能性があります。
stajo05: -->ASG_DUF-4950: An error occurred on host "stajo05" with IP "140.87.25.33" and port "7890" stajo05: -->ASG_SYSTEM-100: String index out of range: -9 stajo05: -->ASG_DUF-3760: Failed to query archive log destination information.stajo05: -->ASG_IAS-15753: Error preparing to instantiate the topology on host "stajo05" stajo05: -->ASG_DUF-3027: Error while executing Instantiating each instance in the topology to standby topology at step - prepare step.
プライマリ・サイトとスタンバイ・サイトで同じASGポートを使用して、次のようなエラー・メッセージがclone instance操作で出力されるのを回避します。
3-May 15:45:43 >>clone instance prodsso1 to stbyinfra1 3-May 15:45:43 stamx11: -->ASG_DUF-4950: An error occurred on host "stamx11" with IP "140.87.21.201" and port "7890" stamx11: -->ASG_DUF-3601: Error connecting to server host 152.68.64.213 on port 7890 stamx11: -->ASG_DUF-3512: Error creating remote worker on node 152.68.64.213:7890.
dsa.conf
ファイルにはASGの構成情報が含まれ、アプリケーション・サーバー・インスタンスのバックアップおよびリストアのIP構成を構成します。dsa.conf
ファイル構成は、アプリケーション・サーバー・インスタンス間で対称的に処理されます。このため、本番サイトのインスタンスからのdsa.conf
ファイルにより、対応するスタンバイ・サイトのインスタンスが同期化されます。
本番インスタンスとスタンバイ・インスタンスのペアでは、ASGのポート番号が一致する必要があります。
ベスト・プラクティスとして、完全修飾パス名とともにadd instanceコマンドを使用します。
Oracleホームの数がプライマリ・ホストとスタンバイ・ホストで異なる場合、DR構成ではASGのclone topology
およびclone instance
コマンドがサポートされません。
クローニング操作の一部として、各ホストのOracleインベントリがクローニングされます。したがって、クローニングされるホストのOracleホーム構成は対称的であることが前提となっています。サポートされるDisaster Recoveryの非対称トポロジの詳細は、リリース10.1.3.2.0の『Oracle Application Server高可用性ガイド』の5.1.3.2項を参照してください。
Windowsシステムでは、Disaster Recovery構成でクローニング操作を実行する前に、次の回避策をとります。
Disaster Recovery構成でクローニング操作を実行する前に、C:\windows\system32
ディレクトリの下にsc.exe
(サービス・キット)のバージョン5.0.2134.1以上をインストールします。
Windowsでクローニング操作を実行する前にこの手順を実行しないと、ASGのクローニング操作時に次のようなエラーが表示される可能性があります。
stajz09: -->ASG_DUF-4040: Error executing the external program or script. The error code is "255" stajz09: -->ASG_IAS-15689: Error running the backup script stajz09: -->ASG_IAS-15685: Failed to backup configuration data for instance "IM.asinfra.us.oracle.com" stajz09: -->ASG_DUF-3027: Error while executing Clone Instance at step - backup step. stajz09: -->ASG_DUF-3027: Error while executing Clone Topology at step - clone home step.
%ORACLE_HOME%\opmn\conf\opmn.xml
ファイルで、dcm-daemonコンポーネントのstart timeoutパラメータの再試行間隔を5秒に増加します。次の例に、dcm-daemonコンポーネントのstart timeoutパラメータの再試行間隔が5に設定されたopmn.xml
ファイルのセクションを示します。
<ias-component id="dcm-daemon" status="enabled" id-matching="true"> <process-type id="dcm-daemon" module-id="DCMDaemon"> <start timeout="600" retry="5"/> <stop timeout="120"/> <process-set id="dcm" numprocs="1">
Windowsでクローニング操作を実行する前にこの2番目の手順を実行しないと、ASGのクローニング操作時に次のようなエラーが表示される可能性があります。
stajz09: -->ASG_SYSTEM-100: Command "C:\work\im/opmn/bin/opmnctl.exe shutdown" failed, check log file C:\work\im\dsa\bkup\log/2007-07-17_01-41-51_loha.log for detail. stajz09: -->ASG_SYSTEM-100: Failure : prepare failed stajz09: -->ASG_SYSTEM-100: stajz09: -->ASG_SYSTEM-100: OPMN managed processes could not be stopped. stajz09: -->ASG_SYSTEM-100: Status code: stajz09: -->ASG_SYSTEM-100: opmnctl shutdown failed.
10.1.4 IMに加えて、10.1.2.2パッチ・セットが適用されている場合は、さらにパッチ5950169も適用する必要があります。適用しない場合、クローニング操作が失敗します。
以前の10.1.xリリースでは、TNSNAMES.ORA
ファイル内のデータベース・エントリはドメイン名なしで作成されていました。
Disaster Recoveryでは、TNSNAMES.ORA
ファイル内のデータベース・エントリのドメイン名が欠如していると、instantiate topology
または他のASGの操作で問題が発生することがあります。
たとえば、次のTNSNAMES.ORA
ファイルのエントリにはドメイン名がなく、Disaster Recoveryで問題が生じる可能性があります。
ORCL1 = (DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE = yes) (ADDRESS = (PROTOCOL = TCP)(HOST = idmdrtest)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl1.pdx.com) ) ) )
この場合、Disaster Recoveryで問題が発生しないように、TNSNAMES.ORA
エントリにドメイン名(PDX.COM
)を追加します(次の例で太字で示しています)。
ORCL1.PDX.COM = (DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE = yes) (ADDRESS = (PROTOCOL = TCP)(HOST = idmdrtest)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl1.pdx.com) ) ) )
TNSNAMES.ORA
ファイルのエントリにドメイン名を追加すると、instantiate topology
操作の実行時に発生する可能性がある次のようなエラー・メッセージを回避できる場合があります。
>>instantiate topology to voidhost1 idmdrtest.pdx.com 10.196.6.80:7892 (home /home/oracleqa/DREDG/immr10142) HA directory exists for instance im1.idmdrtest.pdx.com HA directory exists for instance orcl1 idmdrtest.pdx.com 10.196.6.150:7892 (home /home/oracleqa/DREDG/immr10142) HA directory exists for instance im1.idmdrtest.pdx.com HA directory exists for instance orcl1 idmdrtest.pdx.com 10.196.6.80:7892 Verifying that the topology is symmetrical in both primary and standby configuration idmdrtest.pdx.com 10.196.6.80:7892 (home /home/oracleqa/DREDG/immr10142) This is primary infrastructure host idmdrtest.pdx.com: -->ASG_DUF-4950: An error occurred on host "idmdrtest.pdx.com" with IP "10.196.6.80" and port "7892" idmdrtest.pdx.com: -->ASG_ORACLE-300: ORA-12560: TNS:protocol adapter error idmdrtest.pdx.com: -->ASG_DUF-3700: Failed in SQL*Plus executing SQL statement: connect sys/******@orcl1.pdx.com as sysdba;. idmdrtest.pdx.com: -->ASG_DUF-3502: Failed to connect to database orcl1.pdx.com. idmdrtest.pdx.com: -->ASG_IAS-15753: Error preparing to instantiate the topology on host "idmdrtest.pdx.com" idmdrtest.pdx.com: -->ASG_DUF-3027: Error while executing Instantiating each instance in the topology to standby topology at step - prepare step. >>disconnect
4.3.1項「以前のドキュメントに記載されていないasgctlコマンド: create standby database」
4.3.3項「Windowsではスタンバイ・データベースの作成操作がASG_DGA-12500エラー・メッセージで失敗する」
4.3.5項「10.1.2.0.0 Disaster Recovery設定への10.1.2.1.0パッチセットの適用手順」
4.3.6項「フェイルオーバー操作の結果がORA-01665エラーの場合のノード間におけるトポロジのインスタンス化の実行」
4.3.7項「複数のOracle RACインスタンスが稼働しているためOracleAS Guardでデータベースを停止できない」
asgctlのcreate standby databaseコマンドはドキュメントに記載されていません。このコマンドの詳細は次のとおりです。asgctlのcreate standby databaseコマンドの構文は次のとおりです。
create standby database <database_name> on <remote_host>
<database_name
>は、リモート・ホスト・システム上にスタンバイ・データベースを作成する際に使用される一意のプライマリ・データベース名です。
<remote_host
>は、スタンバイ・データベースが作成されるホスト・システムの名前です。
<remote_host
>に指定されたノードにインストールするには、OracleソフトウェアおよびOracleAS Guardソフトウェアが必要です。
スタンバイ・データベース用に生成されたinit.ora
パラメータ・ファイルは、Oracle RAC非対応のスタンバイ・データベースを想定して構成されます。スタンバイ・データベースがOracle RAC対応の場合、次の初期化パラメータを適切に設定する必要があります。
cluster_database
cluster_database_instances
remote_listener
このコマンドは慎重に使用してください。また、必要な場合のみ使用してください。
ユーザー名とパスワードを正しく入力したにもかかわらずOracleAS Guardサーバーに接続して認証エラーが返された場合、ORACLE_HOME
/dsa
ディレクトリのdsa.conf
ファイルにフラグdsa_realm_override=1
を設定して操作を再試行します。
このDSA構成ファイル・パラメータは、OracleAS Guardリリース情報のreadme.txt
ファイル内のOracleAS Guard構成ファイル・パラメータに関する項には記載されていません。
ターゲットのスタンバイ・データベース環境がクリーンアップされていない場合、Microsoft WindowsでOracleAS Guardがcreate standby databaseコマンドを発行すると、次のエラーが発生します。
ASG_DGA-12500: Standby database instance "db25" already exists on host <hostame>
この問題を修正するには、環境をクリーンアップします。以前に試行したスタンバイの設定がなんらかのシステム上の理由で失敗したか、または既存のスタンバイ・データベースを再構築しようとしたため、ターゲットの環境がクリーンではない可能性があります。
環境をクリーンアップした後、asgctlのcreate standby databaseコマンドを再発行できます。asgctlのcreate standby databaseコマンドの詳細は、4.3.1項「以前のドキュメントに記載されていないasgctlコマンド: create standby database」を参照してください。
コマンド・ウィンドウから環境をクリーンアップする例を次に示します。
oradim -delete -sid db25
OracleAS Guard操作を実行する前に、emagentを停止する必要があります。OracleASサービスを再利用するOracleAS Guardコマンドの場合、この操作が必要です。asgctl run
コマンドをスクリプトで発行して、この操作をOracleAS Guard内部から実行できます。詳細は、『Oracle Application Server高可用性ガイド』の「OracleAS Disaster Recovery」の章を参照してください。
これを行わないと、たとえば「ORA-01093: ALTER DATABASE CLOSEは接続中のセッションがない場合にのみ実行できます」というエラーメッセージが表示されます。
emagentの停止は、switchover
操作の実行のみを目的として記載されています。しかし、これはすべてのOracleAS Guard操作に適用します。ドキュメントは今後のリリースで更新されます。
10.1.2.0.0本番データベース用の既存のDisaster Recovery設定がすでにある場合、次の理論上の手順に従って10.1.2.1.0 Disaster Recoveryパッチセットを適用します。
Disaster Recovery設定をブレークします。asgctl failover
コマンドを実行します。
パッチ10.1.2.1.0を適用します。Disaster Recovery設定を再作成します。asgctl create standby database
コマンドを実行し、続けてasgctl instantiate topology
コマンドを実行します。その他、スタンバイ・データベースの再構築方法の詳細は、Oracle Data Guardのドキュメントを参照してください。
Disaster Recovery設定を再作成します。asgctl create standby database
コマンドを実行し、続けてasgctl instantiate topology
コマンドを実行します。その他、スタンバイ・データベースの再構築方法の詳細は、Oracle Data Guardのドキュメントを参照してください。
asgctl failover
操作後すぐに続けてasgctl instantiate topology
操作を実行しようとすると、「ORA-01665: 制御ファイルがスタンバイ制御ファイルではありません」というエラー・メッセージが返されます。
この問題を回避するには、まずasgctl create standby database
コマンドを実行してリモート・ホストにスタンバイデータベースを作成する必要があります。ドキュメントに以前は記載されていなかったこのasgctlコマンドの詳細は、4.3.1項「以前のドキュメントに記載されていないasgctlコマンド: create standby database」を参照してください。また、4.3.5項「10.1.2.0.0 Disaster Recovery設定への10.1.2.1.0パッチセットの適用手順」も参照してください。
OracleAS GuardをOracle RAC環境で実行している場合、OracleAS Guard操作の実行中に稼働できるOracle RACインスタンスは1つのみです。そのようにしないと、プライマリ・データベースが複数のインスタンスにマウントされるためエラーが発生し、プライマリ・データベースの停止が回避されます。
たとえば、OracleAS Guardのスタンバイ・データベースの作成操作を複数のOracle RACインスタンスが稼働している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.