1. 2日でReal Application Clustersガイド
  2. サービス、FAN、FCFおよびアプリケーション・コンティニュイティを使用したクライアントの高可用性

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

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

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

Oracle RAC環境をデプロイすると、様々な方法で連続的サービスを実現できます。

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

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

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

  • Oracle Databaseサービスについて
    サービスは、ワークロードを互いに共通の要素を持たないグループに分割します。各サービスは、一般的な属性、サービス・レベルしきい値および優先度でワークロードを表します。
  • データベース・リソース・マネージャについて
    データベース・リソース・マネージャはデータベース機能の1つであり、これを使用すると、ユーザー、アプリケーションおよびサービスに割り当てられたデータベース・リソースを制御できます。
  • Oracle RACの高可用性フレームワークについて
    Oracle RACの高可用性フレームワークを使用すると、実行中の状態にあるデータベース、コンポーネントおよびアプリケーションを常にOracle RACで管理できます。
  • 高速アプリケーション通知(FAN)について
    高速アプリケーション通知(FAN)は、Oracle RACで他のプロセスにクラスタ構成およびサービス・レベルの情報を通知するために使用される高可用性通知メカニズムであり、この情報にはUPイベントやDOWNイベントなどのステータスの変更が含まれます。
  • FANコールアウトについて
    FANコールアウトは、高可用性イベントの発生と同時にOracle RACによって実行されるサーバー側の実行可能ファイルです。
  • 停止をマスキングするためのアプリケーション・コンティニュイティについて
    アプリケーション・コンティニュイティにより、計画イベントと計画外イベントの両方についてデータベースの停止をマスキングできます。
  • ロード・バランシング・アドバイザについて
    ロード・バランシング・アドバイザは、Oracle RACデータベース・インスタンスが提供している現在のサービス・レベルの情報をアプリケーションやクライアントに提供します。
  • 接続ロード・バランシングについて
    Oracle Net接続ロード・バランシングは、データベースへの接続に使用されるサービスをサポートするすべてのインスタンスにユーザー接続を分散します。
  • ランタイム接続ロード・バランシングについて
    ランタイム接続ロード・バランシングはOracle接続プールの機能の1つであり、これを使用すると、ロード・バランシング・アドバイザの情報に基づいて、クライアントの作業リクエストをOracle RACデータベースのインスタンス間で分散させることができます。

関連項目:

「サービスの作成」

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

8.1.1 Oracle Databaseサービスについて

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

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

注意:

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

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

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

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

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

サービスを使用して、様々なタイプの作業のワークロードを管理できます。たとえば、オンライン・ユーザー、バッチ処理、レポートは、それぞれ異なるサービスを使用できます。

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

注意:

このデフォルトのデータベース・サービスをアプリケーションのワークロードに使用しないでください。デフォルトのサービスは、管理のみを目的としています。デフォルトのデータベース・サービスは、DB_NAME、DB_UNIQUE_NAMEまたはPDBNameと同じ名前です。デフォルトのデータベース・サービスを有効または無効にしたり、フェイルオーバーすることはできず、ロード・バランシングはサポートされていません。

「サービスの作成」の説明に従って、サービスを少なくとも1つ作成する必要があります。

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

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

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

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

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

関連項目:

親トピック: データベース・サービスを使用した継続的サービスの実現について

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

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

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

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

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

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

関連項目:

親トピック: Oracle Databaseサービスについて

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

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

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

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

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

関連項目:

親トピック: Oracle Databaseサービスについて

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

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

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

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

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

注意:

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

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

データベース・リソース・マネージャはデータベース機能の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管理者ガイドを参照

親トピック: データベース・サービスを使用した継続的サービスの実現について

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

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

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

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

関連項目:

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

親トピック: データベース・サービスを使用した継続的サービスの実現について

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

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

高可用性アプリケーションの主要な要件の1つとして、システムの重要なコンポーネントに問題が発生した場合に、迅速にアプリケーションへの通知が行われることがあげられます。通知により、接続プールまたはアプリケーション・サーバー・コンテナはイベント処理プログラムを実行できます。FANは、クラスタ・リソースの再編成やリソース変更(リソース量の増減など)への適切なタイミングでの対処となります。

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デーモンがアクティブなノードの構成リストとの間でメッセージを送受信します。このノードのリストは、アプリケーション・サーバー層またはクライアント・ノードなどのクラスタ外のノードを含むこともできます。Oracle Database 12cで、クライアントがTNS接続文字列またはURLを使用してONSデーモンを検出するOracleクライアントの自動構成が導入されました。

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セッション・プールを含む)と使用することもできます。

