データベース・クライアントに関する考慮事項

ブローカ管理のフェイルオーバーが発生したときに、ローカル・データベース・サービスに接続しているデータベース・クライアントでは、イベント通知およびデータベース接続フェイルオーバーのサポートを使用できます。

グローバル・サービスのイベント通知とデータベース接続フェイルオーバー・サポートの詳細は、『Oracle Database概要および管理ガイド』を参照してください。

フェイルオーバー後、ブローカは高速アプリケーション通知(FAN)イベントを発行します。FANイベントは次の方法で使用できます。

• アプリケーションでOracle Database JDBC、Oracle Database Oracle Call Interface(OCI)、Oracle Data Provider for .NET(ODP.NET)、Universal Connection Pool for JavaのいずれかのOracle統合データベース・クライアントを使用している場合、プログラムを変更せずにFANを使用できます。これらのクライアントには、フェイルオーバー後に自動的に新規プライマリ・データベースに接続する高速接続フェイルオーバー(FCF)を構成できます。

• JAVAアプリケーションはJDBC FANアプリケーション・プログラミング・インタフェースを利用してFANをプログラムで使用することで、FANイベントにサブスクライブし、イベント受信時にイベント処理アクションを実行できます。

• FANのサーバー側コールアウトをデータベース層で構成できます。

Oracle Database 12c以降のすべてのOracle統合データベース・クライアントでは、FANイベントは、Oracle Notification Service(ONS)を使用して発行されます。以前のリリースの場合、OCIとODP.NETクライアントは、Oracle Advanced Queuing (AQ)を介してFAN通知を受け取ります。

ノート:

ONSを使用してFANイベントを発行するには、単一インスタンスのデータベースをOracle Restartに登録する必要があります。

関連項目:

• Oracle Real Application Clusters(Oracle RAC)データベースでのFAN、FCFおよびONSの構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

Oracle Data Guard固有のFANおよびFCF構成要件

ブローカ管理のフェイルオーバーによって生成されたFANイベントを発行および適切に処理するために満たす必要のある構成要件があります。

これらの要件は、前述のマニュアルおよび次のクライアント固有ガイドに記載されている要件を補足するものです。

• Oracle Database JDBC開発者ガイド

• Oracle Call Interfaceプログラマーズ・ガイド

• Oracle Data Provider for .NET開発者ガイドfor Microsoft Windows

Oracle Netの構成要件

高速接続フェイルオーバー(FCF)を実行するには、クライアントはフェイルオーバー後に新しいプライマリ・データベースを検出できる必要があります。

この項では、この要件に合せてOracle Netの接続記述子を構成する方法について説明します。

接続記述子は次のいずれかの方法で構成できます。

1. 接続時フェイルオーバーの接続記述子を構成します。プライマリ・データベースおよび各スタンバイ・データベースをアドレス・リストに追加します。ネットワーク・アドレスが指定されていない場合に遅延を最小限に抑えるために、CONNECT_TIMEOUTパラメータを小さい値に設定します。リソース競合により通常操作中に接続タイムアウトが発生する場合は、このパラメータの値を大きくします。

   たとえば:

   sales =
   	  (DESCRIPTION= 
   	    (FAILOVER=ON)
   	    (CONNECT_TIMEOUT=5)
   	    (ADDRESS_LIST=
   	      (ADDRESS=(HOST=boston-scan)(PORT=1521))
   	      (ADDRESS=(HOST=dallas-scan)(PORT=1521)))
   	    (CONNECT_DATA=(SERVICE_NAME=sales)))
   

2. DNSやLDAPなどのグローバル・ネーミング・サービスを使用して登録された単一ネットワーク名で、接続記述子を構成します。DB_ROLE_CHANGEシステム・イベントに基づいてトリガーを作成します。このシステム・イベントは、フェイルオーバー後に、ネットワーク名に関連付けられているネットワーク・アドレスを新規プライマリ・データベースのネットワーク・アドレスに変更します。

   関連項目:

   • DB_ROLE_CHANGEシステム・イベントの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。

どちらの場合も、接続記述子にSERVICE_NAMEパラメータを含める必要があります。

データベース・サービスの構成要件

