| Oracle Real Application Clusters管理およびデプロイメント・ガイド 11gリリース1（11.1） E05738-05 |
|
 戻る |
 次へ |
この章では、Oracle Real Application Clusters（Oracle RAC）のワークロードを管理して、アプリケーションで高可用性および高いスケーラビリティを実現する方法について説明します。内容は次のとおりです。
自動ワークロード管理によってワークロードの分散を管理し、ユーザーおよびアプリケーションに対してパフォーマンスを最適化できます。自動ワークロード管理を構成するコンポーネントは次のとおりです。
サービス: 企業のグリッド構想を実現するために、Oracle Databaseでは、サービスと呼ばれる強力な自動ワークロード管理機能が導入されています。サービスは、Oracle RACデータベースで定義可能なエンティティです。サービスによって、データベースのワークロードをグループ化し、サービスを提供するために割り当てられた最適なインスタンスに作業をルーティングできます。
コネクション・ロード・バランシング: 要求されたデータベース・サービスを提供するすべてのインスタンスで、受信する接続を均等に分散するOracle Net Servicesの機能。
高可用性フレームワーク: Oracle Databaseでコンポーネントを常に稼働状態に維持できるOracle RACコンポーネント。
高速アプリケーション通知（FAN）: インスタンス、サービス、またはノードのUPやDOWNなどのクラスタ状態の変更およびワークロード・サービス・レベルの変更をアプリケーションに迅速に警告するためにOracle RACが使用する通知メカニズム。
ロード・バランシング・アドバイザ: データベースとそのインスタンスが提供する現在のサービス・レベルについてアプリケーションに情報を提供します。ロード・バランシング・アドバイザは、サービス用に定義したポリシーに基づいて最適なサービスを得るために、アプリケーション要求の宛先に関する推奨事項をアプリケーションに提供します。
自動ワークロード・リポジトリ: サービス・レベルの統計がメトリックとして追跡されます。サーバーによって生成されるアラートは、特定のしきい値を超えたり、必要なしきい値に達しない場合、これらのメトリックに基づいて発行されます。アラートが発行された場合は、ジョブの優先順位の変更、オーバーロード状態になったプロセスの停止、サービス・レベルの要件の変更などを行って応答します。これによって、サービス・レベルを変更しても、サービスの可用性を引き続き維持できます。各サービスのサービス・レベルは、他のサービスを基準とする優先順位を付けて構成できます。また、次の項目も構成できます。
サービス品質の測定
サービス品質の変更を監視するためのイベント通知およびアラート・メカニズム
サービス品質の変更に応答するためのリカバリ例
自動ワークロード・リポジトリによって、Oracle Clusterwareのワークロード管理フレームワークおよびリソース・マネージャにおけるパフォーマンス・データ表現の永続性とグローバル性が保証されます。この情報によって、Oracle Databaseはサービス別にジョブ・クラスをスケジュールしたり、コンシューマ・グループに優先順位を割り当てることができます。必要に応じて、PL/SQLプロシージャDBMS_SERVICE.DISCONNECT_SESSIONを使用して、手動でワークロードを再度均等に分散させることができます。このプロシージャを使用すると、一連のセッションを切断し、サービスを続行することもできます。
|
関連項目: 自動ワークロード・リポジトリの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。Oracle Databaseパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
高速接続フェイルオーバー: これは、FANイベントをサブスクライブすることによって、高速な接続のフェイルオーバーを提供する、Oracleクライアントの機能です。
ランタイム接続ロード・バランシング: アプリケーションが接続にいくつかの作業を完了するように要求すると、データベース・インスタンスによって提供されている現在のサービス・レベルに基づいて、接続プールで高度な接続の割当てを行うOracleクライアントの機能です。
ユーザーまたはアプリケーションがデータベースに接続するときは、接続文字列の接続データ部分にサービスを指定することをお薦めします。データベースが作成されると、自動的に1つのデータベース・サービスが作成されます。多くのインストールでは、この他に必要な作業はありません。データベースを使用したワークロード管理の柔軟性を高めるために、Oracle Databaseでは、複数のサービスを作成し、どのインスタンスがサービスを提供するかを指定できます。より柔軟なワークロード管理が必要な場合は、この章を読み進めると、サービスで使用できる追加機能を理解できます。
|
注意: この章で説明する機能は、デフォルトのデータベース・サービスでは動作しません。このような機能を活用するには、クラスタ管理サービスを作成する必要があります。自分が作成したサービスのみ管理できます。データベース・サーバーによって作成されたサービスはすべてデータベース・サーバーによって管理されます。 |
Oracle RACデータベース環境およびシングル・インスタンスのOracle Database環境をデプロイして、自動ワークロード管理機能を様々な方法で使用できます。ノード数および使用環境の使用目的と複雑さによって異なりますが、最適な自動ワークロード管理および高可用性構成は、この章で説明する考慮事項を検討して決定してください。この項では、様々なサービス・デプロイメント・オプションについて説明します。
自動ワークロード・リポジトリでは、サービス・レベルの統計がメトリックとして追跡されます。サーバーによって生成されるアラートは、特定のしきい値を超えたり、必要なしきい値に達しない場合、これらのメトリックに基づいて発行されます。アラートが発行された場合は、ジョブの優先順位の変更、オーバーロード状態になったプロセスの停止、サービス・レベルの要件の変更などを行って応答します。これによって、サービス・レベルを変更しても、サービスの可用性を引き続き維持できます。各サービスのサービス・レベルは、他のサービスを基準とする優先順位を付けて構成できます。また、次の項目も構成できます。
この項では、次のサービスのデプロイメントについて説明します。
ワークロードまたはアプリケーションのグループを管理するために、特定のアプリケーションまたはアプリケーションの一部の操作に割り当てるサービスを定義できます。また、作業の種類ごとにサービスとしてグループ化することもできます。たとえば、オンライン・ユーザー、バッチ処理、レポートをそれぞれ異なるサービスとして定義できます。
1つのサービスを共有するすべてのユーザーで、サービス・レベルの要件を同じにすることをお薦めします。サービスには個別の特性を定義できるため、各サービスはそれぞれ別々の作業単位にできます。サービスの使用時には、多数のオプションを使用できます。これらのオプションを実装する必要はありませんが、それらを使用すると、アプリケーションのパフォーマンスが最適化できます。
サービスを定義する際には、そのサービスを通常サポートするインスタンスを定義します。このようなインスタンスを、PREFERRED（優先）インスタンスといいます。また、サービスの優先インスタンスで障害が発生した場合にサービスをサポートする別のインスタンスを定義することもできます。このようなインスタンスを、AVAILABLE（使用可能）インスタンスといいます。
PREFEREDインスタンスを指定する場合は、サービスが通常実行されるインスタンスの数を指定します。Oracle Clusterwareは、サービスを構成したインスタンス数で常にサービスが実行されることを確認しようとします。その後は、インスタンス障害またはサービスの計画的な再配置のために、AVAILABLEインスタンスでサービスが実行される場合があります。リストに2つ以上のインスタンスがある場合に、Oracle ClusterwareによってサービスがどのAVAILABLEインスタンスに再配置されるかは制御できません。Oracle Databaseでは、AVAILABLEインスタンスに移動されたサービスは、PREFERREDインスタンスを再起動しても、PREFERREDインスタンスには戻りません。これには、次の理由があります。
サービスが、指定した数のインスタンスですでに実行されている。
現在のインスタンスでサービスを維持することによって、より高度なサービス可用性が提供される。
サービスを最初のPREFERREDインスタンスに戻さないことで、2回目の機能停止が回避される。
ただし、FANコールアウトを使用して、フェイルバックを簡単に自動化することもできます。
サービスを定義すると、リソース・プロファイルは自動的に作成されます。リソース・ファイルには、Oracle Clusterwareによるサービスの管理方法と、PREFERREDインスタンスが停止した場合にサービスがフェイルオーバーされるインスタンスが定義されています。また、リソース・プロファイルでは、インスタンスおよびデータベースに対するサービスの依存性も定義します。この依存性の情報によって、データベースが停止した場合に、インスタンスおよびサービスが自動的に正しい順序で停止されます。
サービスはリソース・マネージャと統合されており、リソース・マネージャでは、1つのインスタンス内でサービスに接続しているユーザーが使用するリソースを制限できます。リソース・マネージャでは、コンシューマ・グループをサービスにマッピングできるため、あるサービスを使用して接続しているユーザーは、指定されたコンシューマ・グループのメンバーになります。また、自動ワークロード・リポジトリ（AWR）を使用して、サービスのパフォーマンスを監視できます。
Oracle Net Servicesでは、接続時ロード・バランシングが実行されるため、サービスをサポートしているすべてのインスタンス間で、ユーザー接続を分散できます。各サービスに対して、接続時ロード・バランシング・ゴールCLB_GOALを設定して、リスナーにロード・バランシングを使用させる方法を定義できます。また、Oracle Call Interfacesが有効になっているアプリケーションの場合は、FAILOVER_METHOD、FAILOVER_TYPEなどを定義することによって、サービスのすべてのユーザーに対して1つの透過的アプリケーション・フェイルオーバー（TAF）ポリシーを指定することもできます。（TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。）
Oracle RACは、FANを使用して、構成の変更や、サービスで使用可能な各インスタンスが提供している現在のサービス・レベルをアプリケーションに通知します。FANには、クライアントにイベントを発行する方法が2つあります。1つはOracle Notification Service（ONS）で、Oracle Application Serverを含むJava Database Connectivity（JDBC）クライアントによって使用されます。もう1つは、Oracle Streams Advanced Queueingで、Oracle Call Interface（OCI）およびOracle Data Provider for .NET（ODP.NET）クライアントによって使用されます。Advanced Queueingを使用している場合、イベントを受信するにはアプリケーションが有効になっている必要があります。
ランタイム接続ロード・バランシングを使用すると、アプリケーションは、ロード・バランシング・アドバイザ・イベントを使用して、ユーザーにより適切なサービスを提供できます。Oracle JDBCおよびOracle Data Provider for .NETクライアントは、ロード・バランシング・アドバイザ・イベントを使用できるように自動的に統合されています。ロード・バランシング・アドバイザは、サービスに対してインスタンスで提供されている現在のサービス・レベルをクライアントに通知します。また、そのインスタンスに送るワークロードの推奨量を提示します。また、Oracle Net Servicesでは、接続時ロード・バランシングが実行されるため、サービスをサポートするすべてのインスタンス間で、ユーザー接続を分散できます。ロード・バランシング・アドバイザを有効にするには、サービスにGOALパラメータを設定します。
分散トランザクション処理アプリケーションには、一意の要件があります。グローバル・トランザクションでOracle RACを使用しやすくするには、サービスに分散トランザクション処理パラメータを設定して、分散トランザクション処理のすべての密結合ブランチが同一インスタンス上で実行されるようにします。
デフォルトでは、Oracle RACデータベースに特殊なOracle Databaseサービスが作成されます。このデフォルトのサービスは、Oracle RAC環境のすべてのインスタンスで常に使用可能です（制限モードのインスタンスを除く）。このサービスまたはサービスのプロパティは、変更できません。また、データベースでは、次の2つの内部サービスがサポートされています。
いずれの内部サービスも、すべての自動ワークロード管理機能をサポートしています。これらの内部サービスは、停止または無効化できません。
|
注意: 明示的に管理できるのは、自分が作成するサービスにかぎられます。データベースの機能によって内部サービスが作成される場合、そのサービスはこの章の情報を使用して管理できません。 |
Oracle Net Servicesでは、Oracle RAC構成内のインスタンス間でクライアント接続を均等に分散する機能を使用できます。実装可能なロード・バランシングには、クライアント側とサーバー側の2種類のロード・バランシングがあります。クライアント側のロード・バランシングでは、接続要求をリスナー間で均等に分散します。サーバー側のロード・バランシングでは、リスナーがロード・バランシング・アドバイザを使用して、現在サービスを提供している最適なインスタンスに接続要求を割り当てます。Oracle RACデータベースのクライアント接続では、両方の接続時ロード・バランシングを使用する必要があります。
FAN、高速接続フェイルオーバーおよびロード・バランシング・アドバイザは、正確な接続時ロード・バランシング構成（サービスに対する接続時ロード・バランシングの目標の設定など）に基づいて処理を実行します。接続時ロード・バランシングでは、LONGまたはSHORTのいずれかの目標を使用できます。これらの目標の特性は、次のとおりです。
LONG: LONG接続時ロード・バランシング方式は、長時間の接続を使用するアプリケーションに使用します。通常、ロード・バランシング・アドバイザと統合されていない接続プールおよびSQL*Formsセッションで使用します。LONGは、デフォルトの接続時ロード・バランシングの目標です。次の例では、PL/SQLのDBMS_SERVICEパッケージおよびCLB_GOAL_LONGパッケージ定数を使用して、サービスPOSTMANを変更し、長時間セッション用の接続時ロード・バランシングの目標を定義しています。
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'POSTMAN'
, clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);
SHORT: SHORT接続時ロード・バランシング方式は、短時間の接続を使用するアプリケーションに使用します。また、ロード・バランシング・アドバイザと統合されているクライアントを使用している場合もSHORTを使用します。たとえば、GOALを設定する場合は、CBL_GOALをSHORTに設定します。次の例では、DBMS_SERVICE.CLB_GOAL_SHORTパッケージ定数を使用して、サービスORDERを変更し、目標にSHORTを設定しています。
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'ORDER'
, CLB_GOAL => DBMS_SERVICE.CLB_GOAL_SHORT);
DBCAを使用してOracle RACデータベースを作成すると、次の処理が自動的に実行されます。
サーバー側のロード・バランシングの構成および有効化
ローカルおよびリモートのリスナー・パラメータの設定（注意: DBCAを使用しない場合、特に、ポート1521を使用しない場合は、LOCAL_LISTENERデータベース・パラメータおよびREMOTE_LISTENERデータベース・パラメータを手動で設定する必要があります）
サーバー上のtnsnames.oraファイルにおけるクライアント側のロード・バランシング接続定義のサンプルの作成
Oracle Net Servicesによってインスタンスへの接続が確立されると、クライアントが接続をクローズするか、インスタンスが停止するか、または障害が発生するまで、接続はオープン状態のまま維持されます。接続にTAFを構成すると、インスタンスで障害が発生した場合、障害が発生していないインスタンスにセッションは移動されます。
TAFでは、フェイルオーバーが完了すると問合せは再開できますが、INSERT、UPDATE、DELETEなどの他のトランザクションの場合、アプリケーションで、失敗したトランザクションをロールバックして再度送信する必要があります。フェイルオーバーが発生したら、セッションのすべてのカスタマイズ（ALTER SESSION文）を再度実行する必要があります。ただし、TAFでは、ワークロードが変化しても、通常処理の間は接続が移動されません。
サービスはTAFのデプロイメントを簡素化します。サービスのTAFポリシーを定義でき、このサービスを使用するすべての接続によって、自動的にTAFが有効になります。これには、クライアント側の変更は必要ありません。サービスのTAF設定は、クライアントの接続定義内のTAF設定よりも優先されます。サービスのTAFポリシーを定義するには、次の例のようにPL/SQLプロシージャDBMS_SERVICEを使用します。
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'gl.us.oracle.com' , aq_ha_notifications => TRUE , failover_method => DBMS_SERVICE.FAILOVER_METHOD_BASIC , failover_type => DBMS_SERVICE.FAILOVER_TYPE_SELECT , failover_retries => 180 , failover_delay => 5;
|
関連項目: TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
クライアント側のロード・バランシングは、LOAD_BALANCE=ONパラメータ（デフォルトでは、説明リストに対してON）を設定して、クライアントの接続定義に定義します。このパラメータをONに設定した場合は、Oracle Databaseによってアドレス・リストから無作為にアドレスが選択されて、そのノードのリスナーに接続されます。これによって、クラスタ内で使用可能なリスナー間で、クライアント接続が均等に分散されます。接続要求を受信したリスナーは、要求されたサービスを提供するとリスナーが認識しているインスタンスにユーザーを接続します。リスナーがサポートしているサービスを確認するには、lsnrctl servicesコマンドを実行します。
クライアント側のロード・バランシングに加えて、Oracle Net Servicesには接続フェイルオーバー機能が含まれています。リスト内の選択されたアドレスからエラーが戻されると、Oracle Net Servicesによってリストの次のアドレスが試行されます。これは、接続が成功するか、またはリスト内に試行するアドレスがなくなるまで続けられます。可用性を高めるために、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に短縮できます。
Oracle Call Interfaceクライアントには、クライアント側でローカルのsqlnet.oraファイルを作成します。次の行を追加してこのファイルに接続タイムアウトを構成します。
sqlnet.outbound_connect_timeout = 1
Oracle Call Interfaceクライアントのタイムアウト値の粒度は秒単位です。
|
注意: サーバーのsqlnet.oraファイルには接続タイムアウトを構成しないでください。 |
|
関連項目: 両方のタイプのロード・バランシングの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
この項では、FANの詳細を説明します。内容は次のとおりです。
FANは、UPまたはDOWNイベントなどのサービス・ステータスの変更を含む、構成情報およびサービス・レベルの情報を他のプロセスに通知するためにOracle RACが使用する通知メカニズムです。アプリケーションはFANイベントに応答して、すぐにアクションを実行できます。FANのUPイベントおよびDOWNイベントは、インスタンス、サービスおよびノードに適用できます。
クラスタの構成が変更されて、クラスタ内で状態の変更が発生した場合、Oracle RACの高可用性フレームワークは、ただちに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管理者ガイド』を参照してください。）
ONS Application Program Interface（API）を使用すると、FANをプログラムで使用して、FANイベントをサブスクライブしたり、イベントの受信時にイベント処理アクションを実行することができます。
サーバー側のコールアウトを使用して、データベース層にFANを実装できます。
DOWNイベントでは、障害が発生しているインスタンスまたはノードに対するセッションを終了できるため、アプリケーションへの影響を最小限に抑えることができます。未完了のトランザクションは終了され、ただちにアプリケーションのユーザーに通知されます。接続を要求しているアプリケーション・ユーザーは、使用可能インスタンスにのみ割り当てられます。UPイベントでは、サービスおよびインスタンスが起動された場合に新しい接続を作成して、新しく使用可能になったリソースをアプリケーションでただちに使用できます。また、サーバー側のコールアウトによって、FANを使用して、次の操作を実行できます。
ステータス情報を記録します。
リソースの起動に失敗した場合に、DBAへの通知またはサポート・チケットの発行を行います。
サービスと同じ場所に配置することが必要な、依存する外部アプリケーションを自動的に起動します。
ノードの障害などによって、使用可能インスタンスの数が減少した場合、リソース・プランを変更するか、またはサービスを停止します。
必要に応じて、サービスをPREFERREDインスタンスに自動的にフェイルバックします。
FANイベントの発行には、ONSおよびOracle Streams Advanced Queuingが使用されます。発行メカニズムは、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アーキテクチャ内の様々なレベルで発生し、ONSおよびAdvanced Queuingを使用して発行される可能性があります。また、FANコールアウトを使用して通知をプログラミングすることもできます。
障害が発生したノードでサービスが実行されなくなると、障害が発生していないノードから通知が発行されます。Oracle RAC環境内でサービスを提供するインスタンスの位置および数は、アプリケーションに対して透過的です。再起動およびリカバリは自動的に実行されます。この再起動では、データベースのみでなく、リスナーや自動ストレージ管理（ASM）プロセスなどのサブシステムも再起動されます。FANコールアウトを使用すると、障害管理システムに障害をレポートしたり、修復ジョブを開始することができます。
1つ以上のインスタンスを隔離する必要がある修復、アップグレードおよび変更のために、Oracle RACでは、アプリケーション・ユーザーに対するサービスの中断の影響を最小限に抑えて、サービスを再配置、無効化および有効化するインタフェースを使用できます。操作を完了すると、サービスを通常の動作に戻すことができます。
データベースを手動で停止すると、依存性のために、すべてのサービスも自動的に停止されます。その後、データベースを手動で再起動する場合は、データベースのサービスも再起動する必要があります。FANコールアウトを使用すると、データベースの起動時に、サービスを自動的に起動できます。
表4-1に、FANイベントのレコード・パラメータ、イベント・タイプ、およびイベント・プロパティの名前/値のペアを示します。次の例で示すように、イベント・タイプは常に最初のエントリ、タイムスタンプは常に最後のエントリです。
FAN event type: service_member Properties: version=1.0 service=ERP database=FINPROD instance=FINPROD3 host=node3 status=up
表4-1 イベント・レコードのパラメータおよび説明
| パラメータ | 説明 |
|---|---|
|
|
イベント・レコードのバージョン。リリース変更の識別に使用します。 |
|
|
|
|
|
サービスをサポートする一意のデータベース。 |
|
|
サービスをサポートするインスタンスの名前。 |
|
|
サービスまたは停止ノードをサポートするノードの名前。クラスタ同期サービス（CSS）ノード名に該当します。 |
|
|
サービス名。 |
|
|
|
|
|
Failure、Dependency、User、Autostart、Restart。 |
|
|
現在アクティブなサービス・メンバーの数。すべての |
|
|
ノードの |
|
|
通知イベントを順序付ける際に使用するローカル・タイム・ゾーン。 |
FANレコードは、表4-2に示すとおり、各セッションのデータベース署名に該当します。
FANコールアウトは、サーバー側の実行可能ファイルで、高可用性イベントが発生した際に、ただちにOracle RACで実行されます。FANコールアウトを使用すると、クラスタ構成でイベントが発生した場合に、次のようなアクティビティを自動的に実行できます。
障害追跡チケットの発行
ページャへのメッセージ送信
電子メールの送信
サーバー側のアプリケーションの起動および停止
各イベント発生時にイベントを記録したアップタイム・ログの維持
優先度の高いサービスがオンラインになった場合の優先度の低いサービスの再配置
FANコールアウトを使用するには、Oracle Clusterwareを実行しているすべてのノードのCRS_home/racg/usrcoディレクトリに実行可能ファイルを配置します。スクリプトを使用する場合は、実行可能ファイルの最初の行でシェルを設定します。CRS_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
コールアウト・スクリプトの例については、http://www.oracle.com/technology/sample_code/products/rac/のOTN（Oracle Technology Network）で「Oracle Real Application Clusters Sample Code」セクションを参照してください。
FANレコードは、表4-2「FANパラメータおよび該当するデータベース署名」に示すとおり、各セッションのデータベース署名に該当します。署名の情報は、OCI_ATTRIBUTESを使用して参照することもできます。これらの属性は、Oracle Call Interface接続ハンドルで使用できます。この情報を使用すると、FANイベントのデータに該当するセッションでアクションを実行できます。
この項では、ロード・バランシング・アドバイザについて説明します。内容は次のとおりです。
ロード・バランシングは、Oracle RACデータベースで使用可能なすべてのインスタンス間で作業を分散します。アプリケーションでは、特定のサービスを提供するインスタンス間をまたがって実行される、永続的な接続を使用することをお薦めします。接続はあまり頻繁に作成されず、長時間存続します。作業は頻繁にシステムに送られ、この接続を利用します。作業は、比較的短時間存続します。ロード・バランシング・アドバイザは、受け取った作業が、最適なサービス品質を提供するインスタンスに割り当てられるようにアドバイスします。これによって、作業を後で再配置する必要性が最小限に抑えられます。
THROUGHPUT目標またはSERVICE_TIME目標を使用すると、システムにフィードバックが作成されます。作業は、システム全体で最適なサービス時間が実現されるようにルーティングされ、システムの状態変化に透過的に対応します。安定した状態のシステムでは、Oracle RACのすべてのインスタンスでスループットが向上した状態が維持されるようになります。
ロード・バランシング・アドバイザを使用できる標準アーキテクチャには、接続時ロード・バランシング、トランザクション処理モニター、アプリケーション・サーバー、接続コンセントレータ、ハードウェアおよびソフトウェアのロード・バランサ、ジョブ・スケジューラ、バッチ・スケジューラおよびメッセージ・キューイング・システムが含まれます。これらすべてのアプリケーションでは、作業を割り当てることができます。
ロード・バランシング・アドバイザは、リスナー、JDBC暗黙接続キャッシュ、ODP.NET接続プールなどの主要なOracleクライアントに実装されています。また、ロード・バランシング・アドバイザは、ONSを使用してサード・パーティのサブスクリプションが可能です。
ロード・バランシング・アドバイザの追加のパラメータはAFFINITY HINTと呼ばれます。このパラメータは、サービスに目標を設定してロード・バランシング・アドバイザを有効にすると、自動的に有効になります。また、このパラメータは、Webセッションが有効な間存続する一時的なアフィニティ用です。
多くの場合、Webでの対話はセッション全体で何回でも接続と切断が繰り返されます。これらの各接続時、対話によって、ショッピング・カートなどの同じデータまたは類似データにアクセスする場合があります。アフィニティを使用することで、CPU使用率およびトランザクション待機時間が減り、バッファ・キャッシュ効率を上げることができます。AFFINITY HINTパラメータは、アフィニティが特定のインスタンスとサービスの組合せに対してアクティブかどうかを示すフラグです。同じサービスを提供する異なるインスタンスでは、AFFINITY HINTに異なる設定を行うことができます。
Oracle Database 10gまたはOracle Database 11gでは、Universal Connection Pool（UCP）と呼ばれるJavaの接続プールを使用できます。Oracle Database 11gおよびUCPを使用するアプリケーションでは、アフィニティ機能を利用できます。 AFFINITY HINTがロード・バランシング・アドバイザ・イベントで有効になっている場合は、Webセッション用のアフィニティ・コンテキストがUCPによって作成されます。このコンテキストでは、Webセッションでプールから接続を取得すると、プールは初めてセッションを取得した際に接続したインスタンスへの接続を試行します。初回接続時のインスタンスは、ロード・バランシング・アドバイザの情報に基づいて選択します。
ロード・バランシングを有効にする各サービスにサービス・レベルの目標を定義して、ロード・バランシング・アドバイザを使用するように環境を構成できます。これによって、そのサービスのロード・バランシング・アドバイザが有効になり、FANロード・バランシング・イベントが発行されます。実行時のサービス・レベルの目標には、次の2つがあります。
SERVICE_TIME: 応答時間に基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の経過時間およびサービスに対して使用可能な帯域幅に基づきます。SERVICE_TIMEの使用例としては、需要が変動するインターネット・ショッピングなどのワークロードがあります。
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'OE' - , goal => DBMS_SERVICE.GOAL_SERVICE_TIME - , clb_goal => DBMS_SERVICE.CLB_GOAL_SHORT);
THROUGHPUT: スループットに基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の処理速度およびサービスに対して使用可能な帯域幅に基づきます。THROUGHPUTの使用例としては、前のジョブが完了してから次のジョブを開始するバッチ処理などのワークロードがあります。
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'sjob' -
, goal => DBMS_SERVICE.GOAL_THROUGHPUT -
, clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);
目標にNONEを設定すると、サービスのロード・バランシングは無効になります。サービスのゴール設定は、データ・ディクショナリ、DBA_SERVICESビュー、V$SERVICESビューおよびV$ACTIVE_SERVICESビューで確認できます。
ロード・バランシング・アドバイザのFANイベントでは、ロード・バランシング・アルゴリズムのメトリックが提供されます。このイベントを使用する最も簡単な方法は、JDBC、ODP.NET、Oracle Call InterfaceなどのOracle統合クライアントのランタイム接続ロード・バランシング機能を使用することです。クライアント・アプリケーションでは、ONS APIを使用して、これらのイベントを直接サブスクライブできます。表4-3に、ロード・バランシング・アドバイザのFANイベント・パラメータを示します。
表4-3 ロード・バランシング・アドバイザの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 ;
Oracle RACデータベースへの接続に使用される多くの一般的なクライアント・アプリケーション環境は、FANと統合されています。そのため、FANを使用する最も簡単な方法は、Oracle統合クライアントを使用することです。
Oracle Call Interfaceセッション・プール、CMANセッション・プール、JDBC接続プールおよびODP.NET接続プールを使用できます。TAFが有効なOracle Call Interfaceアプリケーションでは、高速フェイルオーバーのためにFAN高可用性イベントを使用します。全体的な目的は、アプリケーションが、常に、最適なサービスを提供する使用可能インスタンスに接続できるようにすることです。FANとの統合によって、Oracle統合クライアントはOracle RACクラスタの最新のステータスをより迅速に認識します。これによって、クライアント接続が待機したり、使用不可能なインスタンスに接続しようとすることはありません。
インスタンスが起動すると、Oracle RACでは、最近起動されたインスタンスへの接続を接続プールで作成し、このインスタンスで提供される追加リソースを接続プールで使用できるように、FANを使用して接続プールに通知します。接続プールおよびFANを使用する場合は、接続プールで使用されているサービスを提供するすべてのインスタンスへのデータベース接続のロード・バランシングが適切に構成されている必要があります。クライアント側とサーバー側の両方のロード・バランシングをOracle Net Servicesで構成することをお薦めします。これは、DBCAを使用してデータベースを作成するときのデフォルトです。FANと統合されたOracle接続プールでは、次の処理を実行できます。
サービスの起動時に、Oracle RACのすべてのインスタンス間で接続を均等に分散します。この方法は、接続プールで定義されているセッションを、サービスがサポートされている最初のOracle RACインスタンスに割り当てるよりも有効です。
終了した接続を削除すると同時に、サービスがインスタンスでDOWNとして宣言され、ノードも同時にDOWNとして宣言されます。
サービスが再起動を繰り返し試行する間クライアントを待機させるかわりに、NOT RESTARTING状態がOracle Databaseで検出されるとすぐにエラーをクライアントにレポートします。
ロード・バランシング・アドバイザのイベントを使用して、実行時の作業要求を均等に分散します。
次の項では、いくつかの特定のクライアント開発環境ごとにFANイベントの有効化方法について説明します。
Oracle JDBC暗黙接続キャッシュでFANを有効にすると、FAN高可用性イベントおよびロード・バランシング・アドバイザが有効化されます。FANを使用する場合、アプリケーションでは、JDBC ThickクライアントまたはJDBC ThinクライアントのどちらのJDBC開発環境でも使用できます。JDBC暗黙接続キャッシュを使用して、高速接続フェイルオーバーおよびランタイム接続ロード・バランシングといったFAN機能を有効にする必要があります。
JDBCクライアントを構成するには、データソースに対して最初のgetConnection()要求を行う前に、FastConnectionFailoverEnabledプロパティを設定します。高速接続フェイルオーバーが有効な場合、フェイルオーバーは、接続キャッシュ内の各接続に対して適用されます。Connection Cache Managerを使用してアプリケーションで明示的に接続キャッシュを作成する場合は、最初にFastConnectionFailoverEnabledを設定する必要があります。
|
関連項目: JDBC暗黙接続キャッシュおよびONSの構成方法の詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』の暗黙接続キャッシュに関する章を参照してください。 |
この項では、JDBCでFANイベントを有効にする方法について説明します。JDBC Thickクライアントで高速接続フェイルオーバーを有効にする場合は、クライアントまたはサービスのいずれのTAFも有効にしないでください。JDBC ThinクライアントまたはJDBC Thickクライアントで高速接続フェイルオーバーを有効にすると、接続プールですべてのFANイベントを受信して、これらのイベントへのアクションを実行できます。高速接続フェイルオーバーを有効にするには、まずUCPまたはJDBC暗黙接続キャッシュを次の手順に従って有効にする必要があります。
キャッシュが有効なデータソースで、次の例に示すように、データソース・プロパティFastConnectionFailoverEnabledにtrueを設定し、Oracle JDBC暗黙接続キャッシュでFANを有効化します。
OracleDataSource ods = new OracleDataSource()
...
ods.setConnectionCachingEnabled(True);
ods.setFastConnectionFailoverEnabled(True);
ods.setConnectionCacheName("MyCache");
ods.setConnectionCacheProperties(cp);
ods.setURL("jdbc:oracle:thin:@(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=VIP1)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=VIP2)(PORT=1521))
(CONNECT_DATA=(service_name=service_name)))");
または、次の構文例に示すように、Java用のUCPを使用し、FastConnectionFailoverEnabledおよびONSConfigurationのPoolDataSourceプロパティを設定します。アプリケーションのCLASSPATHには、ucp.jarとons.jarの両方が必要です。
PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setONSConfiguration("nodes=racnode1:4200,racnode2:4200");
pds.setFastConnectionFailoverEnabled(true);
......
|
注意: -D oracle.jdbc.FastConnectionFailover=trueシステム・プロパティを使用すると、データソースを変更せずに、FANを有効化できます。 |
次の例に示すように、CRS_home/opmn/conf/ons.configを使用して、Oracle Clusterwareを実行中の各ノードでONSが構成されていることを確認します。
|
注意: 通常、ONSの構成は、Oracle RACのインストール時に自動的に完了します。 |
localport=6150 # This is the port ONS is writing to on this node remoteport=6251 # This is the port ONS is listening on this node loglevel=3 useocr=on
ONSデーモンのOracle Cluster Registry（OCR）の情報は、DBCAによって自動的に構成されます。データベースを以前のリリースからアップグレードする場合は、次のように、手動でOCRを構成します。中間層ノードを追加する場合、またはOracle RACノードを更新する場合は、Oracle Clusterwareのbinディレクトリから、racgonsを使用します。
ONSデーモンの構成を追加するには、次のコマンドを実行します。
racgons add_config hostname:port [hostname:port] ...
ONSデーモンの構成を削除するには、次のコマンドを実行します。
racgons remove_config hostname:[port] [hostname:port] ...
リモートONSサブスクリプションを構成します。リモートONSサブスクリプションを使用すると、次のメリットがあります。
すべてのJava中間層ソフトウェアがサポートされます。
クライアント・システムでONSデーモンが不要になります。このプロセスを管理する必要はありません。
データソース・プロパティを使用して、構成作業を簡単に行うことができます。
高速接続フェイルオーバーでリモートONSサブスクリプションを使用する場合、アプリケーションではsetONSConfigurationを使用します。このとき、次の例に示すとおり、Oracleデータソース・インスタンスで文字列remoteONSConfigを使用します。
暗黙接続キャッシュの場合:
ods.setONSConfiguration("nodes=racnode1:4200,racnode2:4200");
UCPの場合:
pds.setONSConfiguration(“nodes=racnode1:4200,racnode2:4200”);
アプリケーションを起動するときに、ons.jarファイルが、アプリケーションのCLASSPATHにあることを確認します。ons.jarファイルはOracleクライアント・インストールの一部で、$ORACLE_HOME/jlibディレクトリにあります。UCPを使用する場合は、ucp.jarもアプリケーションのCLASSPATHに必要です。
|
関連項目: JDBCの詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』を参照してください。 |
OCIクライアントは、Oracle RAC高可用性FANイベントの通知を受信するように登録し、イベント発生時に応答できます。これによって、OCIでのセッションのフェイルオーバーに対する応答時間が短縮されるとともに、接続プールおよびセッション・プールから終了した接続が削除されます。この機能は、TAF、接続プールまたはセッション・プールを使用しているアプリケーションなどのOracle Call Interfaceアプリケーションで実行できます。
まず高可用性イベント用のサービスを有効化する必要があります。これによって、Advanced QueuingのALERT_QUEUEは、自動的に移入されます。アプリケーションでTAFを使用している場合は、サービスのTAF設定を有効にします。Oracle RACデータベースに接続するようにクライアント・アプリケーションを構成します。クライアントには、イベント発生時に使用するコールバックを登録できます。これによって、接続障害が検出されるまでの時間が短縮されます。DOWNイベントの処理中に、Oracle Call Interfaceでは次の処理が実行されます。
問題が発生しているクライアントの接続を終了し、エラーを戻します。
Oracle Call Interface接続プールおよびOCIセッション・プールから接続を削除します。Oracle Call Interfaceセッション・プールでは、各セッションが接続プールの物理的な接続とマッピングされています。1つの接続に複数のセッションが存在する場合もあります。
TAFが構成されている場合、接続をフェイルオーバーします。
TAFが構成されていない場合、クライアントはエラーを受信するのみです。
|
注意: Oracle Call InterfaceではUPイベントは管理されません。 |
Oracle Call Interfaceクライアントに高速接続フェイルオーバーを構成するには、次の手順を実行します。
使用中のサービスのAQ_HA_NOTIFICATIONSの値にTRUEを設定して、サービスでのAdvanced Queuingの通知を有効にします。次に例を示します。
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'gl.us.oracle.com'
, aq_ha_notifications => TRUE
, failover_method => DBMS_SERVICE.FAILOVER_METHOD_BASIC
, failover_type => DBMS_SERVICE.FAILOVER_TYPE_SELECT
, failover_retries => 180
, failover_delay => 5
, clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);
次のように、クライアントでの環境作成時にOCI_EVENTSを有効にします。
( OCIEnvCreate(...) )
クライアント・アプリケーションは、クライアント・スレッドまたはオペレーティング・システムのライブラリとリンクしている必要があります。
オプションで、クライアントのEVENTコールバックが登録されている。
アラート情報を表示するには、DBA_OUTSTANDING_ALERTSビューおよびDBA_ALERT_HISTORYビューを問い合せます。
|
関連項目: OCIの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
Oracle Database 11gリリース（11.1）では、Oracle Call Interfaceセッション・プールによって、動的に管理される事前作成済のデータベース・セッションのセットをアプリケーションの複数スレッドで使用できます。Oracle Databaseでは、インスタンスへのほぼ永続的なチャネルを形成するために、プール内のセッションが継続的に再利用されます。これによって、アプリケーションでセッションが必要となるたびに作成してクローズするオーバーヘッドを削減できます。
Oracle RACでセッション・プールを最大限に最適化するため、要求するスレッドに割り当てられたセッションは、インスタンス・ロードに基づいてインスタンスに適切にマップされます。Oracle Call Interfaceセッション・プールは、Oracle RACのロード・バランシング・アドバイザから受信したサービス・メトリック情報を使用してセッションを割り当てるため、パフォーマンスが向上します。
Oracle Call Interfaceでは、セッションはインスタンス・ロードに基づいてスレッドに動的にマップされます。Oracle Call Interfaceでは、ロード・バランシング・アドバイザによって提供されたサービス・メトリックを使用して、ランタイム接続ロード・バランシングが実行されます。脚注1 特定の時間に、接続の数がスレッドの数を超えることがありますが、最終的にはOracle Call Interfaceによって数が自動調整されるため、ユーザーによる操作は必要ありません。
セッション・プールで複数のインスタンスにまたがるサービスがサポートされている場合は、インスタンス間で作業要求が分散され、より優れたサービスを提供するインスタンスにより多くの要求が割り当てられます。1つのインスタンスのみのサービスをサポートしているセッション・プールの場合、そのプール内で最初に使用可能なセッションが適切なセッションになります。
Oracle Database 10g リリース2（10.2）以上を実行しているサーバーと通信するOracle Database 11g リリース1（11.1）以上のクライアントでは、ランタイム接続ロード・バランシングがデフォルトで有効になっています。ランタイム接続ロード・バランシングを無効にするには、OCISessionPoolCreate()のコール時にモード・パラメータをOCI_SPC_NO_RLBに設定します。
Oracle Data Provider for .NET（ODP.NET）の接続プールでは、ノード、サービスおよびサービス・メンバーが停止したことを示す通知をサブスクライブできます。DOWNイベントが発生すると、停止するインスタンスに送られる接続プール内のセッションは削除されます。また、ODP.NETは、無効になった接続を事前に削除します。切断された接続が削除されたために、接続の合計数がMIN_POOL_SIZEパラメータに設定されている値より小さくなった場合、ODP.NETは、既存のOracle RACインスタンスへの接続を確立します。
ODP.NETを有効化する手順は、高速接続フェイルオーバーを有効化するために接続文字列のパラメータの設定が必要なJDBCを有効化する手順に類似しています。FANを有効にするには、次の手順を実行します。
次の例に示すように、DBMS.SERVICEパッケージを使用して、Advanced Queuingの通知を有効にします。
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'gl.us.oracle.com'
, aq_ha_notifications => TRUE
, clb_goal => DBMS_SERVICE.CLB_GOAL_LONG;
.Net Applicationから接続するユーザーに対して次のコマンドを実行します。user_nameはユーザー名です。
execute dbms_aqadm.grant_queue_privilege('DEQUEUE','SYS.SYS$SERVICE_METRICS', user_name);
FAN高可用性イベントをサブスクライブして、ODP.NET接続プールの高速接続フェイルオーバーを有効にします。これを実行するには、接続時に接続文字列属性HA Eventsにtrueを設定します。これは、接続プールを使用している場合にのみ実行できます。つまり、属性poolingにtrue（デフォルト）が設定されている場合に、これを実行します。次の例では、これを詳細に示します。user_nameはユーザー名、passwordはパスワードです。
// 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=user_name;Password=password;Data Source=oracle;" +
"Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" +
"HA Events=true;Incr Pool Size=5;Decr Pool Size=2";
con.Open();
// Create more connections and carry out work against the DB here.
// Dispose OracleConnection object
con.Dispose();
}
}
ODP.NETを有効化して、FANロード・バランシング・アドバイザのイベントを受信するには、次の手順を実行します。
次の例に示すように、DBMS.SERVICEパッケージを使用し、サービスのGOALおよびCLB_GOALを設定して、Advanced Queuingの通知を有効にします。
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'gl.us.oracle.com'
, failover_method => DBMS_SERVICE.FAILOVER_METHOD_BASIC
, failover_type => DBMS_SERVICE.FAILOVER_TYPE_SELECT
, failover_retries => 180
, failover_delay => 5
, clb_goal => DBMS_SERVICE.CLB_GOAL_LONG
, goal => DBMS_SERVICE.GOAL_SERVICE_TIME);
接続時ロード・バランシングのためにOracle Net Servicesが構成されていることを確認します。
.Net Applicationから接続するユーザーに対して次のコマンドを実行します。user_nameはユーザー名です。
execute dbms_aqadm.grant_queue_privilege('DEQUEUE','SYS.SYS$SERVICE_METRICS', user_name);
ロード・バランシング文字列にTRUEを設定して、ODP.NET接続プールでロード・バランシング・イベントを利用するように構成します（デフォルトはFALSE）。この処理は、接続時に実行できます。接続プールを使用している場合、またはpooling属性にTRUE（デフォルト）が設定されている場合にのみ、この処理を実行できます。次に例を示します。user_nameはユーザー名、passwordはパスワードです。
// C#
using System;
using Oracle.DataAccess.Client;
class LoadBalancingEnablingSample
{
static void Main()
{
OracleConnection con = new OracleConnection();
// Open a connection using ConnectionString attributes
// Also, enable "load balancing"
con.ConnectionString =
"User Id=user_name;Password=password;Data Source=oracle;" +
"Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" +
"Load Balancing=true;Incr Pool Size=5;Decr Pool Size=2";
con.Open();
// Create more connections and carry out work against the DB here.
// Dispose OracleConnection object
con.Dispose();
}
}
|
関連項目: ODP.NETの詳細は、『Oracle Data Provider for .NET開発者ガイド』を参照してください。DBMS_SERVICES PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
|
注意: ODP.NETでは、ノード起動時の接続の再分散はサポートしていません。ただし、サーバー側でフェイルオーバーが有効になっている場合は、ODP.NETで、使用可能インスタンスに接続を移行できます。 |
Oracle RACデータベース環境で接続障害が発生したときに、SQLSetConnectAttr関数のSQL_ORCLATTR_FAILOVER_CALLBACKおよびSQL_ORCLATTR_FAILOVER_HANDLE属性が設定されていると、イベント通知は有効になります。新しい属性のシンボルは、sqora.hファイルで定義します。SQL_ORCLATTR_FAILOVER_CALLBACK属性は、障害イベント発生時にコールするルーチンのアドレスを指定する場合に使用します。
SQL_ORCLATTR_FAILOVER_HANDLE属性は、コールバック・ルーチンでいずれかのパラメータとして渡されるコンテキスト・ハンドルを指定する場合に使用します。この属性は、ODBCアプリケーションで障害イベントが発生している接続を指定する場合に必要です。
コールバック・ルーチンの関数プロトタイプは、次のようになります。
void failover_callback(void *handle, SQLINTEGER fo_code)
handleパラメータは、SQL_ORCLATTR_FAILOVER_HANDLE属性によって設定された値です。属性が設定されていない場合は、NULLが戻されます。
fo_codeパラメータによって、発生している障害イベントを識別します。障害イベントは、OCIプログラミング・インタフェースで定義されたイベントに直接マップされます。発生する可能性のあるイベントは、次のとおりです。
次にこの機能の使用方法を示すサンプル・プログラムを示します。user_nameはユーザー名、passwordはパスワードです。
/*
NAME
ODBCCallbackTestDESCRIPTION
Program to demonstrate the connection failover callback feature.PUBLIC FUNCTION(S)
mainPRIVATE FUNCTION(S)NOTESCommand Line: ODBCCallbackTest filename [odbc-driver]*/
#include <malloc.h>
#include <stdio.h>
#include <string.h>
#include <sql.h>
#include <sqlext.h>
#include <sqora.h>
#define TRUE 1
#define FALSE 0
/*
* Funtion Prototypes
*/
void display_errors(SQLSMALLINT HandleType, SQLHANDLE Handle);
void failover_callback(void *Handle, SQLINTEGER fo_code);
/*
* Macros
*/
#define ODBC_STS_CHECK(sts) \
if (sts != SQL_SUCCESS) \
{ \
display_errors(SQL_HANDLE_ENV, hEnv); \
display_errors(SQL_HANDLE_DBC, hDbc); \
display_errors(SQL_HANDLE_STMT, hStmt); \
return FALSE; \
}
/*
* ODBC Handles
*/
SQLHENV *hEnv = NULL; // ODBC Environment Handle
SQLHANDLE *hDbc = NULL; // ODBC Connection Handle
SQLHANDLE *hStmt = NULL; // ODBC Statement Handle
/*
* MAIN Routine
*/
main(int argc, char **argv)
{
SQLRETURN rc;
/*
* Connection Information
*/
SQLTCHAR *dsn = "odbctest";
SQLTCHAR *uid = "user_name";
SQLTCHAR *pwd = "password";
SQLTCHAR *szSelect = "select * from emp";
/*
* Allocate handles
*/
rc = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, (SQLHANDLE *)&hEnv);
ODBC_STS_CHECK(rc)
rc = SQLSetEnvAttr(hEnv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0);
ODBC_STS_CHECK(rc);
rc = SQLAllocHandle(SQL_HANDLE_DBC, hEnv, (SQLHANDLE *)&hDbc);
ODBC_STS_CHECK(rc);
/*
* Connect to the database
*/
rc = SQLConnect(hDbc, dsn, (SQLSMALLINT)strlen(dsn),
uid, (SQLSMALLINT)strlen(uid),
pwd, (SQLSMALLINT)strlen(pwd));
ODBC_STS_CHECK(rc);
/*
* Set the connection failover attributes
*/
rc = SQLSetConnectAttr(hDbc, SQL_ORCLATTR_FAILOVER_CALLBACK, &failover_callback,0);
ODBC_STS_CHECK(rc);
rc = SQLSetConnectAttr(hDbc, SQL_ORCLATTR_FAILOVER_HANDLE, hDbc, 0);
ODBC_STS_CHECK(rc);
/*
* Allocate the statement handle
*/
rc = SQLAllocHandle(SQL_HANDLE_STMT, hDbc, (SQLHANDLE *)&hStmt);
ODBC_STS_CHECK(rc);
/*
* Wait for connection failovers
*/
while (TRUE)
{
sleep(5000);
rc = SQLExecDirect(hStmt,szSelect, strlen(szSelect));
ODBC_STS_CHECK(rc);
rc = SQLFreeStmt(hStmt, SQL_CLOSE);
ODBC_STS_CHECK(rc);
}
/*
* Free up the handles and close the connection
*/
rc = SQLFreeHandle(SQL_HANDLE_STMT, hStmt);
ODBC_STS_CHECK(rc);
rc = SQLDisconnect(hDbc);
ODBC_STS_CHECK(rc);
rc = SQLFreeHandle(SQL_HANDLE_DBC, hDbc);
ODBC_STS_CHECK(rc);
rc = SQLFreeHandle(SQL_HANDLE_ENV, hEnv);
ODBC_STS_CHECK(rc);
return TRUE;
}
/*
* Failover Callback Routine
*/
void failover_callback(void *Handle, SQLINTEGER fo_code)
{
switch (fo_code)
{
case ODBC_FO_BEGIN:
printf("ODBC_FO_BEGIN recevied");
break;
case ODBC_FO_ERROR:
printf("ODBC_FO_ERROR recevied");
break;
case ODBC_FO_ABORT:
printf("ODBC_FO_ABORT recevied");
break;
case ODBC_FO_REAUTH:
printf("ODBC_FO_REAUTH recevied");
break;
case ODBC_FO_END:
printf("ODBC_FO_END recevied");
break;
default:
printf("Invalid or unknown ODBC failover code recevied");
break;
};
return;
}
/*
* Retrieve the errors associated with the handle passed
* and display them.
*/
void display_errors(SQLSMALLINT HandleType, SQLHANDLE Handle)
{
SQLTCHAR MessageText[256];
SQLTCHAR SqlState[5+1];
SQLSMALLINT i=1;
SQLINTEGER NativeError;
SQLSMALLINT TextLength;
SQLRETURN sts = SQL_SUCCESS;
if (Handle == NULL) return;
/*
* Make sure all SQLState text is null terminated
*/
SqlState[5] = '\0';
/*
* Fetch and display all diagnostic records that exist for this handle
*/
while (sts == SQL_SUCCESS)
{
NativeError = 0;
TextLength = 0;
sts = SQLGetDiagRec(HandleType, Handle, i, SqlState, &NativeError,
(SQLTCHAR *)&MessageText, sizeof(MessageText),&TextLength);
if (sts == SQL_SUCCESS)
{
printf("[%s]%s\n",NativeError, &MessageText);
if (NativeError != 0)
{
printf("Native Error Code: %d", NativeError);
}
i++;
}
}
return;
}
XAトランザクションは、デフォルトでOracle RACインスタンス間をまたがって実行可能であり、XAを使用するアプリケーションは、Oracle RAC環境のメリットをフルに活用してアプリケーションの可用性とスケーラビリティを高めることができます。
この機能は、デフォルトで1に設定されているGLOBAL_TXN_PROCESSES初期化パラメータを使用して制御されます。このパラメータには、Oracle RACインスタンスごとのGTXnバックグラウンド・プロセスの初期数が指定されます。クラスタ全体でこのパラメータをデフォルト値のままにし、2つ以上のOracle RACインスタンス間にまたがる分散トランザクションの実行を可能にします。
これによって、これらのOracle RACインスタンス間で実行される作業単位はリソースを共有し、単一のトランザクション（つまり、作業単位は密結合）として機能できます。さらに、クラスタ内のノードに2PC要求を送信できます。密結合XAトランザクションでは、特殊なタイプの単一のサービス（つまり、Oracle分散トランザクション処理（DTP）サービス）をOracle RACデータベースにデプロイする必要はなくなりました。XAトランザクションは、Oracle RACデータベース上であらゆるタイプのサービス構成によって透過的にサポートされています。
UCPを使用してOracle RAC 11g リリース1(11.1)データベースに接続しているアプリケーションの「高速接続フェイルオーバー」をtrueに設定すると、XAアフィニティを利用できます。グローバル・トランザクション内の最初のデータベース接続では、UCPはロード・バランシング・アドバイザを使用してデータベース接続を取得します。データベースへの後続のすべてのアクセスではアフィニティが使用され、初期リクエストと同じインスタンスに送信されます。
|
関連項目: Oracle RACでのOracle XAの使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。GLOBAL_TXN_PROCESSES初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
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つのインスタンスで実行されるため、すべてのインスタンスを使用して、複数の単一のサービスを介して、多数のDTPトランザクションの負荷を均等に分散できます。これによって、アプリケーションのスループットを最大限に向上できます。
OraMTSなどの外部トランザクション・マネージャは、DTP/XAトランザクションを調整します。ただし、Oracleの内部トランザクション・マネージャが、分散SQLトランザクションを調整します。DTP/XAと分散SQLトランザクションは、両方ともOracle RACのDTPサービスを使用する必要があります。
クラスタ・データベースでノードを追加または削除した場合、最適なパフォーマンス・レベルを維持するために、DTPトランザクションに使用しているサービスの確認と再配置が必要になる場合があります。
|
関連項目: Oracle RACでのトランザクション・ブランチの管理の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
分散トランザクション処理で使用するサービスの場合、Oracle Enterprise ManagerまたはSRVCTLを使用してサービスを作成し、優先インスタンスに1つのインスタンスのみを定義します。AVAILABLEインスタンスは、任意の数を定義できます。たとえば、次のSRVCTLコマンドを実行すると、データベースcrm用の単一のサービスxa_01.service.us.oracle.comが作成されます。このサービスの優先インスタンスは、RAC01です。
srvctl add service -d crm -s xa_01.service.us.oracle.com -r RAC01 -a RAC02, RAC03
次に、DTPパラメータにTRUEを設定して（デフォルトはFALSE）、分散トランザクション処理用のサービスとしてマーク付けします。Oracle Enterprise Managerでは、「クラスタ管理データベース・サービス」の「サービスの作成」ページまたは「サービスの変更」ページで、このパラメータを設定できます。また、DBMS_SERVICEパッケージを使用して、単一のサービスのDTPプロパティを変更することもできます。次に例を示します。
EXECUTE DBMS_SERVICE.MODIFY_SERVICE(service_name =>'xa_01.service.us.oracle.com', DTP=>TRUE);
たとえば、（サービスXA_01を提供する）RAC01が失敗した場合、提供されていた単一のサービスは、RAC02やRAC03などの他のインスタンスの1つにフェイルオーバーされます。
Oracle RACデータベースがコールド・スタートされたために、サービスが他のインスタンスに移行されている場合は、サービスを強制的に再配置して、使用可能なすべてのハードウェアに負荷を均等に分散させる必要がある場合があります。この処理が必要かどうかを確認するには、GV$ACTIVE_SERVICESビューからのデータを使用します。
サービスを作成して管理する場合、データベースで実行する作業を管理しやすい単位に分割します。サービスを使用する目的は、データベース・インフラストラクチャを最大限有効に利用できるようにするためです。サービスの作成およびデプロイは、ユーザーがビジネス要件に基づいて実行できます。また、Oracle Databaseで各サービスのパフォーマンスを計測できます。サービス内のアプリケーション・モジュールおよびモジュールの個別のアクションを定義して、アクションのしきい値を監視できます。これによって、ワークロードを管理して必要な容量を供給することができます。
データベースに新しいサービスを作成した場合、各サービスの自動ワークロード管理の特性を定義する必要があります。サービスの特性には、次のものが含まれます。
サービスを識別する一意のグローバル名。
クライアントがサービスへの接続に使用するOracle Net Services名。
通常の実行環境でサービスが実行される優先インスタンス。
優先インスタンスのいずれかで障害が発生した場合に、サービスが実行される使用可能インスタンス。
最適なサービス品質（単一のトランザクションが完了した効率）または最適なスループット（完了ジョブまたは長時間の問合せが完了した効率）のどちらに基づいてサービスに接続するかを決定するするサービスの目標。この決定は、ロード・バランシング・アドバイザによって行われます。
サービスを分散トランザクションに使用するかどうかを決定するインジケータ。
Advanced Queuingを介してOracle RAC高可用性イベントを受信するように登録されたOCIクライアントおよびODP.NETクライアントにこれらのイベントを送信するかどうかを決定するインジケータ。
セッションのフェイルオーバーの特性。たとえば、フェイルオーバーを行うかどうか、フェイルオーバーが発生したインスタンスでセッションが既存の接続を使用できるかどうか、フェイルオーバーが発生したセッションで中断した問合せの処理を続行できるかどうか、など。サービスの定義では、障害が発生したセッションがサービスへの再接続を試行する回数、および再接続を再試行する間の待機時間も定義します。また、サービスの定義には、サービスを提供するインスタンス間で接続要求を均等に分散する方法をリスナーに対して指定する、接続時ロード・バランシングの目標も含まれます。
各サービスのロード・バランシング接続方式。この方式は、Oracle Databaseで接続が作成される際にリスナーで使用されます。接続は、リスナーにセッションベースで接続を使用するように指定するLONG（接続プールやSQL*FORMSなど）またはリスナーにCPUベースで接続を使用するように指定するSHORTに分類されます。ロード・バランシング・アドバイザが有効になっている場合、この情報を使用して、接続が均等に分散されます。そうでない場合は、CPUの使用状況が使用されます。
サービスの作成に加えて、次の作業が必要になる場合もあります。
サービスの削除。作成したサービスは削除できます。ただし、Oracle Databaseで作成されたデフォルトのデータベース・サービスのプロパティは、削除したり、変更することはできません。
サービスのステータスの確認。サービスは、使用可能インスタンスごとに別々のロールが割り当てられる場合があります。多くのサービスを使用する複雑なデータベースでは、すべてのサービスの詳細を把握しておくことは困難な場合があります。そのため、インスタンスごとまたはサービスごとにステータスの確認が必要になる場合があります。たとえば、特定のインスタンス、または特定のインスタンスを実行するOracleホームに変更を加える前に、このインスタンスのサービスのステータスの確認が必要な場合があります。
データベースまたはインスタンスのサービスの起動および停止。インスタンスへのクライアント接続に使用するサービスは、事前に起動されている必要があります。たとえば、サーバー制御ユーティリティ（SRVCTL）・コマンドsrvctl stop database -d database_nameを実行してデータベースを停止した場合（database_nameは停止するデータベース名）、指定したデータベースへのすべてサービスが停止されます。データベースを起動する場合、これらのサービスを手動で再起動する必要があります。
サービスのコンシューマ・グループへのマッピング。サービスをリソース・マネージャのコンシューマ・グループに自動的にマッピングして、サービスがインスタンスで使用可能なリソース量を制限することができます。コンシューマ・グループを作成し、サービスをこのグループにマッピングする必要があります。
|
関連項目: DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING_PRIプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
データベースまたはインスタンスのサービスの有効化および無効化。デフォルトでは、障害が発生すると、Oracle Clusterwareはサービスの再起動を自動的に試行します。サービスを無効化して、この動作を実行しないように構成することもできます。サービスの無効化は、データベースまたはインスタンスのメンテナンスを実行する場合に便利です。たとえば、アップグレードを実行する際に接続要求を防止することができます。
別のインスタンスへのサービスの再配置。たとえば、クラスタ・ノードを追加または削除した後に、あるインスタンスから別のインスタンスにサービスを移動して、ワークロードを再分散させることができます。
SQL文をパラレルに実行する場合は、初めにデータベースに接続したサービスを提供するインスタンスでのみパラレル・プロセスが実行されます。これはデフォルトの動作です。これによって、パラレル・リカバリやGV$問合せの処理などの他のパラレル操作が影響を受けることはありません。この動作を無効にするには、PARALLEL_INSTANCE_GROUP初期化パラメータに値を設定します。
Oracle Enterprise ManagerおよびDBMS_SERVICE PL/SQLパッケージを使用して、サービスを作成および管理できます。また、SRVCTLユーティリティを使用すると、ほとんどのサービス管理タスクを実行できます。次の項では、これらのツールを使用して、サービスに関連するタスクを実行する方法について説明します。
サービスに関連するタスクを開始する際の中心ページは、「クラスタ管理データベース・サービス」ページです。このページにアクセスするには、クラスタ・データベースの「可用性」ページに移動し、「サービス」セクションの「クラスタ管理データベース・サービス」をクリックします。このページおよびこのページのドリルダウンを使用して、次の処理を実行できます。
クラスタのサービス・リストの表示
現在、各サービスを実行しているインスタンスの表示
各サービスのステータスの表示
サービスの作成および編集
サービスの起動および停止
サービスの有効化および無効化
サービスのインスタンスレベルのタスクの実行
サービスの削除
|
関連項目: Oracle Enterprise Managerを使用したサービスの管理の詳細は、『Oracle Enterprise Manager概要』を参照してください。 |
Oracle Enterprise Managerの次のページから、後述するサービス関連のタスクを実行できます。
「クラスタ管理データベース・サービス」ページでは、次の処理を実行できます。
クラスタのサービス、各サービスが現在実行されているインスタンス、および各サービスのステータスのリストの表示
サービスの起動、停止、有効化または無効化
「サービスの作成」ページおよび「サービスの編集」ページへのアクセス
サービスのインスタンスレベルのタスクを実行できる「サービスの詳細」ページへのアクセス
サービスの接続テスト
「クラスタ管理データベース・サービス」の「詳細」ページでは、次の処理を実行できます。
すべての優先インスタンスおよび使用可能インスタンスのサービスのステータスの表示。ステータスは、Running、Stopped、Disabledのいずれかです。
クラスタ・データベースのインスタンスのサービスの停止および起動
クラスタ・データベースのインスタンスのサービスの無効化および有効化
サービスの負荷を手動で再分散するためのサービスの再配置
「サービスの作成」ページでは、次の処理を実行できます。
名前、高可用性属性およびパフォーマンス属性を指定したサービスの作成
クラスタ・データベースに構成されている各インスタンスでの任意のサービス・ポリシーの選択
TAFポリシーなどの任意のサービスのプロパティの選択。（これによって、クライアント側のTAFが構成されます。サービスのTAFポリシーを設定するには、DBMS_SERVICEパッケージを使用します。）また、通知プロパティ、ロード・バランシングの目標、アラート・レベルおよびリソース管理プロパティを設定することもできます。
|
関連項目: TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
「クラスタ管理データベース・サービス」ページおよびサービス・インスタンスの詳細ページにアクセスするには、次の手順を実行します。
クラスタ・データベースの「ホーム」ページで、「可用性」タブをクリックします。
クラスタ・データベースの「可用性」ページで、「高可用性」オプション・リストの「サービス」ヘッダーで「クラスタ管理データベース・サービス」をクリックします。「クラスタ管理データベース・サービス: クラスタおよびデータベースのログイン」ページが表示されます。
データベース、およびクラスタ・データベースをホスティングしているクラスタの資格証明を入力し、「続行」をクリックします。「クラスタ管理データベース・サービス」ページが表示され、クラスタ・データベース・インスタンスで使用可能なサービスが表示されます。このページでタスクを実行する方法の詳細は、このページのオンライン・ヘルプを参照してください。
|
注意: クラスタ・データベースへアクセスするには、SYSDBA資格証明を所有している必要があります。「クラスタ管理データベース・サービス」では、SYSDBA以外での接続は許可されません。 |
インスタンスレベルでサービスを管理するには、まず「サービス名」をクリックするか、サービス名を選択します。次に「アクション」ドロップダウン・リストで「管理」を選択し、「実行」をクリックします。サービスの「クラスタ管理データベース・サービス」の「詳細」ページが表示されます。このページでタスクを実行する方法の詳細は、このページのオンライン・ヘルプを参照してください。
「再配置」ページにアクセスする手順は、次のとおりです。
前の一連の手順の手順1から3を実行します。
「クラスタ管理データベース・サービス」ページで、サービス名をクリックするか、サービス名を選択します。次に「アクション」ドロップダウン・リストで「管理」を選択し、「実行」をクリックします。サービスの「クラスタ管理データベース・サービス」の「詳細」ページが表示されます。
「再配置」をクリックします。「インスタンスからサービスを再配置」ページが表示されます。このページでは、サービスのロード・バランシングを手動で実行できます。このページでタスクを実行する方法の詳細は、このページのオンライン・ヘルプを参照してください。
表4-4に示すPL/SQLのDBMS_SERVICEパッケージ・プロシージャを使用して、サービスを管理できます。
|
注意: Oracle RAC環境のサービスの作成には、Oracle Enterprise Managerを使用することをお薦めします。 |
表4-4 サービス管理用のDBMS_SERVICEパッケージ・プロシージャ
| プロシージャ | 説明 |
|---|---|
|
Oracle RACデータベースに新しいサービスを追加します。
Oracle RACでサービスを使用する場合、Oracle Enterprise Managerまたは |
|
|
1つ以上のサービスの特性を変更します。 |
|
|
既存のサービスを削除します。 |
|
|
接続中のインスタンス、指定したインスタンスまたはすべてのインスタンスでサービスを起動します。 |
|
|
接続中のインスタンス、指定したインスタンスまたはすべてのインスタンスでサービスを停止します。 |
|
|
接続中のインスタンスまたはPL/SQLプロシージャが実行されるインスタンスのすべてのセッションを終了します。 |
|
関連項目: CREATE_SERVICEプロシージャの構文およびこの項で説明するその他のプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
また、TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
SRVCTLを使用してサービスを作成した場合、別のSRVCTLコマンドでそのサービスを起動する必要があります。一方、後で手動でサービスを停止または再起動する必要がある場合もあります。さらに、自動的な再起動が実行されないようにサービスを無効化したり、サービスを手動で再配置したり、サービスに関するステータス情報を取得することもあります。次の項では、SRVCTLを使用して次の管理タスクを実行する方法について説明します。
SRVCTLを使用してサービスを作成するには、コマンドラインから次の構文を使用したコマンドを入力します。
srvctl add service -d database_unique_name -s service_name -r preferred_list [-a available_list] [-P TAF_policy]
|
注意: SERVICE_NAMESパラメータのエントリには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]
サービスを有効化および無効化するには、コマンドラインから次の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コマンドを実行します。たとえば、次のコマンドを実行すると、crmデータベースで実行中のcrmサービスのステータスが戻されます。
srvctl status service -d apps -s crm
サービスを使用することで、より効果的なパフォーマンスのチューニングを行うことができます。サービスによって、ワークロードを認識して測定でき、リソース使用量および待機時間をアプリケーションの属性として指定できます。すべてのセッションが匿名で共有されている多くのシステムでは、セッションおよびSQLを使用したチューニングのかわりに、サービスおよびSQLを使用したチューニングを実行します。
自動ワークロード・リポジトリ（AWR）では、データベースで実行されているすべてのサービスと作業の応答時間、スループット、リソース使用量および待機イベントの情報など、パフォーマンス統計が保持されます。また、サービスのメトリック、統計、待機イベント、待機クラスおよびSQLレベルのトレースも保持されます。さらに、オプションとして、特定の統計を監視するためのモジュールをアプリケーションで定義して、これらの統計をカスタマイズできます。また、このモジュール内に、重要なビジネス・トランザクションで特定の統計値に応答して実行されるアクションを定義することもできますモジュールおよびアクションによる監視を有効にするには、次のようにDBMS_MONTIOR PL/SQLパッケージを使用します。
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);
監視が有効化されたことを確認するには、DBA_ENABLED_AGGREGATIONSビューを使用します。
サービスによる統計の収集およびトレースは、Oracle RACデータベース全体を対象とします。また、Oracle RACデータベースとシングル・インスタンスのOracle Databaseのどちらの場合も、インスタンスの再起動やサービスの再配置が行われても統計情報は失われません。
サービス名、モジュール名およびアクション名は、V$SESSION、V$ACTIVE_SESSION_HISTORYおよびV$SQLビューで確認できます。コール回数およびパフォーマンス統計は、V$SERVICE_STATS、V$SERVICE_EVENTS、V$SERVICE_WAIT_CLASSES、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 ;
サービス・レベルのしきい値を使用すると、実際のサービス・レベルと最小限の必須サービス・レベルを比較できます。これによって、満足するサービス・レベルが提供されているかどうかを認識できます。最終的な目標は、基準を満たしたサービス・レベルを提供する、予測可能なシステムを構成することです。最小限のリソース使用量で可能なかぎり速い処理を実行することが必要なのではなく、サービスの品質を満たすことが必要です。
各サービスでは、コールの応答時間（SERVICE_ELAPSED_TIME）およびコールのCPUタイム（SERVICE_CPU_TIME）の2つのパフォーマンスに関するしきい値を明示的に指定できます。応答時間は、経過時間が特定の値を超えていないことを確認するために使用します。また、応答時間は実際の時間を表します。応答時間は、ユーザーのためのコールの実行に支障を与える可能性があるすべての遅延および障害を反映する基本的な測定単位です。また、応答時間では、Oracle RACデータベース全体のノード間における、ノード別の処理能力も確認できます。サービス時間およびCPUタイムは、サーバー側のコールの経過時間を移動平均法で算出した時間です。AWRでは、サービス時間に加えてCPUタイムも監視され、パフォーマンスがしきい値を超えた場合には、AWRアラートが発行されます。アラートが発行された場合は、ジョブの優先順位を変更したり、オーバーロード状態になったプロセスを停止したり、サービスを再配置、拡大、縮小、起動、または停止して応答します。これによって、需要量に変動が発生した場合でも、サービスの可用性を維持できます。
payrollサービスのしきい値を確認するために、AWRレポートを使用します。システムが最適な状態で稼働していた際の連続したいくつかの時間間隔で、レポートの出力結果を記録する必要があります。たとえば、メール・サーバーで、毎週月曜日に使用率がピークに達する午前10時から午後2時までのAWRレポートを実行すると仮定します。AWRレポートには、各サービスのコールに対する応答時間（DBタイム）およびCPUの使用時間（CPUタイム）が記録されます。また、AWRレポートには、完了した作業の明細および応答時間に影響を与えた待機時間も記録されます。
DBMS_MONITORを使用して、payrollサービスの警告のしきい値に0.5秒、payrollサービスの重要な警告のしきい値に0.75秒を設定します。Oracle RACデータベース内のすべてのインスタンスのしきい値を設定する必要があります。Oracle Enterprise Managerのアラート用のジョブを使用して、アクションをスケジュールできます。また、アラートを受信したときにアクションが発生するように、プログラムにスケジュールすることもできます。この例では、servallサービスのしきい値を追加し、次のように設定しています。
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 => 'servall');
しきい値の構成を確認する場合は、次の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: ランタイム接続ロード・バランシングは、基本的には、最適な作業を提供するセッション・プール内のセッションへの作業要求のルーティングです。これは、既存のセッション・プールからセッションを選択すると、有効になります。このため、ランタイム接続ロード・バランシングは、きわめて頻繁に発生するアクティビティです。