関連項目:

親トピック: データベース・サービスを使用した継続的サービスの実現について

8.1.5 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ベース)」を参照してください。

関連項目:

親トピック: データベース・サービスを使用した継続的サービスの実現について

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

アプリケーション・コンティニュイティにより、計画イベントと計画外イベントの両方についてデータベースの停止をマスキングできます。

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

データベース・サーバーの計画停止の場合、接続プールはメンテナンス用にスケジュールされたインスタンスからの接続の分配を停止します。新しい接続リクエストは、サービスが使用可能な状態で、まだ機能しているインスタンスにルーティングされます。高速アプリケーション通知(FAN)イベントがOracle接続プールまたはOracle JDBCドライバで受信されるとすぐに、停止サービスへのアイドル接続が削除され、そのインスタンスへの接続は許可されなくなります。

親トピック: データベース・サービスを使用した継続的サービスの実現について

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

アプリケーション・コンティニュイティを使用するには、各種チェックを完了する必要があります。

アプリケーション・コンティニュイティは、アプリケーションが接続の使用方法(接続の確保ではなく、接続を流用して接続プールに返却)に関して正しく記述されていることを前提として機能します。

アプリケーション・コンティニュイティを使用する前に、アプリケーションで使用されるデータベース・サービスの属性を構成する必要があります。統合プールのいずれか(UCP、WLSデータ・ソース)が使用されていない場合は、開始および終了のリクエスト境界を追加する必要があります。接続がOracle接続プールに戻らず、プロパティがピン解除に使用できない場合、リクエスト境界をマークする必要がある場合もあります。

アプリケーション・コンティニュイティを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)以降を使用します。

  • 次のいずれかを使用します。

    • ODP.NET管理対象外ドライバ

    • OCIセッション・プール

    • ユニバーサル接続プール

    • WebLogic Server

    • JDBC Thin Oracleリプレイ・ドライバ

    • Oracle Tuxedo

    • SQL*Plus

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

  • WebLogic Active GridLink Data Source、ユニバーサル接続プール、ODP.NET接続プールまたはOCIドライバには、FANおよびFCFを使用します。あるいは、オプションとして、サード・パーティのJavaコンテナおよびアプリケーション用にFANが組み込まれているJDBC 12.2ドライバを使用します。

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

    アプリケーション・コンティニュイティは、サーバー側で管理されます。クライアント側では、ガベージ・コレクションに対する追加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統合スタックを使用しているときに、アプリケーションの変更なしに(またはわずかな変更で)停止をマスクします。OCIソリューションのアプリケーション・コンティニュイティは、SQL*Plus、OCIセッション・プール、Oracle Tuxedo、Oracle WebLogic Active GridLink、ODP.NET管理対象外ドライバに組み込まれ、OCIドライバとともに使用することもできます。アプリケーションは、アプリケーション・コンティニュイティとともにリリースする前にリプレイに適していることをテストする必要があります。

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

関連項目:

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

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

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

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

関連項目:

親トピック: データベース・サービスを使用した継続的サービスの実現について

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

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

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

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

Oracle Database 12cのデータベース・クライアントは、SCANを使用してデータベースに接続します。SCANは、パブリック・クライアント接続を処理するクラスタ内の複数のリスナーに対応する、複数のIPアドレスに解決できます。SCANは高可用性サポートを提供していないため、SCANでは簡易接続メソッドを使用しないことをお薦めします。かわりに、アプリケーションではOracle Net接続記述子を次の書式で使用する必要があります。 

