プライマリ・コンテンツに移動
Oracle® Database 2日でReal Application Clustersガイド
12c リリース1 (12.1)
B71293-05
目次へ移動
目次 		索引へ移動
索引
前
前 		次
次

6 サービス、FAN、FCFおよびアプリケーション・コンティニュイティを使用したクライアントの高可用性

データベース・サービス、高速アプリケーション通知(FAN)、高速接続フェイルオーバー(FCF)およびアプリケーション・コンティニュイティを使用すると、Oracle Real Application Clusters (Oracle RAC)でクライアントの高可用性およびスケーラビリティを実現できます。古いアプリケーションは、透過的アプリケーション・フェイルオーバー(TAF)を使用できます。

データベース・サービスを使用した継続的サービスの実現について

継続的サービスが実現されるようにOracle RAC環境をデプロイする多数の方法があります。

クラスタ・データベースを使用するアプリケーションでは、通常、クラスタ間でのワークロードのロード・バランスが必要です。Oracle Real Application Clusters (Oracle RAC)はOracle Clusterware上で実行され、Oracle Clusterwareは高可用性(HA)アプリケーション・フレームワークを提供しています。Oracle Clusterwareは、必要なサービス、およびOracle RACとFANを使用したカスタム・エンタープライズ・アプリケーションの間の統合ポイントを提供します。グローバル・データ・サービス(GDS)もデータ・センター間でサービスとFANの統合ポイントを提供しています。

ノードの数や環境の複雑さおよび目的に応じて、様々な考慮事項に基づいて、最適なワークロード管理および高可用性構成を選択します。

Oracle RACデータベースを使用するアプリケーションに継続的サービスを実装するには、次の機能を使用します。

参照:

サービスの作成

Oracleサービスについて

サービスは、ワークロードを互いに共通の要素を持たないグループに分割します。各サービスは、一般的な属性、サービス・レベルしきい値および優先度でワークロードを表します。

動的データベース・サービス(多くの場合、単にサービスと呼ばれます)は、Oracle Databaseでワークロードを管理するための論理的抽象化です。単一のサービスは、1つのアプリケーション、複数のアプリケーション、または単一のアプリケーションのサブセットを表すことができます。たとえば、Oracle E-Business Suiteでは、総勘定元帳、売掛金勘定、受注など、職務ごとにサービスを定義します。単一のサービスをOracle RACデータベースの1つ以上のインスタンスに関連付けると、単一のインスタンスで複数のサービスをサポートできます。

注意:

データベース・サービスは、単一のネットワーク上でのみ提供できます。

サービスには、次のメリットがあります。

  • 同じリソースに対して競合するアプリケーションを管理する単一のエンティティを提供

  • 各ワークロードを1つの単位として管理することが可能

  • クラスタの複雑性をクライアントから隠すことができること

ワークロードを管理するために、特定のアプリケーションまたはアプリケーションの一部の操作に割り当てるサービスを定義できます。サービスを使用して、異なるタイプの作業のワークロードを管理することもできます。たとえば、オンライン・ユーザー、バッチ処理、レポートは、それぞれ異なるサービスを使用できます。

従来、Oracle Databaseでは単一のサービスを提供し、すべてのユーザーはその同じサービスに接続していました。データベースには、このデフォルトのデータベース・サービスが、データベース名で常に存在します。このサービスは変更できません。このサービスでは常にデータベースへの接続が可能なため、管理的なタスクのみに使用してください。デフォルト・データベース・サービスは無効化や再配置ができないため、可用性を高めるために使用するのは避けてください。各自のアプリケーションには常にユーザー定義データベース・サービスを使用します。

注意:

デフォルト・データベース・サービスは管理用で変更できないため、このサービスはアプリケーションのワークロードに使用しないでください。デフォルト・データベース・サービスは、DB_NAMEまたはDB_UNIQUE_NAMEデータベース初期化パラメータと同じ名前を持ちます。「サービスの作成」の説明に従って、1つ以上のサービスを作成してください。

ユーザーまたはアプリケーションがデータベースに接続するときには、接続用のサービスを使用することをお薦めします。Oracle Databaseでは、データベースの作成時にデータベース・サービスが自動的に1つ作成されます。基本的または管理的な接続の場合は、このサービスのみで十分です。ただし、データベースおよびそのワークロードに接続しているアプリケーションをより柔軟に管理する場合は、アプリケーション・サービスを1つ以上作成し、どのデータベース・インスタンスでサービスを提供するかを指定します。

ポリシー管理および管理者管理の両方のデータベース用にサービスを定義できます。

  • ポリシー管理データベース: ポリシー管理データベースのサービスを定義する場合は、データベースが実行されているサーバー・プールにサービスを割り当てます。サービスは、均一(サーバー・プール内のすべてのインスタンスで実行)またはシングルトン(サーバー・プール内の1つのみのインスタンスで実行)のいずれかとして定義できます。

  • 管理者管理データベース: 管理者管理データベースのサービスを定義する場合、どのインスタンスが通常そのサービスをサポートするかを定義します。これらはPREFERREDインスタンスと呼ばれます。優先インスタンスに障害が発生したときにサービスをサポートする他のインスタンスを定義することもできます。これらはAVAILABLEインスタンスと呼ばれます。管理者管理データベースで実行されるサービスには、PREFERREDインスタンスが1つ以上必要です。

サービスはデータベース・リソース・マネージャに統合されており、データベース・リソース・マネージャでは、インスタンス内のサービスが使用するリソースを制限できます。また、Oracle Schedulerのジョブは、特定のインスタンスではなく、サービスを使用して実行できます。

参照:

  • サービスの管理

  • データベースへのクライアント接続の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

管理者管理データベースのサービス・フェイルオーバーについて

管理者管理データベースにサービス・フェイルオーバーを構成する場合は、優先インスタンスおよび使用可能なインスタンスを構成する必要があります。

通常の操作でサービスは、サービスのカーディナリティ(定義されたPREFERREDインスタンスの数)に応じて、優先インスタンスと使用可能インスタンスの任意の組合せにおいて実行できます。サービスの最初の起動時のみ、Oracle ClusterwareはPREFERREDインスタンスでサービスを起動しようとします。インスタンスで障害が発生した場合、サービスを提供していない優先インスタンスおよび使用可能インスタンスの組合せリスト内のいずれかにサービスがフェイルオーバーされます。サービスを提供しない優先インスタンスおよび使用可能インスタンスの組合せリスト内のインスタンスの1つに対して、サービスを手動で再配置することもできます。

サービスが使用可能インスタンスにフェイルオーバーした場合、そのサービスが優先インスタンスに自動的に戻ることはありません。ただし、FANコールアウトを使用すると、優先インスタンスへのサービスの再配置を自動化できます。

サービスの優先インスタンスを構成する際にそのサービスに対して使用可能インスタンスを1つ以上指定しない場合、優先インスタンスが失敗してもサービスは他のインスタンスにフェイルオーバーされません。

Enterprise Managerを使用して、インスタンスを「未使用」として指定することもできます。この設定により、サービスの優先インスタンスが失敗しても、そのサービスはインスタンスで稼働しません。

参照:

ポリシー管理データベースのサービス・フェイルオーバーについて

サービスがUNIFORMまたはSINGLETONの場合、ポリシー管理データベースのサービス・フェイルオーバーの動作は異なります。

均一サービスを指定すると、Oracle Clusterwareは、指定されたサーバー・プールのすべての使用可能インスタンスで常にサービスが実行されるようにします。インスタンスが失敗すると、サービスは、そのインスタンスで利用できなくなります。サーバー・プールのカーディナリティが増大し、インスタンスがデータベースに追加されると、サービスは新しいインスタンスで起動されます。サービスを特定のインスタンスに手動で再配置することはできません。

シングルトン・サービスを指定すると、Oracle Clusterwareは、指定されたサーバー・プールの使用可能インスタンスの1つのみで常にサービスが実行されるようにします。インスタンスが失敗すると、サービスは、サーバー・プール内の別のインスタンスにフェイルオーバーします。サーバー・プール内のどのインスタンスでサービスを実行させるかは指定できません。

SINGLETONサービスの場合、サービスが新しいインスタンスにフェイルオーバーすると、元のインスタンスが再び利用可能になってもサービスはそのインスタンスには戻りません。

参照:

  • サービスの作成

  • データベース・サービスを使用した自動ワークロード管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

サービスの自動開始について

サービスを定義する場合に、そのサービスの管理ポリシーを定義することもできます。

自動または手動の管理ポリシーを選択できます。

  • 自動: サービスはデータベースの起動時に常に起動されます。

  • 手動: データベースの起動後に手動でサービスを起動する必要があります。

注意:

管理者管理データベースで自動サービスを使用すると、計画されたデータベースの起動中に、サービスは優先インスタンスではなく使用可能インスタンスになる最初のインスタンスで開始される場合があります。

関連トピック

データベース・リソース・マネージャについて

データベース・リソース・マネージャはデータベース機能の1つであり、これを使用すると、ユーザー、アプリケーションおよびサービスに割り当てられたデータベース・リソースを制御できます。

データベース・リソース・マネージャにより、ユーザー、アプリケーションおよびサービスは使用可能な分のデータベース・リソースを確実に受け取れます。データベース・リソース・マネージャを使用すると、1つ以上のノードで実行されるOracle RACデータベースで、複数のアプリケーションおよび混合ワークロードを効率的にサポートできます。

データベース・リソース・マネージャには、Oracle DatabaseまたはOracle RAC環境内の作業に優先度を設定する機能があります。たとえば、オンライン・ワーカーなどの優先度の高いユーザーに多くのリソースを割り当ててレスポンス時間を最短に抑え、バッチ・ジョブやレポートなどの優先度の低いユーザーには割り当てるリソースの量を抑えて実行時間を長くできます。データベース・リソース・マネージャにより、リソースに対するより細かな制御が可能になります。

リソースは、データベース管理者が指定したリソース・プランに従ってユーザーに割り当てられます。リソース・プランの指定には、次の用語が使用されます。

  • リソース・プランでは、リソース・コンシューマ・グループに基づいてリソースを各種ユーザー間で分散する方法を指定します。

  • リソース・コンシューマ・グループを使用すると、管理者は、ユーザー・セッションをリソース要件別にグループ化できます。リソース・コンシューマ・グループはユーザー・ロールとは異なり、1データベース・ユーザーに対して、異なるリソース・コンシューマ・グループに割り当てられている異なる複数のセッションを指定できます。

  • リソース割当てメソッドは、データベース・リソース・マネージャで特定のリソースを割り当てる際に使用するメソッドまたはポリシーです。リソース・コンシューマ・グループとリソース・プランでは、リソース割当てメソッドが使用されます。データベースには使用可能なリソース割当てメソッドが用意されていますが、どのメソッドを使用するかはDBAが決定します。

  • リソース・プラン・ディレクティブは、特定のプランにコンシューマ・グループを割り当て、リソース割当てメソッドごとにパラメータを指定してコンシューマ・グループ間でリソースをパーティション化する方法です。

  • DBAによってリソース・プラン内に作成可能なサブプランにより、アプリケーションの複数のユーザー間でリソースをさらに分散できます。

  • レベルは、使用可能なユーザー間での未使用リソースの分散を指定するメカニズムです。最大で8レベルのリソース割当てを指定できます。

