| Oracle® Database開発ガイド 12c リリース1 (12.1) B71295-06 |
|
 前 |
 次 |
この章では、データベースとデータベース・アプリケーションに高可用性を組み込む方法について説明します。
内容は次のとおりです。
この項の内容は次のとおりです。
この項では、透過的アプリケーション・フェイルオーバー(TAF)の概要とTAFの構成方法、およびTAFコールバックを使用してイベントの発生時にそのイベントをアプリケーションに通知する方法について説明します。
内容は次のとおりです。
透過的アプリケーション・フェイルオーバー(TAF)はOCI、OCCI、Java Database Connectivity (JDBC) OCIのドライバおよびODP.NETのクライアント側機能であり、インスタンスまたはネットワークの障害によりデータベース接続に失敗したときに発生するエンドユーザー・アプリケーションに対する障害を最小限にするために設計されています。TAFは、Oracle Real Application Clusters (Oracle RAC)やOracle Data Guardの物理スタンバイ・データベースなどの様々なシステム構成でも、起動後の単一インスタンス・システムでも実装できます(たとえば、修復を行うとき)。
TAFにより、クライアント・アプリケーションは、事前に構成した2次インスタンスに透過的に再接続し、最初の元のインスタンスで確立したのと新たに同じ接続を自動的に作成します。つまり、接続が失われた状態にかかわらず、接続プロパティは直前の接続のプロパティと同じです。この場合、アクティブ・トランザクションはロールバックされます。また、試行の失敗後にアプリケーションが使用しようとしたすべての文もフェイルオーバーします。
|
参照:
|
TAFは、クライアント側でもサーバー側でも構成でき、クライアント側とサーバー側の両方に構成されている場合には、サーバー側が優先されます。クライアント側でTAFを構成するには、接続記述子のCONNECT_DATAの部分にFAILOVER_MODEパラメータを含めます。サーバー側でTAFを構成するには、DBMS_SERVICE.MODIFY_SERVICEパッケージ・プロシージャを使用してターゲット・サービスを変更します。
詳細な構成情報は、4.1.1.1項のリファレンスを参照してください。
TAFコールバックとは、フェイルオーバーが発生したときに登録され、イベントの発生時にそのイベントをアプリケーションに通知するためにフェイルオーバー時にコールされるコールバックです。ユーザーのセッションを再構築する際に何回かコールされます。
アプリケーションの開発者は、フェイルオーバーが進行中であることをユーザーに通知する必要が生じる場合があります。フェイルオーバーの進行時には、若干の遅延が発生するためです。この機能は、最初のコールバックへのコールによって実行されます。また、フェイルオーバーが成功して接続が再確立した場合には、フェイルオーバーが発生したことをユーザーに通知してから、ALTER SESSIONコマンドをリプレイする必要が生じることがあります。このコマンドは、2つ目のインスタンスで自動的にはリプレイされないためです。2回目のコールバックへのコールにより、その機能が実行されます。また、フェイルオーバーが失敗した場合には、フェイルオーバーが発生しなかったことをアプリケーションに通知します。3回目のコールバックへのコールでも、その機能が実行されます。
TAFコールバックを使用すると、次のことが可能になります。
フェイルオーバー・プロセスを通じて、フェイルオーバーのステータスが進行中、成功、失敗のいずれであるかをユーザーに通知します
必要なときにALTER SESSIONコマンドをリプレイします
新しい接続上でセッションが開始されるたびに、プライマリ・ハンドル以外のユーザー・ハンドルを再認証します。各ユーザー・ハンドルはサーバー側セッションを表すため、クライアントでは、そのセッションのためにALTER SESSIONコマンドを再実行する場合があります。
各インタフェースのコールバックの構造とパラメータなどインタフェースごとの具体的なコールバック登録情報と、フェイルオーバー・コールバックの例については、4.1.1.2項のリファレンスを参照してください。
Oracle Database 12cリリース1 (12.1.0.1)から、Oracle DatabaseではJava用のアプリケーション・コンティニュイティがサポートされます。これは、コミット結果とアクティブ要求のリカバリという概念をサポートする機能です。フェイルオーバーが発生し、データベース・サービスへの接続がリストアされたらすぐに、即時の暗黙的なリカバリとアクティブ要求の再発行を可能にすることによって、高可用性(HA)インフラストラクチャにおけるJDBCベースのアプリケーションで、システム障害からのアプリケーション・エラーを回避できます。詳細は、4.3項「アプリケーション・コンティニュイティとトランザクション・ガード」を参照してください。
この項では、高速アプリケーション通知(FAN)および高速接続フェイルオーバー(FCF)の概要と、高可用性環境でアプリケーションがFANイベントに応答する方法、FCFを使用してフェイルオーバー後に接続を再配置する方法について説明します。
内容は次のとおりです。
高可用性の重要な要素が、高速アプリケーション通知(FAN)と呼ばれる通知のメカニズムです。FANは、UPイベントやDOWNイベントなどのサービス・ステータス変更をはじめとして、構成とサービス・レベルの情報を他のプロセスに通知します。アプリケーションはFANイベントに応答して、すぐにアクションを実行できます。FANのUPイベントおよびDOWNイベントは、インスタンス、サービスおよびノードに適用できます。
FANには、インスタンスまたはサーバーで障害が発生した場合に、アクティブなトランザクションを即座に終了する機能が備えられています。FAN統合されているOracle Clientは、イベントおよび応答を受信します。アプリケーションによる応答は、エラーをユーザーに伝播するか、またはトランザクションを再実行しアプリケーション・ユーザーからエラーをマスクすることによって実行されます。DOWNイベントが発生すると、統合されているFANクライアントでは、終了されたデータベースへの接続が即座にクリーン・アップされます。UPイベントが発生すると、FAN統合クライアントでは新しいプライマリ・データベース・インスタンスへの新しい接続が作成されます。
FANは、一般的なOracleクライアント・ドライバの多くに統合されています。そのため、FANを使用する最も簡単な方法は、Oracle統合クライアントを使用することです。Oracle Connection Manager (CMAN)セッション・プール、OCI、Universal Connection Pool for Java、JDBC simplefan APIおよびODP.NET接続プールを使用できます。この機能は、使用可能なプライマリ・データベースにアプリケーションからいつでも一貫して接続できるようにすることを目的としています。
FANイベントは、Oracle Notification ServiceとOracle Streamsアドバンスト・キューイングを使用して発行されます。発行メカニズムは、Oracle RACのインストール時に自動的に構成されます。ここで、Oracle RACがインストールされているということは、Oracle RACに伴うOracleクラスタウェア、Oracle RAC One Node、Oracle Data Guard (ファストスタート・フェイルオーバー)、またはOracleクラスタウェアに伴うOracle Data Guard単一インスタンスがインストールされていることを意味します。Oracle Database 12cリリース1 (12.1)からは、ONSが新しいクライアント(Oracle Database 12cリリース1 (12.1))と新しいサーバー(Oracle Database 12cリリース1 (12.1))に対する第一の通知メカニズムです。AQ HAの通知機能は非推奨となり、古いクライアント(Oracle Database 12cリリース1 (12.1)より前)または古いサーバー(Oracle Database 12cリリース1 (12.1))が使用されている場合の下位互換性のためにのみ維持されます。
JDBCおよびOracle RAC FAN Application Programming Interface(API)を使用するか、OCIでコールバックを使用すると、アプリケーションはFANをプログラムから使用して、FANイベントをサブスクライブしたり、イベントの受信時にイベント処理アクションを実行できます。
JDBCまたはOracle Database 12cリリース1 (12.1.0.1) OCIまたはODP.Netのクライアントを使用する際には、サーバー上で実行されるOracle Notification Services (ONS)ネットワークを作成する必要があります。Oracle Database 10gまたはOracle Database 11g OCIまたはODP.NETのクライアントを使用する際には、サービスでOracle Advanced Queuing (AQ) HA通知を有効にする必要があります。
|
参照:
|
スタンバイ・データベースが存在する構成では、Oracle Notification Services(ONS)をOracle Restart構成に追加した後でサービスに対してOracle Advanced Queuing (AQ) HA通知を有効にすると、クライアントで高速接続フェイルオーバー(FCF)を有効化できます。クライアントでは、FANイベントを受信し、Oracle Data Guardのフェイルオーバーの後で現在のプライマリ・データベースへの接続を再配置できます。Oracle Database 12cリリース1 (12.1)からは、ONSが新しいクライアント(Oracle Database 12cリリース1 (12.1))と新しいサーバー(Oracle Database 12cリリース1 (12.1))に対する第一の通知メカニズムです。AQ HAの通知機能は非推奨となり、古いクライアント(Oracle Database 12cリリース1 (12.1)より前)または古いサーバー(Oracle Database 12cリリース1 (12.1))が使用されている場合の下位互換性のためにのみ維持されます。
スタンバイ・データベースが構成されていないデータベースでも、クライアントのFANイベントを構成できます。停止状態(計画済または計画外)が発生したとき、データベースへの接続を再試行するようにクライアントを構成できます。障害が発生したデータベースはOracle Restartによって再起動されるため、データベースが再起動した時点でクライアントは再接続できます。
Oracle Data Guard環境、またはスタンバイ・データベースのないスタンドアロン環境で、FCFに対してFAN統合クライアントのサポートを使用するには、FANイベントを有効にする必要があります。
FCFは、Oracle Databaseの接続フェイルオーバー機能を、Java Database Connectivity (JDBC)アプリケーションがドライバに依存せずに利用できる方法を提供します。FCFは、暗黙的な接続キャッシュおよびOracle RACと統合されて、高可用性イベント通知の機能を果します。
OCIクライアントは、Oracle Restart高可用性FANイベントの通知を受信し、イベント発生時に応答するように登録することで、FCFを有効にできます。これにより、OCIのセッション・フェイルオーバーのレスポンス時間が向上し、中断した接続を接続プールおよびセッション・プールから削除できます。この機能は、透過アプリケーション・フェイルオーバー(TAF)、接続プールまたはセッション・プールを使用するものも含めたOCIアプリケーションで動作します。
|
参照:
|
Oracle Database 10gリリース2 (10.2)のHAフレームワークでは、JDBCクライアント、OCIクライアントおよびODP.NETクライアントで高速アプリケーション通知(FAN)メッセージがサポートされます。FANは、ノード、データベース、インスタンス、サービス、およびパブリック・ネットワーク・レベルの停止を迅速にアプリケーションに通知するように設計されています。障害が通知されると、アプリケーションは障害が発生した接続を正常なインスタンスで再確立できます。ただし、Oracle Database 12cリリース1 (12.1.0.1)より前のリリースでは、障害のあったトランザクションの結果を確実に判定する機能と、データベース接続のリストア後にアクティブなトランザクションをリカバリする機能はありませんでした。
Oracle Database 12cリリース1 (12.1.0.1)から、DBAはアプリケーションが使用するデータベース・サービスのサーバー側設定を構成して、Java用のアプリケーション・コンティニュイティとトランザクション・ガードの2つの機能を新しくサポートできるようになりました。Java用のアプリケーション・コンティニュイティがいつ透過的(自動で実行される)になり、どのような場合に透過的にならないか、また透過的でないときインフラストラクチャにどのような変更が必要かについては、26.2.2.1項「アプリケーション・コンティニュイティが透過的になるケース」を参照してください。
|
参照:
|
トランザクション・ガードは、JDBC Type 4 (Oracle Thin)、OCI、OCCIおよびODP.Netドライバに対してサポートされるプロトコルおよび開発用APIです。
トランザクション・ガードでは、最大1回のトランザクション実行のセマンティクスという概念が導入されており、これはトランザクションの冪等性とも呼ばれます。アプリケーションがこのサービスを使用してデータベースへの接続をオープンすると、認証時に論理トランザクションID (LTXID)が生成され、データベースではセッション・ハンドルに格納され、クライアント・ドライバではコピーが格納されます。これはデータベース・トランザクションをアプリケーションの観点から識別する、グローバルに一意なIDです。アプリケーションはトランザクション・ガードAPIを使用して、リカバリ可能なエラーに続く既知の結果を取得します。
停止したとき、トランザクション・ガードを使用しているアプリケーションは以前に失敗したセッションのハンドルからLTXIDを取得し、セッション障害が起こる前にアクティブだったトランザクションの結果をそれによって判定できます。LTXIDがUNCOMMITTEDと判定された場合、アプリケーションはUNCOMMITTEDという結果をユーザーに返して実行が必要なアクションを決定するか、オプションとして、コミットされていないトランザクションをリプレイすることもできます。LTXIDがCOMMITTEDと判定された場合、トランザクションがコミットされ、アプリケーションはその結果をエンドユーザーに返すことができ、新しい接続を取得して続行することも可能です。トランザクション・ガードは、直前のユーザー・コールがCOMMITTEDかどうかのみでなく、必要な非トランザクション状態の変更を完了したかどうかもレポートします。USER_CALL_COMPLETEDを参照してください。トランザクション・ガードの詳細は、第25章を参照してください。
Java用のアプリケーション・コンティニュイティは、データベース・セッションのトランザクション状態および非トランザクション状態の再構築を試行することによって、計画済停止または計画外停止(データベース・セッションが使用できない原因になる)をマスクします。そのため、停止状態になってもユーザーには実行が遅延するようには見えなくなります。
Java用のアプリケーション・コンティニュイティは、Oracle Database 12cリリース1 (12.1.0.1)のサーバーと連携して、データベース・セッションがリプレイ可能かどうかを判定します。
リカバリ可能なエラーが発生し、データベース・セッションが使用不可になると、エラー・メッセージがアプリケーションに返送されます。ドライバはFANメッセージ(ダウンまたは中断)を受信し、デッド・セッションを中止して、再接続と再認証を開始します。新しいセッションをチェックアウトし、デッド・セッションのLTXIDを使用して停止状態のセッションの最終結果を判断します。オプションでコールバックが登録されている場合、JDBCリプレイ・ドライバがこのコールバックを使用して接続を初期化し、初期の非トランザクション・セッション状態(NTSS)をリストアして、リクエストのリプレイを続行します。
アプリケーション・コンティニュイティは、トランザクション・ガードを使用して、エラーを受信したセッションから送信された前回の操作の結果を確認することによってリプレイを準備します。送信がコミットされて完了すると、新しいセッションはこの結果をアプリケーションに返し、SESSION_STATE_CONSISTENCYモードがSTATICの場合には非トランザクション状態を確立して続行し、SESSION_STATE_CONSISTENCYモードがDYNAMICの場合には終了します。DYNAMICセッション状態の一貫性は、ほとんどのアプリケーションに適しています。
最後の送信でリプレイが有効な場合、リプレイ・ドライバは送信のリプレイを準備し、保存された文をリクエストのためにリプレイします。リプレイするとき、権限が付与されている場合には、保持されている可変データがリストアされます。クライアントで目に見える結果が元の送信と等しくなるように、サーバーで検証が実行されます。リプレイが完了すると、アプリケーションはアプリケーション・ロジックを続行してランタイム・モードに戻るため、負荷時に発生するのと類似した実行遅延しか起こらなかったかのように見えます。
場合によっては、リプレイはクライアントが決定に使用したデータをリストアできないことがあります。その場合、リプレイは元のエラーをアプリケーションに返し、遅延エラーのように見えます。
アプリケーション・コンティニュイティは、同じDBID (時間上では先行)を持つデータベースのコピーに対して、あるいはActive Data Guardファーム内で、データベースが使用できないことによる停止をリカバリできます。これは、Oracle RAC One、Oracle Real Application Clusters、Data Guard、またはActive Data Guardです。
Java用のアプリケーション・コンティニュイティがいつ透過的(自動で実行される)になり、どのような場合に透過的にならないか、また透過的でないときインフラストラクチャにどのような変更が必要かについては、26.2.2.1項「アプリケーション・コンティニュイティが透過的になるケース」を参照してください。リプレイについて、緩和する必要がある悪影響の詳細は、26.3項「アプリケーション・コンティニュイティの潜在的な副作用」を参照してください。リプレイの制限事項については、26.4項「アプリケーション・コンティニュイティに関する制限および他の考慮事項」を参照してください。
この項では、サービスおよびロード管理のフレームワークについて説明します。サービスおよびロード管理のフレームワーク環境で、OCIベースのアプリケーションが高速アプリケーション通知(FAN)を使用してノードやデータベース、インスタンス、サービス、パブリック・ネットワーク・レベルの停止に対応する方法についても説明します。停止が通知されると、アプリケーションは障害が発生した接続を、このフレームワークの正常なインスタンスで再確立できます。
内容は次のとおりです。
データベース・クラウドは、サービスおよびロード管理のフレームワークによって統合され、高いパフォーマンスと可用性、そしてリソースの最適な利用が保証される自己完結型のデータベース・システムです。このフレームワークでは、ローカルにも、また地理的に分散した地域のデータ・センターでも同期された複数のレプリカを保持する分散データベース間で、処理のワークロードが効果的に均衡されます。レプリカは、Oracle RAC環境のインスタンスの場合もあれば、Oracle Data GuardやOracle Golden Gate、あるいはレプリケーション・テクノロジに対応する任意の組合せを使用して相互接続された単一のインスタンスの場合もあります。したがって、サービスおよびロード管理のフレームワークでは、動的なロード・バランシング、フェイルオーバー、およびレプリケートされたデータベースで一元化されたサービス管理が可能です。
グローバル・サービスは、なんらかの形のデータベース・レプリケーションによって同期される複数のデータベースによって実現され、サービスに必要なサービス品質を満たすデータベース・サービスです。これによって、サービスに対するクライアント・リクエストは、そのサービスを提供するいずれかのデータベースに転送されるようになります。
データベース・クラウド内のデータベース・プールは、同じ管理ドメインに属して同じグローバル・サービスを提供するすべてのデータベースで構成されます。データベース・クラウドは複数のデータベース・プールにパーティション化されるため、各プールを個別の管理者が管理することによってサービス管理が容易になり、セキュリティのレベルも向上します。
グローバル・サービス・マネージャ(GSM)は、サービス・レベルのロード・バランシング機能と、データベース・クラウドにおける一元的なサービス管理の機能を持つソフトウェア・コンポーネントです。ロード・バランシングは、接続時と実行時に行われます。GSMには他にも、サービスを作成、構成、開始、停止および再配置したり、カーディナリティやリージョンの局所性といったグローバル・サービスのプロパティを維持する機能もあります。リージョンは、データベース・クライアントとサーバーを含むデータ・センターとして知られる論理上の境界です。このときクライアントとサーバーは、そのデータ・センターにアクセスするアプリケーションで求められるレベルまでネットワーク待機時間を小さくできる程度に接近しているとみなされます。
GSMは、個別のホスト上で実行されていても、データベース・インスタンスと同じ場所にあってもかまいません。各リージョンでは、少なくとも1つのGSMインスタンスが実行されている必要があります。高可用性が必要な場合は、1つのリージョンに複数のGSMインスタンスをデプロイすることをお薦めします。1つのGSMインスタンスは、特定のリージョンのみに属しますが、そのリージョンに関連付けられているすべてのデータベース・プールでグローバル・サービスを管理します。
アプリケーション開発者の観点から見ると、クライアント・プログラムはリージョンのグローバル・サービス・マネージャ(GSM)に接続して、グローバル・サービスに対する接続をリクエストします。クライアントはデータベースまたはインスタンスを指定する必要はありません。GSMは、サービスを提供しているデータベース・クラウドのデータベース・プール内で最適なインスタンスに、クライアントのリクエストを転送します。
Oracle Database 12cリリース1 (12.1.0.1)以降、DBAは、Global Data Services (GDS)フレームワークでOracle Net文字列を使用して、データベース・サービスのクライアント側接続文字列を構成できます。
Oracle Database 12cリリース1 (12.1.0.1)で導入された論理トランザクションID (LTXID)は、最初に認証時に生成されてセッション・ハンドルに格納され、アプリケーションの観点からデータベース・トランザクションを識別するために使用されます。論理トランザクションIDはグローバルに一意であり、高可用性(HA)インフラストラクチャの中でトランザクションを識別します。
HAフレームワークを使用すると、クライアント・アプリケーション(JDBC、OCI、ODP.NET)で高速アプリケーション通知(FAN)メッセージがサポートされます。FANは、ノード、データベース、インスタンス、サービス、およびパブリック・ネットワーク・レベルの停止を迅速にアプリケーションに通知するように設計されています。停止が通知されると、アプリケーションは障害が発生した接続を正常なインスタンスで再確立できます。
Oracle Database 12cリリース1 (12.1.0.1)から、DBAはアプリケーションが使用するデータベース・サービスのサーバー側設定を構成して、Java用のアプリケーション・コンティニュイティとトランザクション・ガードをサポートできるようになりました。
|
参照:
|
