高可用性

6.1 透過的アプリケーション・フェイルオーバー(TAF)

この項では、透過的アプリケーション・フェイルオーバー(TAF)の概要とTAFの構成方法、およびTAFコールバックを使用してイベントの発生時にそのイベントをアプリケーションに通知する方法について説明します。

トピック:

6.1.1 透過的アプリケーション・フェイルオーバーの理解

透過的アプリケーション・フェイルオーバー(TAF)はOCI、OCCI、Java Database Connectivity (JDBC) OCIのドライバおよびODP.NETのクライアント側機能であり、インスタンスまたはネットワークの障害によりデータベース接続に失敗したときに発生するエンドユーザー・アプリケーションに対する障害を最小限にするために設計されています。TAFは、Oracle Real Application Clusters (Oracle RAC)やOracle Data Guardの物理スタンバイ・データベースなどの様々なシステム構成でも、起動後の単一インスタンス・システムでも実装できます(たとえば、修復を行うとき)。

TAFにより、クライアント・アプリケーションは、事前に構成した2次インスタンスに透過的に再接続し、最初の元のインスタンスで確立したのと新たに同じ接続を自動的に作成します。つまり、接続が失われた状態にかかわらず、接続プロパティは直前の接続のプロパティと同じです。この場合、アクティブ・トランザクションはロールバックされます。また、試行の失敗後にアプリケーションが使用しようとしたすべての文もフェイルオーバーします。

関連項目:

OCI TAFの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください
OCCI TAFの詳細は、『Oracle C++ Call Interfaceプログラマーズ・ガイド』を参照してください
JDBC TAFの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください
ODP .NET TAFの詳細は、『Oracle Data Provider for .NET開発者ガイドfor Microsoft Windows』を参照してください
TAF (接続データ・セクション1)のクライアント側における構成の詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
TAF(DBMS_SERVICE)のサーバー側における構成の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください

6.1.2 透過的アプリケーション・フェイルオーバーの構成

TAFは、クライアント側でもサーバー側でも構成でき、クライアント側とサーバー側の両方に構成されている場合には、サーバー側が優先されます。クライアント側でTAFを構成するには、接続記述子のCONNECT_DATAの部分にFAILOVER_MODEパラメータを含めます。サーバー側でTAFを構成するには、DBMS_SERVICE.MODIFY_SERVICEパッケージ・プロシージャを使用してターゲット・サービスを変更します。

関連項目:

構成の詳細は、「透過的アプリケーション・フェイルオーバーの理解」を参照してください。

6.1.3 透過的アプリケーション・フェイルオーバー・コールバックの使用

TAFコールバックとは、フェイルオーバーが発生したときに登録され、イベントの発生時にそのイベントをアプリケーションに通知するためにフェイルオーバー時にコールされるコールバックです。ユーザーのセッションを再構築する際に何回かコールされます。

アプリケーションの開発者は、フェイルオーバーが進行中であることをユーザーに通知する必要が生じる場合があります。フェイルオーバーの進行時には、若干の遅延が発生するためです。この機能は、最初のコールバックへのコールによって実行されます。また、フェイルオーバーが成功して接続が再確立した場合には、フェイルオーバーが発生したことをユーザーに通知してから、ALTER SESSIONコマンドをリプレイする必要が生じることがあります。このコマンドは、2つ目のインスタンスで自動的にはリプレイされないためです。2回目のコールバックへのコールにより、その機能が実行されます。また、フェイルオーバーが失敗した場合には、フェイルオーバーが発生しなかったことをアプリケーションに通知します。3回目のコールバックへのコールでも、その機能が実行されます。

TAFコールバックを使用すると、次のことが可能になります。

フェイルオーバー・プロセスを通じて、フェイルオーバーのステータスが進行中、成功、失敗のいずれであるかをユーザーに通知します
必要なときにALTER SESSIONコマンドをリプレイします
新しい接続上でセッションが開始されるたびに、プライマリ・ハンドル以外のユーザー・ハンドルを再認証します。各ユーザー・ハンドルはサーバー側セッションを表すため、クライアントでは、そのセッションのためにALTER SESSIONコマンドを再実行する場合があります。

関連項目:

各インタフェースの具体的なコールバック登録情報は、「透過的アプリケーション・フェイルオーバーの構成」を参照してください。