サービスを使用して接続するユーザーは特定のリソース・コンシューマ・グループのメンバーであるため、データベース・リソース・マネージャによってリソース・コンシューマ・グループをサービスにマップできます。したがってリソース・コンシューマ・グループに対して使用可能なリソースを制限できます。

Enterprise Managerからリソース・マネージャのチュートリアルにアクセスできます。「クラスタ・データベース」のホームページにナビゲートして、「管理」メニューから「リソース・マネージャ」を選択し、「スタート・ガイド」を選択します。Oracle Enterprise Managerへのログインの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

参照:

Database Resource Managerの詳細は、Oracle Database管理者ガイドを参照

Oracle RACの高可用性フレームワークについて

Oracle RACの高可用性フレームワークを使用すると、実行中の状態にあるデータベース、コンポーネントおよびアプリケーションを常にOracle RACで管理できます。

インスタンス、コンポーネントまたはアプリケーションに障害が発生しても自動的に再起動できるため、Oracle Databaseの動作を最適な状態に保つことができます。

Oracle Databaseはサービスの可用性の維持に重点を置いています。Oracle RACでは、Oracleサービスは1つ以上のインスタンスでワークロードを共有し、継続的に使用できるように設計されています。Oracle RACの高可用性フレームワークでは、各サービスの構成情報をOracle Cluster Registry(OCR)に格納することでサービスの可用性が維持されます。Oracle Clusterwareは、サービス定義に基づいて複数のインスタンス間でサービスのリカバリおよび調整を行います。

参照:

システムに対する高可用性要件の判断の詳細は、『Oracle Database高可用性概要』を参照してください。

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

高速アプリケーション通知(FAN)は、Oracle RACで他のプロセスにクラスタ構成およびサービス・レベルの情報を通知するために使用される高可用性通知メカニズムであり、この情報にはUPイベントやDOWNイベントなどのステータスの変更が含まれます。

高可用性アプリケーションの主要な要件の1つとして、システムの重要なコンポーネントに問題が発生した場合に、迅速にアプリケーションへの通知が行われることがあげられます。通知により、アプリケーションはイベント処理プログラムを実行できます。そのようなプログラムを即時に実行することによって、コストのかかる接続のタイムアウトおよびアプリケーションのタイムアウトを回避し、クラスタのリソース構成の処理にかかる時間およびクラスタ・コンポーネントの障害の影響を最小化します。

FANを使用すると、クラスタ・コンポーネントに障害が発生したときのアプリケーションの自動リカバリが可能となります。クラスタ構成の変更に対しては、Oracle RACの高可用性フレームワークにより、インスタンスの状態に関して変更が発生したと同時にFANイベントがパブリッシュされます。アプリケーションは、データベースの問合せと問題の検出を待たずに、FANイベントを受信して即時に対応できます。

FANのUPイベントおよびDOWNイベントは、インスタンス、サービスおよびノードに適用できます。FANでは、ロード・バランシング・アドバイザのイベントもパブリッシュされます。FANのUPおよびDOWNイベントには、次のメリットがあります。

  • DOWNイベントでは、障害が発生したインスタンスまたはノードに接続されているセッションを終了できるため、アプリケーションの中断を最小限に抑えることができます。未完了のトランザクションを終了でき、アプリケーション・ユーザーは即時に通知されます。接続をリクエストしているアプリケーション・ユーザーは、リクエストされたサービスを提供している起動済のインスタンスに送られます。

  • UPイベントでは、サービスおよびインスタンスが起動されている場合、アプリケーションが追加のリソースを即時に利用できるように、新しい接続を作成できます。

Oracle ClusterwareおよびOracle RACでは、Oracle Notification Services(ONS)を使用してOracleクラスタ内およびクライアント(または中間層マシン)の両方に対してFANメッセージを伝播します。ONSはOracle Clusterwareとともにインストールされ、ONSデーモンを管理するリソースがインストール・プロセス中に自動的に作成されます。ONSデーモンはクラスタの各ノードで実行され、他のONSデーモンがアクティブなノードの構成リストとの間でメッセージを送受信します。このノードのリストは、アプリケーション・サーバー層またはクライアント・ノードなどのクラスタ外のノードを含むこともできます。

FANは、Oracle Data Guard、Active Data Guard、Oracle WebLogic Server Active GridLink for RAC、Universal Connection Pool (UCP)クライアント、Global Data ServicesおよびOCIベースのクライアント(OCI/OCCI、ODP.NETおよびOCIセッション・プールを含む)と使用することもできます。

参照:

FANコールアウトについて

FANコールアウトは、高可用性イベントの発生と同時にOracle RACによって実行されるサーバー側の実行可能ファイルです。

コールアウトは基本的にシェル・スクリプトであるか、またはなんらかのプログラム言語で書かれてプリコンパイルされた実行可能ファイルです。クラスタ構成でのイベントの発生時に実行されるアクションを、FANコールアウトを使用して自動化する例を次に示します。

  • サーバー側のアプリケーションの起動および停止

  • 優先度の高いサービスがオンラインになった場合の優先度の低いサービスの再配置

  • ページャへのテキストまたは数値メッセージの送信

FANコールアウトの実行可能ファイルは、Grid_home/racg/usrcoサブディレクトリに格納されます。このサブディレクトリがGridホームにない場合は、Grid_home/racg/tmpサブディレクトリと同じ権限および所有権でこのディレクトリを作成する必要があります。