データベース・サービスは、Oracle RACデータベースの特定のデータベース・ロール、およびOracle Restartにより管理される単一インスタンス・データベースでアクティブになるように構成できます。

ブローカはOracle ClusterwareまたはOracle Restartと相互に作用して、適切なデータベース・サービスがアクティブになり、ロール変更後に適切なFANイベントが発行されるようにします。

FANイベントは常にONSを使用して発行されます。ただし、データベースが新規プライマリ・データベースでプライマリ・ロールになっている場合、フェイルオーバーを通知するイベントは、アクティブに構成されているデータベース・サービスに対してのみ発行されます。

任意のデータベース・ロールでアクティブでなければならないサービス(プライマリ、フィジカル・スタンバイ、ロジカル・スタンバイまたはスナップショット・スタンバイ)は、サービスがアクティブでなければならない各データベースで明示的にServer Controlユーティリティ(SRVCTL)によって構成する必要があります。

次のコマンドの例では、サービスPAYROLLがプライマリ・データベースNORTHのPRIMARYでアクティブになるように構成されています。また、スタンバイ・データベースSOUTHのPRIMARYロールでもアクティブになるように構成されているため、ロール・トランジションが発生した場合にはそのデータベースでアクティブになります。これらのサンプル・コマンドで、省略記号(...)は、必要に応じて指定するadd serviceの他のオプションを示します。

ノート:

この項で示した例では、必ずしもご使用の環境で使用する必要のある特定の属性を示しているわけではありません。必要な属性は構成によって異なります(ご使用の環境がOracle RACベースか単一インスタンスかどうかも含めて)。詳細は、適切なOracle RACまたはOracle Restartのマニュアルを参照してください。

プライマリ・データベースNORTH上で、次を実行します。

srvctl add service –db NORTH –service PAYROLL –role PRIMARY ...

-drain_timeout属性を使用してサービスを構成し、スイッチオーバー前にセッションのドレインを待機する時間を設定します。-drain_timeoutに異なる値を使用して様々なサービスが構成されている場合、ブローカは、スイッチオーバーの開始時にアクティブなサービスの構成された最大値の間待機します。

スタンバイ・データベースSOUTH上で、次を実行します。

srvctl add service –db SOUTH –service PAYROLL –role PRIMARY ...

サービスを現在のプライマリ・データベースで起動するかどうかにかかわらず、データベースがフィジカル・スタンバイ・ロールになっているときにアクティブにするサービスも、そのデータベースで作成および起動する必要があります。これは、サービス定義がREDOストリームを介してフィジカル・スタンバイ・データベースに伝播されるようにするためです。これにより、サービスをフィジカル・スタンバイ・データベースで起動できるようになります。サービスをフィジカル・スタンバイで起動できるのは、サービスを起動することによって生成されたREDOが適用された後のみです。サービスがロール変更の前後で同じように動作するように、すべてのデータベース上ですべてのSRVCTL add serviceオプションが同一であることが重要です。

すべてのデータベースが同じ値を持たない場合、SRVCTLは値を上書きしようとしますが、フィジカル・スタンバイ・データベースで失敗します。これは、データベースが読取り専用でオープンであるためです。次のコマンドの例では、サービスsalesがプライマリ・データベースNORTHのPHYSICAL_STANDBYロールでアクティブになるように構成されています。その後、プライマリ・データベースで起動および停止されます。これは、フィジカル・スタンバイ・データベースSOUTHのPHYSICAL_STANDBYロールでもアクティブになるように構成されます。

次をプライマリ・データベースNORTHで実行します。

srvctl add service -db NORTH -service SALES -role PHYSICAL_STANDBY ...

srvctl start service –db NORTH –service SALES

srvctl stop service –db NORTH –service SALES

次をフィジカル・スタンバイ・データベースSOUTHで実行します。

srvctl add service -db SOUTH -service SALES -role PHYSICAL_STANDBY ...

ここでブローカによりスイッチオーバーまたはフェイルオーバーが実行されると、データベースのロールに基づいて、適切なデータベース上でSALESサービスが自動的に開始されます。

