| Oracle® Real Application Clusters管理およびデプロイメント・ガイド 11g リリース2 (11.2) B56290-06 |
|
 前 |
 次 |
ユーザーまたはアプリケーションがデータベースに接続するときは、接続文字列のCONNECT_DATA部分に指定されたサービスを使用することをお薦めします。データベースが作成されると、自動的に1つのデータベース・サービスが作成されます。多くのインストールでは、この他に必要な作業はありません。データベースを使用したワークロード管理の柔軟性を高めるために、Oracle Databaseでは、複数のサービスを作成し、どのインスタンス(またはインスタンスを含むサービス・プール)でサービスが起動されるかを指定できます。より柔軟なワークロード管理が必要な場合は、この章を読み進めると、サービスで使用できる追加機能を理解できます。
|
注意: この章で説明する機能は、デフォルトのデータベース・サービスでは動作しません。このような機能を活用するには、クラスタ管理サービスを作成する必要があります。自分が作成したサービスのみ管理できます。データベース・サーバーによって自動的に作成されたサービスはデータベース・サーバーによって管理されます。 |
この章では、Oracle Real Application Clusters(Oracle RAC)のワークロードを管理して、アプリケーションで高可用性および高いスケーラビリティを実現する方法について説明します。内容は次のとおりです。
自動ワークロード管理によってワークロードの分散を管理し、ユーザーおよびアプリケーションに対してパフォーマンスを最適化できます。自動ワークロード管理を構成するコンポーネントは次のとおりです。
サービス: 企業のグリッド構想を可能にするために、Oracle Databaseでは、サービスと呼ばれる強力な自動ワークロード管理機能が導入されています。サービスはOracle RACデータベースで定義可能なエンティティで、サービスによって、データベースのワークロードをグループ化し、サービスを提供するために割り当てられた最適なインスタンスに作業をルーティングできます。
コネクション・ロード・バランシング: 要求されたデータベース・サービスを提供するすべてのインスタンスで、受信する接続を均等に分散するOracle Net Servicesの機能。
高可用性フレームワーク: Oracle Databaseでコンポーネントを常に稼働状態に維持できるOracle RACコンポーネント。
イベント通知: アプリケーション・サブスクライバとリスナーによって受信できる、Oracle Clusterwareが生成するイベント。これらのイベントは、次に使用されます。
高速アプリケーション通知(FAN): インスタンス、サービスまたはノードのUPやDOWNイベントなどのクラスタ状態の変更およびワークロード・サービス・レベルの変更についての情報をOracle RACアプリケーションおよびクライアントに提供します。FANには、クライアントにイベントを発行する方法が2つあり、1つは、Oracle Notification Serviceデーモンで、Oracle Application Serverを含むJava Database Connectivity(JDBC)クライアントによって使用され、もう1つは、Oracle Streams Advanced Queueingで、Oracle Call InterfaceおよびOracle Data Provider for .NET(ODP.NET)クライアントによって使用されます。
ロード・バランシング・アドバイザ: データベースとそのインスタンスが提供する現在のサービス・レベルについてアプリケーションに情報を提供します。ロード・バランシング・アドバイザは、サービス用に定義したポリシーに基づいて最適なサービスを得るために、アプリケーション要求の宛先に関する推奨事項をアプリケーションに提供します。ロード・バランシング・アドバイザのイベントは、Oracle Notification Serviceを介してパブリッシュされます。
自動ワークロード・リポジトリ(AWR): サービス・レベルの統計をメトリックとして追跡します。サーバーによって生成されるアラートは、特定のしきい値を超えたり、必要なしきい値に達しない場合、これらのメトリックに対して作成されます。
高速接続フェイルオーバー: これは、FANイベントをサブスクライブすることによって、高速な接続のフェイルオーバーを提供する、Oracleクライアントの機能です。
ランタイム接続ロード・バランシング: アプリケーションが接続にいくつかの作業を完了するように要求すると、データベース・インスタンスによって提供されている現在のサービス・レベルに基づいて、接続プールで高度な接続の割当てを行うOracleクライアントの機能です。
単一クライアント・アクセス名(SCAN): Oracle RACに接続しているクライアントに単一の名前を提供し、この名前は、クラスタのノードを追加または削除しても、クラスタの存続期間中は変更されません。SCANに接続しているクライアントでは、Thin JDBC URLやEZConnectなどの単一の接続文字列を使用でき、ロード・バランシングおよびクライアントの接続フェイルオーバーが実現されます。
Oracle RACデータベース環境および非クラスタOracle Database環境をデプロイして、自動ワークロード管理機能を様々な方法で使用できます。ノード数および使用環境の使用目的と複雑さによって異なりますが、最適な自動ワークロード管理および高可用性構成は、この章で説明する考慮事項を検討して決定してください。
自動ワークロード・リポジトリ(AWR)は、データベースのパフォーマンス統計値を収集、処理および保持します。収集されたデータは、レポートとビューに表示できます。データベースでサービスを使用すると、AWRはサービス・レベルでメトリックを追跡します。
メトリックは、時間、トランザクション、データベース・コールなど、様々な単位に対して測定できます。たとえば、1秒当たりのデータベース・コールの数はメトリックです。サーバーによって生成されるアラートは、ユーザー指定のしきい値を超えたり、必要なしきい値に達しない場合、これらのメトリックに基づいて発行されます。その後で、データベースまたはシステム管理者は、次のように応答できます。
Oracle Databaseリソース・マネージャを使用して、あるサービスのサービス・レベルの優先順位を他のサービスよりも高くする
オーバーロード状態になったプロセスを停止する
サービス・レベル要件を変更する
サービス品質の変更に応答するためにリカバリ例を実施する
AWRメトリックおよびパフォーマンス・アラートを使用すると、サービス・レベルが変更されても、継続的なサービスの可用性を維持できます。また、データベース・サービスによって提供されるサービスの品質を測定できます。
AWRによって、Oracle Clusterwareのワークロード管理フレームワークおよびデータベース・リソース・マネージャにおけるパフォーマンス・データ表現の永続性とグローバル性が保証されます。この情報によって、Oracle Databaseはサービス別にジョブ・クラスをスケジュールしたり、コンシューマ・グループに優先順位を割り当てることができます。必要に応じて、Oracle Enterprise ManagerまたはSRVCTLを使用して、手動でワークロードを再度均等に分散させることができます。一連のセッションを切断しても、サービスを続行させておくこともできます。
|
注意: DBMS_SERVICEパッケージを、Oracle RACデータベースが使用するサービスに使用することはお薦めしません。SRVCTLまたはOracle Enterprise Managerを使用してOracle RAC用のデータベース・サービスを作成します。 |
|
関連項目:
|
この項では、次のサービスのデプロイメントについて説明します。
ワークロードまたはアプリケーションのグループを管理するために、特定のアプリケーションまたはアプリケーションの一部の操作に割り当てるサービスを定義できます。また、作業の種類ごとにサービスとしてグループ化することもできます。たとえば、オンライン・ユーザーはあるサービスを使用し、バッチ処理は別のサービスを使用し、レポートはまた別のサービスを使用してデータベースに接続することができます。
1つのサービスを共有するすべてのユーザーで、サービス・レベルの要件を同じにすることをお薦めします。サービスには個別の特性を定義できるため、各サービスはそれぞれ別々の作業単位にできます。サービスの使用時には、多数のオプションを使用できます。これらのオプションを実装する必要はありませんが、それらを使用すると、アプリケーションのパフォーマンスが最適化できます。
データベースに新しいサービスを作成した場合は、サービスごとに自動ワークロード管理の特性を定義する必要があります。サービスの特性には、次のものが含まれます。
|
関連項目:
|
各Oracle Databaseまたはサービスには、サービス名があります。Oracle Databaseのサービス名は、通常、そのグローバル・データベース名です。クライアントは、サービス名を使用して1つ以上のインスタンスに接続します。サービス名は、システム全体で一意である必要があります。
データベース・サービスに接続するために、クライアントはデータベースの場所とデータベース・サービスの名前を提供する接続記述子を使用します。接続記述子は、リスナーの1つ以上のプロトコル・アドレスと、tnsnames.oraファイルの接続先サービスの接続情報で構成されています。
データベース・サービスのエディション属性であり、そのサービスを使用して起動されるセッションの初期セッション・エディションを指定します。新しいセッションを作成するプログラムで初期セッションが指定されていないと、サービスで指定されたエディション名が使用されます。サービスでエディション名が指定されていないと、初期セッション・エディションはデータベースのデフォルト・エディションになります。
Oracle Clusterwareを使用してデータベースを管理する場合、-yオプションを指定してsrvctl add serviceコマンドを使用してサービスを追加するときに、個々のデータベース・サービス用に起動オプションを構成できます。サービスの管理ポリシーをAUTOMATIC(デフォルト)に設定した場合は、SRVCTLを使用してデータベースを起動するとサービスが自動的に起動されます。管理ポリシーをMANUALに設定した場合、サービスは自動起動されず、SRVCTLを使用して手動で起動する必要があります。MANUALに設定しても、Oracle Clusterwareは、実行中のサービスを監視し、障害が発生すると再起動されます。Oracle RAC 11gリリース2(11.2)より前は、すべてのサービスが、MANUAL管理ポリシーで定義されているかのように動作していました。
CRSCTLを使用したOracle Clusterwareの停止および再起動は障害として扱われ、サービスが実行中の場合は再起動されます。
|
注意: 管理者管理データベースでautomaticサービスを使用する場合、計画されたデータベースの起動中に、優先インスタンスではなく最初のインスタンスでサービスが起動することがあります。 |
ご使用の環境でOracle Data Guardを構成してある場合は、SRVCTLに-lオプションを使用して、各サービスにロールを定義できます。サービスにロールを指定すると、Oracle Clusterwareは、データベース・ロールがそのサービスに指定したロールに一致した場合にのみ自動的にサービスを起動します。有効なロールはPRIMARY、PHYSICAL_STANDBY、LOGICAL_STANDBYおよびSNAPSHOT_STANDBYです。
クラスタ内の複数のデータベースが同じサービス名を提供すると、Oracle RACは、該当するすべてのデータベースにわたってそのサービスへの接続を均等に分散します。これはOracle Data Guardのスタンバイ・データベースおよびアクティブ・データベースに役に立ちますが、サービスへのクライアント接続を特定のデータベースに割り当てる必要がある場合、サービス名はクラスタ内で一意である(他のデータベースによって提供されない)必要があります。
|
関連項目: データベース・ロールの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
管理者管理データベースに対してサービスを定義する場合は、SRVCTLに-rオプションを使用して、そのサービスを通常サポートするインスタンスを定義します。このようなインスタンスを、優先インスタンスといいます。また、SRVCTLに-aオプションを使用して、サービスの優先インスタンスで障害が発生した場合にサービスをサポートする別のインスタンスを定義することもできます。このようなインスタンスを、使用可能インスタンスといいます。
優先インスタンスを指定する場合は、サービスが通常実行されるインスタンスの数を指定します。Oracle Clusterwareは、サービスを構成したインスタンス数で常にサービスが実行されることを確認しようとします。その後は、インスタンス障害またはサービスの計画的な再配置のために、使用可能インスタンスでサービスが実行される場合があります。リストに複数のインスタンスがある場合に、Oracle Clusterwareによってサービスがどの使用可能インスタンスに再配置されるかは制御できません。
Oracle Databaseでは、使用可能インスタンスに移動されたサービスは、優先インスタンスを再起動しても、優先インスタンスには戻りません。これには、次の理由があります。
サービスが、指定した数のインスタンスで実行されている。
現在のインスタンスでサービスを維持することによって、より高度なサービス可用性が提供される。
サービスを最初の優先インスタンスに戻さないことで、2回目の機能停止が回避される。
ただし、FANコールアウトを使用して、優先インスタンスへのフェイルバックを簡単に自動化することもできます。
ポリシー管理データベースに対してサービスを定義する場合は、SRVCTLに-gオプションを使用して、そのデータベースが稼働しているサーバー・プールにサービスを割り当てます。サービスは、-cオプションを使用して、UNIFORM(サーバー・プール内のすべてのインスタンスで実行)またはSINGLETON(サーバー・プール内の単一インスタンスでのみ実行)のいずれかとして定義できます。singletonサービスの場合、Oracle RACはそのサービスがアクティブなサーバー・プール内でインスタンスを選択します。そのインスタンスで障害が発生すると、サービスはサーバー・プール内の別のインスタンスにフェイルオーバーします。1つのサーバー・プールで実行可能なサービスは1つだけです。
|
注意: Oracle Database Quality of Service Management(Oracle Database QoS Management)を使用する場合、そのサーバー・プールの最大サイズが1でないかぎり、サーバー・プールでsingletonサービスを持つことができません。 |
ランタイム接続ロード・バランシングを使用すると、アプリケーションは、ロード・バランシング・アドバイザ・イベントを使用して、ユーザーにより適切なサービスを提供できます。Oracle JDBC、Oracle Universal Connection Pool(UCP)for Java、Oracle Call Interface、Connection Manager(CMAN)およびODP.NETクライアントは、ロード・バランシング・アドバイザ・イベントを利用するために自動的に統合されます。ロード・バランシング・アドバイザは、サービスに対してインスタンスで提供されている現在のサービス・レベルをクライアントに通知します。ロード・バランシング・アドバイザを有効にするには、サービスを作成または変更するときに、SRVCTLに-Bオプションを使用します。
また、そのインスタンスに送るワークロードの推奨量を提示します。最適なサービス品質(単一のトランザクションが完了した効率)または最適なスループット(完了ジョブまたは長時間の問合せが完了した効率)のどちらに基づいてサービスに接続するかは、目標によって決定されます。
Oracle Net Servicesでは、接続ロード・バランシングにより、サービスをサポートしているすべてのインスタンスにユーザー接続を分散できます。各サービスに対して、-jオプションを指定したSRVCTLを使用して、接続時ロード・バランシングの目標を設定し、リスナーにロード・バランシングを使用させる方法を定義できます。接続は、リスナーにセッションベースの統計を使用するように指定するLONG(接続プールやSQL*FORMSなど)、またはリスナーにCPUベースの統計を使用するように指定するSHORTに分類されます。ロード・バランシング・アドバイザが有効な場合、この情報を使用して接続が均等に分散されますが、そうでない場合は、使用状況を使用して接続が均等に分散されます。
分散トランザクション処理アプリケーションには、一意の要件があります。グローバル・トランザクションでOracle RACを使用しやすくするには、サービスに対して、分散トランザクション処理オプション(-x TRUE)を指定してSRVCTLを使用し、分散トランザクション処理のすべての密結合ブランチが同一インスタンス上で実行されるようにします。
Oracle RACは、FANを使用して、構成の変更や、サービスで使用可能な各インスタンスが提供している現在のサービス・レベルをアプリケーションに通知します。OCI、ODP.NETクライアントなど、Oracle Streams Advanced Queuingを使用するクライアントを使用している場合は、FANイベントを受信するために、SRVCTLに-qオプションを使用して、そのクライアントが使用するサービスを有効にして、アラート通知キューにアクセスする必要があります。
Oracle Net Servicesによってインスタンスへの接続が確立されると、クライアントが接続をクローズするか、インスタンスが停止するか、または障害が発生するまで、接続はオープン状態のまま維持されます。接続に透過的アプリケーション・フェイルオーバー(TAF)を構成すると、インスタンスで障害が発生した場合、障害が発生していないインスタンスにセッションは移動されます。
TAFでは、フェイルオーバーが完了すると問合せは再開できますが、INSERT、UPDATE、DELETEなどの他のトランザクションの場合、アプリケーションで、失敗したトランザクションをロールバックして再度送信する必要があります。また、フェイルオーバーが発生したら、セッションのすべてのカスタマイズ(ALTER SESSION文)を再度実行する必要があります。ただし、TAFでは、ワークロードが変化しても、通常処理の間は接続が移動されません。
サービスはTAFのデプロイメントを簡素化します。サービスのTAFポリシーを定義でき、このサービスを使用するすべての接続によって、自動的にTAFが有効になります。これには、クライアント側の変更は必要ありません。サービスのTAF設定は、クライアントの接続定義内のTAF設定よりも優先されます。
サービスのTAFポリシーを定義するには、次の例に示すようにSRVCTLを使用しますが、ここで、サービス名はtafconn.example.com、データベース名はCRMです。
$ srvctl modify service -d crm -s tafconn.example.com -P BASIC -e SELECT -z 5 -w 120
また、FAILOVER_METHOD(-mオプション)、FAILOVER_TYPE(-eオプション)などを定義することによって、サービスのすべてのユーザーに対して1つの透過的アプリケーション・フェイルオーバー(TAF)・ポリシーを指定することもできます。さらに、TAFポリシーでは、障害が発生したセッションがサービスへの再接続を試行する回数(-zオプション)、および再接続を再試行する間の待機時間(-wオプション)も定義できます。
TAFが有効なOracle Call Interfaceアプリケーションでは、高速接続フェイルオーバーのためにFAN高可用性イベントを使用します。
|
関連項目: TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
サービス名は複数のデータベース・インスタンスを識別することができ、インスタンスは複数のサービスに属することができます。Oracle RACデータベースのサービスは、次に説明するように、いくつかのデータベース機能で使用されます。
サービスを定義すると、リソース・プロファイルは自動的に作成されます。リソース・ファイルには、Oracle Clusterwareによるサービスの管理方法と、PREFERREDインスタンスが停止した場合にサービスがフェイルオーバーされるインスタンスが定義されています。また、リソース・プロファイルでは、インスタンスおよびデータベースに対するサービスの依存性も定義します。この依存性の情報によって、データベースが停止した場合に、インスタンスおよびサービスが自動的に正しい順序で停止されます。
サービスはリソース・マネージャと統合されており、リソース・マネージャでは、サービスを使用してインスタンスに接続するユーザーによって使用されるリソースを制限できます。リソース・マネージャでは、コンシューマ・グループをサービスにマッピングできるため、そのサービスを使用してインスタンスに接続しているユーザーは、指定されたコンシューマ・グループのメンバーになります。
自動ワークロード・リポジトリ(AWR)によって生成されるメトリック・データは、様々なグループ(イベント、イベント・クラス、セッション、サービス、表領域メトリックなど)に編成されます。通常、Oracle Enterprise ManagerまたはAWRレポートを使用してAWRデータを表示します。
|
関連項目: AWRレポートの生成と表示の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
デフォルトでは、Oracle RAC環境で、パラレルで実行されるSQL文はクラスタ内のすべてのノードで実行できます。このクロスノードまたはノード間パラレル実行を適切に実現するには、ノード間パラレル実行によってインターコネクト・トラフィックが増大する可能性があるため、Oracle RAC環境でのインターコネクトのサイズが適切である必要があります。ノード間パラレル実行を制限するには、初期化パラメータPARALLEL_FORCE_LOCALを使用してOracle RAC環境でパラレル実行を制御します。このパラメータをTRUEに設定すると、パラレル実行サーバーは、SQL文が開始されたのと同じOracle RACノードからのみ実行できます。
サービスを使用して、パラレルSQL操作に使用できるインスタンスの数を制限します。デフォルトのデータベース・サービスを使用すると、パラレルSQL操作は、使用可能なすべてのインスタンスで実行できます。それぞれが1つ以上のインスタンスで構成されるサービスを任意の数だけ作成できます。パラレルSQL操作が開始されると、パラレル実行サーバーは、最初のデータベース接続で使用された特定のサービスを提供するインスタンス上でのみ起動されます。
PARALLEL_INSTANCE_GROUPは、Oracle RACパラメータで、サービスとともに使用すると、パラレル問合せ操作を、限られた数のインスタンスに制限できます。パラレル問合せ操作を、限られた数のインスタンスに制限するには、PARALLEL_INSTANCE_GROUP初期化パラメータにサービスの名前を設定します。これは、パラレル・リカバリやGV$問合せの処理などの他のパラレル操作には影響しません。
Oracle Streamsでは、様々な点でOracle RAC機能が利用されます。Oracle StreamsがOracle Real Application Clusters(Oracle RAC)環境で構成されると、各キュー表には所有インスタンスが割り当てられます。キュー表をホストするインスタンスに障害が発生しても、Oracle RACデータベースの別のインスタンスがキュー表の所有インスタンスになるため、Oracle Streamsは継続して稼働できます。
また、Oracle RACデータベースでは、バッファ・キューごとにサービスが作成されます。インスタンスの起動や停止などのために所有権が切り替わる場合、このサービスは常に、宛先キューの所有者インスタンスで実行され、このキューの所有権に従います。このサービスは、キューからキューへの伝播で使用されます。
|
関連項目: 『Oracle Streams概要および管理』 |
デフォルトでは、Oracle RACデータベースに特殊なOracle Databaseサービスが作成されます。このデフォルトのサービスは、Oracle RAC環境のすべてのインスタンスで常に使用可能です(制限モードのインスタンスを除く)。このサービスまたはサービスのプロパティは、変更できません。また、データベースでは、次の2つの内部サービスがサポートされています。
いずれの内部サービスも、すべての自動ワークロード管理機能をサポートしています。これらの内部サービスは、停止または無効化できません。
|
注意: 明示的に管理できるのは、自分が作成するサービスにかぎられます。データベースの機能によって内部サービスが作成される場合、そのサービスはこの章の情報を使用して管理できません。 |
Oracle Net Servicesでは、Oracle RAC構成内のインスタンス間でクライアント接続を均等に分散する機能を使用できます。実装可能なロード・バランシングには、クライアント側とサーバー側の2種類のロード・バランシングがあります。クライアント側のロード・バランシングでは、接続要求をリスナー間で均等に分散します。サーバー側のロード・バランシングでは、SCANリスナーがロード・バランシング・アドバイザを使用して、現在サービスを提供している最適なインスタンスに接続要求を割り当てます。
Oracle RACデータベースのクライアント接続では、両方の接続時ロード・バランシングを使用する必要があります。
|
関連項目: 両方のタイプのロード・バランシングの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
クライアント側のロード・バランシングは、パラメータLOAD_BALANCE=ONを設定して、クライアントの接続定義(tnsnames.oraファイルなど)に定義します。このパラメータをONに設定した場合は、Oracle Databaseによってアドレス・リストから無作為にアドレスが選択されて、そのノードのリスナーに接続されます。これによって、クラスタ内で使用可能なSCANリスナー間で、クライアント接続が均等に分散されます。
SCANリスナーは、最もロードされていない、要求されたサービスを提供しているインスタンスのローカル・リスナーに接続要求をリダイレクトします。接続要求を受信したリスナーは、要求されたサービスを提供するとリスナーが認識しているインスタンスにユーザーを接続します。リスナーがサポートしているサービスを確認するには、lsnrctl servicesコマンドを実行します。
クライアントがSCANを使用して接続する場合、Oracle NetはSCANに対して定義された3つのIPアドレスの間でクライアント接続要求のロード・バランシングを自動的に行います。ただし、EZConnectを使用している場合は行いません。
クライアント側でSCANと非SCAN VIPの両方を使用する場合は、Oracle RACデータベースでSCAN VIPとノードVIPのリストを合わせたものにREMOTE_LISTENERパラメータを設定します(SCAN VIPとノードVIPをすべて含むために、REMOTE_LISTENERパラメータを手動で更新する必要があります)。
2ノード・クラスタのtnsnames.oraファイルにSCANおよびノードVIP情報を追加するための形式の例を次に示します。
LISTENERS_db_unique_name = (ADDRESS_LIST = (ADDRESS=(PROTOCOL=TCP)(HOST=scan_VIP1)(PORT = scan_port_number)) (ADDRESS=(PROTOCOL=TCP)(HOST=scan_VIP2)(PORT = scan_port_number)) (ADDRESS=(PROTOCOL=TCP)(HOST=scan_VIP3)(PORT = scan_port_number)) (ADDRESS = (PROTOCOL = TCP)(HOST = node_VIP_name1-vip)(PORT = listener_port_number)) (ADDRESS = (PROTOCOL = TCP)(HOST = node_VIP_name2-vip)(PORT = listener_port_number)) )
|
注意: 追加するノードVIPの数は、クラスタ内のノード数と対応している必要があります。 |
次のSQL*Plusコマンドを実行します。
SQL> ALTER SYSTEM SET REMOTE_LISTENER = 'LISTENERS_db_unique_name' SCOPE=BOTH SID='*'
または、次のSQL*Plusコマンドを実行して、2ノード・クラスタを更新することもできます。
SQL> ALTER SYSTEM SET remote_listener = ' (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=scan_VIP1)(PORT = scan_port_number)) (ADDRESS=(PROTOCOL=TCP)(HOST=scan_VIP2)(PORT = scan_port_number)) (ADDRESS=(PROTOCOL=TCP)(HOST=scan_VIP3)(PORT = scan_port_number)) (ADDRESS=(PROTOCOL=TCP)(HOST=node_VIP_name1-vip)(PORT = listener_port_number)) (ADDRESS=(PROTOCOL=TCP)(HOST=node_VIP_name2-vip)(PORT = listener_port_number)))' SCOPE=BOTH SID=*
クライアント側のロード・バランシングに加えて、Oracle Net Servicesには接続フェイルオーバーが含まれています。リスト内の選択されたアドレスからエラーが戻されると、Oracle Net Servicesによってリストの次のアドレスが試行され、接続が成功するか、またはリスト内に試行するアドレスがなくなるまで続けられます。SCANの場合、クライアントに失敗を返す前に、Oracle Net Servicesによって3つのアドレスすべてが試行されます。EZConnectとSCANを併用した場合、この接続のフェイルオーバー機能が使用できます。
可用性を高めるために、Oracle Netがエラーを戻すまでにリスナーからの応答を待機する時間のタイムアウトを指定できます。このタイムアウト・パラメータを設定する方法は、クライアント・アクセスのタイプによって異なります。
次のようにoracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STRプロパティを設定することによって、遅延を回避できます。
Properties prop = new Properties (); prop.put (oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR, "" + (1 * 1000)); // 1 second dbPools[ poolIndex ].setConnectionProperties ( prop );
パラメータの値は、ミリ秒単位で指定します。このため、アプリケーションが再度接続を試みた場合のタイムアウトを500Msに短縮できます。
DBCAを使用してOracle RACデータベースを作成すると、次の処理が自動的に実行されます。
サーバー側のロード・バランシングの構成および有効化
リモート・リスナー・パラメータのSCANリスナーへの設定(注意: DBCAを使用しない場合は、REMOTE_LISTENERデータベース・パラメータをscan_name:scan_portに設定する必要があります。)
サーバー上のtnsnames.oraファイルにおけるクライアント側のロード・バランシング接続定義のサンプルの作成
FAN、高速接続フェイルオーバーおよびロード・バランシング・アドバイザは、正確な接続時ロード・バランシング構成(サービスに対する接続時ロード・バランシングの目標の設定など)に基づいて処理を実行します。接続時ロード・バランシングでは、LONGまたはSHORTのいずれかの目標を使用できます。これらの目標の特性は、次のとおりです。
LONG: LONG接続時ロード・バランシング方式は、長時間の接続を使用するアプリケーションに使用します。通常、接続プールおよびSQL*Formsセッションで使用します。LONGは、デフォルトの接続時ロード・バランシングの目標です。次の例では、srvctlユーティリティを使用してサービスbatchconnを変更し、長時間セッション用の接続時ロード・バランシングの目標を定義しています。
srvctl modify service -d db_unique_name -s batchconn -j LONG
SHORT: SHORT接続時ロード・バランシング方式は、短時間の接続を使用するアプリケーションに使用します。FANと統合された接続プールを使用する場合は、CLB_GOALをSHORTに設定します。次の例では、SRVCTLを使用して、サービスoltpappを変更し、接続時ロード・バランシングの目標にSHORTを設定しています。
srvctl modify service -d db_unique_name -s oltpapp -j SHORT
この項では、FANの詳細を説明します。内容は次のとおりです。
FANは、UPまたはDOWNイベントなどのサービス・ステータスの変更を含む、構成情報およびサービス・レベルの情報を他のプロセスに通知するためにOracle RACが使用する通知メカニズムです。アプリケーションはFANイベントに応答して、すぐにアクションを実行できます。FANのUPイベントおよびDOWNイベントは、インスタンス、サービスおよびノードに適用できます。
クラスタの構成が変更されて、クラスタ内で状態の変更が発生した場合、Oracle RACの高可用性フレームワークは、ただちにFANイベントを発行します。アプリケーションでは、データベースをポーリングして問題を検出するまで待機するかわりにFANイベントを受信して、ただちにアクションを実行できます。FANを使用すると、インフライト・トランザクションをただちに終了でき、インスタンスの失敗時にクライアントに通知することができます。
また、FANは、ロード・バランシング・アドバイザ・イベントも発行します。アプリケーションでFANのロード・バランシング・アドバイザ・イベントを使用して、現在、クラスタ内で最適なサービス品質を提供しているインスタンスに作業要求を割り当てることができます。FANイベントは、次の3つの方法で使用できます。
Oracle統合クライアントを使用すると、プログラムを変更せずにアプリケーションでFANを使用できます。FANイベントの統合クライアントには、Oracle Database JDBC、Oracle Database ODP.NETおよびOracle Database Oracle Call Interfaceが含まれています。また、統合クライアントには、TAFを使用するアプリケーションが含まれます。ロード・バランシング・アドバイザのFANイベントを使用するには、統合OracleクライアントがOracle Database 10gリリース2(10.2)以上である必要があります。(TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。)
JDBCおよびOracle RAC FAN Application Programming Interface(API)を使用するか、Oracle Call Interfaceでコールバックを使用すると、アプリケーションはFANをプログラムから使用して、FANイベントをサブスクライブしたり、イベントの受信時にイベント処理アクションを実行することができます。
サーバー側のコールアウトを使用して、データベース層にFANを実装できます。
DOWNイベントでは、障害が発生しているインスタンスまたはノードに対するセッションを終了できるため、アプリケーションへの影響を最小限に抑えることができます。未完了のトランザクションは終了され、ただちにアプリケーションのユーザーに通知されます。接続を要求しているアプリケーション・ユーザーは、使用可能インスタンスにのみ割り当てられます。UPイベントでは、サービスおよびインスタンスが起動された場合に新しい接続を作成して、新しく使用可能になったリソースをアプリケーションでただちに使用できます。また、サーバー側のコールアウトによって、FANを使用して、次の操作を実行できます。
ステータス情報を記録します。
リソースの起動に失敗した場合に、DBAへの通知またはサポート・チケットの発行を行います。
サービスと同じ場所に配置することが必要な、依存する外部アプリケーションを自動的に起動します。
ノードの障害などによって、ポリシー管理データベースに使用できるインスタンスの数が減少した場合、リソース・プランを変更するか、またはサービスを停止します。
必要に応じて、サービスを管理者管理データベースの優先インスタンスに自動的にフェイルバックします。
FANイベントは、Oracle Notification ServiceとOracle Streamsアドバンスト・キューイングを使用して発行されます。発行メカニズムは、Oracle RACのインストール時に自動的に構成されます。
Connection Manager(CMAN)およびOracle Net ServicesリスナーはFANイベントと統合されます。これによって、リスナーとCMANは、障害の発生したインスタンスから提供されているサービスの登録解除をただちに行ったり、障害の発生したインスタンスに接続要求を誤って送信しないようにできます。
サービスの接続時ロード・バランシングの目標にCLB_GOAL_SHORTを指定している場合、リスナーは、接続時ロードを均等に分散する際に、ロード・バランシング・アドバイザを使用します。ロード・バランシング・アドバイザが使用可能であった場合、リスナーで使用されるメトリックはさらに詳細に制御できます。
Oracle Databaseでは、サービスの可用性の維持に重点が置かれています。Oracle RACのOracleサービスは、1つ以上のインスタンス間で負荷を共有しながら、継続的に使用できるように設計されています。Oracle RACの高可用性フレームワークでは、Oracle Clusterwareおよびリソース・プロファイルを使用して、サービスの可用性を維持します。
Oracle RACの高可用性フレームワークは、データベースおよびデータベースのサービスを監視し、FANを使用してイベント通知を送信します。Oracle Clusterwareは、ビジネス・ルールとサービス属性に従って、サービスをリカバリするか、サービスを均等に分散します。
サービスは、管理者管理のOracle RACデータベースの1つ以上のインスタンスに割り当てるか、またはポリシー管理データベースのサーバー・プールに割り当てることができます。Oracle RACで障害が検出されると、Oracle Clusterwareは、障害が発生したコンポーネントを隔離して、依存するコンポーネントをリカバリします。障害が発生したコンポーネントがインスタンスであった場合、Oracle Clusterwareはサービスをクラスタ内の使用可能インスタンスに再配置します。FANイベントはOracle Databaseアーキテクチャ内の様々なレベルで発生し、Oracle Notification ServiceおよびOracle Streams AQを使用して発行される可能性があります。また、FANコールアウトを使用して通知をプログラミングすることもできます。
障害ノードのサービスが停止すると、稼働を続けるノードから通知が発生します。Oracle RAC環境内でサービスを提供するインスタンスの位置および数は、アプリケーションに対して透過的です。再起動およびリカバリは自動的に実行され、データベースのみでなく、リスナーやOracle Automatic Storage Management(Oracle ASM)プロセスなどのサブシステムも再起動されます。FANコールアウトを使用して、障害管理システムに障害をレポートしたり、修復ジョブを開始することができます。
1つ以上のインスタンスまたはノードを隔離する必要がある修復、アップグレードおよび変更のために、Oracle RACでは、アプリケーション・ユーザーに対するサービスの中断の影響を最小限に抑えて、サービスを再配置、無効化および有効化するインタフェースを使用できます。サービスを再配置する場合は、サービスが一時的に別のインスタンスで実行されるようにする必要があります。サービスを無効にすると、サービスはすべてのデータベース・インスタンスで停止され、使用できなくなります。無効化されたサービスは、自動的に再起動することはありません。操作を完了したら、サービスを通常の操作に戻すか、またはサービスを有効にしてから、再起動することができます。
データベースを手動で停止すると、依存性のために、そのデータベースのすべてのサービスも自動的に停止されます。データベースを手動で再起したときにサービスが自動的に起動するようにする場合は、サービスの管理ポリシーをautomaticに設定する必要があります。サービスではなく、データベースの1つのインスタンスのみを停止する場合は、-fオプションを指定してsrvctl stop instanceコマンドを使用できます。このコマンドで-fオプションを使用すると、そのインスタンスで実行されていたデータベース・サービスは、可能な場合は別のインスタンスにフェイルオーバーされます。
表5-1にFANイベント・タイプ、表5-2にイベント・パラメータの名前/値のペアを示します。次の例で示すように、イベント・タイプは常に最初のエントリ、タイムスタンプは常に最後のエントリです。
FAN event type: SERVICEMEMBER VERSION=1.0 service=fantest database=ractest instance=rac1host=node01 status=up reason=FAILURE card=1 timestamp=2010-07-02 22:06:02
表5-1 FANイベント・タイプ
| イベント・タイプ | 注意 |
|---|---|
|
|
|
表5-2 イベント・パラメータの名前/値のペアと説明
| パラメータ | 説明 |
|---|---|
|
|
イベント・レコードのバージョン。リリース変更の識別に使用します。 |
|
|
サービスをサポートする一意のデータベース名。 |
|
|
サービスをサポートするインスタンスの名前。 |
|
|
サービスまたは停止ノードをサポートするノードの名前。クラスタ同期サービス(CSS)ノード名に該当します。 |
|
|
サービス名。 |
|
|
値は、 注意:
|
|
|
注意:
|
|
|
現在アクティブなサービス・メンバーの数。すべての 次は、 SERVICEMEMBER VERSION=1.0 service=myServ.company.com database=prod instance=PROD1 host=stru09 status=up reason=USER card=1 timestamp=2010-07-27 14:43:03 |
|
|
次は、 NODE VERSION=1.0 host=stru09 incarn=175615351 status=down reason=member_leave timestamp=27-Jul-2010 14:49:32 |
|
|
通知イベントを順序付ける際に使用するローカル・タイム・ゾーン。 |
表5-3に示すように、FANイベント・レコード・パラメータのいくつかには、デフォルトのネームスペースUSERENVを使用しているSYS_CONTEXTファンクションによって戻される値に対応する値があります。
FANコールアウトは、サーバー側の実行可能ファイルで、高可用性イベントが発生した際に、ただちにOracle RACで実行されます。FANコールアウトを使用すると、クラスタ構成でイベントが発生した場合に、次のようなアクティビティを自動的に実行できます。
障害追跡チケットの発行
ページャへのメッセージ送信
電子メールの送信
サーバー側のアプリケーションの起動および停止
各イベント発生時にイベントを記録したアップタイム・ログの維持
優先度の高いサービスがオンラインになった場合の優先度の低いサービスの再配置
FANコールアウトを使用するには、Oracle Clusterwareを実行しているすべてのノードのGrid_home/racg/usrcoディレクトリに実行可能ファイルを配置します。実行可能ファイルは、別のプログラムからオプションの引数でコールされた場合、スタンドアロンで実行可能である必要があります。Grid_home/racg/usrco/callout.shコールアウトのファイルの例を次に示します。
#! /bin/ksh FAN_LOGFILE= [your path name]/admin/log/'hostname`_uptime'.log echo $* "reported="'date' >> $FAN_LOGFILE &
前述の例では、次のような出力が生成されます。
NODE VERSION=1.0 host=sun880-2 incarn=23 status=nodedown reason= timestamp=08-Oct-2004 04:02:14 reported=Fri Oct 8 04:02:14 PDT 2004
表5-3に示すように、FANイベント・レコードの内容は、データベースにログオンしているユーザーの現行のセッションに該当します。また、Oracle Call Interface接続ハンドルと(OCIAttrGet()を使用した)記述子属性を使用すると、ユーザー環境(USERENV)情報も使用できます。この情報を使用すると、FANイベントのデータに該当するセッションでアクションを実行できます。
|
関連項目:
|
すべてのユーザー・コールアウト・イベントはOracle Clusterwareによって発生します。ノードが停止したり、リソース(VIPやデータベースなど)によって状態やプロパティが変更されると、Oracle Clusterwareはその影響に関するOracle Notification Serviceイベントを送信します。このイベントは、常に、少なくともクラスタ内の1つのノードにプッシュされる必要があり、それを確実にする最も効果的な方法は、ユーザー・コールアウトがOracle Notification Serviceリソースのエージェント内からのOracle Notification Serviceイベントをリスニングするようにすることです。
Oracle Notification Serviceリソースが特定のノードで停止した場合は、そのノードでのイベントが消失するため、ユーザー・コールアウトは発行されません。Oracle Notification Serviceイベントは、Oracle Notification Serviceリソースのエージェント内から読み取られ、変換され、ユーザー・コールアウトにポストされます。
通常、イベントはそれが発生したノード上のユーザー・コールアウトにポストされるだけです。たとえば、node1のデータベースが停止した場合、コールアウトはnode1のみにポストされます。唯一の例外は、ノード停止とVIP停止イベントで、これらのイベントは、発生した場所にかかわらず、すべてのノードにポストされます。
|
注意: Oracle Database 11gリリース2(11.2.0.2)では、DATABASEまたはINSTANCEのイベント・タイプに対するserviceおよびdatabaseの2つの属性には、データベース・ドメイン名を含みません。 |
この項では、ロード・バランシング・アドバイザについて説明します。内容は次のとおりです。
ロード・バランシングは、使用可能なすべてのOracle RACデータベース・インスタンス間で作業を分散します。接続プールを使用するなどの場合、アプリケーションでは、特定のサービスを提供するインスタンス間をまたがって実行される、永続的な接続を使用することをお薦めします。永続接続を使用すると、接続が作成される頻度は低く、長期間存在します。作業は頻繁にシステムに送られ、この接続を利用し、比較的短時間存続します。ロード・バランシング・アドバイザは、受信した作業に対して最適なサービス・クオリティを提供するインスタンスにその作業を転送する方法についてのアドバイスを提供します。これにより、後で作業を再配置する必要性が最小化されます。
ロード・バランシング・アドバイザまたはランタイム接続ロード・バランシングの目標を使用することで、フィードバックはシステムに組み込まれます。作業は、システム全体で最適なサービス時間が実現されるようにルーティングされ、システムの状態変化に透過的に対応します。安定した状態のシステムでは、Oracle RACのすべてのインスタンスでスループットが向上した状態が維持されるようになります。
ロード・バランシング・アドバイザを使用できる標準アーキテクチャには、接続時ロード・バランシング、トランザクション処理モニター、アプリケーション・サーバー、接続コンセントレータ、ハードウェアおよびソフトウェアのロード・バランサ、ジョブ・スケジューラ、バッチ・スケジューラおよびメッセージ・キューイング・システムが含まれます。これらすべてのアプリケーションでは、作業を割り当てることができます。
ロード・バランシング・アドバイザは、リスナー、JDBCユニバーサル接続プール、ODP.NET接続プールなどの主要なOracleクライアントとともにデプロイされます。また、サードパーティ・アプリケーションは、JDBCとOracle RAC FAN APIを使用するか、またはOracle Call Interfaceでコールバックを使用して、ロード・バランシング・アドバイザ・イベントをサブスクライブすることもできます。
ロード・バランシングを有効にする各サービスにサービス・レベルの目標を定義して、ロード・バランシング・アドバイザを使用するように環境を構成できます。サービス・レベルの目標を構成すると、ロード・バランシング・アドバイザが有効になり、そのサービスのFANロード・バランシング・イベントのパブリッシュが可能になります。
ランタイム接続ロード・バランシングのサービス・レベルの目標には、次の2つがあります。
SERVICE_TIME: 応答時間に基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の経過時間およびサービスに対して使用可能な帯域幅に基づきます。SERVICE_TIMEの使用例としては、需要が変動するインターネット・ショッピングなどのワークロードがあります。次の例は、onlineサービスを使用して、目標を接続のSERVICE_TIMEに設定する方法を示します。
srvctl modify service -d db_unique_name -s online -B SERVICE_TIME -j SHORT
THROUGHPUT: スループットに基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の処理速度およびサービスに対して使用可能な帯域幅に基づきます。THROUGHPUTの使用例としては、前のジョブが完了してから次のジョブを開始するバッチ処理などのワークロードがあります。次の例は、sjobサービスを使用して、目標を接続のTHROUGHPUTに設定する方法を示します。
srvctl modify service -d db_unique_name -s sjob -B THROUGHPUT -j LONG
ランタイム接続ロード・バランシングの目標をNONEに設定すると、サービスのロード・バランシングが無効になります。データ・ディクショナリのサービスの目標設定は、DBA_SERVICESビュー、V$SERVICESビューおよびV$ACTIVE_SERVICESビューを問い合せて確認できます。また、Oracle Enterprise Managerを使用して、サービスのロード・バランシング設定を確認することもできます。
|
関連項目:
|
ロード・バランシング・アドバイザのFANイベントでは、ロード・バランシング・アルゴリズムのメトリックが提供されます。このイベントを使用する最も簡単な方法は、JDBC、ODP.NET、Oracle Call InterfaceなどのOracle統合クライアントのランタイム接続ロード・バランシング機能を使用することです。他のクライアント・アプリケーションは、Oracle Notification Serviceアプリケーション・プログラミング・インタフェース(ONS API)を使用することでFANをプログラムで利用し、FANイベントをサブスクライブしたり、受信時にイベント処理アクションを実行することができます。表5-4に、ロード・バランシング・アドバイザのFANイベント・パラメータを示します。
表5-4 ロード・バランシング・アドバイザのFANイベント
| パラメータ | 説明 |
|---|---|
|
|
イベント・レコードのバージョン。リリース変更の識別に使用します。 |
|
|
ロード・バランシング・アドバイザ・イベントは、常に |
|
|
サービス名。 |
|
|
サービスをサポートする一意のデータベース。 |
|
|
サービスをサポートするインスタンスの名前。 |
|
|
そのデータベース・インスタンスに送信する作業要求の割合。 |
|
|
サービスの目標を基準としたサービス品質。有効な値は、 |
|
|
通知イベントを順序付ける際に使用するローカル・タイム・ゾーン。 |
|
関連項目: Oracle RAC FAN APIの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。 |
ロード・バランシング・アドバイザのFANイベントの内部キュー表に対して次の問合せを使用すると、インスタンス用に生成されたロード・バランシング・アドバイザ・イベントを監視できます。
SET PAGES 60 COLSEP '|' LINES 132 NUM 8 VERIFY OFF FEEDBACK OFF COLUMN user_data HEADING "AQ Service Metrics" FORMAT A60 WRAP BREAK ON service_name SKIP 1 SELECT TO_CHAR(enq_time, 'HH:MI:SS') Enq_time, user_data FROM sys.sys$service_metrics_tab ORDER BY 1 ;
この問合せの結果には、次のような行が含まれます。
02:56:05|SYS$RLBTYP('hr', 'VERSION=1.0 database=sales service=hr { {in
|stance=sales_4 percent=38 flag=GOOD aff=TRUE}{instance=sales_1
| percent=62 flag=GOOD aff=TRUE} } timestamp=2010-07-16 07:56
|:05')
Oracle RACデータベースへの接続に使用される多くの一般的なクライアント・アプリケーション環境は、FANと統合されています。そのため、FANを使用する最も簡単な方法は、Oracle統合クライアントを使用することです。
次の項では、FANをOracleクライアントと統合する方法と、いくつかの特定のクライアント開発環境でFANイベントを有効にする方法について説明します。
FANを使用する場合の全体的な目的は、アプリケーションが、常に、最適なサービスを提供する使用可能インスタンスに接続できるようにすることです。使用できるOracle統合クライアントは、Oracle Call Interfaceセッション・プール、CMANセッション・プール、JDBCとODP.NET接続プールです。高速接続フェイルオーバー(FCF)機能は、接続プールを介して実装されるFANクライアントです。
FANとの統合によって、Oracle統合クライアントはOracle RACクラスタの最新のステータスをより迅速に認識します。これによって、クライアント接続が待機したり、使用不可能なインスタンスに接続しようとすることはありません。インスタンスが起動すると、Oracle RACでは、最近起動されたインスタンスへの接続を接続プールで作成し、このインスタンスで提供される追加リソースを接続プールで使用できるように、FANを使用して接続プールに通知します。
FANと統合されたOracle接続プールでは、次の処理を実行できます。
サービスの起動時に、Oracle RACのすべてのインスタンス間で接続を均等に分散します。この方法は、接続プールで定義されているセッションを、サービスがサポートされている最初のOracle RACインスタンスに割り当てるよりも有効です。
終了した接続を削除すると同時に、サービスがインスタンスでDOWNとして宣言され、ノードも同時にDOWNとして宣言されます。
サービスが再起動を繰り返し試行する間クライアントを待機させるかわりに、NOT RESTARTING状態がOracle Databaseで検出されるとすぐにエラーをクライアントにレポートします。
ロード・バランシング・アドバイザのイベントを使用して、実行時の作業要求を均等に分散します。
接続プールおよびFANを使用する場合は、接続プールで使用されるサービスを提供するすべてのインスタンスへのデータベース接続のロード・バランシングが適切に構成されている必要があります。Oracle Net Servicesでクライアント側とサーバー側のロード・バランシングを構成することをお薦めします。DBCAを使用してデータベースを作成すると、デフォルトで、クライアント側とサーバー側の両方のロード・バランシングが構成されます。
Oracle JDBCユニバーサル接続プール(UCP)に対して高速接続フェイルオーバー(FCF)を有効にすると、FAN高可用性イベントとロード・バランシング・アドバイザ・イベントの使用が有効化されます。FANを使用する場合、アプリケーションでは、JDBC ThickクライアントまたはJDBC ThinクライアントのどちらのJDBC開発環境でも使用できます。Java Database Connectivity Oracle Call Interface(JDBC/OCI)ドライバ接続プール機能は、JDBCクライアントの一部です。この機能は、OracleOCIConnectionPoolクラスによって提供されます。
UCPは、ロード・バランシング・アドバイザの情報を使用するために統合されます。Oracle Database 11g リリース11.1.0.7.0では、JDBCのユニバーサル接続プールが導入されました。そのため、Oracle RACデータベースで使用するためにOracle Database 10g リリース1で導入された既存のJDBC接続プール(暗黙接続キャッシュ)が非推奨になりました。UCPは、Oracle Database 10g またはOracle Database 11g で使用できます。
JDBCクライアント用のFCFを有効にするには、最初のgetConnection()リクエストを行う前に、oracle.jdbc.poolパッケージでOracleDataSourceクラスのfastConnectionFailoverEnabledプロパティを設定します。JDBCクライアント用のFCFを有効にすると、フェイルオーバー・プロパティは接続プール内のすべての接続に適用されます。JDBC Thinドライバ(Thinドライバ)またはJDBC/OCIクライアントでFCFを有効にすると、接続プールですべてのFANイベントを受信して、これらのイベントへのアクションを実行できます。
JDBCアプリケーションの開発者は、Oracle Database 11gリリース2(11.2)で導入された一連のAPIを使用して、プログラムでFANと統合できるようになりました。Oracle RAC FAN APIを使用すると、Oracle RACによって送信されるFANイベント通知の、アプリケーション・コードによる受信と応答が次の方法で可能になります。
Oracle RACサービスの停止イベント、サービスの起動イベントおよびノードの停止イベントのリスニング
ロード・バランシング・アドバイザ・イベントのリスニングと、それに対する応答
|
関連項目:
|
FCFは、Oracle Notification Serviceを利用して、接続プールとOracle RACデータベース間でデータベース・イベントを伝播します。実行時、接続プールは、Oracle Notification Service環境を設定できる必要があります。Oracle Notification Service(ons.jar)は、Oracleクライアント・ソフトウェアの一部として含まれています。Oracle Notification Serviceは、リモート構成またはクライアント側のOracle Notification Serviceデーモン構成のいずれかを使用して構成できます。リモートOracle Notification Serviceサブスクリプションを使用すると、次のメリットがあります。
すべてのJava中間層ソフトウェアがサポートされます。
クライアント・システムではOracle Notification Serviceデーモンが不要なため、このプロセスを管理する必要はありません。
データソース・プロパティを使用して、構成作業を簡単に行うことができます。
Oracleの暗黙接続キャッシュ用またはUCP用のFCFを有効にできます。UCP for Javaの使用をお薦めします。暗黙接続キャッシュは、非推奨です。
この項では、JDBC用のFCFを有効にする方法について説明します。JDBC/OCIクライアントでFCFを有効にする場合は、クライアントまたはサービスのいずれのTAFも有効にしないでください。FCFを有効にするには、次の手順で説明するように、最初にUCPを有効にする必要があります。
接続プールを作成して、FastConnectionFailoverEnabledを設定します。
次の例では、接続プールを作成し、FCFを有効にします。この例を使用する場合、ucp.jarライブラリはアプリケーションのCLASSPATHに含まれる必要があります。
PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource(); pds.setFastConnectionFailoverEnabled(true);
Oracle Notification Serviceリモート・サブスクリプションに使用するポートを特定します。
次の例に示すように、Oracle Clusterwareを実行している各ノードで、次のコマンドを使用してOracle Notification Service構成を表示します。
srvctl config nodeapps -s
このコマンドの出力では、Oracle Notification Service用に構成されているローカル・ポートおよびリモート・ポートがリストされます。
|
注意: Oracle Notification Service構成は、Oracle Clusterwareのインストール時に自動的に完了しているはずです。 |
アップグレードされたOracle9iデータベースのリモート・ノードに、Oracle Notification Serviceデーモンを追加します。
Oracle Notification ServiceデーモンのOracle Cluster Registry(OCR)内の情報は、Oracle Database 10g以上用に自動的に構成されます。Oracle9iバージョンのデータベースからアップグレードする場合は、次のコマンドを使用してリモート・ノード(クラスタ外のノード)にOracle Notification Serviceデーモンを追加します。
srvctl modify nodeapps -t host_port_list
リモートOracle Notification Serviceサブスクリプションを構成します。
ユニバーサル接続プールを使用する場合、アプリケーションはOracleDataSourceインスタンスのsetONSConfigurationをコールして、使用するノード番号とポート番号を指定します。次の例に示すように、各ノードで使用されるポート番号は、手順2の各ノードで表示されるリモート・ポートと同じです。この例を使用する場合、ons.jarライブラリはアプリケーションのCLASSPATHに含まれる必要があります。
pds.setONSConfiguration("nodes=racnode1:6200,racnode2:6200");
リモートOracle Notification Service構成を使用するアプリケーションでは、次の例のように、アプリケーションを起動する前に、oracle.ons.oraclehomeシステム・プロパティにORACLE_HOMEの場所を設定する必要があります。
java -Doracle.ons.oraclehome=$ORACLE_HOME ...
接続URLを構成します。
FCFを使用する場合、コネクション・ファクトリの接続URLはサービス名構文を使用する必要があります。サービス名は、サービスに接続プールをマップするために使用されます。次の例では、接続URLの構成を示しています。
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");
pds.setURL("jdbc:oracle:thin@//SCAN_name:1521/service_name");......
|
関連項目:
|
UCP JDBC接続プールでは、Oracle RACデータベースによって提供されるロード・バランシング機能が利用されます。ランタイム接続ロード・バランシングでは、Oracle JDBCドライバとOracle RACデータベースを使用する必要があります。
実行時接続ロード・バランシングには、FCFが有効であり、適切に構成されていることが必要です。「JDBC/OCIおよびJDBC Thinドライバ・クライアント用のFCFの構成」を参照してください。また、Oracle RACロード・バランシング・アドバイザは、接続プールで使用されるサービスごとにサービス・レベルの目標で構成される必要があります。接続時ロード・バランシングの目標は、次の例のとおり、SHORTに設定される必要があります。
srvctl modify service -d db_unique_name -s service_name -B SERVICE_TIME -j SHORT
|
関連項目: UCP JDBC接続プール用にランタイム接続ロード・バランシングを構成する方法の詳細は、『Oracle Universal Connection Pool for JDBC開発者ガイド』を参照してください。 |
Oracle Call Interface(OCI)クライアントは、Oracle RAC高可用性FANイベントの通知を受信するように登録し、イベント発生時に応答することによって、FCFを有効にできます。FCFを使用すると、OCIアプリケーションでのセッション・フェイルオーバー応答時間が向上し、接続プールおよびセッション・プールから機能していないインスタンスへの接続も削除されます。FCFはOCIアプリケーションで使用できます(このアプリケーションはTAF、接続プールまたはセッション・プールも使用します)。
FCFを使用するには、ロード・バランシング・アドバイザの目標と接続ロード・バランシングの目標が構成されているサービスを使用する必要があります。サービスのFANイベントを介してOracle RACロード・バランシング・アドバイザから受信されるサービス・メトリックは、Oracle Streams AQキュー表ALERT_QUEUEに自動的に配置されます。クライアント・アプリケーションには、イベント発生時に使用するコールバックを登録できます。これによって、接続障害が検出されるまでの時間が短縮されます。
DOWNイベントの処理中に、OCIでは次の処理が実行されます。
問題が発生しているクライアントの接続を終了し、エラーを戻します。
OCI接続プールおよびOCIセッション・プールから接続を削除します。OCIセッション・プールでは、各セッションが接続プールの物理的な接続とマッピングされています。1つの接続に複数のセッションが存在する場合もあります。
TAFが構成されている場合、接続をフェイルオーバーします。TAFが構成されていない場合、接続先のインスタンスに障害が発生しても、クライアントはエラーを受信するだけです。
アプリケーションでTAFを使用している場合は、SRVCTLまたはOracle Enterprise Managerを使用して、サービスのTAFプロパティを有効にする必要があります。構成済のサービスを使用して、Oracle RACデータベースに接続するようにOCIクライアント・アプリケーションを構成します。
|
注意: Oracle Call InterfaceではUPイベントは管理されません。 |
|
関連項目: TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
OCIクライアント用のFCFの構成
OCIアプリケーションは、Oracle RACインスタンスに接続して、HAイベント通知を有効にする必要があります。さらに、これらのアプリケーションは、次の手順を実行してOCIクライアント用のFCFを構成する必要があります。
OCI接続プールのサービスを構成して、接続時ロード・バランシングとランタイム接続ロード・バランシングを有効にします。また、次の例に示すように、アドバンスト・キューイング通知を有効にするように、サービスを構成します。
$ srvctl modify service -d crm -s ociapp.example.com -q TRUE -B THROUGHPUT -j LONG
次のように、OCIEnvCreate()コールを使用し、MODEパラメータ値にOCI_EVENTSを設定することで、サブスクリプションを有効にするように、クライアントでのOCIコールの環境コンテキストを設定します。
(void) OCIEnvCreate(&myenvhp, OCI_EVENTS|OCI_OBJECT, ...);
アプリケーションをスレッド・ライブラリにリンクします。
スレッド・ライブラリにリンクした後、アプリケーションは、FANイベントが発生すると常に起動されるコールバックを登録できます。
|
関連項目: Oracle Call Interfaceの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。 |
Oracle Database 11gリリース2(11.2)では、OCIセッション・プールによって、動的に管理される事前作成済のデータベース・セッションのセットをアプリケーションの複数スレッドで使用できます。接続プーリングではプール要素は接続ですが、セッション・プーリングではプール要素はセッションとなります。Oracle Databaseでは、セッション・プール内のセッションを継続的に再利用して、インスタンスへのほぼ永続的なチャネルを形成することによって、アプリケーションでセッションが必要になるたびにセッションを作成してクローズするオーバーヘッドを削減できます。
ランタイム接続ロード・バランシングは、リリース11.1以上のクライアントではデフォルトで有効になっており、10.2以上のサーバーと通信します。Oracle RAC環境の場合、アプリケーションのセッション要求を均等に分散させるために、セッション・プールは、高速アプリケーション通知(FAN)イベントを介してOracle RACロード・バランシング・アドバイザ注釈1 から受信されるサービス・メトリックを使用します。セッション・プールに入ってくる作業要求は、現在のサービス・パフォーマンスを使用して、サービスを提供しているOracle RACのインスタンス全体で分散できます。
実行時接続ロード・バランシングは、基本的には作業リクエストをセッション・プール内で作業の処理に最も適切なセッションにルーティングする操作です。既存のセッション・プールからセッションを選択する際に有効になるため、頻度の高いアクティビティです。単一インスタンスでのみサービスをサポートするセッション・プールの場合は、プール内で使用可能な最初のセッションで十分です。プールが複数インスタンスにまたがるサービスをサポートしている場合は、適切なサービスを提供できる、または容量の大きいインスタンスが多数のリクエストを取得するように、作業リクエストをインスタンス間で分散する必要があります。
接続時ロード・バランシングは、アプリケーションによりセッションが最初に作成される時点で発生します。プールの一部であるセッションも、その最初の作成時にOracle RACインスタンス間で適切に分散される必要があります。これにより、各インスタンスでのセッションが作業を実行するチャンスを取得することになります。
OCIクライアントを構成してロード・バランシング・アドバイザのFANイベントを受信する方法
Oracle RAC環境の場合、アプリケーションのセッション要求を均等に分散させるために、セッション・プールは、高速アプリケーション通知(FAN)イベントを介してOracle RACロード・バランシング・アドバイザから受信されるサービス・メトリックを使用します。アプリケーションがサービス時間に基づいてサービス・メトリックを受信できるようにするには、次の条件を満たしていることを確認します。
アプリケーションをスレッド・ライブラリにリンクしている。
次の例に示すように、セッション・プールによって使用されるサービスのロード・バランシング・アドバイザの目標(-Bオプション)および接続ロード・バランシングの目標(-jオプション)を構成している。
srvctl modify service -d crm -s ociapps -B SERVICE_TIME -j SHORT
|
関連項目: Oracle Call Interfaceの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。 |
ODP.NETの接続プールでは、ノード、サービスおよびサービス・メンバーが停止したことを示す通知をサブスクライブできます。DOWNイベントが発生すると、そのインスタンスに送られる接続プール内のセッションはOracle Databaseによって削除され、ODP.NETは無効になった接続を事前対応的に削除します。無効な接続が削除されたことで、接続合計数がMIN_POOL_SIZEパラメータの値を下回った場合、ODP.NETは、既存のOracle RACインスタンスへの追加の接続を確立します。
ODP.NETクライアント用のFANを有効にするには、次の手順を実行します。
次の例に示すように、SRVCTLを使用してサービスのAdvanced Queuingの通知を有効にします。
srvctl modify service -d crm -s odpnet.example.com -q TRUE
ODP.NETアプリケーションを使用して接続するユーザーに対して次のコマンドを実行して、内部イベント・キュー表の権限を付与します。user_nameはデータベース・ユーザーの名前です。
EXECUTE DBMS_AQADM.GRANT_QUEUE_PRIVILEGE('DEQUEUE','SYS.SYS$SERVICE_METR
ICS', user_name);
FAN高可用性イベントをサブスクライブすることによって、ODP.NET接続プールの高速接続フェイルオーバーを有効にします。FCFを有効にするには、次の例に示すように、HA Events=trueおよびpooling=true(デフォルト値)を接続文字列に含めますが、ここで、user_nameはデータベース・ユーザーの名前、passwordはそのユーザーのパスワードです。
con.ConnectionString = "User Id=user_name;Password=password;Data Source=odpnet;" + "Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" + "HA Events=true;Incr Pool Size=5;Decr Pool Size=2";
|
関連項目: ODP.NETアプリケーションでのFANイベントの使用の詳細は、『Oracle Data Provider for .NET開発者ガイド』を参照してください。 |
ODP.NETクライアントまたはアプリケーションを有効化して、FANロード・バランシング・アドバイザのイベントを受信するには、次の手順を実行します。
次の例に示すように、SRVCTLを使用してAdvanced Queuingの通知を有効にし、接続時ロード・バランシングの目標を設定します。
srvctl modify service -d crm -s odpapp.example.com -q TRUE -j LONG
接続時ロード・バランシングのためにOracle Net Servicesが構成されていることを確認します。
ODP.NETアプリケーションを使用して接続するユーザーに対して次のコマンドを実行して、内部イベント・キュー表の権限を付与します。user_nameはデータベース・ユーザーの名前です。
EXECUTE DBMS_AQADM.GRANT_QUEUE_PRIVILEGE('DEQUEUE','SYS.SYS$SERVICE_METR
ICS', user_name);
ConnectionStringのロード・バランシング属性にTRUEを設定して、ODP.NET接続プールでロード・バランシング・イベントを利用するように構成します(デフォルトはFALSE)。この処理は、接続時に実行できます。この処理は、接続プールを使用している場合、またはプーリング属性がTRUE(デフォルト)設定されている場合にのみ実行できます。
次の例では、ロード・バランシングが有効になるようにConnectionStringを構成する方法を示します。user_nameはユーザー名、passwordはパスワードです。
con.ConnectionString = "User Id=user_name;Password=password;Data Source=odpapp;" + "Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" + "Load Balancing=true;Incr Pool Size=5;Decr Pool Size=2";
|
注意: ODP.NETでは、ノード起動時(UPイベント)の接続の再分散はサポートしていません。ただし、サーバー側でフェイルオーバーが有効になっている場合は、ODP.NETで、新しく使用可能になったインスタンスに接続を移行できます。 |
|
関連項目:
|
X/Open Distributed Transaction Processing(DTP)アーキテクチャは、複数のアプリケーション・プログラム(AP)が複数の異なるリソース・マネージャ(RM)から提供されるリソースを共有できるようにするための、標準のアーキテクチャまたはインタフェースを定義しています。APとRM間の作業を調整し、グローバル・トランザクションを実現します。
次の項では、Oracle RACがどのようにXAトランザクションとDTP処理をサポートするかについて説明します。
XAトランザクションは、デフォルトでOracle RACインスタンス間をまたがって実行可能であり、Oracle XAライブラリを使用するアプリケーションは、Oracle RAC環境のメリットをフルに活用してアプリケーションの可用性とスケーラビリティを高めることができます。
GTXnバックグラウンド・プロセスは、Oracle RAC環境でグローバル(XA)・トランザクションをサポートします。GLOBAL_TXN_PROCESSES初期化パラメータ(デフォルトで1に設定)は、各Oracle RACインスタンスのGTXnバックグラウンド・プロセスの初期数を指定します。クラスタ全体でこのパラメータのデフォルト値を使用し、複数のOracle RACインスタンス間にわたる分散トランザクションを可能にします。デフォルト値の使用により、Oracle RACインスタンス全体にわたって実行される作業単位は、リソースを共有し、単一のトランザクションとして機能します(つまり、作業単位は密結合となります)。また、クラスタ内の任意のノードへの2フェーズ・コミット要求の送信も可能となります。
Oracle RAC 11gリリース1(11.1)より前のリリースでは、Oracle RACで密結合を実現する方法として分散トランザクション処理(DTP)サービス、つまりカーディナリティ(1)によって、ロード・バランシングが有効かどうかに関係なくすべての密結合ブランチが確実に同じインスタンスに配置されるサービスを使用していました。密結合されたXAトランザクションについては、XAアプリケーションがXAトランザクション・ブランチを結合または再開しないかぎり、特別なタイプのsingletonサービスをOracle RACデータベースにデプロイする必要はなくなりました。XAトランザクションは、どのタイプのサービス構成であってもOracle RACデータベースで透過的にサポートされています。
|
注意: Oracle RAC 11gリリース1(11.1)以上ではDTPサービスは必要ありませんが、「XAトランザクションに対するDTPサービスのメリット」で説明するように、DTPサービスを使用するとパフォーマンスが向上する可能性があります。 |
Oracle Services for Microsoft Transaction Server(OraMTS)などの外部トランザクション・マネージャは、DTP/XAトランザクションを調整します。ただし、Oracleの内部トランザクション・マネージャが、分散SQLトランザクションを調整します。DTP/XAと分散SQLトランザクションは、両方ともOracle RACのDTPサービスを使用する必要があります。
|
関連項目:
|
Oracle RACの分散トランザクション処理を使用してアプリケーションのパフォーマンスを向上させるために、DTPサービスのメリットを活用する場合があります。DTPサービスを使用すると、分散トランザクションのすべてのブランチをクラスタ内のシングル・インスタンスに割り当てることができます。クラスタ全体でロード・バランスを実行するには、1つまたは2つの大きいアプリケーション・サーバーを使用するよりも、小さいアプリケーション・サーバーのグループをいくつか用意して、各グループ内でトランザクションを単一または一連のサービスに割り当てる方が効果的です。
また、Oracle RACデータベースの複数の接続にわたりロード・バランスを実行するアプリケーション・サーバー層の接続プールでは、この方法を使用して1つのグローバル分散トランザクションのすべての密結合ブランチが、1つのOracle RACインスタンスのみで実行されることを確認できます。これは、X/Open分散トランザクション処理(DTP)やMicrosoft分散トランザクション・コーディネータ(DTC)などのプロトコルを使用した分散トランザクション環境でも同様です。
分散トランザクションのパフォーマンスを向上させるには、サービスを使用してDTP環境を管理します。サービスのDTPプロパティを定義すると、サービスが、Oracle RACデータベースで一度に1つのインスタンスで実行されることが保証されます。DTPサービスを介して実行されるすべてのグローバル分散トランザクションで、密結合ブランチが単一のOracle RACインスタンスで実行されることが保証されます。これには、次のメリットがあります。
密結合ブランチで相互に行った変更が必要である場合に、1つのOracle RACインスタンス内で変更をローカルに参照できます。
DTPでのサービスの再配置およびフェイルオーバーをサポートしています。
Oracle Databaseでは、Oracle RACインスタンスより多くのDTPサービスを使用することによって、Oracle RACデータベースのすべてのインスタンスのサービスで負荷を均等に分散できます。
クラスタ内のすべてのインスタンスを使用するには、分散トランザクションをホスティングする各Oracle RACインスタンスに対して、1つ以上のDTPサービスを作成します。1つの分散トランザクションに対して、1つのDTPサービスを選択します。別々の分散トランザクションに対して異なるDTPサービスを選択して、Oracle RACデータベース・インスタンス間でワークロードを均等に分散します。1つの分散トランザクションのすべてのブランチは1つのインスタンスで実行されるため、すべてのインスタンスを使用し、複数のsingletonサービスを介して、多数のDTPトランザクションの負荷を均等に分散可能になり、その結果、アプリケーションのスループットを最大限にできます。
クラスタ・データベースでノードを追加または削除した場合、最適なパフォーマンス・レベルを維持するために、DTPトランザクションに使用しているサービスの確認と再配置が必要になる場合があります。
|
関連項目: Oracle RACでのトランザクション・ブランチの管理の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
分散トランザクション処理のDTPサービスを作成するには、次の手順を実行します。
Oracle Enterprise ManagerまたはSRVCTLを使用して単一のサービスを作成します。
管理者管理データベースの場合は、優先インスタンスとして1つのインスタンスのみを定義します。次の例に示すとおり、必要な数の使用可能なインスタンスを指定できます。
srvctl add service -d crm -s xa_01.example.com -r RAC01 -a RAC02,RAC03
ポリシー管理データベースの場合は、使用するサーバー・プールを指定して、サービスのカーディナリティをSINGLETONに設定します。次に例を示します。
srvctl add service -d crm -s xa_01.example.com -g dtp_pool -c SINGLETON
サービスのDTPオプション(-x)をTRUEに設定します(デフォルト値はFALSE)です。Oracle Enterprise ManagerまたはSRVCTLを使用して、単一のサービスのDTPプロパティを変更できます。次の例では、SRVCTLを使用してxa_01.example.comサービスを変更する方法を示しています。
srvctl modify service -d crm -s xa_01.example.com -x TRUE
XA_01などのDTPサービスを提供するインスタンスに障害が発生すると、単一のサービスは、RAC02、RAC03などの使用可能インスタンスにフェイルオーバーします。
サービスが他のインスタンスに移行したら、使用可能なすべてのハードウェアで均等に負荷を再分散させるために、優先インスタンスにサービスを強制的に再配置する必要がある場合があります。GV$ACTIVE_SERVICESビューのデータを使用して、STPサービスを再配置する必要があるかどうかを判断できます。
Oracle Enterprise ManagerおよびSRVCTLユーティリティを使用して、サービスを作成および管理できます。次の項では、これらのツールを使用して、サービスに関連するタスクを実行する方法について説明します。
|
注意: DBMS_SERVICEパッケージを使用して、サービスとサービス属性を作成または変更することもできますが、このパッケージを使用して行われた設定は、SRVCTLまたはOracle Enterprise Managerによって上書きされます。DBMS_SERVICEパッケージは、Oracle RACデータベースが使用するサービスに使用しないでください。 |
サービスを作成して管理する場合、データベースで実行する作業を管理しやすい単位に分割します。サービスを使用する目的は、データベース・インフラストラクチャを最大限有効に利用することです。ビジネス要件に基づいて、サービスを作成およびデプロイできます。Oracle Databaseは各サービスのパフォーマンスを計測できます。DBMS_MONITORパッケージを使用すると、サービス内のアプリケーション・モジュールおよびモジュールの個別のアクションを両方定義して、これらのアクションのしきい値を監視できるようになり、これによってワークロードを管理して必要に応じて容量を供給することができます。
サービスの作成には、Oracle Enterprise ManagerまたはSRVCTLのいずれかを使用できます。データベースに新しいサービスを作成した場合は、サービスごとに自動ワークロード管理の特性を定義する必要があります(「サービスの特性」を参照)。
|
関連項目:
|
サービスの作成に加えて、次の作業を実行できます。
サービスの削除。作成したサービスは削除できます。ただし、Oracle Databaseで作成されたデフォルトのデータベース・サービスのプロパティは、削除したり、変更することはできません。
サービスのステータスの確認。サービスは、使用可能インスタンスごとに別々のロールが割り当てられる場合があります。多くのサービスを使用する複雑なデータベースでは、すべてのサービスの詳細を把握しておくことは困難な場合があります。そのため、インスタンスごとまたはサービスごとにステータスの確認が必要になる場合があります。たとえば、特定のインスタンス、または特定のインスタンスを実行するOracleホームに変更を加える前に、このインスタンスのサービスのステータスの確認が必要な場合があります。
データベースまたはインスタンスのサービスの起動および停止。インスタンスへのクライアント接続に使用するサービスは、事前に起動されている必要があります。たとえば、SRVCTLコマンドsrvctl stop database -d db_unique_nameを実行してデータベースを停止した場合(db_unique_nameは停止するデータベース名)、指定したデータベースへのすべてサービスが停止されます。サービス管理ポリシーによっては、データベースの起動時にサービスを手動で再起動する必要がある場合があります。
|
注意: Oracle RACデータベースでOracle Database QoS Managementが有効になっている場合、サービスは、停止後に自動的に再起動されます。 |
サービスのコンシューマ・グループへのマッピング。サービスをリソース・マネージャのコンシューマ・グループに自動的にマッピングして、サービスがインスタンスで使用可能なリソースの量を制限することができます。コンシューマ・グループを作成し、サービスをこのグループにマッピングする必要があります。
|
関連項目: DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRIプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』 |
データベースまたはインスタンスのサービスの有効化および無効化。デフォルトでは、障害が発生すると、Oracle Clusterwareはサービスの再起動を自動的に試みます。サービスを無効化すると、この動作を回避できます。サービスの無効化は、データベースまたはインスタンスのメンテナンスを実行する必要がある場合、たとえばアップグレードの実行中に接続要求を回避する必要がある場合などに便利です。
別のインスタンスへのサービスの再配置。たとえば、クラスタ・ノードを追加または削除した後に、あるインスタンスから別のインスタンスにサービスを移動して、ワークロードを再分散させることができます。
サービスに関連するタスクを開始する際の中心ページは、「クラスタ管理データベース・サービス」ページです。このページにアクセスするには、クラスタ・データベースの「可用性」ページに移動し、「サービス」セクションの「クラスタ管理データベース・サービス」をクリックします。このページおよびこのページのドリルダウンを使用して、次のタスクを実行できます。
クラスタのサービス・リストの表示
現在、各サービスを実行しているインスタンスの表示
各サービスのステータスの表示
サービスの作成および編集
サービスの起動および停止
サービスの有効化および無効化
サービスのインスタンスレベルのタスクの実行
サービスの削除
|
注意: クラスタ・データベースへアクセスするには、SYSDBA資格証明を所有している必要があります。「クラスタ管理データベース・サービス」では、SYSDBA以外での接続は許可されません。 |
|
関連項目:
|
SRVCTLを使用してサービスを作成した場合、別のSRVCTLコマンドでそのサービスを起動する必要があります。一方、後で手動でサービスを停止または再起動する必要がある場合もあります。さらに、自動的な再起動が実行されないようにサービスを無効化したり、サービスを手動で再配置したり、サービスに関するステータス情報を取得することもあります。次の項では、SRVCTLを使用して次の管理タスクを実行する方法について説明します。
SRVCTLを使用してサービスを作成するには、コマンドラインから次の構文を使用したコマンドを入力します。
srvctl add service -ddb_unique_name-sservice_name-t edition_name {-rpreferred_list[-aavailable_list]} | {-g server_pool [-c {UNIFORM | SINGLETON}] [-k net_number]} [-P {BASIC | NONE}] [-l {[PRIMARY] | [PHYSICAL_STANDBY] | [LOGICAL_STANDBY] | [SNAPSHOT_STANDBY]}] [-y {AUTOMATIC | MANUAL}] [-q {TRUE | FALSE}] [-x {TRUE | FALSE}] [-j {SHORT | LONG}] [-B {NONE | SERVICE_TIME | THROUGHPUT}] [-e {NONE |SESSION | SELECT}] [-m {NONE | BASIC}] [-z failover_retries] [-w failover_delay]
|
注意: service_name初期化パラメータの値には、4KBの制限があります。したがって、インスタンスに割り当てられたすべてのサービスの名前の長さは、合計で4KBを超えないようにする必要があります。 |
アプリケーションがサーバーを使用して接続するために、サービスを起動する必要があります。停止したサービスは、一時的に使用できなくなりますが、引き続き自動再起動およびフェイルオーバーの対象となっています。
サービスを停止または起動するには、コマンドラインから次のSRVCTL構文を入力します。
srvctl start service -d database_unique_name [-sservice_name_list] [-iinst_name] [-ostart_options]
srvctl stop service -d database_unique_name -sservice_name_list[-iinst_name] [-ostart_options]
サービスを無効化にすると、Oracle Clusterwareは、そのサービスを自動起動、フェイルオーバーまたは再起動の対象とみなさなくなります。アプリケーション・メンテナンスを実行する場合は、そのメンテナンス操作が完了するまでサービスを無効化にすることで、Oracle Clusterwareが誤ってサービスを再起動しないようにできます。再び通常操作でサービスを使用できるようにするには、サービスを有効化します。
サービスを有効化および無効化するには、コマンドラインから次のSRVCTL構文を使用します。
srvctl enable service -ddatabase_unique_name-sservice_name_list[-iinst_name]
srvctl disable service -ddatabase_unique_name-sservice_name_list[-iinst_name]
サービスを再配置するには、コマンドラインからsrvctl relocate serviceを実行します。このコマンドを使用するのは、サービスが使用可能インスタンスにフェイルオーバーしたが、そのインスタンスの再起動後に、優先インスタンスにサービスを移動させたい場合です。
次のコマンドを実行すると、crmサービスがインスタンスapps1からインスタンスapps3に再配置されます。
srvctl relocate service -d apps -s crm -i apps1 -t apps3
サービスのステータスを取得するには、コマンドラインからsrvctl status serviceコマンドを実行します。たとえば、次のコマンドを実行すると、appsデータベースで実行中のサービスのステータスが戻されます。
srvctl status service -d apps Service erp is running on nodes: apps02,apps03 Service hr is running on nodes: apps02,apps03 Service sales is running on nodes: apps01,apps04
サービスの高可用性構成を取得するには、コマンドラインからsrvctl config serviceコマンドを実行します。たとえば、次のコマンドを実行すると、appsデータベースで実行中のerpサービスの構成が戻されます。
srvctl config service -d apps -s erp Service name: erp Service is enabled Server pool: sp1 Cardinality: UNIFORM Disconnect: false Service role: PRIMARY Management policy: AUTOMATIC DTP transaction: false AQ HA notificaitons: false Failover type: NONE Failover method: NONE TAF failover retries: 0 TAF failover delay: 0 Connection Load Balancing Goal: LONG Runtime Load Balancing Goal: SERVICE_TIME TAF policy specification: NONE Edition: Service is enabled on nodes: Service is disabled on nodes:
サービスを使用することで、より効果的なパフォーマンスのチューニングを行うことができます。サービスによって、ワークロードを認識して測定できるため、リソース使用量および待機時間をアプリケーションの属性として指定できます。すべてのセッションが匿名で共有されている多くのシステムでは、セッションおよびSQLを使用したチューニングのかわりに、サービスおよびSQLを使用したチューニングを実行します。
自動ワークロード・リポジトリ(AWR)では、データベースで実行されているすべてのサービスと作業の応答時間、スループット、リソース使用量および待機イベントの情報など、パフォーマンス統計が保持されます。また、サービスのメトリック、統計、待機イベント、待機クラスおよびSQLレベルのトレースも保持されます。さらに、オプションとして、特定の統計を監視するためのモジュールをアプリケーションで定義して、これらの統計をカスタマイズできます。また、このモジュール内に、重要なビジネス・トランザクションで特定の統計値に応答して実行されるアクションを定義することもできます
モジュールおよびアクションの監視を有効にするには、DBMS_MONTIOR PL/SQLパッケージを使用します。たとえば、erpサービスを使用する接続の場合、次のコマンドを使用すると、payrollモジュールのexceptions payアクションを監視できます。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(SERVICE_NAME => 'ERP', MODULE_NAME=> 'PAYROLL', ACTION_NAME => 'EXCEPTIONS PAY');
erpサービスを使用する接続の場合、次のコマンドを使用すると、payrollモジュールのすべてのアクションを監視できます。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(SERVICE_NAME => 'ERP', MODULE_NAME=> 'PAYROLL', ACTION_NAME => NULL);
アプリケーション・モジュールとアクションの監視が有効化されたことを確認するには、DBA_ENABLED_AGGREGATIONSビューを使用します。
サービスによる統計の収集およびトレースは、Oracle RACデータベース全体を対象とします。また、Oracle RACデータベースと非クラスタのOracle Databaseのどちらの場合も、インスタンスの再起動やサービスの再配置が行われても統計の集計は失われません。
サービス名、モジュール名およびアクション名は、V$SESSION、V$ACTIVE_SESSION_HISTORYおよびV$SQLビューで確認できます。コール回数およびパフォーマンス統計は、V$SERVICE_STATS、V$SERVICE_EVENT、V$SERVICE_WAIT_CLASS、V$SERVICEMETRICおよびV$SERVICEMETRIC_HISTORYで確認できます。重要なトランザクションで統計の収集を有効にしている場合、V$SERV_MOD_ACT_STATSビューを使用すると、各データベース・インスタンスのそれぞれのサービス名、モジュール名およびアクション名に対して、コール速度を確認できます。
SQL*Plusスクリプトの次のサンプルを実行すると、5秒間隔でサービス品質の統計が収集されます。これらのサービス品質の統計を使用して、サービスの品質を監視したり、作業を割り当てたり、サービスをOracle RAC全体のインスタンス間で均等に分散できます。
SET PAGESIZE 60 COLSEP '|' NUMWIDTH 8 LINESIZE 132 VERIFY OFF FEEDBACK OFF
COLUMN service_name FORMAT A20 TRUNCATED HEADING 'Service'
COLUMN begin_time HEADING 'Begin Time' FORMAT A10
COLUMN end_time HEADING 'End Time' FORMAT A10
COLUMN instance_name HEADING 'Instance' FORMAT A10
COLUMN service_time HEADING 'Service Time|mSec/Call' FORMAT 999999999
COLUMN throughput HEADING 'Calls/sec'FORMAT 99.99
BREAK ON service_name SKIP 1
SELECT
service_name
, TO_CHAR(begin_time, 'HH:MI:SS') begin_time
, TO_CHAR(end_time, 'HH:MI:SS') end_time
, instance_name
, elapsedpercall service_time
, callspersec throughput
FROM
gv$instance i
, gv$active_services s
, gv$servicemetric m
WHERE s.inst_id = m.inst_id
AND s.name_hash = m.service_name_hash
AND i.inst_id = m.inst_id
AND m.group_id = 10
ORDER BY
service_name
, i.inst_id
, begin_time ;
サービス・レベルのしきい値を使用すると、実際のサービス・レベルとサービスの必須レベルを比較できます。これによって、満足するサービス・レベルが提供されているかどうかを認識できます。最終的な目標は、基準を満たしたサービス・レベルを提供する、予測可能なシステムを構成することです。最小限のリソース使用量で可能なかぎり速く実行することは必要ではなく、必要なのは、サービスの品質を満たすことです。
AWRを使用すると、コールの応答時間(ELAPSED_TIME_PER_CALL)およびコールのCPU時間(CPU_TIME_PER_CALL)の2つのパフォーマンスしきい値を、サービスごとに明示的に指定できます。応答時間のしきい値は、各サービスの各ユーザー・コールの経過時間が特定の値を超えないようにすることを示すもので、コールのCPU時間のしきい値は、各サービスの各コールによるCPUの使用時間が特定の値を超えないようにすることを示すものです。応答時間は、ユーザーのためのコールの実行に支障を与える可能性があるすべての遅延および障害を反映する基本的な測定単位です。また、応答時間では、Oracle RACデータベースのノード間における、ノード別の処理能力の差異も確認できます。
Oracle RACデータベースの各インスタンスに、これらのしきい値を設定する必要があります。経過時間およびCPU時間は、サーバー側のコールの経過時間を移動平均法で算出した時間です。AWRは経過時間およびCPU時間を監視し、パフォーマンスがしきい値を超えた場合には、AWRアラートを発行します。これらのアラートに対してOracle Enterprise Managerのジョブを使用してアクションをスケジュールすることも、アラート受信時にプログラムによってアクションが発生するようにアクションをスケジュールすることもできます。アラートが発行された場合は、ジョブの優先順位を変更したり、オーバーロード状態になったプロセスを停止したり、サービスを再配置、起動または停止して応答します。これによって、需要量に変動が発生した場合でも、サービスの可用性を維持できます。
この項の内容は次のとおりです。
この例では、payrollサービスのしきい値を確認する必要があります。この情報は、AWRレポートを使用して取得できます。システムが最適な状態で稼働しているときに、いくつかの連続した時間間隔で実行したレポートの結果を比較する必要があります。たとえば、payrollアプリケーションがアクセスするサーバーで、毎週木曜日に使用率がピークに達する午後1時から午後5時までの間にAWRレポートを実行するとします。AWRレポートには、payrollサービスを含む各サーバーのコールについて、応答時間(経過データベース時間)およびCPUの使用時間(CPU時間)が含まれます。また、AWRレポートには、完了した作業のブレークダウンおよび応答時間に影響を与えている待機時間も記録されます。
DBMS_MONITORを使用して、payrollサービスのコールごとの経過時間に対する警告しきい値に0.5秒(500000マイクロ秒)を設定します。また、payrollサービスのコールごとの経過時間の重要な警告のしきい値を0.75秒(750000マイクロ秒)に設定します。
この例では、payrollサービスのしきい値を次のように追加します。
EXECUTE DBMS_SERVER_ALERT.SET_THRESHOLD( METRICS_ID => DBMS_SERVER_ALERT.ELAPSED_TIME_PER_CALL , warning_operator => DBMS_SERVER_ALERT.OPERATOR_GE , warning_value => '500000' , critical_operator => DBMS_SERVER_ALERT.OPERATOR_GE , critical_value => '750000' , observation_period => 30 , consecutive_occurrences => 5 , instance_name => NULL , object_type => DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE , object_name => 'payroll');
次のSELECT文を使用すると、しきい値の構成がすべてのインスタンスに設定されていることを確認できます。
SELECT METRICS_NAME, INSTANCE_NAME, WARNING_VALUE, CRITICAL_VALUE, OBSERVATION_PERIOD FROM dba_thresholds ;
各サービス内の重要なモジュールおよびアクションに対するパフォーマンス・データのトレース機能を有効にできます。パフォーマンス統計は、V$SERV_MOD_ACT_STATSビューで参照できます。たとえば、次のように設定できます。
ERPサービスで、payrollモジュール内のexceptions payアクションを監視します。
ERPサービスで、payrollモジュール内のすべてのアクションを監視します。
HOT_BATCHサービスで、postingモジュール内のすべてのアクションを監視します。
次のコマンドは、サービスのモジュールとアクションの監視を有効化する方法を示します。
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'erp', module_name=> 'payroll', action_name => 'exceptions pay'); EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'erp', module_name=> 'payroll', action_name => NULL); EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'hot_batch', module_name =>'posting', action_name => NULL);
サービス、モジュールおよびアクションの監視が有効化されいてることを確認するには、次のSELECT文を使用します。
COLUMN AGGREGATION_TYPE FORMAT A21 TRUNCATED HEADING 'AGGREGATION' COLUMN PRIMARY_ID FORMAT A20 TRUNCATED HEADING 'SERVICE' COLUMN QUALIFIER_ID1 FORMAT A20 TRUNCATED HEADING 'MODULE' COLUMN QUALIFIER_ID2 FORMAT A20 TRUNCATED HEADING 'ACTION' SELECT * FROM DBA_ENABLED_AGGREGATIONS ;
次に、出力の例を示します。
AGGREGATION SERVICE MODULE ACTION ------------ -------------------- ---------- ------------- SERVICE_MODULE_ACTION ERP PAYROLL EXCEPTIONS PAY SERVICE_MODULE_ACTION ERP PAYROLL SERVICE_MODULE_ACTION HOT_BATCH POSTING
脚注の凡例
脚注 1: 実行時接続ロード・バランシングは、基本的には作業リクエストをセッション・プール内で作業の処理に最も適切なセッションにルーティングする操作です。既存のセッション・プールからセッションを選択すると、有効になります。このため、ランタイム接続ロード・バランシングは、きわめて頻度の高いアクティビティです。