6.2 高速アプリケーション通知(FAN)と高速接続フェイルオーバー(FCF)

この項では、高速アプリケーション通知(FAN)および高速接続フェイルオーバー(FCF)の概要と、高可用性環境でアプリケーションがFANイベントに応答する方法、FCFを使用してフェイルオーバー後に接続を再配置する方法について説明します。

トピック:

6.2.1 高速アプリケーション通知(FAN)について

高可用性の重要な要素が、高速アプリケーション通知(FAN)と呼ばれる通知のメカニズムです。FANは、UPイベントやDOWNイベントなどのサービス・ステータス変更をはじめとして、構成とサービス・レベルの情報を他のプロセスに通知します。アプリケーションはFANイベントに応答して、すぐにアクションを実行できます。FANの UP イベントおよび DOWN イベントは、インスタンス、サービスおよびノードに適用できます。

FANには、インスタンスまたはサーバーで障害が発生した場合に、アクティブなトランザクションを即座に終了する機能が備えられています。FAN統合されているOracle Clientは、イベントおよび応答を受信します。アプリケーションによる応答は、エラーをユーザーに伝播するか、またはトランザクションを再実行しアプリケーション・ユーザーからエラーをマスクすることによって実行されます。DOWNイベントが発生すると、統合されているFANクライアントでは、終了されたデータベースへの接続が即座にクリーン・アップされます。UPイベントが発生すると、FAN統合クライアントでは新しいプライマリ・データベース・インスタンスへの新しい接続が作成されます。

FANは、一般的なOracleクライアント・ドライバの多くに統合されています。したがって、FANを使用する最も簡単な方法は、次のいずれかの統合されているOracleクライアントを使用することです。

OCIセッション・プール
Universal Connection Pool for Java
Thin JDBC Driver (12.2以降)
ODP.NET管理対象と管理対象外プロバイダ
すべてのWebLogic Serverデータ・ソースとOracle Tuxedo

この機能は、使用可能なプライマリ・データベースにアプリケーションからいつでも一貫して接続できるようにすることを目的としています。

FANイベントは、Oracle Notification Serviceを使用して発行されます。発行メカニズムは、Oracle RACのインストール時に自動的に構成されます。ここで、Oracle RACがインストールされているということは、Oracle RACに伴うOracleクラスタウェア、Oracle RAC One Node、Oracle Data Guard (ファストスタート・フェイルオーバー)、またはOracleクラスタウェアに伴うOracle Data Guard単一インスタンスがインストールされていることを意味します。Oracle Database 12c リリース(12.1)以降では、ONSが新しいクライアント(Oracle Database 12c リリース1 (12.1))と新しいサーバー(Oracle Database 12c リリース1 (12.1))に対する第一の通知メカニズムになっています。AQ HAの通知機能は非推奨になり、古いOCIやODP.NET管理対象外クライアント(Oracle Database 12c リリース1 (12.1)より前)または古いサーバー(Oracle Database 12c リリース1 (12.1)より前)が使用されている場合の、下位互換性のためにのみ維持されます。

JDBCまたはOracle Database 12 c リリース1 (12.1.0.1) OCIまたはODP.NETのクライアントを使用する場合、Oracle Notification ServiceはユーザーのTNSを使用して自動的に構成されます。OCIベースのクライアントを使用する場合は、サービスのHA通知(-notification = TRUE)を設定し、oraccess.xmlにEVENTSを設定します。

関連項目:

FANの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください
Oracle Restart環境でFANイベントを有効にする方法については、『Oracle Database管理者ガイド』を参照してください
Oracleクラスタウェアを設定して有効にしたOracle RAC環境で、ランタイム接続ロード・バランシングのアドバイザFANイベントを受信し、アプリケーションのセッション要求を均等に分散する方法の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください
Oracle RACのロード・バランシング・アドバイザによって分散されるサービス・メトリックを使用する、ステートレス接続プールのランタイム・ロード・バランシングについては、『Oracle C++ Call Interfaceプログラマーズ・ガイド』を参照してください
高速接続フェイルオーバーの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください

6.2.2 FANイベント通知の受信について

