プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3 JDBCデータ・ソースの管理
12c (12.1.3)
E56266-09
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

5 Active GridLinkデータ・ソースの使用方法

この章では、WebLogic Server 12.1.3でのActive GridLink (AGL)データ・ソースの構成方法とチューニング方法について説明します。

この章には次の項が含まれます:

Active GridLinkデータ・ソースとは

単一の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とマルチ・データ・ソースの比較」を参照してください。

図5-1 Active GridLinkデータ・ソースの接続

図5-1の説明が続きます
「図5-1 Active GridLinkデータ・ソースの接続」の説明

AGLデータ・ソースには、汎用データ・ソースの機能に加え、Oracle RACに対する次のサポートが含まれています。

高速接続フェイルオーバー

AGLデータ・ソースは、高速接続フェイルオーバーを使用します。また、Oracle Notification Service (ONS)を使用したOracle RACイベントに応答します。これにより、AGLデータ・ソースの接続プールには確実に有効な接続(予約済の接続を含む)が格納されるようになり、接続のポーリングやテストの必要がなくなります。さらに、接続は使用可能になるときに、確実に新しいノード上に作成されるようになります。

図5-2 高速接続フェイルオーバー

図5-2の説明が続きます
「図5-2 高速接続フェイルオーバー」の説明

AGLデータ・ソースでは、次の目的に高速接続フェイルオーバーを使用します。

  • 高速な障害検出を提供する。

  • 無効な接続を中断して、接続プールから削除する。

  • Oracle RACノードの計画済停止と計画外停止に対して正常なシャットダウンを実行する。「Oracle RAC停止時のAGLサポート」を参照してください。

  • ノードの追加や削除などのトポロジの変化に適応する。

  • 実行時の作業リクエストをアクティブなすべてのOracle RACインスタンスに分散する(クラスタへの再参加を含む)。


注意:

AGLデータ・ソースは、非推奨のFastConnectionFailoverEnabled接続プロパティをサポートしていません。このプロパティを有効化したXA接続を作成しようとすると、java.sql.SQLException: Can not use getXAConnection() when connection caching is enabledという例外が発生します。これは、このプロパティに対するドライバの高速接続フェイルオーバーの実装がXA接続をサポートしていないためです。

ランタイム接続ロード・バランシング

AGLデータ・ソースでは、ロード・バランシングを使用できます。AGLデータ・ソースは、データベースが発行するOracle FANイベントに基づいて、ランタイム接続ロード・バランシング(RCLB)を使用し、Oracle RACの各インスタンスに接続を分散します。つまり、データベースのトポロジに関係なく、データベースがAGLデータ・ソースを通じて接続のロード・バランシングを駆動するため、データ・ソースの構成が簡略化され、パフォーマンスが向上します。

ランタイム接続ロード・バランシングにより、WebLogic Serverでは次の事項が可能になります。

  • バック・エンド・ノードの能力(CPU、可用性、応答時間など)に応じた作業分散の調整。

  • Oracle RACトポロジの変更への対処。

  • 高いパフォーマンスおよびスケーラビリティに対応するプール済接続の管理。

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

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

FANが有効化されていない場合、AGLデータ・ソースはラウンドロビン・ロード・バランシング・アルゴリズムを使用して、各Oracle RACノードに接続を割り当てます。


注意:

各接続は、AGLデータ・ソースで一定期間ごとにシャットダウンされます。様々なRACインスタンスに割り当てられた接続がFANロード・バランシング・アドバイザのランタイム・ロード・バランシングと一致しない場合は、過重インスタンスへの接続が破棄され、新しい接続が開かれます。このプロセスは、デフォルトでは30秒ごとに発生します。

この動作を調整するには、接続のリバランスが行われるまでシステムが待機する時間(秒)を指定するシステム・プロパティweblogic.jdbc.gravitationShrinkFrequencySecondsを使用します。値を0にすると、再バランシング処理が無効になります。


Oracle RAC停止時のAGLサポート

