ヘッダーをスキップ
Oracle Application Serverリリース・ノート
10g(10.1.4.0.1) for AIX 5L Based Systems(64-bit)
B31750-05
  目次
目次

戻る
戻る
 
次へ
次へ
 

4 高可用性

この章では、OracleAS Disaster Recoveryソリューションを使用する高可用性トポロジに関連した問題について説明します。この章の内容は次のとおりです。

4.1 一般的な問題および回避方法

この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。

4.1.1 OracleAS Guardリリース10.1.2.2.1へのアップグレード

OracleAS Guardキット10.1.2.2.1スタンドアロン・インストール・キットを使用して、OracleAS Guardのリリース10.1.2.2.1へのアップグレードをお薦めします。インストール・キットは、次のURLにあるOracle Technology Networkで入手できます。

http://www.oracle.com/technology/index.html

4.1.2 インスタンスのクローニング操作またはトポロジのクローニング操作の実行に関する問題

現在、asgctlのトポロジのクローニング操作のセマンティックでは、OracleASホームの外部にあるデータベースをクローニングしません。そのため、いくつかのインフラストラクチャ・インストール・タイプを使用してOracleASホームにインストールされたデフォルトのデータベースのみクローニングされます。asgctlのcreate standby databaseコマンドは、Oracle Data Guardに精通していないユーザーが使用します。

4.1.3 OracleAS Guardリリース10.1.2.1.1はOracle RACデータベースで使用できない

このリリースに同梱されている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サポートに問い合せてください。

4.1.4 OracleAS Guardでユーザー指定のデータベース識別子を検索できない場合、不適切なエラー・メッセージが表示される

OracleAS Guardでユーザー指定の識別子を検索できない場合、不適切なエラー・メッセージが返されます。OracleインスタンスSIDではなくデータベース名を入力した場合、これが問題であるとは指摘されません。

OracleAS Guardで、ユーザー指定のデータベース識別子に対応するoratabエントリを検出できない場合、次のASG_SYSTEM-100メッセージが既存のASG_DUF-3554メッセージより優先され、両方のメッセージがコンソールに表示されます。

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

4.2 構成の問題および回避方法

この項では、構成の問題およびその回避方法について説明します。内容は次のとおりです。

4.2.1 repCaタイプのデータベースであると検出されたMRCAデータベースがasgctlのshutdown topologyコマンドで停止しない

asgctlのshutdown topologyコマンドはデータベース以外のインスタンスのみを処理します。そのため、repCA環境でOracleAS Guardがインスタンスを検出し、repCaタイプのデータベースであると判定した場合、このインスタンスはトポロジの停止操作で無視されます。repCAタイプのデータベースはOracleAS Guardの外部で管理されているとみなされます。

4.2.2 プライマリ・サイトとスタンバイ・サイトでデータベース・ピアに同じデータベースSIDが必要

Disaster Recoveryトポロジでは、プライマリ・サイトとスタンバイ・サイトでデータベース・ピアのSIDが同じである必要があります。

4.2.3 データベースの初期化パラメータをすべて大文字で表記してインスタンス化および同期化の問題を回避する

データベースの初期化パラメータは、すべて大文字で表記します。

次の例では、アーカイブ・ログの保存先パラメータに使用される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.

4.2.4 本番サイトとスタンバイ・サイトで同じASGポートを使用してclone instance操作の問題を回避する

プライマリ・サイトとスタンバイ・サイトで同じ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のポート番号が一致する必要があります。

4.2.5 add instanceコマンドでの完全修飾パス名の使用

ベスト・プラクティスとして、完全修飾パス名とともにadd instanceコマンドを使用します。

4.2.6 プライマリ・ホストとスタンバイ・ホストでOracleホームの数が異なるとASGクローニングがサポートされない

Oracleホームの数がプライマリ・ホストとスタンバイ・ホストで異なる場合、DR構成ではASGのclone topologyおよびclone instanceコマンドがサポートされません。

クローニング操作の一部として、各ホストのOracleインベントリがクローニングされます。したがって、クローニングされるホストのOracleホーム構成は対称的であることが前提となっています。サポートされるDisaster Recoveryの非対称トポロジの詳細は、リリース10.1.3.2.0の『Oracle Application Server高可用性ガイド』の5.1.3.2項を参照してください。

4.2.7 TNSNAMES.ORAファイル内のエントリにドメイン名がないとDisaster Recoveryで問題が生じる

以前の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 ドキュメントの訂正箇所および記載もれ

4.3.1 以前のドキュメントに記載されていないasgctlコマンド: create standby database

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

このコマンドは慎重に使用してください。また、必要な場合のみ使用してください。

4.3.2 OracleAS Guardサーバーに接続すると認証エラーが返される

ユーザー名とパスワードを正しく入力したにもかかわらずOracleAS Guardサーバーに接続して認証エラーが返された場合、ORACLE_HOME/dsaディレクトリのdsa.confファイルにフラグdsa_realm_override=1を設定して操作を再試行します。

このDSA構成ファイル・パラメータは、OracleAS Guardリリース情報のreadme.txtファイル内のOracleAS Guard構成ファイル・パラメータに関する項には記載されていません。

4.3.3 OracleAS Guard操作を実行する前にすべてのemagentを停止する必要がある

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操作に適用します。ドキュメントは今後のリリースで更新されます。

4.3.4 10.1.2.0.0 Disaster Recovery設定への10.1.2.1.0パッチセットの適用手順

10.1.2.0.0本番データベース用の既存のDisaster Recovery設定がすでにある場合、次の理論上の手順に従って10.1.2.1.0 Disaster Recoveryパッチセットを適用します。

  1. Disaster Recovery設定をブレークします。asgctl failoverコマンドを実行します。

  2. パッチ10.1.2.1.0を適用します。Disaster Recovery設定を再作成します。asgctl create standby databaseコマンドを実行し、続けてasgctl instantiate topologyコマンドを実行します。その他、スタンバイ・データベースの再構築方法の詳細は、Oracle Data Guardのドキュメントを参照してください。

  3. Disaster Recovery設定を再作成します。asgctl create standby databaseコマンドを実行し、続けてasgctl instantiate topologyコマンドを実行します。その他、スタンバイ・データベースの再構築方法の詳細は、Oracle Data Guardのドキュメントを参照してください。

4.3.5 フェイルオーバー操作の結果がORA-01665エラーの場合のノード間におけるトポロジのインスタンス化の実行

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

この問題を回避するには、まずasgctl create standby databaseコマンドを実行してリモート・ホストにスタンバイデータベースを作成する必要があります。ドキュメントに以前は記載されていなかったこのasgctlコマンドの詳細は、4.3.1項「以前のドキュメントに記載されていないasgctlコマンド: create standby database」を参照してください。また、4.3.4項「10.1.2.0.0 Disaster Recovery設定への10.1.2.1.0パッチセットの適用手順」も参照してください。

4.3.6 複数のOracle RACインスタンスが稼働しているためOracleAS Guardでデータベースを停止できない

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.