(DESCRIPTION =
      (CONNECT_TIMEOUT=90) (RETRY_COUNT=20)(RETRY_DELAY=3) (TRANSPORT_CONNECT_TIMEOUT=3)
       (ADDRESS_LIST =
             (LOAD_BALANCE=on)
             (ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521))
             (CONNECT_DATA=(SERVICE_NAME = 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データベースを作成した場合、デフォルトでは、サーバー側のロード・バランシングが構成されて有効化されます。

関連項目:

親トピック: データベース・サービスを使用した継続的サービスの実現について

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

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

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

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

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

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

関連項目:

親トピック: 接続ロード・バランシングについて

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

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

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

  • 短期: 接続ロード・バランシングの目標をSHORTに設定すると、ランタイム接続ロード・バランシングの目標の設定に応じてレスポンス時間またはスループットに基づき、接続が分散されます。短期の接続ロード・バランシングの目標は、短期間の接続を行うアプリケーションに使用します。

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

注意:

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

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

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

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

ランタイム接続ロード・バランシングでは、高いパフォーマンスを実現するために、アプリケーションがロード・バランシング・アドバイザの情報を使用します。OCIセッション・プールおよびODP .NET接続は、ランタイム接続ロード・バランシングをサポートします。Javaアプリケーションの場合には、Universal Connection Pool (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. 作業リクエストを最短のレスポンス時間で処理する接続をクライアントが受信します。

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

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

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

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

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

関連項目

親トピック: データベース・サービスを使用した継続的サービスの実現について

8.2 サービスの作成

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コマンドを使用できます。

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

8.2.1 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)ファイルの更新」を選択します。

    図8-2 Oracle Enterprise Managerの「サービスの作成」ページ

    図8-2の説明が続きます
    「図8-2 Oracle Enterprise Managerの「サービスの作成」ページ」の説明
  6. (ポリシー管理データベースの場合のみ)サービス・タイプに均一またはシングルトンを選択します。

    図8-3 「サービスの作成」ページの「高可用性構成」セクション

    図8-3の説明が続きます
    「図8-3 「サービスの作成」ページの「高可用性構成」セクション」の説明
  7. (管理者管理データベースの場合のみ)インスタンスごとに、優先インスタンスであるか、または使用可能インスタンスであるかを選択します。どのような状況でもインスタンスでサービスを実行しない場合は、そのインスタンスの「サービス・ポリシー」に「未使用」を設定します。
  8. 接続数の合計ではなく、経過時間に基づいて接続ワークロードを分散させるには、「サービス・プロパティ」セクションの「接続ロード・バランシングの目標」で「短い」を選択します。それ以外の場合は、「長い」を選択します。
  9. 次のスクリーンショットに示すように、「通知プロパティ」サブヘッダーの下の「ロード・バランシング・アドバイザの有効化」を選択し、このサービスのロード・バランシング・アドバイザを有効化します。「サービス時間」または「スループット」のいずれかのサービス・レベルの目標を選択します。

    図8-4 「サービスの作成」ページの下部

    図8-4の説明が続きます
    「図8-4 「サービスの作成」ページの下部」の説明
  10. このサービスをOracle Call Interface(OCI)またはODP.NETアプリケーションで使用してFANを有効化する場合、「通知プロパティ」ヘッダーの下の高速アプリケーション通知の有効化を選択します。
  11. 「サービスしきい値レベル」セクションで、「経過時間」および「CPU時間」メトリックの「警告」および「クリティカル」しきい値(ミリ秒)を入力することにより、サービス・レベルしきい値をオプションで設定できます。
  12. このサービスで使用されるリソースを制御するリソース・プランを使用する場合、「リソース管理プロパティ」セクションの「コンシューマ・グループ・マッピング」リストからコンシューマ・グループの名前を選択します。たとえば、LOW_GROUPというコンシューマ・グループを選択すると、開発ユーザーに与えるデータベース・リソースへの優先度を低くすることができます。

    注意:

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

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

関連項目:

親トピック: サービスの作成

8.2.2 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に設定します。

    • session_state: 複数のデータベース・トランザクションを伴うアプリケーション・リクエストに対するアプリケーション・コンティニュイティ・サポートの場合、推奨値はDYNAMICです。

    • drain_timeout: リソース・ドレインの完了まで許容される秒数。指定できる値は、""、0または任意の正の整数です。デフォルト値は空の文字列で、このオプションが設定されていないことを意味します。0の場合、即時にドレインが発生します。

    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 create 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

親トピック: サービスの作成

8.3 サービスの管理

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

関連項目:

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

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

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

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

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

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

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

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

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

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

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

  • サービスの削除。

関連項目:

親トピック: サービスの管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連項目:

親トピック: サービスの管理

8.3.3 新規作成されたサービスをサポートする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環境のすべての情報が正しいかを検証します。

関連項目:

親トピック: サービスの管理

8.3.4 サービスのグループの管理

SRVCTLを使用すると、単一コマンドでサービスのグループを管理できます。

多くの企業が多数のサービスを実行しています。多数のサービスが単一のデータベースまたはインスタンスで提供されることも、多数のデータベースが同じノード上で実行する少数のサービスを提供することもあります。個別のサービスごとにSRVCTLコマンドを実行する必要はなくなり、影響を受けるすべてのサービスのノード名、データベース名、プラガブル・データベース(PDB)名、またはインスタンス名を指定することのみが必要になります。

例8-1 ノードでの全サービスの開始

特定のノードで実行されているサービスをすべて開始するには、次のようなコマンドを使用します。

srvctl start service –node racnode01

例8-2 データベース用の全サービスの開始

データベースでサポートされているサービスをすべて開始するには、次のようなコマンドを使用します。

srvctl start service –db racdb

データベース・インスタンス用のサービスをすべて開始するには、次のようなコマンドを使用します。

srvctl start service –db racdb –inst racdb1

プラガブル・データベース用のサービスをすべて開始するには、次のようなコマンドを使用します。

srvctl start service –db racdb -pdb pdb_region1

例8-3 ノードでの全サービスの停止

切断される前にまだ機能しているインスタンスに移行するための時間を接続に60秒与えて、指定のノードで実行されているサービスをすべて停止するには、次のようなコマンドを使用します。

srvctl stop service –node racnode01 -drain_timeout 60 -stopoption IMMEDIATE

このコマンドは、60秒のドレイン間隔を許容してracnode01で実行されているサービスをすべて停止します。60秒後、IMMEDIATEオプションを使用して、残りのセッションをすべて停止します。60秒のドレイン・タイムアウト設定は、特定のサービスの属性設定をいずれもオーバーライドします。

例8-4 データベース用の全サービスの停止

データベースおよびいずれかのPDBでサポートされているサービスをすべて停止するには、次のようなコマンドを使用します。

srvctl stop service –db racdb –drain_timeout 15 –stopoption IMMEDIATE

このコマンドは、15秒のドレイン間隔を許容してracdbデータベース用のサービスをすべて停止します。15秒後、IMMEDIATEオプションを使用して、残りのセッションをすべて停止します。15秒のドレイン・タイムアウト設定は、特定のサービスの属性設定をいずれもオーバーライドします。

データベース・インスタンス用のサービスをすべて停止するには、次のようなコマンドを使用します。

srvctl stop service –db racdb –inst racdb1 –drain_timeout 15 –stopoption IMMEDIATE

このコマンドは、15秒のドレイン間隔を許容してracdb1データベース・インスタンス用のサービスをすべて停止します。15秒後、IMMEDIATEオプションを使用して、残りのセッションをすべて停止します。15秒のドレイン・タイムアウト設定は、特定のサービスの属性設定をいずれもオーバーライドします。

プラガブル・データベース用のサービスをすべて停止するには、次のようなコマンドを使用します。

srvctl stop service –db racdb –pdb pdb_region1 –drain_timeout 15 –stopoption TRANSACTIONAL

このコマンドは、15秒のドレイン間隔を許容してpdb_region1プラガブル・データベース用のサービスをすべて停止します。15秒後、TRANSACTIONALオプションを使用して、残りのセッションをすべて停止します。15秒のドレイン・タイムアウト設定は、特定のサービスの属性設定をいずれもオーバーライドします。

特定のデータベースについて、停止するサービスのリストを指定することもできます。たとえば、PDBによって提供されるサービスの一部のみを停止するには、次のようなコマンドを使用します。

srvctl stop service –db racdb –pdb pdb_region1 –service “crm_service, hr_service, batch_service” –drain_timeout 60 –stopoption IMMEDIATE

前述のコマンドで、crm_service、hr_serviceおよびbatch_serviceはすべてサービスの名前です。

例8-5 ノードでのすべてのデータベース・インスタンスの停止

ノードのデータベースまたはデータベース・インスタンスをすべて停止するには、次のようなコマンドを使用します。

srvctl stop database -node racnode01 -drain_timeout 60 –stopoption IMMEDIATE -failover –force

-failoverを指定している場合、次のアクションが発生します。

  • –drain_timeout属性と–stopoption属性を考慮して、可能な場合、すべてのサービスが再配置されます。

  • フェイルオーバーできないサービスは、–stopoptionに指定された値に相当するアクションを使用して停止します。

  • 停止中のインスタンスでセッションが受け入れられないように、サービスが停止します。

  • –drain_timeoutで指定された期間が経過するか、ターゲット指定されたサービスを使用して全セッションが切断されると、インスタンスは停止します。

  • インスタンスは、–stopoptionで指定された方法を使用して停止します。

-–forceを指定している場合、次のアクションが発生します。

  • 残りのサービスは、–drain_timeout値および–stopoption値を考慮して停止します。

  • 停止中のインスタンスでセッションが受け入れられないように、サービスが停止します。

  • –drain_timeoutで指定された期間が経過するか、ターゲット指定されたサービスを使用して全セッションが切断されると、インスタンスは停止します。

  • インスタンスは、ABORTオプションを使用して停止します。

例8-6 サービス・のグループの再配置

srvctl relocate serviceコマンドを使用して、サービスのグループをターゲットの宛先(インスタンス、ノード、データベースまたはプラガブル・データベースのいずれか)に再配置できます。次に例を示します。 

srvctl relocate service –database racdb –oldinst racdb01 –newinst racdb02
  -drain_timeout 30 -force

前述のコマンド例では、すべてのサービスがデータベース・インスタンスracdb01からデータベース・インスタンスracdb02に再配置されます。サービスが再配置されるのは、サービス構成で定義されるとおり、ターゲットでそのサービスをサポートできる場合のみです。再配置できないサービスは、元の場所に残されます。

親トピック: サービスの管理

8.4 ユーザーを妨害しない計画メンテナンスの管理

機能を組み合せて使用すると、接続済のセッションへの影響が皆無かそれに近い状態でデータベース・サービスまたはインスタンスを停止できます。

Oracleソフトウェアのアップグレード、パッチ適用、ハードウェアの置換えなど、様々な理由でデータベース・インスタンスを停止することが必要となる場合があります。このトピックの手順を使用すると、ユーザーへの影響が最小限になり、実行中のアプリケーションは中断されません。

サービスは、管理者管理のOracle RACデータベースの1つ以上のインスタンスに割り当てるか、またはポリシー管理のOracle RACデータベースのサーバー・プールに割り当てることができます。Oracle RACで障害が検出されると、Oracle Clusterwareは、障害が発生したコンポーネントを隔離して、依存するコンポーネントをリカバリします。サービスの場合、障害が発生したコンポーネントがインスタンスであれば、Oracle Clusterwareはサービスの可用性の現行レベル(サービスのカーディナリティ)を維持しようとします。サービス定義によりフェイルオーバーが許可され、カーディナリティを維持するためにフェイルオーバーが必要な場合は、フェイルオーバーが発生します。

計画メンテナンスの場合の推奨される方法は、制御期間にわたって高速アプリケーション通知(FAN)対応のOracle接続プールからデータベース接続をドレインすることです。サービス属性の-drain_timeoutおよび-stopoptionはドレイン期間を制御する他、指定の期間内に処理が完了しなかったセッションの処理方法も定義します。処理を完了してプールにチェックインするリクエストまたは接続を閉じるリクエストは、計画メンテナンスの影響を受けない新しい場所に送ることができます。

-drain_timeoutと-stopoptionはいずれもサービスの作成または変更時に定義できるサービス属性です。サービスに属性を設定する利点は、いったん設定すると、それ以降のSRVCTL計画メンテナンス操作すべてに使用されることです。これらの属性をSRVCTLコマンドラインで指定して現在の設定をオーバーライドすることもできます。

FANが構成されたFAN対応プール(Oracle Call Interface (OCI)、Universal Connection Pool (UCP)、データベース常駐接続プーリング(DRCP)、WebLogic ServerまたはOracle Data Provider for .NET)を使用して、ユーザーを妨害せずに計画メンテナンスを管理する手順は次のとおりです。

  1. SRVCTL relocateコマンドを使用してセッションを中断せずに停止中のインスタンスからサービスを再配置するか、UNIFORMサービスを使用している場合は、このインスタンスのサービスを停止します。パラメータ–stopoptionをSRVCTLコマンドラインで使用する場合、srvctl stop serviceまたはsrvctl relocate serviceを使用する際に-forceを使用する必要があります。次に例を示します。 

    srvctl relocate service –database racdb –service myservice –drain_timeout 60
  –stopoption IMMEDIATE –oldinst racdb1 -force

  2. サービスを(srvctl relocate serviceまたはsrvctl stop serviceを発行して)停止すると、FAN DOWNイベントが送信されます。すると、FAN対応プールでアイドル・セッションがすぐにクリアされ、次のチェックインでリリースされるアクティブ・セッションがマークされます。プールは、drain_timeout値(秒)と等しい時間、チェックインの発生を待機します。drain_timeoutがゼロまたはNULLに設定されている場合、ドレインに関する遅延時間はなく、-stopoptionで指定されている方法でサービスをすぐに停止します。

    ドレイン間隔は、サービス属性drain_timeoutを使用するか、SRVCTLコマンドラインで–drain_timeoutを使用して、特定のサービスに設定できます。

    他のインスタンスの既存の接続は使用可能なままで、必要な場合はこれらのインスタンスに新しい接続をオープンできます。

  3. アプリケーションはすべてのセッションを閉じる必要がありますが、実際はこれが常に発生するわけではありません。処理を完了できる時間間隔(-drain_timeout)を設定することをお薦めします。ドレイン・タイムアウト間隔が経過すると、サービスは停止します。

  4. これで、ユーザー・セッションを切断することなく、データベース・インスタンスを停止できます。

  5. メンテナンス操作を実行したら、インスタンスを再起動してサービスを再開します。ランタイム・ロード・バランシングが有効な場合は、リストアされたインスタンスを使用するようにセッションを戻して均衡化します。FAN対応クライアントを使用している場合、サービスのFAN UPイベントがサービスを元の優先インスタンスに徐々に移動します。

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

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

フェイルオーバーを自動化する場合、アプリケーション・クライアントには考慮する主要な要素が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つの追加機能を使用できます。トランザクション・ガードによってアプリケーションでは、最後の移行中トランザクションの結果を認識することで、独自の停止のマスキングを構築できます。

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

関連項目:

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

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

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

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

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

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

    • RETRY_DELAY: 接続に対する後続の再試行間の遅延時間(秒)を指定します。このパラメータは、RETRY_COUNTパラメータと組み合せることで機能します。

    • TRANSPORT_CONNECT_TIME: クライアントがデータベースへのTCP接続を確立するために許容される時間を制御します。

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

    net_service_name=
 (DESCRIPTION= 
  (CONNECT_TIMEOUT=60)(RETRY_COUNT=3)(RETRY_DELAY=2)(TRANSPORT_CONNECT_TIMEOUT=3
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=tcp)(HOST=docrac-scan.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リファレンス』を参照してください。

親トピック: 高可用性のためのクライアントの構成

8.5.2 高可用性のためのアプリケーション・クライアントの構成

可用性が高く、アプリケーション・コンティニュイティおよびトランザクション・ガードを使用するように、Oracle Call Interface (OCI)、Java Database Connectivity (JDBC)およびOracle Data Provider for .NET (ODP.NET)のクライアントを構成できます。

高可用性のための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の統合機能もサポートされています。

高可用性のためのJDBCクライアントの構成の詳細は、次を参照してください。

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

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

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

  • トランザクション・ガードの構成の詳細は、『Oracle Database JDBC開発者ガイド』の「Javaのトランザクション・ガード」を参照してください。

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

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

高可用性のためのOCIクライアントの構成の詳細は、次を参照してください。

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

Oracle Data Provider for .NET(ODP.NET)の接続プールは、サーバーの稼働中または停止中に表示されるOracle RACからのFAN通知をサブスクライブします。これらの通知に基づいて、ODP.NETの接続プールは、次の作業を実行します。

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

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

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

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

高可用性のためのODP.NETの構成の詳細は、次を参照してください。

親トピック: 高可用性のためのクライアントの構成