9.3 ランタイム接続ロード・バランシングについて
この項には次のサブセクションが含まれます:
9.3.1 実行時接続ロード・バランシングの概要
Oracle Real Application Clusters環境では、接続は関連サービスを提供するインスタンスに属しています。すべてのインスタンスが等しく実行され、接続がキャッシュからランダムに取り出されるのが最も理想的です。しかし、あるインスタンスのパフォーマンスが他のインスタンスを上回る場合、接続をランダムに選択すると効率が悪くなります。実行時接続ロード・バランシング機能を使用すると、最適なパフォーマンスを提供するインスタンスに作業要求がルーティングされるため、作業を再配置する必要が最小限になります。
UCP JDBC接続プールは、Oracle RACデータベースが提供するロード・バランシング機能を利用します。実行時接続ロード・バランシングには、Oracle JDBCドライバおよびOracle RACデータベースを使用する必要があります。
実行時接続ロード・バランシングは、次の場合に便利です。
-
従来のワークロード・バランシングが最適でない場合
-
クラスタ・データベース内のリソースを最大限に利用するようにリクエストをルーティングする必要がある場合
-
クラスタ内の許容量が異なり、時間とともに変化することが予想される場合
-
低速なノード、ハングアップしたノードおよびデッド・ノードに作業を送信しないようにする要件が必須である場合
UCPは、Oracle RACロード・バランシング・アドバイザを使用します。このアドバイザを使用して、Oracle RACインスタンス間の作業のバランスをとり、最高のパフォーマンスを発揮するインスタンスを特定します。アプリケーションは、最高のパフォーマンスを発揮するインスタンスから透過的に接続を受け取ります。速度が落ちたインスタンス、レスポンスを返さないインスタンスまたは障害が発生したインスタンスからは、ただちに接続リクエストが変更されます。
-
高いパフォーマンスおよびスケーラビリティのためにプールされた接続を管理します。
-
データベース・インスタンスにルーティングする作業の比率の推奨値を継続的に受け取ります。
-
CPU性能またはレスポンス時間など、様々なバックエンド・ノードの能力に基づいて作業の分散を調整します。
-
クラスタ構成の変更、アプリケーション・ワークロード、過度に使用されているノード、ハングアップにすばやく対応します。
-
Oracle RACロード・バランシング・アドバイザからメトリックを受け取ります。パフォーマンスが良好なインスタンスへの接続が最もよく使用されます。パフォーマンスが低いインスタンスへの新しい未使用の接続は、時間とともに使用されなくなります。分散メトリックを受け取らない場合、接続はランダムに選択されます。
9.3.2 実行時接続ロード・バランシングの設定
実行時接続ロード・バランシングには、FCFが有効であり、適切に構成されていることが必要です。
また、ロード・バランシングを有効にする各サービスのサービス・レベルの目標を使用してOracle RACロード・バランシング・アドバイザを構成する必要があります。
-
サービス目標は、次のいずれかに設定する必要があります。
-
DBMS_SERVICE.SERVICE_TIME -
DBMS_SERVICE.THROUGHPUT
サービス目標は
goalパラメータを使用して、接続バランシング目標はclb_goalパラメータを使用して設定できます。 -
-
接続バランシング目標は
SHORTに設定する必要があります。次に例を示します。EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'sjob' -, goal => DBMS_SERVICE.GOAL_THROUGHPUT -, clb_goal => DBMS_SERVICE.CLB_GOAL_SHORT);
または
EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'sjob' -, goal => DBMS_SERVICE.GOAL_SERVICE_TIME -, clb_goal => DBMS_SERVICE.CLB_GOAL_SHORT);
DBMS_SERVICE.create_serviceプロシージャをコールして、接続バランシング目標も設定できます。
注意:
接続バランシング目標は、LONGに設定することができます。ただし、これはクローズされたワークロードに対して、つまり完了した作業の割合と新しく始める作業の割合が等しいときに、最も有効です。