この項では、Oracle RACサービスの計画シャットダウンと計画外シャットダウンをAGLデータ・ソースによって処理する方法について説明します。

  • 計画シャットダウンは、データベース・インスタンスまたはサービスがシャットダウン操作のターゲットになっていて、シャットダウンがリクエストされたことを示す、対応するデータベース・イベントが発行されると発生します。データベースの計画シャットダウンをサポートするため、AGLは、データベース・シャットダウンのターゲットが新しい接続を受け入れなくなったことを検出しても、使用中の接続をすぐには中断しません。そのかわり、AGLデータ・ソースは、物理接続を閉じて再作成する前に進行中のトランザクションをすべて完了させる一方で、アイドル接続をクリーンアップすることで、新しい接続リクエストがアクティブなシャットダウン・モードのデータベース・ターゲットに送信されないようにできます。これにより、シャットダウン・インスタンスの接続を排出できます。

    計画シャットダウンのためには、AGLデータ・ソースの構成でFANが有効化されており、アプリケーションが適時プールへの接続を返す必要があります。「ONSクライアント構成の構成」を参照してください。

  • 計画外シャットダウンの場合は、このデータ・ソースによって進行中のトランザクションがロールバックされ、接続が閉じられます。新しいリクエストは、Oracle RACのアクティブなインスタンスにロード・バランシングされます。

Oracle RAC 11.2より以前のOracle RACの停止に対する処理

Oracle RAC 11.2より以前のリリースでは、Oracle RACインスタンスをシャットダウンするときに、それに対応するサービスを先にシャットダウンしていない場合は、計画外シャットダウンになります。

GridLinkアフィニティ

WebLogic Server GridLinkのアフィニティ・ポリシーは、RACクラスタの使用率を最大化して、パフォーマンスを向上するためのものです。次の項を参照してください。

セッション・アフィニティ・ポリシー

同一のレコード・セットに対して繰り返される操作は、同一のRACインスタンスで処理することでWebアプリケーションのパフォーマンスが向上できます。オンライン・ショッピングやオンライン・バンキングなどのビジネス・アプリケーションは、このパターンの典型的な例としてあげられます。

AGLデータ・ソースは、セッション・アフィニティ・ポリシーを使用して、Webセッション(トランザクションを含む)ごとのすべてのデータベース操作が、RACクラスタの同一のOracle RACインスタンスに向けられるようにします。


注意:

コンテキストは、HTTPセッションに格納されます。これは、アプリケーションがHTTPセッションを各ウィンドウ(1つのブラウザ内または複数のブラウザ全体でのウィンドウ)にマップする方法に応じて異なります。

セッション・アフィニティ・ポリシーを使用するAGLデータ・ソースが、Webセッションのコンテキスト外からアクセスされると、そのアフィニティ・ポリシーはXAアフィニティ・ポリシーに変化します。「XAアフィニティ・ポリシー」を参照してください。

図5-4 セッション・アフィニティ

図5-4の説明が続きます
「図5-4 セッション・アフィニティ」の説明

AGLデータ・ソースは、AffEnabled属性を使用することでRACロード・バランシング・アドバイザ(LBA)をモニターして、RACクラスタのRACアフィニティが有効化されているかどうかを判断します。最初の接続リクエストはランタイム接続ロード・バランシング(RCLB)を使用してロード・バランシングされ、アフィニティ・コンテキストが割り当てられます。それ以降のすべての接続リクエストは、セッションが終了するかトランザクションが完了するまで、最初の接続のアフィニティ・コンテキストを使用して、同一のOracle RACインスタンスにルーティングされます。アフィニティは、データベース名、サービス名およびインスタンス名に基づいています。デフォルトでは、AGLデータ・ソースのセッション・アフィニティ・ポリシーは常に有効化されていますが、Webセッションのセッション・アフィニティは次の場合にアクティブになります。

  • Oracle RACが有効化されていてアクティブであり、サービスでRCLBが有効化されている。RCLBは、サービスのGOAL (CLB_GOALではありません)が、SERVICE_TIMEまたはTHROUGHPUTに設定されている場合に、サービスごとに有効化されます。

  • クラスタ待機時間において十分なパフォーマンスの向上があるとデータベースで判断され、ONSからの情報のペイロードに含まれるアフィニティ・フラグがTRUEに設定されている。

セッション・アフィニティを実装することに有効性がないとデータベースで判断された場合(高データベース可用性条件など)、データベースはロード・バランシング・アルゴリズムをデフォルトの作業割当てポリシーに戻して、ペイロード内のアフィニティ・フラグをFALSEに設定します。

XAアフィニティ・ポリシー