Oracle Database 12c リリース2 (12.2)以降では、ユニバーサル接続プールまたはOracle WebLogic ServerとActive Grid Link (AGL)を使用しない場合でも、Oracle RAC FAN APIを使用すると、Oracle Databaseの高可用性(HA)機能を利用できます。この機能はOracle Notification System(ONS)メッセージ・トランスポート・メカニズムに依存しています。

ONSを使用するには、システム、サーバーおよびクライアントで構成が必要です。Oracle RAC高速アプリケーション通知を使用するには、simplefan.jarファイルがCLASSPATHに存在するか、ons.jarファイルがCLASSPATHに存在するか、Oracle Notification Services (ONS)クライアントがクライアント・システムにインストールされ、稼働している必要があります。

関連項目:

Oracle RAC FAN APIの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

6.2.3 高速接続フェイルオーバー(FCF)について

スタンバイ・データベースが存在する構成では、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 RACのロード・バランシング・アドバイザによって分散されるサービス・メトリックを使用する、ステートレス接続プールのランタイム・ロード・バランシングについては、『Oracle C++ Call Interfaceプログラマーズ・ガイド』を参照してください
高速接続フェイルオーバーの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください
Oracle Universal Connection Pool for JDBC Java APIリファレンス
JDBCクライアントに対してFCFを有効にする方法については、『Oracle Database管理者ガイド』を参照してください
OCIクライアントに対してFCFを有効にする方法については、『Oracle Database管理者ガイド』を参照してください
ODP.NETクライアントに対してFCFを有効にする方法については、『Oracle Database管理者ガイド』を参照してください

6.3 アプリケーション・コンティニュイティとトランザクション・ガード

アプリケーション・コンティニュイティは、フェイルオーバーのためのDBA機能です。トランザクション・ガードは、フェイルオーバーのコードを独自に作成するための、開発者用の機能です。

Oracle高可用性フレームワークでは、JDBCクライアント、OCIクライアントおよびODP.NETクライアントで高速アプリケーション通知(FAN)メッセージがサポートされます。FANは、ノード、データベース、インスタンス、サービス、およびパブリック・ネットワーク・レベルの停止を迅速にアプリケーションに通知するように設計されています。障害が通知されると、アプリケーションは障害が発生した接続を正常なインスタンスで再確立できます。

アプリケーション・コンティニュイティはアプリケーションに対して透過的です。この機能は、Oracle Database 12cとOracleドライバによって提供されます。これは、データベース・サービスの属性を設定することで有効になります。

関連項目:

アプリケーション・コンティニュイティの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
トランザクション・ガードの詳細は、「トランザクション・ガードの使用」を参照してください
OCI、トランザクション・ガードおよびアプリケーション・コンティニュイティの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。
JDBC、トランザクション・ガードおよびアプリケーション・コンティニュイティの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください

6.3.1 アプリケーション・コンティニュイティの概要

アプリケーション・コンティニュイティは、データベース・セッションのトランザクション状態および非トランザクション状態の再構築を試行することによって、計画済停止または計画外停止(データベース・セッションが使用できない原因になる)をマスクします。そのため、停止状態になってもユーザーには実行が遅延するようには見えなくなります。

アプリケーション・コンティニュイティは、Oracle Database 12c以降のサーバーと連携して、データベース・セッションがリプレイ可能かどうかを判定します。リカバリ可能なエラーが発生し、データベース・セッションが使用不可になると、エラー・メッセージがアプリケーションに返送されます。ドライバはFANメッセージ(停止または割込み)を受信して、デッド・セッションを中断します。

最後の送信でリプレイが有効な場合、12cドライバは送信のリプレイを準備し、保存された文をリクエストのためにリプレイします。アプリケーション・コンティニュイティは、トランザクション・ガードを使用して、エラーを受信したセッションから送信された前回の操作の結果を確認することによってリプレイを準備します。送信がコミットされて完了すると、新しいセッションはこの結果をアプリケーションに返し、SESSION_STATE_CONSISTENCYモードがSTATICの場合には非トランザクション状態を確立して続行し、SESSION_STATE_CONSISTENCYモードがDYNAMICの場合には終了します。DYNAMICセッション状態の一貫性は、ほとんどのアプリケーションに適しています。

