| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.1.2) E48088-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.1.2) E48088-03 |
|
前 |
次 |
この章では、Active GridLink (AGL)データ・ソースの構成方法とチューニング方法について説明します。
単一のAGLデータ・ソースにより、WebLogic Serverと、1つ以上のOracle RACクラスタが含まれるOracle Databaseサービスとの間の接続を提供します。Oracle Databaseサービスとは、共通属性を持つワークロードのことです。このサービスにより、管理者は単一のエンティティとしてワークロードを管理できます。AGLデータ・ソースの数は、Oracle RACクラスタのノード数に合わせるのではなく、データベース内でのサービス数の増加に合わせてスケールします。複数クラスタの高可用性サポートには、Data Guard、GoldenGate、Global Database Serviceなどがあります。
|
注意: Active GridLinkとマルチ・データ・ソースは、Oracle RACクラスタと連動するように設計されています。汎用データ・ソースをOracle RACクラスタとともに使用することはお薦めしません。「AGLとマルチ・データ・ソースの比較」を参照してください。 |
AGLデータ・ソースには、汎用データ・ソースの機能に加え、Oracle RACに対する次のサポートが含まれています。
AGLデータ・ソースは、高速接続フェイルオーバーを使用します。また、Oracle Notification Service (ONS)を使用したOracle RACイベントに応答します。これにより、AGLデータ・ソースの接続プールには確実に有効な接続(予約済の接続を含む)が格納されるようになり、接続のポーリングやテストの必要がなくなります。さらに、接続は使用可能になるときに、確実に新しいノード上に作成されるようになります。
AGLデータ・ソースでは、次の目的に高速接続フェイルオーバーを使用します。
高速な障害検出を提供する。
無効な接続を中断して、接続プールから削除する。
Oracle RACノードの計画済停止と計画外停止に対して正常なシャットダウンを実行する。「Oracle RACの停止に対する適切な処理」を参照してください。
ノードの追加や削除などのトポロジの変化に適応する。
実行時の作業リクエストをアクティブなすべてのOracle RACインスタンスに分散する(クラスタへの再参加を含む)。
|
注意: AGLデータ・ソースは、非推奨の |
AGLデータ・ソースでは、ロード・バランシングを使用できます。AGLデータ・ソースは、データベースが発行するOracle FANイベントに基づいて、ランタイム接続ロード・バランシング(RCLB)を使用し、Oracle RACの各インスタンスに接続を分散します。つまり、データベースのトポロジに関係なく、データベースがAGLデータ・ソースを通じて接続のロード・バランシングを駆動するため、データ・ソースの構成が簡略化され、パフォーマンスが向上します。
ランタイム接続ロード・バランシングにより、WebLogic Serverでは次の事項が可能になります。
バック・エンド・ノードの能力(CPU、可用性、応答時間など)に応じた作業分散の調整。
Oracle RACトポロジの変更への対処。
高いパフォーマンスおよびスケーラビリティに対応するプール済接続の管理。
FANが有効化されていない場合、AGLデータ・ソースはラウンドロビン・ロード・バランシング・アルゴリズムを使用して、各Oracle RACノードに接続を割り当てます。
|
注意: 各接続は、AGLデータ・ソースで一定期間ごとにシャットダウンされます。様々なRACインスタンスに割り当てられた接続がFANロード・バランシング・アドバイザのランタイム・ロード・バランシングと一致しない場合は、過重インスタンスへの接続が破棄され、新しい接続が開かれます。このプロセスは、デフォルトでは30秒ごとに発生します。 この動作を調整するには、接続のリバランスが行われるまでシステムが待機する時間(秒)を指定するシステム・プロパティ |
AGLデータ・ソースにより、Oracle RACサービスの計画済シャットダウンと計画外シャットダウンに対する正常な処理が可能になります。
計画済シャットダウンの場合、このデータ・ソースを使用することで、進行中のトランザクションは接続が閉じられる前に完了できるようになります。新しいリクエストは、Oracle RACのアクティブなインスタンスにロード・バランシングされます。
計画外シャットダウンの場合は、このデータ・ソースによって進行中のトランザクションがロールバックされ、接続が閉じられます。新しいリクエストは、Oracle RACのアクティブなインスタンスにロード・バランシングされます。
WebLogic Server GridLinkのアフィニティ・ポリシーは、RACクラスタの使用率を最大化して、パフォーマンスを向上するためのものです。次の項を参照してください。
同一のレコード・セットに対して繰り返される操作は、同一のRACインスタンスで処理することでWebアプリケーションのパフォーマンスが向上できます。オンライン・ショッピングやオンライン・バンキングなどのビジネス・アプリケーションは、このパターンの典型的な例としてあげられます。
AGLデータ・ソースは、セッション・アフィニティ・ポリシーを使用して、Webセッション(トランザクションを含む)ごとのすべてのデータベース操作が、RACクラスタの同一のOracle RACインスタンスに向けられるようにします。
|
注意: コンテキストは、HTTPセッションに格納されます。これは、アプリケーションがHTTPセッションを各ウィンドウ(1つのブラウザ内または複数のブラウザ全体でのウィンドウ)にマップする方法に応じて異なります。 |
セッション・アフィニティ・ポリシーを使用するAGLデータ・ソースが、Webセッションのコンテキスト外からアクセスされると、そのアフィニティ・ポリシーはXAアフィニティ・ポリシーに変化します。「XAアフィニティ・ポリシー」を参照してください。
AGLデータ・ソースは、AffEnabled属性を使用することでRACロード・バランシング・アドバイザ(LBA)をモニターして、RACクラスタのRACアフィニティが有効化されているかどうかを判断します。最初の接続リクエストはランタイム接続ロード・バランシング(RCLB)を使用してロード・バランシングされ、アフィニティ・コンテキストが割り当てられます。それ以降のすべての接続リクエストは、セッションが終了するかトランザクションが完了するまで、最初の接続のアフィニティ・コンテキストを使用して、同一のOracle RACインスタンスにルーティングされます。アフィニティは、データベース名、サービス名およびインスタンス名に基づいています。デフォルトでは、AGLデータ・ソースのセッション・アフィニティ・ポリシーは常に有効化されていますが、Webセッションのセッション・アフィニティは次の場合にアクティブになります。
Oracle RACが有効化されていてアクティブであり、サービスでRCLBが有効化されている。RCLBは、サービスのGOAL (CLB_GOALではありません)が、SERVICE_TIMEまたはTHROUGHPUTに設定されている場合に、サービスごとに有効化されます。
クラスタ待機時間において十分なパフォーマンスの向上があるとデータベースで判断され、ONSからの情報のペイロードに含まれるアフィニティ・フラグがTRUEに設定されている。
セッション・アフィニティを実装することに有効性がないとデータベースで判断された場合(高データベース可用性条件など)、データベースはロード・バランシング・アルゴリズムをデフォルトの作業割当てポリシーに戻して、ペイロード内のアフィニティ・フラグをFALSEに設定します。
複数のノード間で接続をロード・バランシングするために、次の2つのオプションがあります。
LOAD_BALANCE=onにして、複数の非SCANアドレスを使用する
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=myservice)))
1つのOracle単一クライアント・アクセス名(SCAN)アドレスを使用する
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=scanname)(PORT=scanport))(CONNECT_DATA=(SERVICE_NAME=myservice)))
SCANアドレスは、WebLogicコンソールで、TNSリスナーとONSリスナーの両方のホストを指定するために使用できます。SCANアドレスを含むAGLデータ・ソースは、Oracle RACのノードが追加または削除された場合でも変更する必要がないため、複数の非SCANアドレスを使用するよりもお薦めできます。ただし、SCANアドレスは、このアドレスを使用するようにデータベースを構成している場合にのみ使用できます。ご使用の環境に対して適切に構成されたSCAN URLについては、御社のネットワーク管理者に問い合せてください。
|
注意: Oracle RAC 11.2以降を使用する場合は、次の点について考慮してください。
SCANアドレスの使用方法の詳細は、『Real Application Clusters管理およびデプロイメント・ガイド11gリリース2 (11.2)』の自動ワークロード管理の概要に関する項と、 |
この機能を使用すると、Oracleウォレットを使用したONSリスナーとのセキュアな通信を構成できるようになります。「セキュアなONSクライアント通信」を参照してください。
WebLogicドメイン内にAGLデータ・ソースを作成する場合は、管理コンソールまたはWebLogic Scripting Tool (WLST)を使用します。
内容は次のとおりです。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのActive GridLinkデータ・ソースの作成に関する項。
サンプルのWLSTスクリプトEXAMPLES_HOME\wl_server\examples\src\examples\wlst\online\jdbc_data_source_creation.py。EXAMPLES_HOMEは、WebLogic Serverのコード・サンプルが構成されるディレクトリを表しています。このサンプルでは、汎用データ・ソースが作成されます。『WebLogic Scripting Toolの理解』のWLSTオンライン・サンプル・スクリプトに関する項を参照してください。
次の各項では、管理コンソールからデータ・ソースの構成ウィザードを使用して、データ・ソースを作成するために使用する基本手順の概要について説明します。
「JDBCデータ・ソースのプロパティ」には、データ・ソースのアイデンティティを決定するオプションと、データベース接続でデータを処理する方法を決定するオプションがあります。
JDBCデータ・ソースの名前は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、そのリソース以外のすべてのJDBCシステム・リソース(データ・ソースを含む)間で一意の名前にする必要があります。名前の競合を避けるために、データ・ソースの名前は、その他の構成オブジェクト(サーバー、アプリケーション、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど)の名前の間でも一意にする必要があります。特定のアプリケーションにスコープ設定されたJDBCアプリケーション・モジュールの場合、データ・ソースの名前は、同様にスコープ設定されたJDBCデータ・ソース間で一意にする必要があります。
単一の名前または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成します。単一のJDBC接続プールを指す複数のデータ・ソースを含む従来の構成のかわりに、複数JNDI名のデータ・ソースを使用できます。詳細は、『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。
管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic ServerはJDBCドライバの種類に応じて特定のトランザクション・オプションを自動的に選択します。
XAドライバの場合、システムはグローバル・トランザクション処理のための「2フェーズ・コミット」プロトコルを自動的に選択します。
非XAドライバ(リプレイ・ドライバ)の場合、ローカル・トランザクションは定義によってサポートされ、WebLogic Serverは次のオプションを提示します。
グローバル・トランザクションのサポート: グローバル・トランザクションでデータ・ソースからの接続を使用する場合は、XAドライバを選択していないときにも、このオプションを選択します(デフォルトで選択済)。詳細は、「非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化」を参照してください。
「グローバル・トランザクションのサポート」を選択する場合は、グローバル・トランザクションを処理するときに、トランザクション・ブランチに使用するWebLogic Serverのプロトコルも選択する必要があります。
ロギング・ラスト・リソース: このオプションを選択すると、接続を使用するトランザクション・ブランチは、トランザクションのラスト・リソースとして処理され、ローカル・トランザクションとして処理されます。2フェーズ・コミット(2PC)トランザクションのコミット・レコードは、リソース自体の表に挿入され、その結果によりグローバル・トランザクションの準備フェーズの成功または失敗が決定されます。このオプションは、「2フェーズ・コミットのエミュレート」と比べて、パフォーマンス上の利点があり、データの安全性も向上しますが、いくつかの制限があります。「「ロギング・ラスト・リソース」トランザクション・オプションの理解」を参照してください。
2フェーズ・コミットのエミュレート: このオプションを選択すると、接続を使用するトランザクション・ブランチは、トランザクションの準備フェーズの結果として常に成功を戻します。これは、パフォーマンス上の利点がありますが、障害の状況によってはデータに危険が及びます。このオプションは、ヒューリスティックな状況に耐えられるアプリケーションでのみ使用してください。「2フェーズ・コミットのエミュレート・トランザクション・オプションの理解」を参照してください。
1フェーズ・コミット: このオプションを選択すると(デフォルトで選択済)、データ・ソースからの接続のみがグローバル・トランザクションに関与するようになり、そのトランザクションは1フェーズ・コミット最適化を使用して完了します。トランザクションに複数のリソースが関与していると、トランザクション・マネージャが1PCリソースのXAResource.prepareを呼び出したときに、例外がスローされます。
データ・ソースをサポートするようにトランザクションを構成する方法の詳細は、「JDBCデータ・ソース・トランザクション・オプション」を参照してください。
接続プロパティは、データ・ソースとDBMSとの間の接続を構成するために使用します。一般的な属性には、サービス名、データベース名、ホスト名、ポート番号、ユーザー名とパスワードがあげられます。
|
注意: サービス名の使用方法:
|
コンソールを使用すると、次のいずれかの方法で接続プロパティを入力できます。
「GridLinkデータ・ソース接続プロパティのオプション」ページで、「個別のリスナー情報の入力」を選択して、「次へ」をクリックします。接続のプロパティを入力します。次に例を示します。
「サービス名」にmyServiceを入力します。
「ホストとポート:」に、left:1234、center:1234、right:1234と入力します。各リスナーのホストとポートは、コロンで区切ります。
「データベース・ユーザー名」に、myDataBaseと入力します。
「パスワード」に、myPassword1と入力します。
必要に応じて、「プロトコル」をSDPに設定します。
コンソールにより、完全なJDBC URLが自動的に生成されます。次に例を示します。
jdbc:oracle:thin:@( DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE=on) (FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=myService)))
「GridLinkデータ・ソース接続プロパティのオプション」ページで、「完全なJDBC URLの入力」を選択して、「次へ」をクリックします。接続のプロパティを入力します。次に例を示します。
「完全なJDBC URL」に、JDBC URLを入力します。次に例を示します。
jdbc:oracle:thin:@( DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE=on) (FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=myService)))
SCANアドレスを使用することもできます。例: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=MyScanAddr-scn.myCompany.com)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))
「データベース・ユーザー名」に、myDataBaseと入力します。
「パスワード」に、myPassword1と入力します。
必要に応じて、「プロトコル」をSDPに設定します。
「データベース接続のテスト」を使用すると、データ・ソース構成をファイナライズする前に、表名またはSQL文を使用してデータベース接続をテストできます。必要に応じて、Properties属性とSystem Properties属性を使用すると、追加の構成情報をテストできます。
「ONSクライアント構成」を使用すると、データ・ソースをOracle FANイベントにサブスクライブして、処理できるようになります。ONSクライアントを構成するには:
「FANの有効化」を選択します。
「ONSホストとポート」で、ONSベースのFANイベントを受け取るためにONSデーモンが接続するリスニング・アドレスとリスニング・ポートをカンマで区切ったリストを入力します。単一クライアント・アクセス名(SCAN)アドレスを使用すると、FAN通知にアクセスできます。
|
注意: Oracle 12cデータベースとWebLogic Serverリリース12.1.2以上を使用する場合は、ONSリスナーのリストを自分で指定する必要はありません。ONSリストは、データベースからドライバに自動的に提供されます。この情報は、関連するランタイムMBeanで確認できます。ただし、関連するONSのOracleウォレットをSSLで使用する場合は、ONSリスナーのリストを指定する必要があります。 |
必要に応じて、SSLを使用したセキュアなONSクライアント通信を構成します。「セキュアなONSクライアント通信」を参照してください。
WebLogic ServerでOracleウォレット・ファイルを使用するには、次の手順を実行する必要があります。
AGLデータ・ソース構成を変更して、SSL証明書とONSウォレット・パスワード(任意)が格納されているOracleウォレット・ファイルのディレクトリを含めます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのOracleウォレットを使用したセキュアなONSリスナーに関する項を参照してください。
Oracleウォレットの詳細は、『Database Advanced Security管理者ガイド』を参照してください。
「ONSクライアント構成のテスト」を使用すると、データ・ソース構成をファイナライズする前に、ONSリスナーへの接続をテストできます。
1つ以上のターゲットを選択して、新しいAGLデータ・ソースをデプロイします。ターゲットを選択していない場合でもデータ・ソースは作成されますが、デプロイされません。そのデータ・ソースは、後でデプロイする必要があります。
ソケット・ダイレクト・プロトコル(SDP)を使用する場合は、インフィニバンドを使用するようにデータベース・ネットワークを構成する必要があります。SDPは、SCANアドレスをサポートしていません。『Oracle Database Net Services管理者ガイド』のインフィニバンド接続のSDPサポートの構成に関する項を参照してください。
SDP接続全体にロード・バランシングするように構成する場合は、すべてのノードでTNSNAMES.ORAファイルを編集して、LISTENER_IBLOCALエントリにSDPエンドポイントを追加する必要があります。
|
注意:
|
次に例を示します。
LISTENER_IBLOCAL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =
sclcgdb02ibvip.country.myCorp.com)(PORT=1522))
(ADDRESS = (PROTOCOL = SDP)(HOST =
sclcgdb02-bvip.country.myCorp.com)(PORT=1522))
)
)
その後で、次のURLを使用して、LISTERNER_IBネットワーク上で接続を分散します。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=SDP) (HOST=sclcgdb01-bvip.country.myCorp.com)(PORT=1522))(ADDRESS=(PROTOCOL=SDP) (HOST=sclcgdb02-ibvip.country.myCorp.com)(PORT=1522)))(CONNECT_DATA=(SERVICE_NAME=elservice)))
各JDBCデータ・ソースは、そのデータ・ソースのデプロイ時またはサーバーの起動時に作成されるJDBC接続のプールを1つ保持します。アプリケーションは、プールからの接続を使用して、その接続を使用後にプールに返します。接続のプーリングにより、アプリケーション用のデータベース接続を作成するという負担のかかるタスクを排除して、パフォーマンスを向上できます。
|
注意: 特定のOracle JDBC拡張機能は、プールされた接続の将来のユーザーが接続の動作を継承するという方法で、接続の動作を永続的に変更することが可能です。WebLogic Serverは、このようなタイプの呼出しに対して、可能な場合は接続の保護を試行します。 |
次の各項では、JDBCデータ・ソースの接続プール・オプションについて説明します。
次の項目を使用すると、さらに多くの情報を確認して、これらのオプションとその他の関連オプションを設定できます。
管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページ。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ ソース: 構成: 接続プール」を参照してください。
JDBCConnectionPoolParamsBean。これは、JDBCDataSourceBeanの子MBeanです。
WebLogic JDBCデータ・ソースは、JDBCドライバで実装されるjavax.sql.ConnectionPoolDataSourceインタフェースをサポートしています。ドライバ・レベルの機能は、JDBCデータ・ソースのProperties属性にプロパティと値を追加することで有効化できます。Properties属性のドライバ・レベルのプロパティは、ドライバのConnectionPoolDataSourceオブジェクトで設定します。
|
注意: JDBCデータ・ソースでは、 |
WebLogic JDBCデータ・ソースは、システム・プロパティの値を使用したドライバ・プロパティの設定をサポートしています。各プロパティの値は、指定されたシステム・プロパティから実行時に導出されます。接続ベースのシステム・プロパティを構成するには、管理コンソールを使用して、データ・ソース構成のSystem Properties属性を編集します。
|
注意: WebLogic Serverの起動時に、Javaシステム・プロパティとして |
WebLogic Serverがデータ・ソース内にデータベース接続を作成したときに、サーバーがデータベース接続を初期化するSQLコードを自動的に実行するように設定できます。この機能を有効化するには、管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページの「初期化SQL」属性に、SQLと入力し、その後に実行するSQLコードを空白を挟んで入力します。この属性を空欄(デフォルト)のままにしておくと、WebLogic Serverは、データベース接続を初期化するコードを実行しなくなります。
WebLogic Serverは、データベース接続をデータ・ソースに作成するたびに、このコードを実行します。また、サーバー起動時、接続プールの拡張時および接続のリフレッシュ時にも、このコードを実行します。
この機能を使用して、DBMS固有の操作設定値(接続固有)を設定することも、必要な操作を実行するためのメモリーや権限を接続に用意することもできます。
コードの先頭には、SQLと、それに続けて空白を入力します。次に例を示します。
SQL alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'
または
SQL SET LOCK MODE TO WAIT
InitSQLを使用して設定できるオプションは、DBMSに応じて異なります。
WebLogic Serverには、Oracleドライバの使用時にデータ・ソースのパフォーマンスを向上できる、いくつかの属性が用意されています。詳細は、「Oracleドライバおよびデータベースの詳細な構成」を参照してください。
次の項では、ONSクライアントを構成する方法について説明します。
データ・ソースで、Oracle高速アプリケーション通知(FAN)イベントへのサブスクライブと、このイベントの処理を有効化します。
「FANの有効化」を選択します。
ONSベースのFANイベントを受信するための、ONSデーモンのリスニング・アドレスとリスニング・ポートのリストをカンマで区切って指定します。単一クライアント・アクセス名(SCAN)アドレスを使用すると、FAN通知にアクセスできます。
|
注意: WebLogic Serverリリース12.1.2以降でOracle 12cデータベースを使用している場合は、AGLデータ・ソース構成の一部としてONSリスナーのリストを指定する必要はありません。ONSリストは、データベースからドライバに自動的に提供されます。この情報は、関連するランタイムMBeanで確認できます。ただし、関連するONSのOracleウォレットをSSLで使用する場合は、ONSリスナーのリストを指定する必要があります。 |
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのONSクライアント・パラメータの構成に関する項を参照してください。
SSLを使用してONSデーモンと通信するには、ウォレット・ファイルを使用する必要があります。「セキュアなONSクライアント通信」を参照してください。
WebLogic Serverドメイン内のJDBCデータ・ソースで、接続プールの属性を適切に構成すると、アプリケーションとシステムのパフォーマンスを向上できます。詳細は、「データ・ソース接続プールのチューニング」を参照してください。
次の各項では、GridLink JDBCオブジェクトのモニタリングについて説明します。
JDBCのモニタリングの詳細は、「WebLogic JDBCリソースのモニタリング」を参照してください。
AGLデータ・ソースの実行時の統計は、管理コンソールを使用するか、関連するランタイムMBeanを通じて表示できます。
JDBCOracleDataSourceRuntimeMBeanには、データ・ソース・インスタンスの現在の状態を取得するメソッドがあります。JDBCOracleDataSourceRuntimeMBeanには、データ・ソースの現在の状態を取得するメソッドと、データ・ソースに関する統計を取得するメソッドが用意されています。取得できる統計には、平均のアクティブな接続数、現在のアクティブな接続数、最大のアクティブな接続数などがあります。このMBeanは、AGLデータソース内でアクティブな各ノードに対する子のJDBCOracleDataSourceInstanceRuntimeMBeanも保持しています。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCOracleDataSourceRuntimeMBeanに関する項を参照してください。
JDBCOracleDataSourceInstanceRuntimeMBeanには、データ・ソース・インスタンスの現在の状態を取得するメソッドがあります。アクティブなONSリスナーごとに1つのインスタンスが存在します。auto-ONSを使用する構成では、管理者がONS文字列を構成していない場合は、これが使用可能なONSリスナーを検出する唯一の方法になります。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCOracleDataSourceInstanceRuntimeMBeanに関する項を参照してください。
ONSDaemonRuntimeMBeanには、AGLデータ・ソースに関連付けられたONSクライアント構成をモニタリングするメソッドがあります。詳細は、Oracle WebLogic Server MBeanリファレンスのONSDaemonRuntimeMBeanに関する項を参照してください。
WebLogic Serverのデバッグ機能を有効化すると、アプリケーションで発生した特定の問題を追跡できるようになります。
JDBCの登録済デバッグ範囲は、次のとおりです。
DebugJDBCRAC: AGLデータ・ソースのライフサイクル、UCPコールバックおよび接続情報に関する情報を出力します。
DebugJDBCONS: ONSクライアント情報(LBAイベント本体を含む)をトレースします。アクティブなONSリスナーごとに、1つのトレースを使用できます。auto-ONSを使用する構成では、管理者がONS文字列を構成していない場合は、これが使用可能なONSリスナーを確認する唯一の方法になります。
DebugJDBCReplay: アプリケーション・コンティニュイティのリプレイ情報をトレースします。
DebugJDBCUCP: UCPドライバからの下位レベルRAC情報をトレースします。
UPC JDKロギングを有効化にする場合は、http://download.oracle.com/docs/cd/B28359_01/java.111/e10788/get_started.htm#sthref67の手順を実行してください。
AGLデータ・ソースは、高速アプリケーション通知(FAN)を有効化することなく構成して使用することもできます(ただし、これは推奨されていません)。この構成では、2回連続して接続テストに失敗すると、RACノードへの接続が無効化されます。接続テストが成功すると、接続が確立されます。TestConnectionsOnReserveを有効化することをお薦めします。構成済のファイアウォールが、このプロトコルを遮断する場合は、FANをオフにすることが必要になる場合があります。
次の表は、「FANの有効化」がfalseに設定されているときに使用できる、AGLデータ・ソースの機能を示しています。
表5-1 GridLinkの機能(「FANの有効化」がFalseの場合)
| Active GridLinkの機能 | 「FANの有効化」がFalseの場合に使用可能 |
|---|---|
|
RACクラスタへのアクセスのための単一データ・ソース構成 |
はい |
|
個別のRACクラスタ・インスタンスに対するランタイムMBean |
はい |
|
ランタイム・ロード・バランシング(RLB)を使用した接続ロード・バランシング |
いいえ |
|
高速アプリケーション通知 |
いいえ |
|
高速接続フェイルオーバー(FCF) |
いいえ |
|
正常なシャットダウン |
いいえ |
|
グラビテイション (接続の再バランシング) |
いいえ |
|
ONSクライアント・サポート(パスワードおよび暗号化されたウォレットの構成を含む) |
いいえ |
|
トランザクション・アフィニティ |
はい |
|
セッション・アフィニティ |
いいえ |
WebLogic Server 12.1.2の新しい構成属性ActiveGridlinkは、データ・ソース構成がAGLデータソースであることを明示的に宣言するために使用します。これは、管理コンソールでGridLinkデータ・ソースを作成するときに、自動的に有効化されます。WLSTを使用してデータ・ソース構成を作成する場合は、ActiveGridlink=trueを設定する必要があります。
|
注意: WebLogic Server 12.1.2より以前のリリースとの後方互換性を維持するために、 |
従来のデータ・ソース構成は、アップグレード処理時に更新されません。高速アプリケーション通知(FAN)を有効化することなくRACクラスタにアクセスするために、従来のAGLデータ・ソースを更新する必要がある場合は、編集またはWLSTを使用して構成内でActiveGridlink=trueを設定します。
次の各項では、AGLデータ・ソースを使用する際のベスト・プラクティスについて説明します。
アプリケーションは、すべての例外をキャッシュして処理する必要があります。AGLデータ・ソースを使用するアプリケーションは、流用された接続でJDBC操作を実行するときに、IO socket read errorなどの例外を予期しておく必要があります。接続の有効性を検査して、必要なときには再接続することがベスト・プラクティスになります。接続の例外は、FANイベントの到着前にドライバが停止を検出した場合や、接続のクリーンアップの結果として発生することがあります。計画外停止イベントの場合は、その停止の影響を受けるすべての接続が、接続プールによって中断されます。
この項では、AGLの接続の変更点について要約します。FANとONSは有効化されていることを前提にしています。
構成済の初期容量に基づいて、最初にプールに接続が追加されます。これには、リスナーに基づいた接続時間のロード・バランシングが使用されます。これが正しく機能するには、複数の非SCANアドレスにLOAD_BALANCE=ONを指定するか、SCANを使用する必要があります。
ランタイム・ロード・バランシングに基づいて必要に応じて、接続がプールに追加されます。ただし、これは、トランザクションまたはWebセッションの最後のリクエストにアフィニティを提供するインスタンスに接続が追加された場合、XAアフィニティまたはWebセッション・アフィニティによりオーバーライドされます。
計画済停止イベントが発生すると、そのインスタンスの未使用の接続はすぐに解放され、使用中の接続はプールに返された時点で解放されます。
計画外停止イベントが発生すると、そのインスタンスのすべての接続がすぐに破棄されます。
起動イベントが発生すると、新しいインスタンスに接続が事前に作成されます。
グラビテイションの縮小が発生すると、負荷の高いインスタンス(期間単位)で未使用の接続が1つ破棄されます。
通常の縮小が発生すると、最小容量になるまで未使用接続の半数が破棄されます。このとき、負荷(期間単位)は考慮されません。
AGLは、RACクラスタのサポートに対応したマルチ・データ・ソース(MDS)の上位実装です。次の項では、AGLデータ・ソースの利点に関する追加情報について説明します。AGLの利点は、次のとおりです。
単一URLによるデータ・ソースが1つ必要です。マルチ・データ・ソースでは、n個の汎用データ・ソースと1つのマルチ・データ・ソースが必要になります。
汎用データ・ソースのうちの1つの実行速度低下が障害に結び付く、ポーリング・メカニズムが不要になります。
クラスタに対するノードの手動追加や手動削除が不要になります。
ノードが使用可能になったときに、高速内部通知(帯域外)を提供します。これにより、Oracle Notification Service (ONS)を使用した新しいノードへの接続のロード・バランシングが可能になります。
ノードが停止したときに高速内部通知を提供します。これにより、接続はONSを使用してノードを回避できるようになります。
ロード・バランシング・アドバイザ(LBA)を提供します。これにより、負荷が最小のノードに新しい接続が作成されるようになります。また、LBA情報はグラビテイションにも使用され、負荷に基づいてアイドル接続を移動します。
XAトランザクションまたはWebセッションに基づいたアフィニティを提供します。これにより、大幅にパフォーマンスが向上することがあります。
DataGuardのようなHA構成の利点をフル活用します。詳細は、http://www.oracle.com/technetwork/middleware/weblogic/learnmore/1534212を参照してください。
RAC接続対応のマルチ・データ・ソース(MDS)は、2005年からWebLogic Serverでサポートされています。Oracle RACが普及するに従い、MDSも広く使用されるようになりました。2011年初頭にActive GridLink (AGL)が導入されたことで、多くのMDSユーザーがAGLに移行しています。自動化されたアップグレード・パッチは存在しませんが、目的の環境にAGLを手動で実装するプロセスは簡単です。「AGLとマルチ・データ・ソースの比較」を参照してください。
アプリケーションに対しては、なにも変更する必要はありません。標準的なアプリケーションは、JNDIのMDSを検索し、そのMDSを使用して接続を取得します。MDSと同じJNDI名をAGLに指定すると、アプリケーションでJNDIのデータ・ソース名を使用するプロセスはまったく同じになります。
構成にのみ変更が必要になります。AGLデータ・ソースは、MDSからの情報と、単一のAGL記述子で結合されたメンバー汎用データ・ソースで構成されています。唯一必要になる追加情報は、RACクラスタに関するOracle Notification Service (ONS)の構成です。多くの場合、ONS情報はMDSで使用されていたものと同じホスト名で構成されていて、唯一の追加情報はポート番号です。このポート番号は、SCANアドレスを使用することで簡略化できます。
MDS記述子には、多量の情報は含まれていません。主な構成要素は、次のとおりです。
JNDI名。アプリケーションに対する透過性を維持するためには、これを新しいAGLデータ・ソース名にする必要があります。MDSをAGLデータ・ソースと同時に実行するときには、AGLデータ・ソースに新しいJNDI名を付ける必要がありますが、その場合はアプリケーションも新しいJNDI名を使用するように更新する必要があります。
メンバー汎用データ・ソースのリストは、AGLデータ・ソースの構成に必要な残りの情報を提供します。
各メンバー汎用データ・ソースは、それぞれに独自のURLを持ちます。「Oracle RACでのマルチ・データ・ソースの使用」で説明するように、次のパターンになります。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=
(PROTOCOL=TCP)(HOST=host1-vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))
各メンバーは、独自のホスト/ポートのペアを持ちます。各メンバーは、同一のサービスを持つことがあり、多くの場合、別々のホストの同じポートを持ちます。AGLデータ・ソースのURLは、ホスト/ポートのペアで構成されています。次に例を示します。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=host1-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2-vip)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=dbservice))
これには、複数のホストや仮想IP (VIP)のアドレスではなく、Oracle単一クライアント・アクセス名(SCAN)アドレスを使用するようにしてください。SCANアドレスは、より簡単でノードの変更がクラスタ透過的になります。SCANアドレスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。次に例を示します。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=scanaddress)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=dbservice))
「アルゴリズムのタイプ」は無視します。
次の項では、MDSからAGLに移行する際に必要な基本手順について説明します。
管理コンソールを使用して、MDSと汎用データ・ソースを構成から削除します。
管理コンソールを使用して、単一のAGLデータ・ソースを追加します。
MDSと同じJNDI名を付けます。
どの汎用データ・ソースを使用していたかに応じて、XAドライバまたは非XAドライバを選択します。
完全なURLを入力します。詳細は、「マルチ・データ・ソースからの移行に伴う構成の変更」を参照してください。
ユーザーとパスワードを設定します。これは、MDSメンバーに使用していたものと同じ内容にする必要があります。
「GridLinkデータソース接続のテスト」ページで、「すべてのリスナーのテスト」をクリックして、新しいURLを検証します。
ONS接続の情報を入力します。1つ以上のhost:portペアを指定します。例: host1-vip:6200またはscanaddress:6200。可能な場合は、単一のSCANアドレスとポートを使用します。「FANの有効化」が選択されていることを確認します。
ONS接続をテストします。
データ・ソースをデプロイします。
AGLデータ・ソースを編集して、追加パラメータを構成します。
新しいデータ・ソースの作成中には構成できないデータ・ソースのパラメータが多数あります。多くの場合、MDSで使用していたパラメータ設定値を使用できます。競合が発生した場合は、その競合を解決してから、環境に応じた適切な設定値を選択する必要があります。
管理コンソールを使用してAGLデータ・ソースを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC GridLinkデータ・ソースの構成に関する項を参照してください。