グローバル・トランザクションのXAアフィニティにより、Oracle RACクラスタで実行されるグローバル・トランザクションに対するすべてのデータベース操作は、同一のOracle RACインスタンスに向けられるようになります。次の制限事項について考慮する必要があります。

  • XAトランザクションは、複数のインスタンスを対象にできません。

  • XAトランザクション内の接続には、厳密なアフィニティが強制適用されます。適切なインスタンスに接続が作成できない場合は、例外がスローされます。

図5-5 XAアフィニティ

図5-5の説明が続きます
「図5-5 XAアフィニティ」の説明

SCANアドレス

複数のノード間で接続をロード・バランシングするために、次の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以降を使用する場合は、次の点について考慮してください。
  • Oracle RACのリスナーがSCANに設定されていると、AGLデータ・ソース構成では、SCANアドレスのみが使用できるようになります。

  • Oracle RACのリスナーがList of Node VIPsに設定されていると、AGLデータ・ソース構成では、VIPアドレスのリストのみが使用できるようになります。

  • Oracle RACのリスナーがMix of SCAN and List of Node VIPsに設定されていると、AGLデータ・ソース構成では、SCANとVIPの両方のアドレスが使用できるようになります。

SCANアドレスの使用方法の詳細は、『Real Application Clusters管理およびデプロイメント・ガイド11gリリース2 (11.2)』の自動ワークロード管理の概要に関する項と、http://www.oracle.com/technetwork/database/clustering/overview/scan-129069.pdfを参照してください。


Oracleウォレットを使用したONSリスナーとのセキュアな通信

この機能を使用すると、Oracleウォレットを使用したONSリスナーとのセキュアな通信を構成できるようになります。「セキュアなONSクライアント通信」を参照してください。

Active GridLinkデータ・ソースの作成

WebLogicドメイン内にAGLデータ・ソースを作成する場合は、WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用します。

内容は次のとおりです。

  • Oracle WebLogic Server管理コンソール・オンライン・ヘルプActive GridLinkデータ・ソースの作成に関する項

  • サンプルのWLSTスクリプトEXAMPLES_HOME\wl_server\examples\src\examples\wlst\online\jdbc_data_source_creation.pyEXAMPLES_HOMEは、WebLogic Serverのコード・サンプルが構成されるディレクトリを表しています。このサンプルでは、汎用データ・ソースが作成されます。『WebLogic Scripting Toolの理解』のWLSTオンライン・サンプル・スクリプトに関する項を参照してください。

次の各項では、WebLogic Server管理コンソールからデータ・ソースの構成ウィザードを使用して、データ・ソースを作成するために使用する基本手順の概要について説明します。

JDBCデータ・ソースのプロパティ

「JDBCデータ・ソースのプロパティ」には、データ・ソースのアイデンティティを決定するオプションと、データベース接続でデータを処理する方法を決定するオプションがあります。

データ・ソース名

JDBCデータ・ソースの名前は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、そのリソース以外のすべてのJDBCシステム・リソース(データ・ソースを含む)間で一意の名前にする必要があります。名前の競合を避けるために、データ・ソースの名前は、その他の構成オブジェクト(サーバー、アプリケーション、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど)の名前の間でも一意にする必要があります。特定のアプリケーションにスコープ設定されたJDBCアプリケーション・モジュールの場合、データ・ソースの名前は、同様にスコープ設定されたJDBCデータ・ソース間で一意にする必要があります。

JNDI名

単一の名前または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成します。単一のJDBC接続プールを指す複数のデータ・ソースを含む従来の構成のかわりに、複数JNDI名のデータ・ソースを使用できます。詳細は、『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。

ドライバの選択

アプリケーション・コンティニュイティのリプレイ・ドライバ(XAまたは非XA Thinドライバ)を選択します。


注意:

現時点では、リプレイ・ドライバはXAトランザクションをサポートしていません。

トランザクション・オプションの構成

WebLogic Server管理コンソールを使用して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との間の接続を構成するために使用します。一般的な属性には、サービス名、データベース名、ホスト名、ポート番号、ユーザー名とパスワードがあげられます。


注意:

サービス名の使用方法:
  • データベース・ドメインを使用するときには、サービス名にドメイン名の接尾辞を付加する必要があります。たとえば、データベース名がdb.country.myCorp.comで、サービス名がmyserviceのときには、myservice.db.country.myCorp.comと入力する必要があります。


コンソールを使用すると、次のいずれかの方法で接続プロパティを入力できます。

接続プロパティの入力