前述の各例では、データベースに1つのサービスのみを設定する方法を説明しました。次の例では、データベースに複数のサービスを設定する方法を示し、また、ブローカを使用することによって適切なサービスが適切なデータベース上で確実に開始される仕組みについて説明します。

プライマリ・データベースがBOSTON、スタンバイ・データベースがCHICAGOであると仮定します。次のSRVCTLコマンドを発行して、Data Guard構成内の両方のデータベースが、各データベースで実行する可能性のある2つのサービスについて認識するようにします。

BOSTONの場合

srvctl add service -db BOSTON -service SALESRW  -role PRIMARY -policy AUTOMATIC
srvctl add service -db BOSTON  -service SALESRO  -role PHYSICAL_STANDBY -policy AUTOMATIC

CHICAGOの場合:

srvctl add service -db CHICAGO  -service SALESRW  -role PRIMARY -policy AUTOMATIC
srvctl add service -db CHICAGO  -service SALESRO  -role PHYSICAL_STANDBY -policy AUTOMATIC

まず、正しいノード上でサービスを手動で開始する必要があります。また、SALESROサービスをプライマリ上で開始して停止し、このサービスをスタンバイ上で開始できるようにすることも必要です。次のSRVCTLコマンドを発行します。

BOSTONの場合:

srvctl start service -db BOSTON -service SALESRW
srvctl start service -db BOSTON -service SALESRO
srvctl stop service -db BOSTON -service SALESRO

CHICAGOの場合:

srvctl start service -db CHICAGO -service SALESRO

これで、適切なサービスが適切なデータベース上で実行されています。

ブローカによってスイッチオーバーまたはフェイルオーバーが実行されると、データベースの現在のロールに基づいて、サービスSALESRWまたはSALESROが開始されます。したがって、SALESRWはCHICAGO (現在のプライマリ)上で開始され、SALESROはBOSTON (現在のフィジカル・スタンバイ)上で開始されます。いずれかのデータベースが停止して起動した場合も、同じことが発生します。つまり、起動するデータベースのロールに適したサービスが開始されます。

いずれかのデータベースで次の手動コマンドを発行すると、サービスの作成に使用されるSRVCTLコマンドで指定されたロールに関係なく、SALESROサービスとSALESRWサービスの両方が起動されることに注意してください。現在のデータベース・ロールに指定されたサービスのみを起動するには、srvctl start serviceコマンドに-role修飾子を追加します。

BOSTONの場合:

srvctl start service -db CHICAGO

CHICAGOの場合:

srvctl start service -db BOSTON

SRVCTLコマンドではデータベース・ロールが自動的に考慮されないため、サービスを手動で開始するときは常に、開始するサービスの名前を指定するか、次の例のようにstart serviceコマンドの一部として-role修飾子を含める必要があります。

srvctl start service -db BOSTON -role

ノート:

サービスが自動的に起動するように構成されている場合(-policy AUTOMATIC)、データベース・ロールが変更された後にのみ、自動的に起動します。

ノート:

Oracle Data Guard構成では、スタンバイ・データベースのSRVCTL -startoptionは、スイッチオーバー後には、常にOPENに設定されます。

関連項目:

• Oracle RACデータベースでの、SRVCTLユーティリティを使用するデータベース・サービスの構成の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください

ONSの構成要件

クライアント側のONS構成を使用する場合、クライアント側のONS構成ファイルで、プライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。

クライアントでリモートONSサブスクリプションを使用する場合、クライアントでプライマリ・データベースおよび各スタンバイ・データベースのONSデーモンのホスト名およびポートを指定する必要があります。

アプリケーション・コンティニュイティ

アプリケーション・コンティニュイティは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断せず、迅速な方法でリプレイできるようにするOracle Databaseの機能です。

Oracle Data Guardのフィジカル・スタンバイ・データベースへのスイッチオーバーに対し、アプリケーション・コンティニュイティがサポートされます。また、最大可用性データ保護モードのフィジカル・スタンバイに対するファスト・スタート・フェイルオーバーもサポートされます。プライマリ・データベースおよびスタンバイ・データベースでは、アプリケーション・コンティニュイティを使用するには、Oracle RACまたはOracle Active Data Guardのライセンスが必要です。

関連項目:

• アプリケーション・コンティニュイティの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。