| Oracle Application Server リリース・ノート 10g リリース3（10.1.3.1.0）for AIX 5L Based Systems (64-bit) B40032-04 |
|
 戻る |
 次へ |
| Oracle Application Server リリース・ノート 10g リリース3（10.1.3.1.0）for AIX 5L Based Systems (64-bit) B40032-04 |
|
戻る |
次へ |
この章では、OracleAS High Availabilityソリューションを使用した可用性の高いトポロジに関連した問題について説明します。この章の内容は次のとおりです。
この項では、一般的な問題とその対処方法について説明します。内容は次のとおりです。
第15.1.1項「様々なOracle Application ServerリリースからのOracleASインスタンスに対する互換ASGリリース」
第15.1.3項「リモート・クライアントからインスタンスを追加すると、リモート・インスタンスではなくローカル・インスタンスに追加される」
第15.1.4項「非対称型トポロジでのスイッチオーバー操作には、プライマリ・サイトにあるスタンバイ・ピアを持たないインスタンスのすべてのコンポーネントを停止する必要がある」
第15.1.7項「OracleAS Guardリリース10.1.2.1.1はOracle RACデータベースで使用できない」
第15.1.8項「ユーザー指定のデータベース識別子が見つからない場合、OracleAS Guardから不適切なメッセージが返される」
第15.1.9項「asgctl create standby databaseコマンドを発行する前に、スタンバイ・サイトのデータベース・インスタンスを停止する必要がある」
第15.1.14項「OracleAS Guardによって管理されるデータベースでのOracle BPEL Process Managerデハイドレーション・ストアの配置」
第15.1.15項「OracleAS Guardでテストおよび認証されるApplication Serverコンポーネント」
第15.1.17項「スタンバイにREDOログ・ファイル・ディレクトリが存在しない場合、create standbyコマンドが失敗する」
第15.1.19項「データベースSIDは、プライマリ・サイトおよびスタンバイ・サイトのデータベース・ピアで同一である必要がある」
第15.1.20項「インスタンス化および同期に関する問題を回避するため、データベース初期化パラメータはすべて大文字を使用する」
第15.1.21項「ASG_DUF-3800「OPMN Managerへの接続の試行に失敗しました。」エラーへの対処方法」
第15.1.22項「クローン・インスタンス操作に関する問題を回避するため、本番サイトとスタンバイ・サイトのASGに同一のポートを使用する」
第15.1.24項「プライマリ・ホストとスタンバイ・ホストでOracleホームの数が異なる場合、ASGクローンはサポートされない」
デフォルトでは、特定リリースのOracle Application Serverを使用してOracle Application Serverインスタンスをインストールすると、そのインスタンスのOracleホームに特定リリースのApplication Server Guard（ASG）がインストールされます。外部リソース（Oracleデータベースなど）が置かれ、OracleAS Disaster Recoveryトポロジに含める必要のあるスタンドアロン・ホストにも、ASGをインストールします。
複数リリースのASGが使用可能です。Oracle Application ServerインスタンスのホームにインストールされたASGリリースを、そのインスタンスのインストール時にアップグレードすることが可能な（推奨される）場合もあります。Oracle Application ServerインスタンスのホームにあるASGリリースをアップグレードするには、Oracle Technology Network（OTN）から推奨ASGリリースのASGスタンドアロン・キットをダウンロードし、そのASGスタンドアロン・キットを使用して推奨ASGリリースをホームにインストールします。また、ASGスタンドアロン・キットは、OracleAS Disaster Recoveryトポロジに含める必要のあるスタンドアロン・ホストにASGをインストールする際にも使用します。
表15-1および表15-2を使用して、特定のOracle Application Serverリリース用のApplication Serverインスタンスのホームにインストールした場合に、特定のASGリリースに互換性があるかどうかを判断してください。表の左側の列は、ASGスタンドアロン・インストール・キットを使用できる様々なASGリリースを示します。他の列は、Oracle Application Serverインスタンスを作成できる様々なOracle Application Serverリリースを示します。
N: このASGリリースには、このOracle Application Serverリリースのインスタンスとの互換性がありません。
X: このASGリリースは、このOracle Application Serverリリースのインスタンス用Oracleホームにはインストールできません。
Y-NR: このASGリリースには、このOracle Application Serverリリースのインスタンスとの互換性がありますが、別のASGリリースが望ましいため、このASGリリースをインスタンスのOracleホームにインストールしないことをお薦めします。
Y: このASGリリースには、このOracle Application Serverリリースのインスタンスとの互換性があります。このASGリリースをインスタンスのOracleホームにインストールすることをお薦めします。
表15-1に、Oracle Application Serverリリース10.1.2.0.2〜10.1.3.3のOracle Application Serverインスタンス互換のASGリリースを示します。
表15-1 リリース10.1.2.0.2〜10.1.3.3のOracleASインスタンス互換のASGリリース
| ASGリリース | 10.1.2.0.2のOracleASインスタンス | 10.1.2.1のOracleASインスタンス | 10.1.2.2のOracleASインスタンス | 10.1.3.0のOracleASインスタンス | 10.1.3.1のOracleASインスタンス | 10.1.3.2のOracleASインスタンス | 10.1.3.3のOracleASインスタンス |
|---|---|---|---|---|---|---|---|
|
10.1.2.0.2 |
Y-NR |
X |
X |
N |
N |
N |
N |
|
10.1.2.2 |
Y |
Y |
Y |
N |
N |
N |
N |
|
10.1.2.2.1（ASG専用リリース）脚注1 |
Y |
Y |
Y |
N |
N |
N |
N |
|
10.1.3.0 |
N |
N |
N |
Y-NR |
X |
N |
X |
|
10.1.3.1 |
N |
N |
N |
Y-NR |
Y-NR |
Y-NR |
X |
|
10.1.3.3 |
N |
N |
N |
Y |
Y |
Y |
Y |
脚注1 これはOracleAS 10.1.4.2リリースで提供（デフォルトでインストール）されたASGリリースです。このASGリリースは、OracleAS 10.1.2.xリリース互換です。OracleAS 10.1.2.2.1リリースはありません。
たとえば、Oracle Application Server 10.1.3.1インスタンスがあり、インスタンス・ホームにインストールするASGリリースを確認する必要がある場合は、表15-1を使用して次のことを判断できます。
Oracle Application Server 10.1.3.1インスタンス互換のASG 10.1.2.xリリースはありません。
ASG 10.1.3.0リリースは、Oracle Application Server 10.1.3.1インスタンスのOracleホームにインストールできません。
ASG 10.1.3.1リリースはOracle Application Server 10.1.3.1インスタンス互換ですが、ASG 10.1.3.1リリースをOracle Application Server 10.1.3.1インスタンスのOracleホームにインストールしないことをお薦めします。
ASG 10.1.3.3リリースはOracle Application Server 10.1.3.1インスタンス互換であり、ASG 10.1.3.3リリースをOracle Application Server 10.1.3.1インスタンスのOracleホームにインストールすることをお薦めします。
表15-2に、Oracle Application Serverリリース10.1.4.0〜10.1.4.2のOracle Application Serverインスタンス互換のASGリリースを示します。
表15-2 リリース10.1.4.0〜10.1.4.2のOracleASインスタンス互換のASGリリース
| ASGリリース | 10.1.4.0のOracleASインスタンス脚注1 | 10.1.4.1のOracleASインスタンス脚注2 | 10.1.4.2のOracleASインスタンス脚注3 |
|---|---|---|---|
|
10.1.2.0.2 |
Y-NR |
Y-NR |
X |
|
10.1.2.2 |
Y-NR |
Y-NR |
Y-NR |
|
10.1.2.2.1（ASG専用リリース）)脚注4 |
Y |
Y |
Y |
|
10.1.3.0 |
N |
N |
N |
|
10.1.3.1 |
N |
N |
N |
|
10.1.3.3 |
N |
N |
N |
脚注1 ASG 10.1.2.0.2がデフォルトでインストールされます。
脚注2 ASG 10.1.2.0.2がデフォルトでインストールされます。
脚注3 ASG 10.1.2.2.1がデフォルトでインストールされます。
脚注4 これはOracleAS 10.1.4.2リリースで提供（デフォルトでインストール）されたASGリリースです。このASGリリースは、OracleAS 10.1.2.xリリース互換です。OracleAS 10.1.2.2.1リリースはありません。
後述の表に、OracleAS Disaster Recoveryトポロジで互換性のあるASGリリースの組合せを示します。トポロジとは、OracleAS Disaster Recoveryの本番サイトおよびスタンバイ・サイトを構成する、Oracle Application Serverインスタンス・ホームとスタンドアロン・ホスト・ホームの組合せのコレクションです。各Oracle Application Serverホームには、デフォルトで、またはASGスタンドアロンのインストールにより、特定のASGリリースがインストールされています。OracleAS Disaster Recoveryの操作は分散型のため、トポロジ全体でインストールするように推奨されるASGリリースのコレクションが存在します。EDGデプロイの例では、OracleホームのコレクションをASGリリース10.1.3.3または10.1.2.2.xにアップグレードする必要があります。
表15-3を使用して、OracleAS Disaster Recoveryトポロジで2つのASGリリースに互換性があるかどうかを判別してください。表の左列で第1のASGリリースを見つけてから、表の他の列のいずれかで第2のASGリリースを見つけます。
表15-3の各項目の意味は、次のとおりです。
Y-NR: 第1のASGリリースは第2のASGリリース互換ですが、このASGリリースの組合せはトポロジで使用しないことをお薦めします。
Y: 第1のASGリリースは第2のASGリリース互換です。このASGリリースの組合せをトポロジで使用することをお薦めします。
表15-3に、ASGリリース間の互換性を示します。
表15-3 トポロジにおける互換ASGリリース
| ASGリリース | 10.1.2.0.2 | 10.1.2.2 | 10.1.2.2.1 | 10.1.3.0 | 10.1.3.1 | 10.1.3.3 |
|---|---|---|---|---|---|---|
|
10.1.2.0.2 |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
|
10.1.2.2 |
Y-NR |
Y |
Y |
Y-NR |
Y-NR |
Y |
|
10.1.2.2.1 |
Y-NR |
Y |
Y |
Y-NR |
Y-NR |
Y |
|
10.1.3.0 |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
|
10.1.3.1 |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
|
10.1.3.3 |
Y-NR |
Y |
Y |
Y-NR |
Y-NR |
Y |
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
この問題を回避してトポロジにインスタンスを追加するには、トポロジに配置済のシステムからOracleAS Guardクライアントを使用して、asgctl add instanceコマンドを実行します。
非対称型トポロジで、スタンバイ・ピアを持たないインスタンスに対してasgctlスイッチオーバー操作を実行する場合は、その前に、無視指定されているプライマリ・サイト上のそれらのすべてのインスタンスでopmnctl stopallコマンドを実行して、そのすべてのコンポーネントを停止する必要があります。
非対称型トポロジにXMLポリシー・ファイルが使用されており、次の例に示すような<instanceList successRequirement ="Ignore"がインスタンスに設定されている場合は、スイッチオーバー操作において、そのインスタンスは無視されます。
. . . <instanceList successRequirement = "Ignore"> <instance>instance B</instance> </instanceList> . . .
この例では、スイッチオーバー操作時に、OracleAS Guardによって、元のプライマリ・サイトにあるOracleAS GuardとOPMN以外のすべてのコンポーネントが停止されますが、ポリシー・ファイルの指定に従ってインスタンスBは無視されます。この場合、ポリシー・ファイルによってプライマリ・サイト上のスタンバイ・ピアを持たないインスタンスBの無視が指定されているため、プライマリ・サイトのすべてのコンポーネントが停止されずスイッチオーバー操作は失敗します。
この問題を回避して、この非対称型トポロジでスイッチオーバー操作を成功させるには、OracleAS Disaster Recovery管理者は、スイッチオーバー操作の前にインスタンスBのすべてのコンポーネントに対してopmnctl stopall操作を実行する必要があります。
サーバー・ロード・バランサを使用してHTTPリクエストを複数のOracle HTTP Serverインスタンスに送っている場合、いくつかのアプリケーションへのWebアクセス（Application Server ControlコンソールおよびOracle Web Services Managerなど）が、HTTPサーバーの物理ホストにリダイレクトされることがあります。
リダイレクトされたリクエストが確実にロード・バランサに送信されるようにするには、ロード・バランサ用にOracle HTTP Serverの仮想ホストを構成します。
たとえば、Oracle HTTP Serverがポート7777でリスニングし、bigip.acme.comというロード・バランサがポート80でリスニングしている場合、httpd.confファイルのエントリは次のようになります。
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName bigip.us.oracle.com Port 80 ServerAdmin youyour.address RewriteEngine On RewriteOptions inherit </VirtualHost>
現在、asgctlクローン・トポロジ操作のセマンティクスはOracle Application Serverホーム外のデータベースをクローニングしません。そのため、いくつかのインフラストラクチャ・インストール・タイプによりOracle Application Serverホームにインストールされたデフォルトのデータベースのみがクローニングされます。Oracle Data Guardに慣れていないユーザーは、asgctl create standby databaseコマンドを使用してください。
このリリースで同梱されている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スタンドアロン・インストールとしてOracle OTNからダウンロードできます。詳細は、Oracleサポート・サービスにお問い合せください。
OracleAS Guardのadd instanceコマンドを使用してOracle RACインスタンスをトポロジに追加する際、ユーザー指定の識別子が見つからない場合に、OracleAS Guardから不適切なエラー・メッセージが返されます。ユーザーがOracleインスタンスSIDではなくデータベース名を入力した場合、問題は発生しません。
現在、OracleAS Guardがユーザー指定のデータベース識別子をoratabエントリ（UNIXの場合）またはシステム・レジストリ・サービス（Windowsの場合）で見つけられない場合は、次の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
スタンバイ・サイトのデータベースを起動し実行している場合は、asgctl create standby databaseコマンドを発行する前に停止することをお薦めします。
ASG_DGA-12500: Standby database instance "<instance_name>" already exists on host "<hostname>"
Oracle RAC/Oracle RAC以外の環境で使用される命名規則に問題があります。asgctl create standby databaseコマンドを試行する前に、asgctl内のプライマリ・サイトおよびスタンバイ・サイトの両方に対してasgctl set primary databaseコマンドを発行し、OracleAS Guard内にサービス名のマッピングを定義する必要があります。実行しないと次のエラー・メッセージが返されます。
ASG_DUF-4902: Object not found in clipboard for key "orcl1keySourceDb".
すでに「物理スタンバイ」状態のデータベースからasgctl create standby database操作を実行しようとすると、エラーora-01671が発生します。正しくは、このエラーが返されるのではなく、スタンバイ・データベースがすでに実行中であることを示す適切なエラー・メッセージが表示されます。これは既知の問題です。
ASGクローン・トポロジまたはクローン・インスタンス操作を使用する場合、tarユーティリティを使用します。これらの操作のターゲット・システムでは、スタンドアロンASGインストールが実行されるシステム・ユーザー・アカウントのデフォルトPATHにGNU tarのバージョンを指定する必要があります。
GNU tarは次の場所で入手できます。
Disaster Recovery設定で同一システムに複数のORACLE_HOMEディレクトリがある場合、set primary databaseコマンドが次のエラーで失敗します。
prodnode1: -->ASG_DUF-4950: An error occurred on host "stama03v1" with IP "XXX.XX.XX.XXX" and port "7890" prodnode1: -->ASG_ORACLE-300: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor prodnode1: -->ASG_DUF-3700: Failed in SQL*Plus executing SQL statement: connect sys/******@rac as sysdba;. prodnode1: -->ASG_DUF-3502: Failed to connect to database orcl. prodnode1: -->ASG_DUF-3027: Error while executing at step - Default Step. . The database credentials have been set successfully, but they have not been validated
この問題に対処するには、Disaster Recovery設定の同一インベントリを共有するシステム上のデータベースが1つのみであることを確認します。
OracleAS Disaster RecoveryトポロジでOracle BPEL Process Managerを実行している場合は、次のことを確認してください。
プライマリ・サイトおよびスタンバイ・サイトのデータベースに格納されているOracle BPEL Process Managerデハイドレーション・データが継続的に同期化されること。
スイッチオーバー操作の発生時に、Oracle BPEL Process Managerでスタンバイ・サイトのデータベースが使用されること。
そのためには、次の作業を実行します。
デハイドレーション・データをデータベースに格納します。
ログ・アーカイブを設定し、Oracle Data Guardでのスタンバイ・データベースの保護を最大可用性モード（最大保護モードではなく）に設定します。これによって、スタンバイ・データベースがオフラインになっても、プライマリ・データベースをシャットダウンせずにスタンバイ・サイトでログを継続的に適用できます。
|
注意: Oracle Data Guardを最大保護モードに構成しないでください。定義により、このモードではスタンバイ・データベースがオフラインになった場合にプライマリ・データベースもオフラインになるためです。 デフォルトでは、ASG "create standby database"コマンドを使用すると、スタンバイ・データベースが最大パフォーマンス・モードに構成されます。次のステップ2に示すように、モードを最大可用性に変更する必要があります。 |
データベースをOracleAS Disaster Recoveryトポロジに含めます。Oracle Data Guardの設定にOracle Application Serverを使用しなかった場合でも、このデータベースをOracleAS Guardで監視できます。これによって、データベースと関連サービスがOracle Application Serverサービスと連携してフェイルオーバーされます。
スタンバイ・データベースを作成し、ASG "create standby database"コマンドを使用して最大可用性モードにするには、次の手順を実行します。
スタンバイ・サイトにデータベースを作成し、OracleAS Disaster Recoveryトポロジに含めます。次の2つの方法があります。
スタンバイ・サイトにデータベースを手動でインストールし、プライマリ・サイトでASG "instantiate topology"コマンドを実行します。
ASGCTL> instantiate topology to standbynode1
standbynode1はスタンバイ・ノードの物理名を指します。スタンバイ・ノードには、それに対応するノードがプライマリ・サイト上に存在します。
ASGコマンドおよびOracleAS Disaster Recoveryの詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
または
プライマリ・ノードでASG "create standby database"コマンドを実行して、スタンバイ・ノード上にスタンバイ・データベースを作成します。このコマンドによって、プライマリ・データベースが最大パフォーマンス用に構成され、log_archive_dest_nがスタンバイ・データベースのLGRW SYNC AFFIRMアーカイブ属性によって構成されます。
ASGCTL> create standby database orcl1 on standbynode1
orcl1はデータベース名、standbynode1はスタンバイ・ノードの物理名を指します。
構成を最大可用性モードにアップグレードします。
プライマリ・データベースで、次のSQLコマンドを実行します。
SQL> alter database set standby database to maximize availability;
スタンバイ・データベースで、次のSQLコマンドを実行し、スタンバイ・データベースを管理リカバリ・モードにします。（これによってスタンバイ・データベースがメディア・リカバリの定常状態になります）。
|
注意: 管理リカバリ用のスタンバイ・データベースの構成は、最大可用性の要件ではありませんが、フェイルオーバー時間の短縮をもたらします。 |
SQL> alter database recovery managed standby database
[disconnect from session];
コマンドの実行後にセッションを終了する場合は、オプションの"disconnect from session"部分を追加します。
注意:
上の手順では、Oracle Data Guardでのプライマリ・データベースの保護モードが最大パフォーマンスから最大可用性に変更されます。
Oracle Data Guardの各種保護モード（最大保護、最大可用性および最大パフォーマンス）の詳細は、『Oracle Data Guard概要および管理』ガイドを参照してください。
プライマリ・データベースを最大可用性モードで実行すると、使用可能なオンライン・ログ・ファイルの待機でハングが発生することがあります。最大可用性のプライマリ・データベースでは、オンライン・ログ・ファイルはスタンバイ・データベースにアーカイブされるまで再使用されません。これは、スタンバイ・データベースが長時間オフラインになった場合に発生することがあります。
同期の要件が同じであるデータのみを同一のデータベースに格納する必要があります。
たとえば、Oracle BPEL Process ManagerとOracleAS Portalでは同期化の目的が異なるため、Oracle BPEL Process Managerデハイドレーション・ストアとOracleAS Portalデータは別々のデータベースに格納する必要があります。Oracle BPEL Process Managerデハイドレーション・ストアの同期化の目的は、デハイドレーション・ストアとBPELプロセスとの一貫性を維持することですが、OracleAS Portalの同期化の目的は、中間層内とデータベース内で保守されているデータおよび構成の相違をなくすことです。
"sync topology"コマンドによって実行される処理
この構成でASG "sync topology"コマンドを実行すると、次の処理が実行されます。
プライマリでログ・スイッチが実行され、ログが確実に送出されてアーカイブされます。
プライマリおよびスタンバイ・サイトでプロセス管理が実行されます。
Oracleホーム内のすべてのデータの増分変更がカプセル化されます。
スタンバイ・ピアがプライマリの構成レベルにリストアされます。
変更内容がすべてのスタンバイ・インスタンスに伝播されます。
スタンバイ・データベースの場合:
管理リカバリが実行されている場合、"sync topology"コマンドでは単に同期SCNおよびスタンバイ・データベースの現在のデータベースSCNがレポートされます。この構成では、スタンバイ・データベースSCNが同期SCNより大きいことが保証されます。ASGによって、スタンバイ・データベースの現在のSCNレベルに対応する同期SCNレベルがログに記録されます。
管理リカバリが実行されていない場合、"sync topology"コマンドでスタンバイ・データベースが同期SCNにリカバリされます。これは、次のコマンドを実行した場合と同等です。
alter database recover managed standby database until change <sync-scn>
OracleAS GuardはOracle Application Server 10g SOAリリースのほとんどのコンポーネントでテストおよび認証されています（ASGで検証されていないコンポーネントはBAMとRegistryのみです）。
OracleAS GuardでのBPEL PMおよびESBの構成に関する具体的な推奨事項は、『OracleAS Guardのリリース・ノート』を参照してください。
asgctl create standby databaseコマンドが、ASG_DUF-4950エラーおよびコンソールでの次のようなエラー・メッセージの表示により失敗する場合があります。
ASG_DUF-4950: An error occurred on host "myhost" with IP "1.1.1.1" and port "7890" ASG_SYSTEM-100: 10 ASG_DUF-4900: An exception occurred on the server. ASG_DGA-13009: Error during Create Physical Standby
プライマリ・サイトのDBノード上のduf_client.logファイルに、次のようなメッセージが表示されます。
java.lang.ArrayIndexOutOfBoundsException: 10 at oracle.duf.DufJdbc.queryRedoLogInfo(DufJdbc.java:535) at oracle.duf.DufDb$jdbc.queryRedoLogInfo(DufDb.java:4966) at oracle.duf.DufDb$jdbc.access$2000(DufDb.java:4884) at oracle.duf.DufDb.queryRedoLogInfo(DufDb.java:3439)
この問題は、10以上のREDOログ・ファイルにより構成されているデータベースをASGが適切に処理できないことが原因で発生します。
この問題を回避するには、REDOログ・ファイルの数を10未満に減らします。
この問題は、10.1.3.3のリリースで修正されています。
本番サイト上のREDOログ・ファイル・ディレクトリがスタンバイに存在しない場合、asgctl create standby databaseコマンドは失敗します。ASGでは、ターゲットのREDOログ・ディレクトリ構造が本番サイト上のREDOログ・ディレクトリ構造と対称であることが必要です。これらが同じディレクトリに存在しない場合、次の出力により失敗します。
ASG_ORACLE-300: ORA-00301: error in adding log file '/PATH/redo010.log' - file cannot be created ASG_ORACLE-300: ORA-27040: file create error, unable to create file ASG_DUF-3700: Failed in SQL*Plus executing SQL statement: ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 '/PATH/redo010.log' SIZE 52428800 /* ASG_DGA */;. ASG_DUF-3535: Failed to create standby redo log. ASG_DUF-3535: Failed to create standby redo log. ASG_DGA-13011: Error during Create Physical Standby: Finish-configure standby. ASG_DUF-3027: Error while executing Creating physical standby database - finish phase at step - finish step.
この問題を回避するには、スタンバイ・サイト上のターゲットのREDOログ・ファイル・ディレクトリを、本番サイトと同じディレクトリに作成します。
ASGスイッチオーバーまたはフェイルオーバー操作後に、Disaster Recoveryのメタデータ・リポジトリ・データベース内にメタデータ索引ブロックの破損が発生する場合があります。
この問題の詳細およびその対処方法は、次に示すOracleMetaLinkノート386830.1を参照してください。
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=386830
SIDは、Disaster Recoveryトポロジ内のプライマリ・サイトおよびスタンバイ・サイトのデータベース・ピアで同一である必要があります。
データベース初期化パラメータはすべて大文字を使用します。
次の例では、データベース初期化パラメータである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.
10.1.2.2 ASGスタンドアロン・キットを使用して10.1.4.x Oracleホームを更新すると、ASGは、optic.jarのコピーをOracleホームのoptic.jarとは互換性がないコンポーネント・パスにインストールします。これは、ランタイム・システムの操作には影響を及ぼしませんが、特定の構成におけるその後のASG操作で問題を発生させる可能性があります。
この潜在的な問題を回避する方法は、次のとおりです。
トポロジのすべてのノード上で、$ORACLE_HOME/dsa/jlibディレクトリ内のoptic.jarの名前をoptic.jar.origに変更します。
ASGコンポーネントが起動している場合は、再起動します。
Disaster Recovery構成にOracle Application Serverリリース10.1.4.0.1 Identity Managementおよび10.1.2.2 ASGスタンドアロン・キットが含まれていて、前述の対処方法を実行しない場合、switchover topology操作時に、ASG_DUF-3800エラーの「OPMN Managerへの接続の試行に失敗しました。」エラー・メッセージが表示される場合があります。
表示されるエラーは、次のようなものです。
"4-May 12:51:20 stamx12 152.68.64.214:7890(home/opt/maa/oracle/product/10.1.4/im) 4-May 12:51:20 Running opmnctl reload command: "/opt/maa/oracle/product/10.1.4/im/opmn/bin/opmnctl reload". 4-May 12:51:25 stamx11: -->ASG_DUF-4950: An error occurred on host "stamx11" with IP "140.87.21.201" and port "7890" stamx11: -->ASG_DUF-4950: An error occurred on host "stamx11" with IP "152.68.64.213" and port "7890" stamx11: -->ASG_DUF-3800: Failed trying to connect to the OPMN Manager. stamx11: -->ASG_DUF-3027: Error while executing Starting each instance in the topology at step - starting instance step. stamx11: -->ASG_DUF-3027: Error while executing Switchover each instance in the topology to standby topology at step - starting and resyncing instance step."
clone instance操作時に次のようなエラー・メッセージを回避するには、プライマリ・サイトとスタンバイ・サイトのASGに同一のポートを使用します。
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構成情報が含まれており、これはApplication Serverインスタンスのバックアップ/リストアIP構成内に構成されます。dsa.confファイル構成は、Application Serverインスタンス間で対称的に処理されます。このため、本番サイトのインスタンスにあったdsa.confファイルは、対応するスタンバイ・サイトのインスタンスに対して同期化されます。
ASGに関して、本番およびスタンバイのインスタンスのペア間のポート番号は一致している必要があります。
ベスト・プラクティスとして、add instanceコマンドとともに完全修飾パス名を使用します。
プライマリ・ホストとスタンバイ・ホストでOracleホームの数が異なる場合、ASG clone topologyコマンドおよびclone instanceコマンドは、DR構成によりサポートされません。
クローン操作の一部として、各ホストのOracle Inventoryがクローンされます。したがって、Oracleホーム構成は、クローンされるすべてのホストで対称的であると想定されます。
サポートされているDisaster Recovery非対称型トポロジの詳細は、『Oracle Application Server高可用性ガイド』第5章の関連する項を参照してください。
ESBリポジトリ・サーバーとESBランタイム・サーバーが異なるOracleホームにある分散ESB環境では、ESBランタイム・インスタンスを起動する前にESBリポジトリを起動する必要があります。
Oracle Enterprise Service Bus（ESB）サービス・エンドポイントのURLは、次のようになります。
http://esb-runtime-server:7777/event/ESBSystemName/ESB_ServiceName
/eventは、コンテキスト・ルートのESBランタイム・エンジン・サーバー（J2EEアプリケーション）です。ESBサーバーの後に1つ以上のESBシステムを配置でき、各システムに1つ以上のESBサービスを含めることができます。さらに、あるOC4Jコンテナの単一ESBサーバーを、ESBSystem1およびESBSystem2を格納するように構成し、別のOC4Jコンテナの別のESBサーバーを、ESBSystem3およびESBSystem4を格納するように構成できます。
これらのESBサーバーが同じOPMNクラスタ上の同じHTTPサーバーの後にあると、問題が発生します。http://virtualurl:80/event/ESBSystem1/ESBServer1のコールが、Oracle HTTP Serverにより、指定のESBシステムに関連付けられていないESBサーバーにルーティングされ、エラーが発生する場合があります。
対処方法
この問題には、静的ルーティングを使用することで対処できます。Oracle HTTP Serverのmod_oc4j.confファイルを編集し、サービスを提供する特定の各OC4Jを指す静的マウント・ポイントを追加します。たとえば、OC4Jインスタンス1および3がサービス1を提供し、OC4Jインスタンス2がサービス2を提供する場合、マウント・ディレクティブは次のようになります。
Oc4jMount /event/ESBSystemName/ESB_Service1/* instance://ias_instance_1:home Oc4jMount /event/ESBSystemName/ESB_Service1/* instance://ias_instance_3:home Oc4jMount /event/ESBSystemName/ESB_Service2/* instance://ias_instance_2:home
|
注意: マウント・ポイント構成の詳細は、『Oracle HTTP Server管理者ガイド』の第7章「モジュールの概要」の Oc4jMountディレクティブに関する項を参照してください。 |
この項では、構成に関する問題とその対処方法について説明します。内容は次のとおりです。
第15.2.1項「asgctl shutdown topologyコマンドではrepCa型データベースであると検出されたMRCAデータベースが停止しない」
第15.2.2項「新規プライマリ・サイトのOracle RACノード・インスタンスのうち1つのみがasgctl switchover操作後に起動される」
第15.2.3項「リモート・クライアントからのasgctl add instance操作では、対象のリモート・システムではなくローカル・システムにインスタンスが追加される」
第15.2.6項「10.1.2.0.0 Disaster Recovery設定を10.1.2.1.0パッチセットでパッチする手順」
第15.2.7項「フェイルオーバー操作実行後にトポロジ・アクセス・ノードのインスタンス化を実行すると、ORA-01665エラーが発生する」
第15.2.8項「Oracle RACの2つ以上のインスタンスが実行中であるとOracleAS Guardはデータベースを停止できない」
第15.2.12項「データベースでOMFストレージまたはASMストレージが使用されている場合に、スタンバイ・データベースの作成に失敗する」
asgctl shutdown topologyコマンドは、データベース以外のインスタンスのみを処理します。そのため、repCA環境でOracleAS Guardがインスタンスを検出し、repCa型データベースであると判断すると、そのインスタンスはshutdown topology操作で無視されます。repCA型データベースはOracleAS Guard外で管理されるとみなされます。
したがって、MRCAデータベースがトポロジに追加された環境内では、データベースはasgctl shutdown topologyコマンドで処理されません。
Oracle RACデータベースが含まれるDisaster Recovery環境では、スイッチバック操作（switchover topology to <primary site>）の後、OracleAS Guardによって1つのOracle RACノード上でのみデータベースが起動されます。プライマリ・サイトの残りのOracle RACインスタンスについては手動で起動する必要があります。
リモート・クライアントからasgctl add instance操作を実行した後、インスタンスが対象のリモート・システムではなくローカル・システムに追加されていることに注意してください。
この問題に対処するには、Disaster Recoveryの管理者がまずasgctl add instance操作を実行する前にローカル・クライアント・システムでasgctl discover topology操作を実行し、リモート・システムにインスタンスを追加する必要があります。
ユーザーがOracleAS Guardサーバーに接続し、正しいユーザー名およびパスワードが入力されていても認証エラーが表示される場合は、<ORACLE_HOME>/dsaディレクトリのdsa.confファイルにフラグdsa_realm_override=1を追加し、操作を再試行する必要があります。
このDSA構成ファイル・パラメータは、OracleAS Guardリリース情報のreadme.txtファイルのOracleAS Guard構成ファイル・パラメータに関する項で記述されていないことに注意してください。
OracleAS Guard操作を実行する前に、EMエージェントを停止する必要があります。この操作は、OracleASサービスを再利用するOracleAS Guardコマンドに必要です。スクリプトでasgctl runコマンドを発行し、OracleAS Guard内からこの操作を実行できます。詳細は、『Oracle Application Server高可用性ガイド』のOracleAS Disaster Recoveryに関する章を参照してください。
それ以外の場合、「ORA-01093: ALTER DATABASE CLOSEは接続中のセッションがない場合にのみ実行できます」などのエラー・メッセージが表示される可能性があります。
EMエージェントの停止は、スイッチオーバー操作の実行についてのみ説明されています。しかし、この操作はすべてのOracleAS Guard操作に適用されます。ドキュメントは今後のリリースで更新される予定です。
すでに既存のDisaster Recovery設定が10.1.2.0.0本番データベースにある場合、これらの概念手順に従い、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 failover操作のすぐ後にasgctl instantiate topology操作を実行すると、「ORA-01665: 制御ファイルがスタンバイ制御ファイルではありません」エラー・メッセージが返されます。
この問題に対処するには、最初にasgctl create standby databaseコマンドを実行し、スタンバイ・データベースをリモート・ホスト上に作成する必要があります。これまでドキュメントに記載されていないこのasgctlコマンドの詳細は、第15.3.1項「これまでドキュメントに記載されていないasgctlコマンドの可用性: create standby database」を参照してください。また、詳細は、第15.2.6項「10.1.2.0.0 Disaster Recovery設定を10.1.2.1.0パッチセットでパッチする手順」も参照してください。
Oracle RAC環境でOracleAS Guardを実行している場合は、OracleAS Guard操作の実行中に実行しているOracle RACインスタンスが1つのみである必要があります。そうでない場合は、プライマリ・データベースが2つ以上のインスタンスにマウントされているというエラーが発生し、停止できません。
たとえば、2つ以上のOracle RACインスタンスが実行されているOracle RAC環境でOracleAS Guardのcreate standby database操作を実行すると、次のエラーが表示されます。
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.
Database Configuration Assistant（DBCA）を使用して新しいデータベース・インスタンスを作成すると、SIDにはデータベース名がデフォルトで設定されます。SIDフィールドにデータベース名以外の名前を入力し、このデータベースをDisaster Recoveryトポロジに後で追加すると、トポロジ内の追加されたインスタンス名は空になります。
この問題を回避するには、プライマリ・サイトまたはスタンバイ・サイトに設定されたDisaster Recoveryにデータベースを作成するときに、DBName（ドメインなし）とDBSIDが同じであることを確認します。
データベースが常駐しているソース・プライマリ・ノード以外のノードから、ASGクライアントによってcreate standby databaseコマンドが開始された場合、このコマンドは失敗します。この問題を回避するには、プライマリ・サイトのデータベースが常駐している同じプライマリ（ソース）ノードからcreate standbyコマンドを実行します。
たとえば、本番データベースからスタンバイ・データベースにcreate standbyコマンドを実行するとします。ここで、prodnode1がプライマリ・サイト・データベースのノード名で、standbynode1がそのスタンバイ・データベースのノード名であるとします。ASGCTL shellは常にprodnode1で起動および接続される必要があります。standbynode1からASGCTL shellを実行し、prodnode1に接続した場合、create standbyコマンドは失敗します。
新規プライマリ・データベースがそのリモート・データベース・インスタンスへの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';
データベース・ストレージ・オプションで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を再度実行し、既存のデータベースを正常に上書きします。
asgctl create standby databaseコマンドは、単一のスタンバイ・データベースの作成を自動化するよう設計されています。これは、OMF（Oracle Managed Files）やASM（Automatic Storage Management）ストレージ・オプションなどの一部のデータベース・オプションをサポートしていません。create standby databaseコマンドを使用してスタンバイ・サイトでデータベースを作成する場合は、OMFまたはASMストレージ・オプションを指定せず、DBCA（Database Configuration Assistant）を使用してプライマリ・サイトで新規のデータベース・インスタンスを作成します。
OMFまたはASMストレージ・オプションを使用して新規データベース・インスタンスを作成する場合は、次の場所にある『Oracle Data Guard概要および管理』のOMFまたはASMを使用するスタンバイ・データベースの作成の項を参照してください。
http://www.oracle.com/technology/documentation/index.html
OMFまたはASMストレージ・オプションを使用してデータベースを作成した後は、これをフェイルオーバーやインスタンス化トポロジ操作などのDisaster Recovery操作に含めることができるよう、asgctl add instanceコマンドを使用してインスタンスをDisaster Recoveryトポロジに追加します。asgctl add instanceコマンドの使用の詳細は、リリース10.1.3.2の『Oracle Application Server高可用性ガイド』、Oracle RACデータベースをトポロジに追加する際にOracleAS Guardのadd instanceコマンドに失敗するに関する項を参照してください。
この項では、ドキュメントの記載内容の誤りおよび省略事項について説明します。内容は次のとおりです。
第15.3.1項「これまでドキュメントに記載されていないasgctlコマンドの可用性: create standby database」
第15.3.2項「「Oracle BPEL Process Managerのクラスタ化」は『Oracle BPEL Process Managerインストレーション・ガイド』を参照」
asgctl create standby databaseコマンドはドキュメントに記載されていません。次の情報では、このコマンドを詳細に説明しています。
asgctl create standby databaseコマンドの構文は次のとおりです。
create standby database <database_name> on <remote_host>
<database_name>は、リモート・ホスト・システムでスタンバイ・データベースを作成するために使用されるプライマリ・データベースの一意名です。
<remote_host>は、スタンバイ・データベースが作成されるホスト・システムの名前です。
OracleソフトウェアおよびOracleAS Guardソフトウェアは、<remote_host>として指定されたノードにインストールする必要があります。スタンバイ・データベースに対して生成されるinit.oraパラメータ・ファイルは、非Oracle RAC対応スタンバイ・データベースを想定して構成されます。スタンバイ・データベースをOracle RAC対応にする場合、次の初期化パラメータを適切に定義する必要があります。
cluster_database
cluster_database_instances
remote_listener
ユーザーは、このコマンドを必要な場合のみ慎重に使用する必要があります。
『Oracle Application Server高可用性ガイド』の第5.2.2項「アクティブ/アクティブ・トポロジのOracle BPEL Process Manager」には、『Oracle BPEL Process Manager管理者ガイド』の「Oracle BPEL Process Managerのクラスタ化」の章への参照が含まれています。この章は、実際には『Oracle BPEL Process Managerインストレーション・ガイド』にあります。
リリース10.1.3.2の『Oracle Application Server高可用性ガイド』の第5.12.1.1項「スケジューリングした停止」には、サブセクション「サイト・スイッチオーバー操作」があります。
「サイト・スイッチオーバー操作」サブセクションの番号付きリストの手順5に、RACデプロイに関する次の2つのリスト要素を、リスト要素cおよびdとして付け加える必要があります。
Oracle RAC Disaster Recoveryデプロイの場合、スイッチオーバー前に、すべてのRACインスタンスをシャットダウンして単一のRACノードを起動します。
データベース・ノード上でORACLE_HOME、ORACLE_SID、およびPATH変数を設定した後、データベース・ノードを起動します。
DBHOME/bin/sqlplus /as sysdba SQL> startup
『Oracle Application Server高可用性ガイド』の第5.2.2項「アクティブ/アクティブ・トポロジのOracle BPEL Process Manager」には、必須のJGroupとOC4Jグループの構成に関する推奨事項が記載されていません。JGroupとOC4Jグループの構成の詳細は、『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』を参照してください。