「GridLinkデータ・ソース接続プロパティのオプション」ページで、「個別のリスナー情報の入力」を選択して、「次へ」をクリックします。接続のプロパティを入力します。次に例を示します。

  • 「サービス名」myServiceを入力します。

  • 「ホストとポート:」に、left:1234center:1234right: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)))

完全なURLの入力

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

サポートされているAGLデータ・ソースURLフォーマット

AGLデータ・ソースは長いフォーマットのJDBC URLのみをサポートします。サポートされている長いフォーマットのパターンは次のようになります。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=[SCAN_VIP])(PORT=[SCAN_PORT])))(CONNECT_DATA=(SERVICE_NAME=[SERVICE_NAME])))

簡易接続(短い)フォーマットURLは、AGLデータ・ソースではサポートされていません。AGLデータ・ソースでの使用がサポートされていない簡易接続URLパターンの例を次に示します。

jdbc:oracle:thin:[SCAN_VIP]:[SCAN_PORT]/[SERVICE_NAME]

AGLデータソースURLに関する推奨事項

次の項では、AGLデータ・ソースURLを作成する際の一般的な推奨事項を示します。

  • 単一のDESCRIPTIONを使用します。接続遅延を防ぐためにDESCRIPTION_LISTを避けます。

  • 各RACクラスタまたはDataGuardデータベースに1つのADDRESS_LISTを使用します。

  • すべてのADDRESS_LISTエントリが同じ値を使用するように、DESCRIPTIONレベルでRETRY_COUNTRETRY_DELAYCONNECT_TIMEOUTを入力します。

  • RETRY_DELAYは、接続の再試行間の遅延時間(秒)を指定します。この属性はOracle 12.1.0.2リリースの新しい属性です。

  • RETRY_COUNTは、接続試行を終了するまでに、ADDRESSリストが横断する回数の指定に使用します。デフォルト値は0です。FAILOVER=onSCANリスナーを使用中に、RETRY_COUNTを2に設定すると、3つのSCAN IPアドレスがある場合、それぞれが3回横断されるため、接続試行が9回(3 * 3)行われることになります。

  • 各アドレス・リストにLOAD_BALANCE=onを指定し、SCANアドレスのバランスを取ります。

  • サービス名は、PDBまたは管理サービスではなく、構成されたアプリケーション名にしてください。

  • CONNECT_TIMEOUTは、Oracle Net接続の完了に使用する時間全体の指定に使用されます。ログオンの混乱を避けるために、CONNECT_TIMEOUT=90またはそれ以上に設定します。JDBCドライバ12.1.0.2以前では、CONNECT_TIMEOUTは、URLの各アドレスのTCP/IP接続タイムアウトにも使用されていました。TCP/IP接続を考慮する場合、タイムアウト全体の従属的要件ではありますが、短いCONNECT_TIMEOUTの方が適しています。

  • URLプロパティによって上書きされるため、データ・ソースにoracle.net.CONNECT_TIMEOUTドライバ・プロパティを設定しないでください。

接続のテスト

「データベース接続のテスト」を使用すると、データ・ソース構成をファイナライズする前に、表名またはSQL文を使用してデータベース接続をテストできます。必要に応じて、Properties属性とSystem Properties属性を使用すると、追加の構成情報をテストできます。

ONSクライアント構成の構成

「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クライアント通信」を参照してください。

セキュアなONSクライアント通信

WebLogic ServerでOracleウォレット・ファイルを使用するには、次の手順を実行する必要があります。

ONSクライアント構成のテスト

「ONSクライアント構成のテスト」を使用すると、データ・ソース構成をファイナライズする前に、ONSリスナーへの接続をテストできます。

データ・ソースのターゲット設定

1つ以上のターゲットを選択して、新しいAGLデータ・ソースをデプロイします。ターゲットを選択していない場合でもデータ・ソースは作成されますが、デプロイされません。そのデータ・ソースは、後でデプロイする必要があります。

ソケット・ダイレクト・プロトコルの使用

ソケット・ダイレクト・プロトコル(SDP)を使用する場合は、インフィニバンドを使用するようにデータベース・ネットワークを構成する必要があります。SDPは、SCANアドレスをサポートしていません。『Oracle Database Net Services管理者ガイド』インフィニバンド接続のSDPサポートの構成に関する項を参照してください。

SDPを使用したランタイム・ロード・バランシングの構成

SDP接続全体にロード・バランシングするように構成する場合は、すべてのノードでTNSNAMES.ORAファイルを編集して、LISTENER_IBLOCALエントリにSDPエンドポイントを追加する必要があります。


注意:

TNSNAMES.ORAファイルは、インスタンスの起動時またはALTER SYSTEM SET LISTENER_NETWORKS="listener address"コマンドの使用時にのみ読み取られます。TNSNAMES.ORAファイルの更新後には、すべてのインスタンスを再起動するか、すべてのネットワーク上でALTER SYSTEM SET LISTENER_NETWORKSコマンドを実行してください。

次に例を示します。

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

AGL接続プール機能の構成

各JDBCデータ・ソースは、そのデータ・ソースのデプロイ時またはサーバーの起動時に作成されるJDBC接続のプールを1つ保持します。アプリケーションは、プールからの接続を使用して、その接続を使用後にプールに返します。接続のプーリングにより、アプリケーション用のデータベース接続を作成するという負担のかかるタスクを排除して、パフォーマンスを向上できます。


注意:

特定のOracle JDBC拡張機能は、プールされた接続の将来のユーザーが接続の動作を継承するという方法で、接続の動作を永続的に変更することが可能です。WebLogic Serverは、このようなタイプの呼出しに対して、可能な場合は接続の保護を試行します。

次の各項では、JDBCデータ・ソースの接続プール・オプションについて説明します。

次の項目を使用すると、さらに多くの情報を確認して、これらのオプションとその他の関連オプションを設定できます。

JDBCドライバ・レベルの機能の有効化

WebLogic JDBCデータ・ソースは、JDBCドライバで実装されるjavax.sql.ConnectionPoolDataSourceインタフェースをサポートしています。ドライバ・レベルの機能は、JDBCデータ・ソースのProperties属性にプロパティと値を追加することで有効化できます。Properties属性のドライバ・レベルのプロパティは、ドライバのConnectionPoolDataSourceオブジェクトで設定します。


注意:

JDBCデータ・ソースでは、Properties属性のドライバ・レベルのプロパティとして、FastConnectionFailoverEnabledConnectionCachingEnabledまたはConnectionCacheNameを使用しないでください。

接続ベースのシステム・プロパティの有効化

WebLogic JDBCデータ・ソースは、システム・プロパティの値を使用したドライバ・プロパティの設定をサポートしています。各プロパティの値は、指定されたシステム・プロパティから実行時に導出されます。接続ベースのシステム・プロパティを構成するには、WebLogic Server管理コンソールを使用して、データ・ソース構成のSystem Properties属性を編集します。


注意:

WebLogic Serverの起動時に、Javaシステム・プロパティとしてoracle.jdbc.FastConnectionFailoverを指定してはいけません。

SQLコードを使用したデータベース接続の初期化

WebLogic Serverがデータ・ソース内にデータベース接続を作成したときに、サーバーがデータベース接続を初期化するSQLコードを自動的に実行するように設定できます。この機能を有効化するには、WebLogic Server管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページの「初期化SQL」属性で、SQLと入力し、その後に実行するSQLコードを空白を挟んで入力します。または、SQLを使用せずに単純な表名を指定できます。SELECT COUNT(*) FROM tablenameという文を使用します。この属性を空欄(デフォルト)のままにしておくと、WebLogic Serverは、データベース接続を初期化するコードを実行しなくなります。

WebLogic Serverは、データベース接続をデータ・ソースに作成するたびに、このコードを実行します。また、サーバー起動時、接続プールの拡張時および接続のリフレッシュ時にも、このコードを実行します。

この機能を使用して、DBMS固有の操作設定値(接続固有)を設定することも、必要な操作を実行するためのメモリーや権限を接続に用意することもできます。

コードの先頭には、SQLと、それに続けて空白を入力します。たとえば、Oracle DBMSでは次のようになります。

SQL alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'

Informix DBMSでは次のようになります。

SQL SET LOCK MODE TO WAIT

SQL文はJDBC Statement.execute()を使用して実行します。InitSQLを使用して設定できるオプションは、DBMSに応じて異なります。サポートされている文については、データベース・ベンダーのドキュメントを参照してください。複数の文を実行する場合は、ストアド・プロシージャを作成して実行することもできます。この構文はベンダー固有です。たとえば、Oracleストアド・プロシージャを実行するには、次のように指定します。

SQL CALL MYPROCEDURE()

Oracleパラメータの構成

WebLogic Serverには、Oracleドライバの使用時にデータ・ソースのパフォーマンスを向上できる、いくつかの属性が用意されています。詳細は、「Oracleドライバおよびデータベースの詳細な構成」を参照してください。

ONSクライアントの構成

次の項では、ONSクライアントを構成する方法について説明します。

FANイベントの有効化

データ・ソースで、Oracle高速アプリケーション通知(FAN)イベントへのサブスクライブと、このイベントの処理を有効化します。

  1. 「FANの有効化」を選択します。

  2. 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クライアント通信」を参照してください。

Active GridLinkデータ・ソースの接続プールのチューニング

WebLogic Serverドメイン内のJDBCデータ・ソースで、接続プールの属性を適切に構成すると、アプリケーションとシステムのパフォーマンスを向上できます。詳細は、「データ・ソース接続プールのチューニング」を参照してください。

GridLink JDBCリソースのモニタリング

次の各項では、GridLink JDBCオブジェクトのモニタリングについて説明します。

JDBCのモニタリングの詳細は、「WebLogic JDBCリソースのモニタリング」を参照してください。

実行時統計の表示

AGLデータ・ソースの実行時の統計は、WebLogic Server管理コンソールを使用するか、関連するランタイムMBeanを通じて表示できます。

JDBCOracleDataSourceRuntimeMBean

JDBCOracleDataSourceRuntimeMBeanには、データ・ソース・インスタンスの現在の状態を取得するメソッドがあります。JDBCOracleDataSourceRuntimeMBeanには、データ・ソースの現在の状態を取得するメソッドと、データ・ソースに関する統計を取得するメソッドが用意されています。取得できる統計には、平均のアクティブな接続数、現在のアクティブな接続数、最大のアクティブな接続数などがあります。このMBeanは、AGLデータソース内でアクティブな各ノードに対する子のJDBCOracleDataSourceInstanceRuntimeMBeanも保持しています。詳細は、Oracle WebLogic Server MBeanリファレンスJDBCOracleDataSourceRuntimeMBeanに関する項を参照してください。

JDBCOracleDataSourceInstanceRuntimeMBean

JDBCOracleDataSourceInstanceRuntimeMBeanには、データ・ソース・インスタンスの現在の状態を取得するメソッドがあります。アクティブなONSリスナーごとに1つのインスタンスが存在します。auto-ONSを使用する構成では、管理者がONS文字列を構成していない場合は、これが使用可能なONSリスナーを検出する唯一の方法になります。詳細は、Oracle WebLogic Server MBeanリファレンスJDBCOracleDataSourceInstanceRuntimeMBeanに関する項を参照してください。

ONSDaemonRuntimeMBean

ONSDaemonRuntimeMBeanには、AGLデータ・ソースに関連付けられたONSクライアント構成をモニタリングするメソッドがあります。

次に示すのは、ONS接続をテストするためのWLSTスクリプトです。この例では、Active GridLinkデータ・ソースの名前はgldsで、ターゲットはmyserverになっています。

connect(<wluser>, <wlpassword>, 't3://localhost:7001')
serverRuntime()
cd('JDBCServiceRuntime')
cd('myserver')
cd('JDBCDataSourceRuntimeMBeans')
cd('glds')
cd('ONSClientRuntime')
cd('glds')
cd('ONSDaemonRuntimes')
cd('glds_0')
cmo.ping()

詳細は、Oracle WebLogic Server MBeanリファレンスONSDaemonRuntimeMBeanに関する項を参照してください。

Active GridLinkデータ・ソースのデバッグ

WebLogic Serverのデバッグ機能を有効化すると、アプリケーションで発生した特定の問題を追跡できるようになります。

JDBCのデバッグ範囲

JDBCの登録済デバッグ範囲は、次のとおりです。

  • DebugJDBCRAC: AGLデータ・ソースのライフサイクル、UCPコールバックおよび接続情報に関する情報を出力します。

  • DebugJDBCONS: ONSクライアント情報(LBAイベント本体を含む)をトレースします。アクティブなONSリスナーごとに、1つのトレースを使用できます。auto-ONSを使用する構成では、管理者がONS文字列を構成していない場合は、これが使用可能なONSリスナーを確認する唯一の方法になります。

  • DebugJDBCReplay: アプリケーション・コンティニュイティのリプレイ情報をトレースします。

  • DebugJDBCUCP: UCPドライバからの下位レベルRAC情報をトレースします。

UCP JDKロギング

UPC JDKロギングを有効化にする場合は、http://download.oracle.com/docs/cd/B28359_01/java.111/e10788/get_started.htm#sthref67の手順を実行してください。

コマンド行を使用したデバッグの有効化

AGLデータ・ソースのデバッグ・プロパティを、コマンド行から適切に設定します。次に例を示します。

-Dweblogic.debug.DebugJDBCRAC=true 
-Dweblogic.debug.DebugJDBCONS=true
-Dweblogic.debug.DebugJDBCUCP=true
-Dweblogic.debug.DebugJDBCREPLAY=true

これらの値の設定は、静的であり、サーバー起動時にのみ使用されます。

FAN通知を使用しないActive GridLinkデータ・ソースの使用方法

AGLデータ・ソースは、高速アプリケーション通知(FAN)を有効化することなく構成して使用することもできます(ただし、これは推奨されていません)。この構成では、2回連続して接続テストに失敗すると、RACノードへの接続が無効化されます。接続テストが成功すると、接続が確立されます。TestConnectionsOnReserveを有効化することをお薦めします。構成済のファイアウォールが、このプロトコルを遮断する場合は、FANをオフにすることが必要になる場合があります。

次の表は、「FANの有効化」がfalseに設定されているときに使用できる、AGLデータ・ソースの機能を示しています。

表5-1 GridLinkの機能(「FANの有効化」がFalseの場合)

Active GridLinkの機能 「FANの有効化」がFalseの場合に使用可能

RACクラスタへのアクセスのための単一データ・ソース構成

はい

個別のRACクラスタ・インスタンスに対するランタイムMBean

はい

ランタイム・ロード・バランシング(RLB)を使用した接続ロード・バランシング

いいえ

高速アプリケーション通知

いいえ

高速接続フェイルオーバー(FCF)

いいえ

正常なシャットダウン

いいえ

グラビテイション (接続の再バランシング)

いいえ

ONSクライアント・サポート(パスワードおよび暗号化されたウォレットの構成を含む)

はい

トランザクション・アフィニティ

はい

セッション・アフィニティ

いいえ


ActiveGridlink属性の理解

WebLogic Server 12.1.2以降では、ActiveGridlink属性を使用して、データ・ソース構成がAGLデータ・ソースであることを明示的に宣言します。これは、WebLogic Server管理コンソールでGridLinkデータ・ソースを作成するときに、自動的に有効化されます。WLSTを使用してデータ・ソース構成を作成する場合は、ActiveGridlink=trueを設定する必要があります。


注意:

WebLogic Server 12.1.2より以前のリリースとの後方互換性を維持するために、FanEnabled=trueまたはOnsNodeListがNULL以外のときには、データ・ソース構成は常にAGLデータ・ソース構成になります。この場合、ActiveGridlink値は無視されます。

従来のデータ・ソース構成は、アップグレード処理時に更新されません。高速アプリケーション通知(FAN)を有効化することなくRACクラスタにアクセスするために、従来のAGLデータ・ソースを更新する必要がある場合は、編集またはWLSTを使用して構成内でActiveGridlink=trueを設定します。

Active GridLinkデータ・ソースのベスト・プラクティス

次の各項では、AGLデータ・ソースを使用する際のベスト・プラクティスについて説明します。

例外のキャッシュと処理

アプリケーションは、すべての例外をキャッシュして処理する必要があります。AGLデータ・ソースを使用するアプリケーションは、流用された接続でJDBC操作を実行するときに、IO socket read errorなどの例外を予期しておく必要があります。接続の有効性を検査して、必要なときには再接続することがベスト・プラクティスになります。接続の例外は、FANイベントの到着前にドライバが停止を検出した場合や、接続のクリーンアップの結果として発生することがあります。計画外停止イベントの場合は、その停止の影響を受けるすべての接続が、接続プールによって中断されます。

Active Gridlinkデータ・ソースによる接続の作成

この項では、AGLの接続の変更点について要約します。FANとONSは有効化されていることを前提にしています。

  • 構成済の初期容量に基づいて、最初にプールに接続が追加されます。これには、リスナーに基づいた接続時間のロード・バランシングが使用されます。これが正しく機能するには、複数の非SCANアドレスにLOAD_BALANCE=ONを指定するか、SCANを使用する必要があります。

  • ランタイム・ロード・バランシングに基づいて必要に応じて、接続がプールに追加されます。ただし、これは、トランザクションまたはWebセッションの最後のリクエストにアフィニティを提供するインスタンスに接続が追加された場合、XAアフィニティまたはWebセッション・アフィニティによりオーバーライドされます。

  • 計画済停止イベントが発生すると、そのインスタンスの未使用の接続はすぐに解放され、使用中の接続はプールに返された時点で解放されます。

  • 計画外停止イベントが発生すると、そのインスタンスのすべての接続がすぐに破棄されます。

  • 起動イベントが発生すると、新しいインスタンスに接続が事前に作成されます。

  • グラビテイションの縮小が発生すると、負荷の高いインスタンス(期間単位)で未使用の接続が1つ破棄されます。

  • 通常の縮小が発生すると、最小容量になるまで未使用接続の半数が破棄されます。このとき、負荷(期間単位)は考慮されません。

AGLとマルチ・データ・ソースの比較

AGLは、RACクラスタのサポートに対応したマルチ・データ・ソース(MDS)の上位実装です。次の項では、AGLデータ・ソースの利点に関する追加情報について説明します。AGLの利点は、次のとおりです。

  • 単一URLによるデータ・ソースが1つ必要です。マルチ・データ・ソースでは、n個の汎用データ・ソースと1つのマルチ・データ・ソースが必要になります。

  • 汎用データ・ソースのうちの1つの実行速度低下が障害に結び付く、ポーリング・メカニズムが不要になります。

  • クラスタに対するノードの手動追加や手動削除が不要になります。

  • ノードが使用可能になったときに、高速内部通知(帯域外)を提供します。これにより、Oracle Notification Service (ONS)を使用した新しいノードへの接続のロード・バランシングが可能になります。

  • ノードが停止したときに高速内部通知を提供します。これにより、接続はONSを使用してノードを回避できるようになります。

  • ロード・バランシング・アドバイザ(LBA)を提供します。これにより、負荷が最小のノードに新しい接続が作成されるようになります。また、LBA情報はグラビテイションにも使用され、負荷に基づいてアイドル接続を移動します。

  • XAトランザクションまたはWebセッションに基づいたアフィニティを提供します。これにより、大幅にパフォーマンスが向上することがあります。

  • DataGuardのようなHA構成の利点をフル活用します。詳細は、Oracle WebLogic Serverと可用性の高いOracle Database: Oracle Integrated Maximum Availability Solutionを参照してください。

マルチ・データ・ソースからActive GridLinkへの移行

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))
    
  • 「アルゴリズムのタイプ」は無視します。

マルチ・データ・ソースからActive GridLinkデータ・ソースへの移行の基本手順

次の項では、MDSからAGLに移行する際に必要な基本手順について説明します。

  • WebLogic Server管理コンソールを使用して、MDSと汎用データ・ソースを構成から削除します。

  • WebLogic Server管理コンソールを使用して、単一のAGLデータ・ソースを追加します。

    • MDSと同じJNDI名を付けます。

    • どの汎用データ・ソースを使用していたかに応じて、XAドライバまたは非XAドライバを選択します。

    • 完全なURLを入力します。詳細は、「マルチ・データ・ソースからの移行に伴う構成の変更」を参照してください。

    • ユーザーとパスワードを設定します。これは、MDSメンバーに使用していたものと同じ内容にする必要があります。

    • 「GridLinkデータソース接続のテスト」ページで、「すべてのリスナーのテスト」をクリックして、新しいURLを検証します。

    • ONS接続の情報を入力します。1つ以上のhost:portペアを指定します。例: host1-vip:6200またはscanaddress:6200。可能な場合は、単一のSCANアドレスとポートを使用します。「FANの有効化」が選択されていることを確認します。

    • ONS接続をテストします。

  • データ・ソースをデプロイします。

  • AGLデータ・ソースを編集して、追加パラメータを構成します。

    新しいデータ・ソースの作成中には構成できないデータ・ソースのパラメータが多数あります。多くの場合、MDSで使用していたパラメータ設定値を使用できます。競合が発生した場合は、その競合を解決してから、環境に応じた適切な設定値を選択する必要があります。

WebLogic Server管理コンソールを使用してAGLデータ・ソースを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプJDBC GridLinkデータ・ソースの構成に関する項を参照してください。