Grid_home/racg/usrcoサブディレクトリにある実行可能ファイルは、Oracle Notification Service(ONS)を通じてFANイベントを受信すると非同期方式ですぐに実行されます。ほとんどのイベント・タイプにおいて、コールアウトはクラスタ内の1つのノード(イベントを生成しているノード)で実行されるため、Oracle Clusterwareを実行するすべてのノードに、FANコールアウトで使用される実行可能ファイルのコピーを用意しておく必要があります。コールアウト・スクリプトの例は、Oracle Technology Networkにあるホワイト・ペーパー(http://www.oracle.com/technetwork/database/options/clustering/overview/fastapplicationnotification12c-2980342.pdf)の「付録D コールアウト・プログラム(PERLベース)の例」の項にあります。

参照:

  • FANコールアウトの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

  • 高速アプリケーション通知およびFANコールアウトの構成の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照

クライアント・フェイルオーバーを向上させるためのトランザクション・ガードの使用について

トランザクション・ガードは、計画済および計画外の停止と送信の繰返しの場合に、実行を1回以下にするためにアプリケーションで使用される汎用ツールを提供します。

Oracle Database 12c以降、アプリケーションでは論理トランザクションID (LTXID)を使用して、停止後のデータベース・セッション内でオープンになっている最終トランザクションの結果を判断できます。トランザクション・ガードを使用しないと、アプリケーションが停止の後に操作を実行しようとして、トランザクションが重複してコミットされ論理破損が発生する可能性があります。

トランザクション・ガードがない場合、停止後にアプリケーションをリカバリする際の根本的問題の1つが、クライアントに返送されたコミット・メッセージに継続性がないことです。クライアントとサーバーの間が中断されると、クライアントには通信が失敗したことを示す(リカバリ可能エラーとも呼ばれる)エラー・メッセージが示されます。このエラーは、送信でコミット操作が実行されたかどうかまたはすべての予測されるコミットの実行中に完了まで手続きコールを実行したかどうかをアプリケーションに通知しません。エラーはセッション・ステート変更または断続的な障害も示しません。さらに、アプリケーションはクライアントから切断されても実行を続行する場合があります。

このリカバリ可能エラーによって、エンド・ユーザーまたはアプリケーションが、(アプリケーション・コンティニュイティを使用せずに)再試行するために、トランザクションの送信が重複して発行され、データベースですでにコミットされている変更が再発行されるなど、その他の論理破損が引き起こされます。トランザクションは、非トランザクション状態が不正確な場合、またはそのトランザクションがコミットされている場合は、有効に再送信できません。コミットされているが完了していないコールの処理を続けると、誤った状態のデータベース・セッションがアプリケーションで使用されることになります。

Oracle Database 12cリリース1 (12.1)ではトランザクション・ガードによって、自動的かつ透過的に基準化された方法で冪等性を達成するために、アプリケーションで使用される新たな統合ツールが提供されます。トランザクション・ガードは、論理トランザクションID (LTXID)を使用して、重複するトランザクションを削除します(トランザクションの冪等性と呼ばれるプロセスです)。論理トランザクションIDはコミット時に継続され、ロールバックの後に再使用されます。通常の実行中、LTXIDは、各データベース・トランザクションについてクライアントおよびサーバーの両方で自動的にセッションで保持されます。コミット時に、LTXIDはトランザクションのコミットの一部として保持され、データベースは次のLTXIDを使用するためにクライアントに返します。

例6-1 アプリケーション・コンティニュイティまたはアプリケーションによってトランザクション・ガードが使用される仕組み

  1. Oracle ClientドライバがFAN停止イベントを受け取ります。

  2. FANは終了したセッションを自動的に中断します。

  3. リカバリ可能エラーの場合は、次のように続きます。

    1. クライアント・ドライバで提供されたAPI (JDBCの場合はgetLogicalTransactionId()、ODP.NETの場合はLogicalTransactionIdおよびOCIの場合はOCI_ATTR_GET)を使用して、失敗したセッションから最終LTXIDを取得します。

    2. 新しいセッションを取得します。

    3. PL/SQLプロシージャDBMS_APP_CONT.GET_LTXID_OUTCOMEを、失敗したセッションから取得した最終LTXIDとともに呼び出します。

      注意:

      DBMS_APP_CONTパッケージにおけるEXECUTE権限を、パッケージを使用するデータベース・ユーザーに付与してください。

    4. このトランザクションの結果がCOMMITTEDおよびCOMPLETEDの場合は、そのトランザクションの結果をアプリケーションに返します。

    5. セッション状態の結果(メッセージやPL/SQLブロックなど)がCOMMITTEDであるがCOMPLETEDではない場合は、そのトランザクションの結果をアプリケーションに返します。トランザクションがコミットされたが、その他の状況(アプリケーションの続行を妨げる行カウントなど)が存在する可能性を示す警告も返されます。

      注意:

      ほとんどのアプリケーションでこれらの状態は必要ありません。必要とされる場合の注意点を上に示しています。行カウントや呼出しのその他の状態に注意する必要がない場合は、COMMITTEDをアプリケーションに返します。

    6. トランザクションの結果がCOMMITTEDではない場合は、ユーザーまたはアプリケーションは、最後のリクエストを再送信することを選択できます。

参照:

  • トランザクション・ガードおよび冪等性の詳細は、『Oracle Database開発ガイド』を参照してください。

  • トランザクション・ガードおよびOracle RACのクライアント・フェイルオーバーの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

  • Javaアプリケーションでのトランザクション・ガードの使用については、『Oracle Database JDBC開発者ガイド』を参照してください。

  • ODP.NETアプリケーションに対するトランザクション・ガードのサポートの詳細は、Microsoft Windows用Oracle Data Provider for .NET開発者ガイドを参照してください。

停止をマスキングするためのアプリケーション・コンティニュイティについて

アプリケーション・コンティニュイティは、計画済イベントおよび計画外イベントのデータベースの停止をマスキングできます。

計画済および計画外の停止後、アプリケーション・コンティニュイティは、データベース・セッションを再構築し、データベース・セッションを使用不可にしているリカバリ可能エラー後の保留中の作業を再送信することで、停止をマスキングしようとします。

アプリケーション・コンティニュイティが構成されていると、エンドユーザー・リクエストがまだ完了していない場合にリプレイされます(停止の発生時にリプレイが有効な場合)。リプレイは、サービスに指定されたリプレイ・タイムアウト属性を時間が超えていない場合に、開始されます。コンポーネントにエラーが発生したり、コンポーネントが無反応になると、アプリケーション・コンティニュイティはデータベース・セッションを現在の時間にリストアしようとします。リプレイが成功するとこの機能は、一時的な停止(セッション障害、インスタンスまたはノードの停止、ネットワーク障害など)や計画済停止(修復、構成変更およびソフトウェアのパッチ適用など)からアプリケーションをマスキングします。

アプリケーション・コンティニュイティを使用する準備

アプリケーション・コンティニュイティを使用する前に、様々なチェックを実行する必要があります。

アプリケーション・コンティニュイティを使用する前に、アプリケーションで使用されるデータベース・サービスの属性を構成する必要があります。また、ピン接続ではなく、接続を流用してから返すようにアプリケーションを変更することも必要です。これは通常、プロパティです。統合プールのいずれか(UCP、WLSデータ・ソース)が使用されていない場合、リクエスト境界を追加する必要があります。接続がOracle接続プールに戻らず、プロパティがピン解除に使用できない場合、リクエスト境界をマークする必要がある場合もあります。Oracle Database 12cリリース1 (12.1)では、Javaのアプリケーション・コンティニュイティをJDBC-Thin Oracleドライバ、JDBC Universal Connection Pool、およびWebLogic Server Active Grid Linkで汎用的に使用できます。これはPeopleSoftアプリケーションの使用時にOCI 12cでも使用できます。

アプリケーション・コンティニュイティをOracle RACデータベースで使用するには、次の構成チェックリストを使用します。

サービス構成チェック

  • 動的データベース・サービス(アプリケーション・サービスとも呼ばれる)を作成して、データベースに接続します。Oracle RACまたはOracle Data Guardデータベースへの接続には、Oracle SID、インスタンス名またはデフォルトのデータベース・サービスを使用しないでください。

  • サービスについて、failovertypeをTRANSACTION、commit_outcomeをTRUE、そしてnotificationをTRUEに設定します。オプションで、使用に適した接続を探す場合は、rlb_goaをSERVICE_TIME、そしてclb_gloalをSHORTに設定します。「SRVCTLを使用したサービスの作成」を参照してください。

ソフトウェア構成チェック(データベースおよび中間層)

  • Oracle Database 12cリリース1 (12.1)以上を使用します。

  • JDBC Replayデータ・ソースとともに構成されたJDBC Universal Connection Pool (12.1)またはWebLogic Active GridLink (12.1.2以降)を使用します。固有のJDBC接続プールとともにJDBC Replayデータ・ソースを使用することもできます。

  • アプリケーション・サーバー・レベルの文キャッシュ(たとえば、WebLogicまたはサード・パーティ製アプリケーション・サーバーの文キャッシュ)が有効になっている場合、リプレイの使用時はこれを無効にする必要があります。かわりに、アプリケーション・コンティニュイティをサポートするJDBC文キャッシュを構成します。JDBC文キャッシュは、JDBCおよびOracleに最適化されているため、性能にも優れています。oracle.jdbc.implicitstatementcachesize=nnnを使用します。

  • WebLogic Active GridLink Data Source、Universal Connection Poolには、FANおよびFCFを使用するか、またはサード・パーティ・ツールでシンプルJDBC FANを使用します。

  • リソース要件をチェックし、中間層に十分なCPUおよびメモリーがあることを確認します。

    アプリケーション・コンティニュイティはサーバー側で管理され、CRCで使用可能な場合はハードウェアを使用します。クライアント側では、ガベージ・コレクションに対する追加CPUコストが発生します。呼出しがリクエストの最後まで保持されるため、リプレイ・ドライバにはベース・ドライバよりも多くのメモリーが必要です。リクエストの最後で、呼出しはガベージ・コレクタに解放されます。この処理は、クローズされた呼出しを解放するベース・ドライバによって異なります。

    注意:

    CPUオーバーヘッドは、検証がハードウェアによって補佐されている、現在のIntelおよびSparcチップを使用したプラットフォームのデータベース側で減少します。

  • アプリケーションが可変、または各インスタンスで異なる可能性のある順次データを使用できるかどうか判別します。その場合は、SYSDATE、SYSTIMESTAMP、SYS_GUIDの元の値と、フェイルオーバー中の順序を保持するようにアプリケーションを構成します。

    KEEP [DATE TIME|SYSGUID|Sequence]のユーザーへのGRANT権限の発行の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

  • DBMS_APP_CONT PL/SQLパッケージでのEXECUTEを、アプリケーション・コンティニュイティを使用するユーザーに付与します。

  • アプリケーション認証を行った後、リプレイを使用するユーザーに、可変を維持するためのGRANT権限を割り当てます。

  • リプレイできないリクエストがあるかどうかをアプリケーション開発者に確認します。これらのリクエストのリプレイを無効にするには、アプリケーションが明示的にAPIを呼び出す必要があります。

アプリケーション・コード・チェック(アプリケーション開発者に確認)

  • アプリケーションがOracle JDBCの具象クラスを使用するかどうか判別します。その場合にOracle固有APIへのアクセスが必要とされるようなときは、この具象クラスを標準のJDBCまたはOracle JDBCインタフェースと置き換えることを計画します。次のMy Oracle Supportノート1364193.1を参照してください:

    https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1364193.1

  • 接続再試行と、この試行間の遅延を設定する接続文字列を使用します。JDBCを使用した接続プロパティの構成の例については、「高速接続フェイルオーバー用JDBCクライアントの構成」を参照してください。

  • アプリケーションからデータベースへの接続の初期化に、オプションのコールバックが使用されるかどうかを判別します。Oracle WebLogic ServerまたはUniversal Connection Poolの使用時は、接続ラベリングが推奨されます。登録されている場合は、実行時およびリプレイでコールバックが実行されます。

  • アプリケーション内のコード・パスに対してリプレイを明示的に無効にする必要があるかどうかを判別します。特に、メッセージングやコールアウトなどの外部PL/SQLコールおよびサーバー・サイドJavaを確認します。リプレイを使用しない場合は、disableReplay APIを使用します。

  • リクエスト境界を識別、または各リクエストに対してアプリケーションがWebLogic Server PoolまたはUniversal Connection Poolから接続を流用してから返しているかどうかを識別するため、アプリケーションで開始および終了リクエストAPIをアプリケーション固有の接続プールに追加する必要があるかどうかを判別します。

    各リクエストに対してアプリケーションがWebLogic Server PoolまたはUniversal Connection Poolから接続を流用してから返している場合は、変更は不要です。

    アプリケーションがOracle接続プールを使用し、リクエスト間の接続を返さない場合は、接続をプールに返すように設定するプロパティがあるかどうかを確認します。設定するプロパティがない場合、またはアプリケーション固有の接続プールを使用中の場合は、beginRequestおよびendRequestの境界を追加する必要があります。

参照:

  • アプリケーション・コンティニュイティの動作およびアプリケーションでの使用方法の詳細は、『Oracle Database開発ガイド』を参照してください。

  • トランザクションの詳細は、『Oracle Database概要』を参照してください。

  • Javaアプリケーションのアプリケーション・コンティニュイティの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

  • サービスの作成

計画済停止に対するアプリケーション・コンティニュイティの使用

アプリケーション・コンティニュイティは、Oracle接続プールからのリクエストの排出と組み合された計画済停止について推奨されます。

FANが構成されたFAN対応プール(OCI、UCP、DRCP、WebLogic ServerまたはODP.NET)を使用した手順は次のとおりです。

  1. SRVCTL relocateコマンドを使用して、セッションを妨げずにシャットダウン中のインスタンスからサービスを再配置します(-forceパラメータは使用しません)。同一のサービスを再配置する場合は、インスタンスでsrvctl stop serviceを使用します(-forceパラメータは使用しません)。

  2. 計画済停止に対するFANイベントはアイドル・セッションを即時にクリアして、アクティブ・セッションをチェックイン時(リクエストの最後)に解放するとマーク付けします。これによって作業を妨げずにセッションがインスタンスから排出されます。

  3. すべてのセッションをチェックインする必要がありますが、実際はこれが常に発生するわけではありません。セッションのチェックインに十分な時間が経過したら、ABORT停止オプションを使用してインスタンスを停止します。アプリケーション・コンティニュイティが有効化されたプール(UCPおよびWebLogic Server)の場合、チェックインしなかったそれらの残りのセッションのリカバリがアプリケーション・コンティニュイティによって試行されます。

    この手順が適用されるのはUCPおよびWLSと、beginRequest/endRequestをJDBC Thin Replay Driverに追加するすべてのプールです。

  4. インスタンスおよびサービスを再起動します。ランタイム・ロード・バランシング(がもし有効な場合)は、次のリクエスト境界でリストアされたインスタンスを使用するために、セッションを戻して均衡化します。

ロード・バランシング・アドバイザについて

ロード・バランシング・アドバイザは、Oracle RACデータベース・インスタンスが提供している現在のサービス・レベルの情報をアプリケーションやクライアントに提供します。

アプリケーションでは、サービスに定義されたワークロード管理ディレクティブに基いて最高のパフォーマンスが達成されるように、ロード・バランシングの高速アプリケーション通知(FAN)イベントを利用してクラスタ内のインスタンスにリクエストを送信できます。また、インスタンスが再起動すると、最近起動したインスタンスへの接続が接続プールによって作成され、このインスタンスが提供する追加のリソースが利用されるため、Oracle RACではFANを使用してアプリケーションの接続プールを通知します。

ロード・バランシング・アドバイザは、Oracle Database 12cに組み込まれている自動ワークロード・リポジトリに統合されています。自動ワークロード・リポジトリは、各サービスについて応答時間とCPU消費を測定します。

ロード・バランシング・アドバイザによって示されるアドバイスでは、サーバーの処理能力およびサーバー上のサービスの現在のワークロードが考慮されます。ロード・バランシング・アドバイザを有効にすることにより、負荷が高いインスタンス、動作が遅いインスタンス、応答がないインスタンス、または障害が発生しているインスタンスで作業を行わないことによって、アプリケーションのスループットを向上させることができます。

ランタイム接続ロード・バランシング機能を備えた統合Oracleクライアントを使用すれば、プログラムを修正せずに、アプリケーションでロード・バランシング・アドバイザを利用できます。FANとの統合によって、Oracle統合クライアントでは、Oracleクラスタの現在のステータスをより迅速に認識します。これにより、クライアント接続が、使用できなくなったインスタンスへの接続を試みたり、それを待機することを防げます。FANイベント対応の統合クライアントには、Oracle Database 12c JDBC、Oracle Database 12c ODP.NET、およびOracle Database 12c Oracle Call Interface (OCI)で使用されるUniversal Connection Pool (UCP)が含まれます。

使用されている各サービスにサービス・レベル目標を定義して、ロード・バランシング・アドバイザを使用するようにOracle RAC環境を構成できます。サービス・レベル目標を定義することで、そのサービスのロード・バランシング・アドバイザが有効になり、FANロード・バランシング・イベントの発行が有効になります。ランタイム接続ロード・バランシングにおけるサービスレベルの目標値には、次の2つのタイプがあります。

  • サービス時間。ロード・バランシング・アドバイザでは、インスタンスに対する作業リクエストの送信を、そのインスタンスのレスポンス時間に応じて試行します。ロード・バランシング・アドバイザのデータは、そのサービスを使用した接続で作業が完了するまでの経過時間と、そのサービスに到達するまでに使用できるバンド幅に基づいています。この目標は、インターネットのショッピング・システムなどの、完了までにかかる時間が変動するワークロードに最適です。

  • スループット。ロード・バランシング・アドバイザでは、サービスに対してCPUで消費される合計レスポンス時間の割合が測定されます。この値からは、レスポンス時間ではなくインスタンスの効率性がわかります。この目標はトレーディング・システムなどの、各作業リクエストがほぼ同じ時間内に完了する必要のあるワークロードに最適です。

「ロード・バランシング・アドバイザの有効化」オプションを選択していない場合は、サービス・レベルの目標値が「なし」に設定され、そのサービスに対するロード・バランシングが無効になります。

参照:

接続ロード・バランシングについて

Oracle Net接続ロード・バランシングは、データベースへの接続に使用されるサービスをサポートするすべてのインスタンスにユーザー接続を分散します。

Oracle Netは、クライアントおよびOracle Databaseサーバー上に存在するソフトウェア・コンポーネントです。このコンポーネントは、クライアント・アプリケーションとサーバー間の接続を確立して維持し、業界標準プロトコルを使用してクライアントとサーバー間でメッセージを交換します。クライアント・アプリケーションとデータベースが通信するには、クライアント・アプリケーションが接続先のデータベースの場所の詳細を指定し、データベースがIDまたはアドレスなどを示す必要があります。

データベース・サーバー上には、Oracle Netリスナーが存在し、これは通常リスナーと呼ばれます。リスナーは、クライアント接続リクエストをリスニングするプロセスです。リスナーの構成ファイルはlistener.oraです。

Oracle Database 12cのデータベース・クライアントは、SCANと簡易接続メソッドを使用してデータベースに接続します。SCANは、パブリック・クライアント接続を処理するクラスタ内の複数のリスナーに対応する、複数のIPアドレスに解決できます。簡易接続メソッドを使用すると、すべてのクライアント・ネットワーク・ファイルを構成する必要がありません。接続識別子は、次の形式で簡単に指定できます。

SCAN[:port]/service_name

SCANはクラスタのSCANです。ポート番号を指定しない場合、デフォルト値の1521がTCPポート識別子に使用されます。service_nameは動的データベース・サービスの名前です。

Net Configuration Assistant (NETCA)を使用して、ネット・サービス名を作成することもできます。ネット・サービス名が接続記述子になります。接続記述子のアドレスの一部は、実際はリスナーのプロトコル・アドレスです。 クライアントは接続記述子を使用して、クライアントが接続するデータベースまたはインスタンスを指定します。

ネット・サービス名を使用する場合は、最初にネット・サービス名を接続記述子にマッピングした際に、データベース・インスタンスへの接続が確立されます。このマッピング情報は、ネーミング・メソッドを使用してアクセスされた1つ以上の情報リポジトリに格納されます。最もよく使用されるネーミング・メソッドはローカル・ネーミングであり、これを使用すると、ネット・サービス名および接続記述子はtnsnames.oraというローカライズ済の構成ファイルに格納されます。

クライアントがサービスを使用してクラスタ・データベースに接続する場合に、Oracle Netの接続ロード・バランシング機能を使用して、そのサービスをサポートするすべてのインスタンス間でユーザー接続を分散できます。実装可能なロード・バランシングには、クライアント側とサーバー側の2種類のロード・バランシングがあります。Oracle RACデータベースのクライアント接続では、両方のタイプの接続ロード・バランシングを使用する必要があります。Oracle Database Configuration Assistant(DBCA)を使用してOracle RACデータベースを作成した場合、デフォルトでは、サーバー側のロード・バランシングが構成されて有効化されます。

参照:

クライアント側のロード・バランシングについて

クライアント側のロード・バランシングでは、接続リクエストをリスナー間で均等に分散します。

リスナーは、接続リクエストを受信すると、リクエストされたサービスを提供することをリスナーが認識するインスタンスにユーザーを接続します。

クライアント側のロード・バランシングは、tnsnames.oraファイルにパラメータLOAD_BALANCE=yesを設定して、クライアントの接続定義に定義します。このパラメータをyesに設定すると、Oracleクライアントはアドレス・リストから無作為にアドレスを選択し、そのノードのリスナーに接続します。その結果、クラスタ内の使用可能なリスナー間で、クライアント接続が均等に分散されます。

DBCAを使用してOracle RACデータベースを作成する場合、アシスタントでは、tnsnames.oraファイルにロード・バランシング接続定義のサンプルが作成されます。

クライアント側のロード・バランシングには、接続フェイルオーバーが含まれます。接続フェイルオーバーを使用すると、選択したアドレスからエラーが返された場合にOracle Net Servicesによってアドレス・リストにある次のアドレスが試され、これは接続に成功するか、アドレス・リストにあるすべてのアドレスが試されるまで続けられます。

参照:

サーバー側のロード・バランシングについて

サーバー側のロード・バランシングでは、ロード・バランシング・アドバイザからの情報を使用して、リスナーにより、現在サービスを提供している最適なインスタンスに接続リクエストが転送されます。

各サービスに対して、接続ロード・バランシングの目標を設定し、リスナーでのロード・バランシングの使用方法を定義できます。接続ロード・バランシングには、長期または短期のいずれかの目標を使用できます。これらの目標の特性は次のとおりです。

  • 短期: 最適な応答時間に基づいて、複数のインスタンスに接続が分散されます。短期の接続ロード・バランシングの目標は、短期間の接続を行うアプリケーションに使用します。

  • 長期: サービスをサポートする各インスタンスにおいて、インスタンスごとのセッション数に基づいて接続が分散されます。長期の接続ロード・バランシングの目標は、長期間の接続を行うアプリケーションに使用します。これは通常、接続プールやSQL*Formsセッションで使用されます。長期の目標は、デフォルトの接続ロード・バランシングの目標です。

注意:

データベースの作成にDBCAを使用しなかった場合、またはデフォルトの1521以外のリスナー・ポートを使用している場合は、SCAN:portを指すようにクラスタ・データベースのLOCAL_LISTENERおよびREMOTE_LISTENERデータベース初期化パラメータを構成する必要があります。

参照:

ランタイム接続ロード・バランシングについて

ランタイム接続ロード・バランシングはOracle接続プールの機能の1つであり、これを使用すると、ロード・バランシング・アドバイザの情報に基づいて、クライアントの作業リクエストをOracle RACデータベースのインスタンス間で分散させることができます。

接続は、ロード・バランシング・アドバイザのFANイベントに従って、データベース・インスタンスにより提供される現在のパフォーマンス・レベルに基づいて割り当てられます。これによって、最初のデータベース接続時のロード・バランシングではなく、トランザクション・レベルでのロード・バランシングが実現します。

ランタイム接続ロード・バランシングでは、高いパフォーマンスを実現するために、アプリケーションがロード・バランシング・アドバイザの情報を使用します。OCIセッション・プールおよびODP .NET接続は、ランタイム接続ロード・バランシングをサポートします。Javaアプリケーションに対しては、ユニバーサル接続プール(UCP)をお薦めします。ユニバーサル接続プールは、ロード・バランシング・アドバイザの情報を活用するように統合されています。UCPはOracle Database 11gパッチセット1 (11.1.0.7)で導入されたもので、Oracle Database 10g、Oracle Database 11gまたはOracle Database 12cに対して使用できます。

次のような構成のサービスで、ランタイム接続ロード・バランシングに対してクライアント・データ・ソースを有効にする必要があります。

  • ロード・バランシング・アドバイザが有効にされ、サービス・レベル目標がSERVICE_TIME、THROUGHPUTまたはNONEに設定されている。

  • サービスの接続ロード・バランシング目標が「短い」に設定されている。

次の手順の図は、ランタイム接続ロード・バランシングを説明したものです。この図では、Oracle RACデータベースに3つのインスタンスがあります。ここで、インスタンス1およびインスタンス3のパフォーマンスは最適であり、インスタンス2のパフォーマンスは現在は最適ではないとロード・バランシング・アドバイザで示されているとします。Universal Connection Poolでランタイム接続ロード・バランシングが有効になっている場合、次のプロセスが発生します。

  1. クライアントが接続プールからの接続をリクエストします。

  2. ランタイム接続ロード・バランシングにより、最も効率的な(最適な)インスタンスに属する接続が接続プールから選択されます。次の手順の図では、接続のルーティング先となるノードが3つ存在します。CPUワークロードが最も少ないインスタンス1には、現在、着信接続の約60パーセントが割り当てられています。現在過負荷の状態にあるインスタンス2には、着信接続の約10パーセントしか割り当てられていません。ワークロードの高いインスタンス3には、着信接続の約30パーセントが割り当てられています。この場合、接続リクエストの処理に最適なインスタンスは、インスタンス1です。

  3. 作業リクエストを最短のレスポンス時間で処理する接続をクライアントが受信します。

図6-1 ランタイム接続ロード・バランシング

図6-1の説明が続きます
「図6-1 ランタイム接続ロード・バランシング」の説明

Oracle Database 11g以上では、ロード・バランシング・アドバイザのイベント内にアフィニティ・ヒントと呼ばれる追加のフラグを使用できます。アフィニティ・ヒントとは、インスタンスとサービスの特定の組合せに対して、アフィニティが利点となるかを示すフラグのことです。同様のサービスを提供する別のインスタンスでは、アフィニティ・ヒントを異なる設定にすることができます。

アフィニティ・ヒントは、サービスから目標を設定しロード・バランシング・アドバイザをオンにした場合、自動です。このフラグはWebセッションの継続期間中の一時アフィニティとなります。Webでの対話は、セッション全体の間に接続と切断を何度も繰り返すことがよくあります。これらの接続ではそれぞれ、ショッピング・カート、Siebelなど、同じデータまたはほぼ同じデータにアクセスする可能性があります。アフィニティにより、バッファ・キャッシュの効率が向上するので、CPUの使用率やトランザクションの待機時間を抑えることができます。

Oracle Database 12cおよびUCPを使用するアプリケーションは、この新たなアフィニティ機能を活用できます。アフィニティ・フラグをロード・バランシング・アドバイザのイベントでオンにすると、UCPはWebセッション用のアフィニティ・コンテキストを作成します。この際、セッションはプールから接続し、そのプールは常に最初にセッションを取得したインスタンスに対して接続を試みます。最初に接続するインスタンスは、現在のロード・バランシング情報に基づいて選択します。

関連トピック

サービスの作成

Oracle Enterprise ManagerまたはSRVCTLユーティリティを使用してサービスを作成できます。

注意:

DBMS_SERVICEパッケージは、サービスの提供に必要なデータベース構造を作成しますが、Oracle Clusterwareの機能(サービスの配置、障害の特性など)は構成されません。

ワークロードを管理するために、特定のアプリケーションまたはアプリケーションの一部の操作に割り当てるデータベース・サービスを定義できます。サービスを使用して、異なるタイプの作業のワークロードを管理することもできます。

  • Enterprise Managerを使用したサービスの作成
    Oracle Enterprise Manager Cloud ControlまたはOracle Enterprise Manager Database Expressを使用して、サービスを作成できます。
  • SRVCTLを使用したサービスの作成
    SRVCTLは、Oracle Clusterwareで管理されるサービスの作成とOracle Databaseオブジェクトの管理に使用できるコマンドライン・インタフェースです。Oracle Enterprise Manager Database Expressで使用できない機能については、かわりにSRVCTLコマンドを使用できます。

Enterprise Managerを使用したサービスの作成

Oracle Enterprise Manager Cloud ControlまたはOracle Enterprise Manager Database Expressを使用して、サービスを作成できます。

Enterprise Managerを使用してサービスを作成する手順:

  1. Oracle Enterprise Managerで、クラスタ・データベースのホームページに移動します。

    Oracle Enterprise Managerへのログインの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

  2. 「可用性」メニューから、「クラスタ管理データベース・サービス」を選択します。Oracle RACデータベースおよびホストのオペレーティング・システムに対する資格証明を入力または確認し、「続行」をクリックします。

    「クラスタ管理データベース・サービス」ページが表示されます。

  3. 「サービスの作成」をクリックします。

    「サービスの作成」ページが表示されます。

  4. 「サービス名」フィールドに、サービスの名前(DEVUSERSなど)を入力します。
  5. サービスを作成した後でそれを開始するには、「作成後にサービスを開始」を選択します。Oracle Enterprise Manager Cloud Controlで新規サービスをローカルOracle Net Services tnsnames.oraファイルに追加する場合は、「ローカル・ネーミング・パラメータ(tnsnames.ora)ファイルの更新」を選択します。
  6. (ポリシー管理データベースの場合のみ)サービス・タイプに均一またはシングルトンを選択します。
  7. (管理者管理データベースの場合のみ)インスタンスごとに、優先インスタンスであるか、または使用可能インスタンスであるかを選択します。どのような状況でもインスタンスでサービスを実行しない場合は、そのインスタンスの「サービス・ポリシー」に「未使用」を設定します。
  8. 接続数の合計ではなく、経過時間に基づいて接続ワークロードを分散させるには、「サービス・プロパティ」セクションの「接続ロード・バランシングの目標」で「短い」を選択します。それ以外の場合は、「長い」を選択します。
  9. 次のスクリーンショットに示すように、「通知プロパティ」サブヘッダーの下の「ロード・バランシング・アドバイザの有効化」を選択し、このサービスのロード・バランシング・アドバイザを有効化します。「サービス時間」または「スループット」のいずれかのサービス・レベルの目標を選択します。
  10. このサービスをOracle Call Interface(OCI)またはODP.NETアプリケーションで使用してFANを有効化する場合、「通知プロパティ」ヘッダーの下の高速アプリケーション通知の有効化を選択します。
  11. 「サービスしきい値レベル」セクションで、「経過時間」および「CPU時間」メトリックの「警告」および「クリティカル」しきい値(ミリ秒)を入力することにより、サービス・レベルしきい値をオプションで設定できます。
  12. このサービスで使用されるリソースを制御するリソース・プランを使用する場合、「リソース管理プロパティ」セクションの「コンシューマ・グループ・マッピング」リストからコンシューマ・グループの名前を選択します。たとえば、LOW_GROUPというコンシューマ・グループを選択すると、開発ユーザーに与えるデータベース・リソースへの優先度を低くすることができます。

    注意:

    「サービスの編集」ページでは、サービスに対するコンシューマ・グループ名を変更できません。これは、特定のサービスに関連付けられたコンシューマ・グループが複数存在する場合があるためです。ただし、「サービスの編集」ページには、「リソース・コンシューマ・グループ・マッピング」ページへのリンクが含まれており、ここでサービスに対するコンシューマ・グループ・マッピングを変更できます。

  13. 特定のOracle Schedulerジョブ・クラスでこのサービスが使用される場合、「リソース管理プロパティ」の「ジョブ・スケジューラ・マッピング」リストから名前を選択してマッピングを指定できます。
  14. 「OK」をクリックして、サービスを作成します。

参照:

SRVCTLを使用したサービスの作成

SRVCTLは、Oracle Clusterwareで管理されるサービスの作成とOracle Databaseオブジェクトの管理に使用できるコマンドライン・インタフェースです。Oracle Enterprise Manager Database Expressで使用できない機能については、かわりにSRVCTLコマンドを使用できます。 SRVCTLユーティリティの使用方法の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。

SRVCTLを使用してアプリケーション・コンティニュイティまたはトランザクション・ガードのサービスを構成する手順:

  1. アプリケーション・コンティニュイティのサービスを構成するには、サービス属性のfailovertypeをTRANSACTION、commit_outcomeをTRUE、そしてnotificationをTRUEに設定します。また、次に示すアプリケーション・コンティニュイティおよびロード・バランシングのその他のサービス属性に値を設定することもできます。

    • replay_init_time: その時間が経過するまでリプレイを開始しない時間を秒単位(60秒、300秒、600秒など)で指定します。推奨値は900秒です。

    • retention: コミット結果がトランザクション・ガードで保持される時間(秒)を指定します。推奨値は86400 (24時間)です。

    • failoverretry: 各リプレイに対する接続試行回数です。推奨値は30です。

    • failoverdelay: 接続試行間の遅延(秒単位)です。推奨値は10です。

    • clbgoal: 接続ロード・バランシングの場合、ランタイム・ロード・バランシングの使用時はSHORTを使用します。

    • rlbgoal: SERVICE_TIMEに設定します。

    SRVCTLを使用してサービス属性を変更するには、次のようなコマンドを使用します。ここでracdbはOracle RACデータベースの名前を、app1は変更するサービスの名前を表します。

    srvctl modify service -db racdb -service app1 -clbgoal SHORT 
-rlbgoal SERVICE_TIME -failoverretry 30 -failoverdelay 10 
-failovertype TRANSACTION -replay_init_time 1800 -retention 86400 
-notification TRUE commit_outcome TRUE
  2. ポリシー管理されたOracle RACデータベースに対してアプリケーション・コンティニュイティのサービスを作成するには、次のようなコマンドを使用します。ここでracdbはOracle RACデータベースの名前を、app2は変更するサービスの名前を、そしてSvrpool1はサービスが提供されるサーバー・プールの名前を表します。
    srvctl modify service -db racdb -service app2 -serverpool ora.Srvpool1
-clbgoal SHORT -rlbgoal SERVICE_TIME -failoverretry 30
-failoverdelay 10 -failovertype TRANSACTION -replay_init_time 1800 
-retention 86400 -notification TRUE -commit_outcome TRUE
  3. トランザクション・ガードを有効にしてアプリケーション・コンティニュイティを有効にしない場合は、commit_outcome = TRUEにしてサービスを作成します。属性retentionを使用して、履歴を保持する時間(秒)を指定することもできます。また、FANイベントについては属性notificationをTRUEに設定することをお薦めします。

    SRVCTLを使用してサービス属性を変更するには、次のようなコマンドを使用します。ここでracdbはOracle RACデータベースの名前を、app2は作成するサービスの名前を表します。

    srvctl modify service -db racdb -service app2 -commit_outcome TRUE -retention 86400 -notification TRUE

サービスの管理

Oracle Enterprise Managerでサービスを作成および管理できます。また、SRVCTLユーティリティを使用すると、大部分のサービス管理タスクを実行できます。

参照:

Oracle Enterprise Managerを使用したサービス管理について

「クラスタ管理データベース・サービス」ページは、サービス関連のすべてのタスクを開始するマスター・ページです。

このページにアクセスするには、「クラスタ・データベース: メンテナンス」ページに移動し、「サービス」セクションの「クラスタ管理データベース・サービス」をクリックします。このページとページ内のリンクを使用して、次の操作を実行できます。

  • クラスタのサービスのリストの表示。

  • 各サービスが現在実行されているインスタンスの表示。

  • 各サービスのステータスの表示。

  • サービスの作成または編集。

  • サービスの開始または停止。

  • サービスの有効化または無効化。

  • サービスに関するインスタンス・レベルのタスクの実行。

  • サービスの削除。

参照:

「クラスタ管理データベース・サービス」ページの使用

Oracle Enterprise Managerを使用してサービスを管理する際に、「クラスタ管理データベース・サービス」ページを使用します。

「クラスタ管理データベース・サービス」ページにアクセスするには、次の手順を実行します。

  1. Oracle Enterprise Managerで、クラスタ・データベースのホームページに移動します。

    Oracle Enterprise Managerへのログインの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

  2. 「可用性」メニューから、「クラスタ管理データベース・サービス」を選択します。Oracle RACデータベースおよびホストのオペレーティング・システムに対する資格証明を入力または確認し、「続行」をクリックします。

    「クラスタ管理データベース・サービス」ページが表示され、そのクラスタ・データベース・インスタンス上で使用可能なサービスが表示されます。

  3. このページを使用して、次のいずれかのタスクを行います。

    • クラスタのサービス、各サービスが現在実行されているインスタンス、各サービスのステータス、サービスに関連付けられたサーバー・プール、サービスの応答性、およびそのサービスのアラートまたはメッセージのリストの表示。

    • サービスの開始または停止。

    • サービスの接続テスト、または使用中のOracle Net TNS文字列の表示。

    • 「サービスの作成」ページへのアクセス。

    • サービスの編集、削除、有効化または無効化。

    • 各サービスに関連付けられたサーバー・プールの「サーバー・プールの編集」ページへのアクセス。

参照:

新規作成されたサービスをサポートするOracle Netの検証

クラスタにSCANを構成および使用すると、各クライアントでネットワーク設定を変更する必要がなくなります。lsnrctlユーティリティを使用すると、新しいサービスがOracle Netで認識されてデータベース・クライアントから使用可能となっていることを検証できます。

注意:

クラスタ、データベース、データベース・インスタンス、Oracle Automatic Storage Management (Oracle ASM)およびリスナーを管理するユーティリティを使用する際には、管理するオブジェクトやコンポーネントのホーム・ディレクトリにある適切なバイナリを使用します。また、ORACLE_HOME環境変数は、このディレクトリを指すように設定します。

たとえば、lsnrctlを使用してSCANリスナーを管理する場合は、(そのリスナーが実行されている)Gridホームにあるバイナリを使用します。ORACLE_HOME環境変数は、Gridホームの場所に設定します。

新規作成されたサービスがOracle Net Servicesでサポートされていることを確認するには、次の手順を実行します。

  1. 次のコマンドを使用して、ローカル・ノード上のリスナーによって新しいサービスが認識されるかどうかを確認します。
    lsnrctl status LISTENER_SCAN1
    次のような新しいサービスのリストが表示されます。
    Services Summary...
Service "DEVUSERS.example.com" has 2 instance(s).
  Instance "sales1", status READY, has 1 handler(s) for this service...
  Instance "sales2", status READY, has 1 handler(s) for this service...

    新しく作成したサービスの表示名(DEVUSERS.example.comなど)は、接続文字列内で使用するサービス名です。

  2. (オプション)テキスト・エディタを使用して、サービスの優先インスタンスまたは使用可能インスタンスとしてリストされるインスタンスを含む各ノード、およびサービスを使用してデータベースに接続する各クライアントのORACLE_HOME/network/adminディレクトリのtnsnames.oraファイルを変更します。次のようなエントリを追加して各ノードのVIPアドレスを指定します。
    DEVUSERS = 
  (DESCRIPTION = 
    (ADDRESS_LIST = 
      (ADDRESS = (PROTOCOL = TCP)(HOST = docrac1-vip)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = docrac2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    )
  (CONNECT_DATA = (SERVICE_NAME = DEVUSERS.oracle.com))
   )

    前述の例では、パラメータADDRESS_LISTには、サービスの優先インスタンスまたは使用可能インスタンスのいずれかとして構成されたインスタンスを含む各ノードの1つのADDRESSが含まれています。

  3. SQL*PlusおよびSCANを使用してOracle RACデータベースへの接続を試行することにより、Oracle Net Servicesの構成をテストします。
    簡易接続ネーミングの接続識別子は、次の形式です。
    "[//]SCAN[:port]/service_name"

    SCANはクラスタのSCANであり、デフォルトではcluster_name.GNS_sub_domainです。service_nameは、データベースへの接続に使用するデータベース・サービスの名前です。オプションとして、Oracle SCANリスナーが接続をリスニングするTCPポート番号を指定できます。

    たとえば、次のコマンドを使用して、docracクラスタに存在するOracle RACデータベースのDEVUSERSサービスに接続します。これはexample.comドメインに属します。

    $ sqlplus system@\"docrac.example.com/DEVUSERS.example.com\"
Enter password: password

    パスワードを入力すると、Oracle RACデータベースに正常に接続していることを示すメッセージが表示されます。エラー・メッセージが表示された場合は、接続識別子を調査して、ユーザー名、パスワード、およびサービス名が正しく入力されたか、Oracle RAC環境のすべての情報が正しいかを検証します。

参照:

  • 接続ロード・バランシングの理解

  • リスナー構成を表示する方法の詳細は、Oracle Database 2日でデータベース管理者を参照してください。

  • クライアント・コンピュータからOracleデータベースに接続する方法の詳細は、Oracle Database 2日でデータベース管理者を参照してください。

高可用性のためのクライアントの構成

フェイルオーバーを自動化する場合、アプリケーション・クライアントには考慮する主要な要素が3つあります。

  • 1つは、新規のデータベース・インスタンスへの接続が試行される前のTCP/IPネットワーク・タイムアウトの待機を避けるために、障害発生時に接続されているクライアントに障害が発生したことを迅速かつ自動で通知する必要があることです(タイムアウトの範囲は8分から2時間の間で、オペレーティング・システムによって異なります)。Oracle RAC構成では、高速アプリケーション通知(FAN)を使用してJDBCクライアント、OCIクライアントおよびODP.NETクライアントに通知します。FANイベント通知およびコールアウトによって、サイトでの障害発生後にクライアントが自動かつ迅速にリダイレクトできます。

  • 2つ目のクライアント・フェイルオーバーの主要な要素は、障害発生後の新規インスタンスへの新規受信リクエストのリダイレクトで、これはアプリケーション・サービスを使用して実装できます。複数インスタンスのOracle RACデータベースにアプリケーション・サービスを作成してアクティブ化し、1つのインスタンスでサービスが使用できなくなった場合、クライアント接続はサービスを利用できる他のインスタンスにリダイレクトされます。アプリケーションではデータベース・サービスの名前のみを接続文字列で指定する必要があり、インスタンス名を指定する必要はありません。これは、リスナー相互登録を使用することで、クラスタ内のSCANリスナーおよびその他のリモート・リスナーが、接続リクエストの受信時にどのインスタンスが現在サービスを提供しているかを認識しているためです。

  • 3つ目の主要要素はクライアントおよびアプリケーションからの停止のマスキングです。データベース・セッションの停止のマスキングはアプリケーション開発にとって複雑なタスクのため、エラーおよびタイムアウトが頻繁にクライアントに公開されます。アプリケーション・コンティニュイティは、計画済および計画外の停止後に完了していないアプリケーション・リクエストをリプレイすることで、アプリケーションから停止をマスキングしようとします。

アプリケーション・コンティニュイティを利用できないアプリケーションの場合、OCIベース・アプリケーション用のTransparent Application Failover (TAF)と、トランザクション・ガードの2つの追加機能を使用できます。トランザクション・ガードによってアプリケーションでは、最後の移行中トランザクションの結果を認識することで、独自の停止のマスキングを構築できます。

この項では、アプリケーション・クライアントの高可用性の構成について説明します。

  • 可用性の高い接続のためのOracle Net Servicesパラメータの構成
    サービスを使用してデータベースに接続する場合は、高可用性を構成するために設定できる様々なパラメータがあります。
  • 高可用性JDBCクライアントの構成
    接続プール、アプリケーション・コンティニュイティおよびトランザクション・ガードを使用するようにJDBCクライアントを構成することによって、可用性を高くできます。
  • 高可用性OCIクライアントの構成
    Oracle Call Interface (OCI)によって、FANおよびロード・バランシング・アドバイザ・イベントが統合されます。ロード・バランシング・アドバイザを利用するには、OCIセッション・プールを有効にする必要があります。
  • 高可用性ODP.NETクライアントの構成
    Oracle Data Provider for .NET (ODP.NET)は、高速アプリケーション通知(FAN)、ランタイム接続ロード・バランシング、透過的アプリケーション・フェイルオーバー(TAF)およびトランザクション・ガードとの統合を提供しています。

参照:

可用性の高い接続のためのOracle Net Servicesパラメータの構成

サービスを使用してデータベースに接続する場合は、高可用性を構成するために設定できる様々なパラメータがあります。

  • Oracle Databaseに接続する必要があるアプリケーションの場合は、次のOracle Net Servicesパラメータを使用して接続待機時間を最小化します。

    • CONNECT_TIMEOUT: アドレスへの接続を試みるときに待機する時間を制御します

    • RETRY_COUNT: アプリケーションがデータベースへの接続を試みる回数を制御します

    • TRANSPORT_CONNECT_TIME: クライアントがデータベースへのTCP接続を確立するために使用できる時間を制御します

    このパラメータは、tnsnames.oraファイルのタイムアウト・セクションか、接続文字列のDESCRIPTIONレベルで次のように指定できます。

    net_service_name=
 (DESCRIPTION= 
  (CONNECT_TIMEOUT=60)(RETRY_COUNT=3)(TRANSPORT_CONNECT_TIMEOUT=3
  (ADDRESS_LIST=
   (ADDRESS=(PROTOCOL=tcp)(HOST=docrac.example.com)(PORT=1521))
   (CONNECT_DATA=
   (SERVICE_NAME=racdb.example.com)))

    注意:

    • CONNECT_TIMEOUTパラメータは、sqlnet.oraパラメータのsqlnet.OUTBOUND_CONNECT_TIMEOUTに相当し、これをオーバーライドします。

    • サーバーsqlnet.oraファイルにあるsqlnet.outbound_connection_timeoutパラメータは構成しないでください。Oracle Clusterwareの操作に影響を与える可能性があります。

    • TRANSPORT_CONNECT_TIMEOUTパラメータは、sqlnet.oraパラメータのtcp.CONNECT_TIMEOUTに相当し、これをオーバーライドします。

参照:

Oracle Net Servicesのタイムアウトおよび再試行パラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

高可用性JDBCクライアントの構成

接続プール、アプリケーション・コンティニュイティおよびトランザクション・ガードを使用するようにJDBCクライアントを構成することによって、可用性を高くできます。

JDBC接続を使用するアプリケーションでは接続プールを利用できるので、データにアクセスするたびにデータベースへの接続を新しく作成するかわりに、プールの既存の接続を使用できます。Universal Connection Pool(UCP)はJavaベースの接続プールで、すべてのタイプのデータベース(OracleまたはOracle以外)に対する、すべてのタイプの接続(JDBC、LDAP、JCA)をサポートしており、任意の中間層を持っています(OracleまたはOracle以外)。また、TopLinkやBPELといったスタンドアロンのデプロイメントもサポートしています。UCPでは、高速接続フェイルオーバー、ランタイム接続ロード・バランシング、Web Affinity、アプリケーション・コンティニュイティ、およびJDBC Thinドライバ使用時のOracle RACによるトランザクション・ガードなどのOracle Databaseの統合機能もサポートされています。

高速接続フェイルオーバーがない状態で、ノードまたはネットワークが停止しアプリケーションがそのインスタンスに接続を試みると、接続リクエストが数分間ハングし、TCPがタイムアウトに達するまで待機することがあります。統合されたFCF機能を持つ接続プールを使用しない場合でも、接続障害通知機能を構成することで、ご使用のアプリケーションでは引き続きOracle RAC高可用性イベントが通知されます。

アプリケーション・コンティニュイティは、汎用目的のアプリケーションから独立したインフラストラクチャを提供します。これにより、計画済または計画外の停止発生後にアプリケーションからの作業のリカバリが可能になります。停止は、修復、構成変更またはパッチ適用後のシステム、通信またはハードウェア・レイヤーに関連している可能性があります。アプリケーション・コンティニュイティは非トランザクションおよびトランザクションのユーザー・コールをリプレイして、停止が発生しなかったかのようにデータベース・セッションを再構築することで、データベース・セッションをリストアします。アプリケーション・コンティニュイティはこのリプレイをアプリケーション配下で実行するため、停止は、アプリケーションからは遅れた実行のように見えます。

トランザクション・ガードは信頼性の高いプロトコルで、データベース・セッションを使用不能にしている、停止後に処理中だった最後のトランザクションの結果を返すツールです。トランザクション・ガードによって、エンド・ユーザーが不満を抱く不明なエラー、カスタマ・サポート・コールおよび機会損失のコストを削減します。

注意:

  • トランザクション・ガードは、分散トランザクションまたはXAトランザクションをリプレイしません。

  • Universal Connection Pool (UCP)を使用する際は、高速アプリケーション通知と、アプリケーション・コンティニュイティ(オプション)を構成します。接続失敗通知(ConnectionFailureNotification接続プロパティ)は構成しないでください。

参照:

高速接続フェイルオーバーのためのJDBCクライアントの構成

高速接続フェイルオーバーのためにJDBCクライアントを構成するには、次の手順に従います。

Universal Connection Pool (UCP)は、Oracle Notification Serviceが構成され、プールのプロパティsetFastConnectionFailoverEnabledが有効な場合にFANをサブスクライブします。

また、UCPは、ランタイム・ロード・バランシングのための接続に使用される動的データベース・サービスを構成する場合にも、FANロード・バランシング・イベントをサブスクライブします。接続プールは使用されていない接続を作業リクエストに無作為に割り当てるのではなく、受信した最新の情報に従って、最適なサービスを提供する接続を選択します。ノードがハングすると、ランタイム・ロード・バランシングはすぐに、ハング・ノードからクラスタ内の別のノードへ接続を移動します。

高速接続フェイルオーバーのためにJDBCクライアントを構成するには、次の手順を実行します。

  1. Oracle Enterprise Manager Cloud Controlのクラスタ管理サービスに関するページを使用して新規サービスを作成します。サービスの作成の詳細は、「サービスの作成」を参照してください。
  2. UCP DataSourceプロパティFastConnectionFailoverEnabledをTRUEに設定して、JDBCクライアントの高速接続フェイルオーバーを有効化します。また、JDBCアプリケーション内でリモートOracle Notification Services (ONS)サブスクリプションを構成して、Java仮想マシン (JVM)が必要に応じてONSを生成できるようにします。次に例を示します。
    PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
Pds.setConnnectionPoolName("FCFSampleUCP");
pds.setONSConfiguration("nodes=racnode1:4200,racnode2:4200");
pds.setFastConnectionFailoverEnabled(true);
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");

    リモートONSサブスクリプションには、クライアント・アプリケーションでフェイルオーバーに使用できるすべてのホストが含まれている必要があります。

  3. oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STRプロパティをデータ・ソース上でゼロ以外の値に設定します。JDBCクライアントがこのプロパティの設定時に、使用できないホストに接続しようとした場合、接続試行はoracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STRに対して指定した時間にバインドされます。指定した時間が過ぎても接続に成功しない場合、クライアントはアドレス・リストにある次のホストに接続しようとします。ほとんどのインストールに対して十分なプロパティの設定値は3秒です。
  4. 次に示す例のように、SCANとサービス名、SCANリスナーがリスニングするポート(デフォルト値1521を使用していない場合)を含む接続記述子を使用するようにJDBCクライアントを構成します。
    @//docrac.example.com:1525/orcl_JDBC

    注意:

    透過アプリケーション・フェイルオーバー(TAF)処理はFAN ONS処理を妨害する可能性があるため、TAFをJDBCクライアントの高速接続フェイルオーバーで構成しないでください。

    たとえば、データベース初期化パラメータremote_listenerがSCANリスナー・アドレスに設定されている場合、JDBCアプリケーションでは、次のような接続文字列を使用してデータベースに接続します。

    pds.setURL("jdbc:oracle:thin:@(DESCRIPTION = 
 (TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(FAILOVER=ON)(CONNECT_TIMEOUT=60)
 (ADDRESS_LIST =(ADDRESS=(PROTOCOL=tcp)
 (HOST=docrac.example.com)(PORT=1521)) 
 (CONNECT_DATA=(SERVICE_NAME=service_name)))

    JDBCドライバではOracle Netを使用しないため、JDBC Thinドライバを使用する場合は、URLに完全な接続記述子を含む必要があります。

  5. ucp.jarとons.jarがいずれもアプリケーションのCLASSPATHにあることを確認します。

参照:

  • サービスの作成

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

  • JavaでのOracle RACの高速アプリケーション通知のインストールおよび構成の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

  • Javaを使用したデータベース接続でのUniversal Connection Poolの使用の詳細は、『Oracle Universal Connection Pool for JDBC開発者ガイド』を参照してください。

  • ユーザーを認証するメソッドの作成の詳細は、『Oracle Database 2日でJava開発者ガイド』を参照してください。

  • Oracle RACの高速アプリケーション通知のインストールおよび構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

JDBC ThinドライバのプールされていないクライアントのシンプルFANの構成

プールされていないJDBCクライアントのシンプルFANを構成するには、ConnectionFailureNotification接続プロパティを使用します。

JDBCシンプルFANにより、スタンドアロンのOracle JDBC接続はノード障害にすばやく応答できます。この機能により、スタンドアロンのJDBC Thinドライバ接続はFANイベントをリスニングし、接続を閉じたり、ユーザー・アプリケーションにリカバリの迅速な開始を許可することで、ノードのダウン・イベントに対応できます。ノードがダウンした後で、JDBCメソッド・コールがすぐに例外をスローする場合を除き、アプリケーションの動作は変更されません。

プールされていないJDBCクライアントのFANを構成する手順:

  1. 接続障害通知プロパティは、-Dオプションを使用してシステム・プロパティとして設定するか、または接続作成時に接続プロパティの引数に含めることによって設定します。

    システム・プロパティとして設定するには、次のようなコマンドを使用します。

    java -Doracle.jdbc.ConnectionFailureNotification=true

    接続プロパティの引数で設定するには、次のようなコードを使用します。

    Properties props = new Properties();
props.put("ConnectionFailureNotification", "true");
Connection = DriverManager.getConnection(url, props);
  2. ノードのダウン・イベントを受信する転送メカニズムを構成します。Oracle Notification Services (ONS)が転送メカニズムとして選択されている場合、次のコードに示すように、SetONSConfigurationプロパティを使用します。ここで、racnode1およびracnode2は、ONSを実行するクラスタ内のノードを示します。
    props.setONSConfiguration("nodes=racnode1:4200,racnode2:4200");
  3. ons.jarがアプリケーションのCLASSPATHにあることを確認します。

参照:

  • Oracle RACの高可用性フレームワークの概要

  • Oracle RACの高速アプリケーション通知のインストールおよび構成の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

  • ユーザーを認証するメソッドの作成の詳細は、『Oracle Database 2日でJava開発者ガイド』を参照してください。

Javaのアプリケーション・コンティニュイティのためのJDBCクライアントの構成

新規Replayデータ・ソース(oracle.jdbc.replay.OracleDataSource)は、Javaのアプリケーション・コンティニュイティの使用時に接続を取得するためのアプリケーションのフロントエンドとして機能します。

Replayデータ・ソースは、UCPおよびWebLogic Server Active GridLinkの両方のデータ・ソースに対して、新規の物理的なJDBC接続を生成する接続ファクトリとして機能します。Oracle Databaseとの連携においてJDBCリプレイ・ドライバは、データベースの指示に従って、Oracle Database 12cによるクライアント対話中のコールの履歴を保持します。データベース・サービスの欠落で生じるセッションの停止(計画済または計画外)に続いて、JDBCリプレイ・ドライバは非トランザクションおよびトランザクションのデータベース・セッション状態を再構築しようとし、それによって停止が遅れた実行として示されます。
Javaのアプリケーション・コンティニュイティおよびJDBCリプレイ・ドライバを使用するには、Oracle Database 12cクライアントを使用してOracle Database 12cデータベースに接続する必要があります。Javaのアプリケーション・コンティニュイティは次の構成でサポートされています。

  • Oracle JDBC Replayデータ・ソースを使用し、UCPまたはWebLogic Server Active GridLinkのどちらも使用しないJDBCアプリケーション - 通常のスタンドアロンJDBCのケース

  • UCPデータ・ソースを使用中のJDBCアプリケーション - UCPデータ・ソースを使用するように構成されているスタンドアロンまたはサード・パーティのアプリケーション・サーバー

  • WebLogic Server Active GridLinkのみを使用してUCPデータ・ソースを使用しないJDBCアプリケーション - 通常のWebLogic Server J2EEのケース

JDBCリプレイ・ドライバを使用するようにJDBCクライアントを構成する手順:

  1. リプレイが保証されているアプリケーションを使用していることを確認します。
  2. アプリケーションで使用するサービスがまだ存在しない場合は、SRVCTLを使用してそのサービスを作成します。このサービスについてFAILOVER_TYPE属性をTRANSACTION、commit_outcome属性をTRUE、そしてFANの通知をTRUEに設定します。

    サービスの作成の詳細は、「サービスの作成」を参照してください。

  3. 次の例に示すとおり、replayDataSourceオブジェクトを使用して接続要素を構成します。
    replayDataSource rds = PoolDataSourceFactory.getreplayDataSource();
rds.setConnnectionPoolName("replayExample");
rds.setONSConfiguration("nodes=racnode1:4200,racnode2:4200");
rds.setFastConnectionFailoverEnabled(true);
rds.setConnectionFactoryClassName("oracle.jdbc.replay.OracleDataSourceImpl");

Connection conn = replayDataSource.getConnection();

    「高速接続フェイルオーバー用JDBCクライアントの構成」のURLの例を参照してください。

  4. データベースへの接続時に、サービスを提供するすべてのインスタンスにアクセス可能なURLを使用します。可用性の高いデータベース接続の作成の詳細は、「可用性の高い接続のためのOracle Net Servicesパラメータの構成」を参照してください。

注意:

アプリケーション・コンティニュイティを使用するセッションを切断または終了する場合、アプリケーション・コンティニュイティはセッションをリカバリしようとします。リプレイせずにセッションを切断または終了するには、Oracle Database開発ガイドを参照してください。

参照:

  • Javaのアプリケーション・コンティニュイティのためのOracle JDBCの構成の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

  • アプリケーション・コンティニュイティの使用の詳細は、『Oracle Database開発ガイド』を参照してください。

  • Universal Connection Poolでのアプリケーション・コンティニュイティの使用の詳細は、『Oracle Universal Connection Pool開発者ガイド』を参照してください。

トランザクション・ガードを使用するためのJDBC-Thinクライアントの構成

トランザクション・ガードは信頼性の高いプロトコルで、データベース・セッションを使用不能にしている、停止後に処理中だった最後のトランザクションの結果を返すツールです。

トランザクション・ガードによって、ユーザーが不満を抱く不明なエラー、カスタマ・サポート・コールおよび機会損失のコストを削減します。トランザクション・ガードを使用しないと、停止後に操作を再試行しようとするアプリケーションおよびユーザーが、トランザクションを重複してコミットしたり、不適切な順序でトランザクションをコミットすることによって、論理破損が発生することがあります。

参照:

  • トランザクション・ガードで使用するJDBC-Thinクライアントの構成の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

  • トランザクション・ガードの使用の詳細は、『Oracle Database開発ガイド』を参照してください。

高可用性OCIクライアントの構成

Oracle Call Interface(OCI)によって、FANおよびロード・バランシング・アドバイザ・イベントが統合されます。ロード・バランシング・アドバイザを利用するには、OCIセッション・プールを有効にする必要があります。

参照:

  • Oracle Database開発ガイドの「トランザクション・ガードの使用」に関する項

  • Oracle Call Interfaceプログラマーズ・ガイドの透過的アプリケーション・フェイルオーバーの構成に関する項

FAN通知を受信するためのOCIクライアントの構成

Oracle Call Interface (OCI)クライアントはOracle Real Application Clusters (Oracle RAC)高可用性イベントの発生時に通知を受信して応答するように登録できます。

高速アプリケーション通知(FAN)イベントの受信を登録することによって、OCIの接続フェイルオーバーのレスポンス時間が向上し、中断した接続を接続プールおよびセッション・プールから削除できます。この機能はすべてのOCIクライアント・アプリケーションで動作します。

FAN通知を受信するようにOCIクライアントを構成するには、次の手順を実行します。

  1. Oracle Enterprise Cloud Controlのクラスタ管理サービスに関するページを使用してOCIクライアントのサービスを作成します。

    サービスに対する優先インスタンスとしてプライマリ・インスタンスを構成する必要があります。「通知プロパティ」で「OCIおよびODP.NETアプリケーションでの高速アプリケーション通知(FAN)の有効化」を選択します。

  2. OCIクライアント・アプリケーションをスレッド・ライブラリlibthreadまたはlibpthreadにリンクします。
  3. 次の例のように、イベントが発生したかどうかをアプリケーションでチェックする必要があります。
    void evtcallback_fn(ha_ctx, eventhp)
...  
printf("HA Event received.\n");
  if (OCIHandleAlloc( (dvoid *)envhp, (dvoid **)&errhp, (ub4) OCI_HTYPE_ERROR, 
                      (size_t) 0, (dvoid **) 0))
    return;
  if (retcode = OCIAttrGet(eventhp, OCT_HTYPE_EVENT, (dvoid *)&srvhp, (ub4 *)0,
                           OCI_ATTR_HA_SRVFIRST, errhp))
    checkerr (errhp, (sword)retcode;
  else {
     printf("found first server handle.\n");
     /*get associated instance name */
     if (retcode = OCIAttrGet(srvhp, OCI_HTYPE_SERVER, (dvoid *)&instname,
                           (ub4 *)&sizep, OCI_ATTR_INSTNAME, errhp))
       checkerr (errhp, (sword)retcode);
     else
       printf("instance name is %s.\n", instname);
  4. HAイベントの受信後、クライアントおよびアプリケーションでは、高可用性イベントが発生するたびに起動するコールバックを登録できます。次に、例を示します。
    /*Registering HA callback function */
  if (checkerr(errhp, OCIAttrSet(envhp, (ub4) OCI_HTYPE_ENV, 
                             (dvoid *)evtcallback_fn, (ub4) 0,
                             (ub4)OCI_ATTR_EVTCBK, errhp)))
  {
    printf("Failed to set register EVENT callback.\n");
    return EX_FAILURE;
  }
  if (checkerr(errhp, OCIAttrSet(envhp, (ub4) OCI_HTYPE_ENV,
                                (dvoid *)evtctx, (ub4) 0, 
                                (ub4)OCI_ATTR_EVTCTX, errhp)))
  {
    printf("Failed to set register EVENT callback context.\n");
    return EX_FAILURE;
  }
return EX_SUCCESS;

    イベントのコールバックとコンテキストを登録した後、OCIは高可用性イベントが発生するたびに登録された関数を1回コールします。

参照:

トランザクション・ガードを使用するためのOCIクライアントの構成

Oracle Call Interface (OCI)クライアントは、リカバリ可能エラーが発生したときに、トランザクション・ガードを使用して移行中のトランザクションをリプレイできます。

OCIは、高速アプリケーション通知(FAN)メッセージおよび透過的アプリケーション・フェイルオーバー(TAF)をサポートしています。FANは、ノード、データベース、インスタンス、サービスおよびパブリック・ネットワーク・レベルでの停止をOCIベースのアプリケーションに迅速に通知するように設計されています。障害が通知されると、アプリケーションはTAFを使用して、障害が発生した接続を正常なインスタンスで再確立できます。障害のあったトランザクションの結果を確実に判定する機能と、データベース接続のリストア後に現在のトランザクションをリカバリする機能はありませんでした。この項では、トランザクションTAFを有効にするためのOCIの構成方法について説明します。トランザクションTAFは、リカバリ可能エラーが発生したときにアクティブだったトランザクションをリプレイするためのOCIドライバの機能です。

トランザクション・ガードを使用するようにOCIクライアントを構成するには:

  1. Oracle Enterprise Manager Cloud Controlのクラスタ管理サービスに関するページを使用してOCIクライアントのサービスを作成します。
    1. commit_outcome属性にTRUEを設定します。
    2. サービスのフェイルオーバー・タイプにTRANSACTIONを設定します。

    OCIアプリケーションが複数のトランザクションを含むデータベース・リクエストを発行する場合は、SESSION_STATEサービス属性にSTATICを設定する必要もあります。SESSION_STATEにstaticを設定すると、アプリケーション・リクエストの境界に関係なく、TAFコールバックが各データベース・トランザクションで必要な非トランザクション・セッションの状態をリストアできるようになります。

  2. FAN通知を受信するためのOCIクライアントの構成で説明されている手順を実行し、OCIクライアントでFANを有効にします。
  3. OCIアプリケーションで接続プールを使用する場合は、トランザクションの記録がセッションのチェックアウトで開始され、セッションのチェックインでパージされます。

    接続プールを使用しない場合は、次の例に示すようにOCIアプリケーション内で、アプリケーション・リクエストの開始と終了をマークします。アプリケーション・リクエストの開始と終了の間のトランザクション履歴が、再生のために記録されます。

    次の疑似コードは、トランザクション・ガードを使用するようにOCIクライアント・アプリケーションを構成する方法の例を示しています。

    Get_Connection();

Configure_Connection();

/* mark the beginning of an application request; purge session's 
recorded call history  */ 

state = OCI_SESSION_STATE_RESTORABLE; 
OCIAttrSet(usrhp, OCI_HTYPE_SESSION, &state, 0,
           OCI_ATTR_SESSION_STATE, errhp); 
/* process an application request */ 

/* mark end of application request; purge session's recorded call history */
state = OCI_SESSION_STATELESS; 
OCIAttrSet(usrhp, OCI_HTYPE_SESSION, &state, 0, 
           OCI_ATTR_SESSION_STATE, errhp); 

Release_connection();

参照:

高可用性ODP.NETクライアントの構成

Oracle Data Provider for .NET (ODP.NET)は、高速アプリケーション通知(FAN)、ランタイム接続ロード・バランシング、透過的アプリケーション・フェイルオーバー(TAF)およびトランザクション・ガードとの統合を提供しています。

Oracleインスタンスへの接続が予期せず切断された場合は、TAFによって、他のOracleインスタンスへフェイルオーバーがシームレスに試行されます。フェイルオーバーに時間がかかることがあるため、TAFコールバックによってアプリケーションにその遅延を通知する必要がある場合があります。ODP.NETではOracleConnectionオブジェクトのFailoverイベントによってTAFコールバックをサポートします。TAFコールバックを受信するには、イベント・ハンドラ機能をOracleConnectionオブジェクトのFailoverイベントで登録する必要があります。また、接続パラメータenlistはTAFを機能させるためにfalseに設定する必要があります。

ODP.NETの接続プールは、ノードの停止時、およびサーバーの起動時または停止時に表示されるOracle RACからのFAN通知をサブスクライブします。これらの通知に基づいて、ODP.NETの接続プールは、次の作業を実行します。

  • TCP/IPタイムアウトを待機しないようにアクティブなセッションに割り込みます。次に

  • ユーザー・セッションに渡されないように、停止したノードやインスタンス、ネットワークに対して接続されていたアイドル・セッションをクリアします

  • 正常なノードに対して新しい接続を作成します(可能な場合)

ODP.NETは、ランタイム接続ロード・バランシングを提供しアプリケーション・ワークロードのロード・バランスを拡張します。接続プールから使用可能な接続を無作為に選択するのではなく、現在のワークロード情報に基づいて最適なサービスを提供できる接続を選択します。

FAN通知を受信するためのODP.NETクライアントの構成

ODP.NETを有効化する手順は、Fast Connection Failover (FCF)の有効化に接続文字列内でのパラメータの設定が必要という点で、JDBCを有効化する手順と似ています。

FAN通知を受信するようにODP.NETクライアントを構成するには、次の手順を実行します。

  1. Oracle Enterprise Manager Cloud Controlのクラスタ管理サービスに関するページを使用してODP .NETクライアントのサービスを作成します。
    1. 「通知プロパティ」で「OCIおよびODP.NETアプリケーションでの高速アプリケーション通知(FAN)の有効化」を選択します。
    2. 「接続ロード・バランシングの目標」を「長い」に設定します。
  2. 接続時またはデータ・ソース定義時にha events接続文字列属性をtrueに設定して、FAN高可用性イベントをサブスクライブし、ODP.NET接続プールの高速接続フェイルオーバーを有効にします。

    この設定が機能するのは接続プールを使用している場合のみであることに注意してください(pooling属性がtrueの場合のみ)。

    サービスのランタイム・ロード・バランシングの属性をSERVICE_TIMEに設定することで、ランタイム接続ロード・バランシングを有効にすることもできます。

    次のようなコードを使用します。ここで、usernameはアプリケーションがデータベースへの接続に使用するデータベース・ユーザーの名前、passwordはそのデータベース・ユーザーのパスワードです。サービス名はodpservです。

    // C#
using System;
using Oracle.DataAccess.Client;
class HAEventEnablingSample
{
  static void Main()
  {
    OracleConnection con = new OracleConnection();

    // Open a connection using ConnectionString attributes
    // Also, enable "load balancing"
    con.ConnectionString =
      "User Id=username;Password=password;" +
      "Data Source=//docrac.example.com/odpserv;" +
      "Min Pool Size=10;Connection Lifetime=86400;Connection Timeout=60;" +
      "HA Events=true;Incr Pool Size=5;Decr Pool Size=2";

    con.Open();
    // Carry out work against the database here.
    con.Close();
    // Dispose OracleConnection object
    con.Dispose();
    }
 }
  3. ランタイムロード・バランシング・イベントは、SYS.SYS$SERVICE_METRICSキュー内でメッセージとしてパブリッシュされます。アプリケーションでデータベースへの接続に使用するデータベース・ユーザーに対して、このキューのデキュー権限を付与する必要があります。

    次のようなコマンドを使用します。ここで、usernameは.NETアプリケーションがデータベースへの接続に使用するデータベース・ユーザー名です。

    execute
dbms_aqadm.grant_queue_privilege('DEQUEUE','SYS.SYS$SERVICE_METRICS', username);

    この手順で指定されるusernameは、前の手順のUser ID引数に使用されたusernameと同じです。

参照:

  • サービスの作成

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

  • イベント通知とユーザー登録コールバックの詳細は、Microsoft Windows用Oracle Data Provider for .NET開発者ガイドを参照してください。

  • ODP.NETクライアントへの高速アプリケーション通知の構成の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照

ODP.NETクライアントの概要およびトランザクション・ガードの使用

ODP.NETアプリケーションがトランザクション・コミット・リクエストを送信し、ノード、ネットワークまたはデータベース障害などのタイプの障害が発生する場合、ODP.NETはトランザクションがコミットされたかどうかを確定できます。

Oracle Database 12c以降、アプリケーションでは論理トランザクションID (LTXID)を使用して、停止後のデータベース・セッション内でオープンになっている最終トランザクションの結果を判断できます。トランザクション・ガードを使用すると、最後の送信内容がコミットされて完了したか、そうでないかが、停止後にアプリケーションまたはユーザーに戻されるため、エンド・ユーザーの操作性が大幅に向上します。コミットされた結果はコミットされた状態になります。コミットされていない結果はコミットされないままで続行(ユーザーまたはアプリケーションから再送信するなど)が可能です。

トランザクション・ガードを使用しないと、アプリケーションが停止の後に操作を実行しようとして、トランザクションが重複してコミットされ論理破損が発生する可能性があります。

参照:

  • サービスの作成

  • サービスの管理

  • ODP.NETアプリケーションでのトランザクション・ガードの使用例については、Microsoft Windows用Oracle Data Provider for .NET開発者ガイドを参照してください。

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

  • ODP.NETクライアントへの高速アプリケーション通知の構成の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照

前
前 		次
次
目次へ移動
目次 		索引へ移動
索引