この章では、OracleAS Disaster Recoveryソリューションを使用する高可用性トポロジに関連した問題について説明します。この章の内容は次のとおりです。
この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。
5.1.3項「OracleAS Guardリリース10.1.2.1.1はOracle RACデータベースで使用できない」
5.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で、ユーザー指定のデータベース識別子に対応するoratabエントリ(UNIX)またはシステム・レジストリ・サービス(Windows)を検出できない場合、次のASG_SYSTEM-100メッセージが既存のASG_DUF-3554メッセージより優先され、両方のメッセージがコンソールに表示されます。
On Unix systems: 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 On Windows systems: 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
この項では、構成の問題およびその回避方法について説明します。内容は次のとおりです。
5.2.1項「repCaタイプのデータベースであると検出されたMRCAデータベースがasgctlのshutdown topologyコマンドで停止しない」
5.2.4項「本番サイトとスタンバイ・サイトで同じASGポートを使用してclone instance操作の問題を回避する」
5.2.6項「プライマリ・ホストとスタンバイ・ホストでOracleホームの数が異なるとASGクローニングがサポートされない」
5.2.7項「TNSNAMES.ORAファイル内のエントリにドメイン名がないとDisaster Recoveryで問題が生じる」
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項を参照してください。
以前の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
この項では、ドキュメントの訂正箇所および記載もれについて説明します。内容は次のとおりです。
5.3.1項「以前のドキュメントに記載されていないasgctlコマンド: create standby database」
5.3.4項「10.1.2.0.0 Disaster Recovery設定への10.1.2.1.0パッチセットの適用手順」
5.3.5項「フェイルオーバー操作の結果がORA-01665エラーの場合のノード間におけるトポロジのインスタンス化の実行」
5.3.6項「複数の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構成ファイル・パラメータに関する項には記載されていません。
OracleAS Guard操作を実行する前に、emagentを停止する必要があります。OracleASサービスを再利用するOracleAS Guardコマンドの場合、この操作が必要です。asgctlの実行コマンドをスクリプトで発行して、この操作をOracleAS Guard内部から実行できます。詳細は、『Oracle Application Server高可用性ガイド』の「OracleAS Disaster Recovery」の章を参照してください。
これを行わないと、たとえば「ORA-01093: ALTER DATABASE CLOSEは接続中のセッションがない場合にのみ実行できます」というエラーメッセージが表示されます。
emagentの停止は、スイッチオーバー操作の実行のみを目的として記載されています。しかし、これはすべての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のドキュメントを参照してください。
asgctlのフェイルオーバー操作後すぐに続けてasgctlのトポロジのインスタンス化操作を実行しようとすると、「ORA-01665: 制御ファイルがスタンバイ制御ファイルではありません」というエラー・メッセージが返されます。
この問題を回避するには、まずasgctlのcreate standby databaseコマンドを実行してリモート・ホストにスタンバイデータベースを作成する必要があります。ドキュメントに以前は記載されていなかったこのasgctlコマンドの詳細は、5.3.1項「以前のドキュメントに記載されていないasgctlコマンド: create standby database」を参照してください。また、5.3.4項「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.