FAILOVER_RESTOREがLEVEL1か、コールバックが設定されている場合、クライアント(JDBC replay driver, ODP.NET or OCI)は接続を初期化して、初期の非トランザクション・セッション状態(NTSS)をリストアします。リプレイするとき、権限が付与されている場合には、保持されている可変データがリストアされます。クライアントで目に見える結果が元の送信と等しくなるように、サーバーで検証が実行されます。リプレイが完了すると、アプリケーションはアプリケーション・ロジックを続行してランタイム・モードに戻るため、負荷時に発生するのと類似した実行遅延しか起こらなかったかのように見えます。

場合によっては、リプレイはクライアントが決定に使用したデータをリストアできないことがあります。その場合、リプレイは元のエラーをアプリケーションに返し、遅延エラーのように見えます。

アプリケーション・コンティニュイティは、同じDBID (時間上では先行)を持つデータベースのコピーに対して、あるいはActive Data Guardファーム内で、データベースが使用できないことによる停止をリカバリできます。これは、Active Data Guard内のOracle RAC One、Oracle Real Application Clustersであることも、1つのRACまたは複数のRAC全体、またはActive Data Guard (ADG)へのPDB再配置を使用するMultitenantであることもあります。

関連項目:

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

6.3.2 トランザクション・ガードの概要

トランザクション・ガードは信頼性の高いプロトコルとインターフェイスであり、エラーまたはタイムアウトがクライアントに返されたときに、現在進行中のトランザクションのコミット結果を返します。アプリケーションはトランザクション・ガードのインタフェースを利用して、正常にリカバリ可能なエラー処理をコード化することができます。停止中に明確なメッセージを提供することで、ユーザー・エクスペリエンスが大幅に向上します。

トランザクション・ガードでは、最大1回のトランザクション実行のセマンティクスという概念が導入されており、これはトランザクションの冪等性とも呼ばれます。アプリケーションがこのサービスを使用してデータベースへの接続をオープンすると、認証時に論理トランザクションID (LTXID)が生成され、データベースではセッション・ハンドルに格納され、クライアント・ドライバではコピーが格納されます。これはデータベース・トランザクションをアプリケーションの観点から識別する、グローバルに一意なIDです。アプリケーションはトランザクション・ガードのインタフェースを使用して、リカバリ可能なエラーに続く既知のコミット結果を取得します。

停止したとき、トランザクション・ガードを使用しているアプリケーションは以前に失敗したセッションのハンドルからLTXIDを取得し、セッション障害が起こる前にアクティブだったトランザクションの結果をそれによって判定できます。LTXIDがUNCOMMITTEDと判定された場合、アプリケーションはUNCOMMITTEDという結果をユーザーに返して実行が必要なアクションを決定するか、オプションとして、コミットされていないトランザクションをリプレイすることもできます。LTXIDがCOMMITTEDと判定された場合、トランザクションがコミットされ、アプリケーションはその結果をエンドユーザーに返すことができ、新しい接続を取得して続行することも可能です。トランザクション・ガードは、直前のユーザー・コールがCOMMITTEDかどうかのみでなく、必要な非トランザクション状態の変更を完了したかどうかもレポートします。USER_CALL_COMPLETEDを参照してください。

関連項目:

トランザクション・ガードの使用

6.4 データベース・クラウドのサービスおよびロード管理

トピック:

データベース・クラウドのサービスおよびロード管理について

6.4.1 データベース・クラウドのサービスおよびロード管理について

データベース・クラウドは、サービスおよびロード管理のフレームワークによって統合され、高いパフォーマンスと可用性、そしてリソースの最適な利用が保証される自己完結型のデータベース・システムです。このフレームワークでは、ローカルにも、また地理的に分散した地域のデータ・センターでも同期された複数のレプリカを保持する分散データベース間で、処理のワークロードが効果的に均衡されます。レプリカは、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用のアプリケーション・コンティニュイティとトランザクション・ガードをサポートできるようになりました。

関連項目:

グローバル・サービス管理の概要と、サービスおよびロード管理フレームワークの物理コンポーネントおよび論理コンポーネントの詳細は、『Oracle Database概要』を参照してください
データベース・クラウドにおけるグローバル・サービス管理の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください
Global Data Services (GDS)フレームワークへの接続に関するデータベース・クライアントの構成の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。
OCI、アプリケーション・コンティニュイティおよびトランザクション・ガードの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください
JDBC、アプリケーション・コンティニュイティおよびトランザクション・ガードの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください