1. Oracle WebLogic Server JDBCデータ・ソースの管理
  2. JDBCデータ・ソース・タイプ
  3. Active GridLinkデータ・ソースの使用方法

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

Active GridLink (AGL)データ・ソースは、WebLogic ServerとOracleデータベース間の接続を提供します。Oracleデータベースは、オンプレミス・データベース・サービスとクラウド・データベース・サービスの両方を、Oracle Grid InfrastructureおよびOracle Clusterwareのクラスタ機能とともに提供します。

詳細は、「サポートされているOracleオンプレミスおよびクラウド・データベース・サービス」および「ActiveGridlink属性の理解」を参照してください。

AGLデータ・ソースを使用するには、AGLデータ・ソースの作成、接続プールおよびOracleデータベース・パラメータの構成、チューニング、モニタリングなどが必要です。次の項では、これらの概念の詳細を説明します:

  • Active GridLinkデータ・ソースとは
    Active GridLink(AGL)データ・ソースは、WebLogic Serverと、1つ以上のOracle RACクラスタが含まれる可能性があるOracleデータベース・サービス間の接続を提供します。Oracleデータベース・サービスが共通属性を備えたワークロードとして表現され、システム管理者はこのワークロードを単一のエンティティとして管理できます。
  • Active GridLinkデータ・ソースの構成
    WebLogic Server管理コンソールまたはWLSTを使用して、WebLogicドメインにActive GridLinkデータ・ソースを構成します。
  • SDPを使用したランタイム・ロード・バランシングの構成
    SDP接続全体にロード・バランシングするように構成する場合は、すべてのノードでTNSNAMES.ORAファイルを編集して、LISTENER_IBLOCALエントリにSDPエンドポイントを追加する必要があります。
  • Active GridLink接続プール機能の構成
    アプリケーションは、プールからの接続を使用して、その接続を使用後にプールに返します。接続のプーリングにより、アプリケーション用のデータベース接続を作成するという負担のかかるタスクを排除して、パフォーマンスを向上できます。接続プールには、SQLを使用したデータベース接続の初期化に加え、接続プールに関連付けられたJDBCドライバの機能およびシステム・プロパティを制御できるオプションがあります。
  • Active GridLinkデータ・ソースの接続プールのチューニング
    WebLogic Serverドメイン内のJDBCデータ・ソースで、接続プールの属性を適切に構成すると、アプリケーションとシステムのパフォーマンスを向上できます。
  • Active GridLink JDBCリソースのモニタリング
    Active GridLinkデータ・ソースのモニタリングおよびデバッグについて学習します。
  • FAN通知を使用しないActive GridLinkデータ・ソースの使用方法
    Active GridLinkデータ・ソースは、高速アプリケーション通知(FAN)を有効化せずに構成して使用することもできます。この構成では、2回連続して接続テストに失敗すると、RACノードへの接続が無効化されます。接続テストが成功すると、接続が確立されます。
  • Active GridLinkデータ・ソースのベスト・プラクティス
    Active GridLinkデータ・ソースを使用する場合の例外のキャッチと処理、および接続の作成方法を理解することにより、Active GridLinkデータ・ソースを使用するためのベスト・プラクティスについて学習します。
  • Active GridLinkとマルチ・データ・ソースの比較
    Oracle RACクラスタの使用時にマルチ・データ・ソースではなくActive GridLinkデータ・ソースを使用する利点がいくつかあります。
  • マルチ・データ・ソースからActive GridLinkへの移行
    単純な手動プロセスを使用して、Active GridLinkデータ・ソースからマルチ・データ・ソースに移行できます。
  • Active GridLinkデータ・ソースでのデータベース停止時間の管理
    Oracle RACデータベース環境で、Active GridLinkデータ・ソースを使用してデータベースの停止時間を処理するいくつかの方法を学習します。
  • 段階的排出
    計画されたデータベース・メンテナンスの間、すべての接続を即時にクローズするのではなく、段階的にデータベース接続をクローズします。この戦略は、アプリケーションのパフォーマンスが不均一になることを防ぎます。

親トピック: JDBCデータ・ソース・タイプ

Active GridLinkデータ・ソースとは

Active GridLink (AGL)データ・ソースは、WebLogic Serverと、1つ以上のOracle RACクラスタが含まれる可能性があるOracleデータベース・サービス間の接続を提供します。Oracleデータベース・サービスが共通属性を備えたワークロードとして表現され、システム管理者はこのワークロードを単一のエンティティとして管理できます。

AGLデータ・ソースの数は、Oracle RACクラスタのノード数に合せるのではなく、データベース内でのサービス数の増加に合わせてスケールします。複数クラスタの高可用性サポートには、Data Guard、GoldenGate、Global Database Serviceなどがあります。

ノート:

Active GridLinkとマルチ・データ・ソースは、Oracle RACクラスタと連動するように設計されています。汎用データ・ソースをOracle RACクラスタとともに使用することはお薦めしません。「AGLとマルチ・データ・ソースの比較」を参照してください

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

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

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

親トピック: Active GridLinkデータ・ソースの使用方法

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

高速接続フェイルオーバー機能により、無効な接続の検出とクリーンアップ、使用可能な接続のロード・バランシング、アクティブなOracle RACインスタンス上での作業の再配信といった、Oracle RACイベント通知を実装するためのアプリケーション非依存の方法が提供されます。

WebLogic Serverは、高速接続フェイルオーバーをサポートしています。『Oracle Universal Connection Pool for JDBC開発者ガイド』の高速接続フェイルオーバーの概要に関する項を参照してください。

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

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

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

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

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

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

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

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

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

ノート:

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

親トピック: Active GridLinkデータ・ソースとは

Oracle高速接続フェイルオーバーを使用する場合のJDBCドライバの構成

データ・ソースで高速接続フェイルオーバーを有効にするには、ドライバ・クラス名およびONSの構成文字列のプロパティに特定の値を設定する必要があります。

次の接続プール・プロパティを設定します。

  • ドライバ・クラス名内—クラス名をoracle.jdbc.pool.OracleDataSourceに設定します。

  • プロパティ内—Oracle RACノードをリモートにサブスクライブするONS構成文字列をOracle FAN/ONSイベントに設定します。たとえば: ONSConfiguration=nodes=hostname1:port1,hostname2:port2

    ノート:

    OracleのOracleDataSourceクラスはXA対応ではないため、結果として生じるデータ・ソースではXA接続プールは実装されません。

実行時接続ロード・バランシング

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

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

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

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

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

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

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

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

ノート:

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

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

親トピック: Active GridLinkデータ・ソースとは

GridLinkアフィ二ティ

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

親トピック: Active GridLinkデータ・ソースとは

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

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

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

ノート:

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

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

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

図4-4の説明が続きます
「図4-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に設定します。

親トピック: GridLinkアフィニティ

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

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

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

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

図4-5 XAアフィニティ

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

親トピック: GridLinkアフィニティ

SCANアドレス

複数のノード間で接続をロード・バランシングするために、次の2つのオプションがあります。

  • 1つのOracle単一クライアント・アクセス名(SCAN)アドレスを使用する

    jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=scanname)(PORT=scanport))(CONNECT_DATA=(SERVICE_NAME=myservice)))

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

複数の非SCANアドレスを使用するよりも、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の両方のアドレスが使用できるようになります。

参照:

親トピック: Active GridLinkデータ・ソースとは

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

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

親トピック: Active GridLinkデータ・ソースとは

Active Data Guardのサポート

Active GridLinkデータ・ソースは、Oracle Active Data Guardとも連携します。単一インスタンス(Oracle Restartを使用)とOracle RACデータベースの両方に対して、Oracle Clusterwareがインストールされ、プライマリ・サイトおよびスタンバイ・サイトでアクティブになっている必要があります。Oracle Data GuardブローカはOracle Clusterwareと連動して、Data Guardフェイルオーバーの発生後、ロールベースのサービスを新規プライマリ・データベースへ適切にフェイルオーバーします。Cluster Ready Services (CRS)は、ロール変更が発生するとFANイベントを送信します。

親トピック: Active GridLinkデータ・ソースとは

サポートされているOracleオンプレミスおよびクラウド・データベース・サービス

Oracleデータベースには、Oracle Grid InfrastructureおよびOracle Clusterwareのクラスタ機能で提供される高速アプリケーション通知(FAN)機能を使用するオンプレミス・データベース・サービスとクラウド・データベース・サービスの両方が用意されています。

FAN機能を使用するOracleデータベースのオンプレミス・サービスには、次の製品および機能が含まれています:

FAN機能を使用するOracleデータベース関連のクラウド・サービスには、次の製品が含まれています:

親トピック: Active GridLinkデータ・ソースとは

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

ソケット・ダイレクト・プロトコル(SDP)を使用する場合は、インフィニバンドを使用するようにデータベース・ネットワークを構成する必要があります。SDPは、SCANアドレスをサポートしていません。

『Oracle Database Net Services管理者ガイド』のインフィニバンド接続のSDPサポートの構成に関する項を参照してください。

親トピック: Active GridLinkデータ・ソースとは

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

WebLogic Server管理コンソールまたはWLSTを使用して、WebLogicドメインにActive GridLinkデータ・ソースを構成します。

参照:

  • Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC GridLinkデータ・ソースの作成。

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

WebLogic Server管理コンソールを使用してデータ・ソースを作成するには、次の基本ステップを実行する必要があります:

親トピック: Active GridLinkデータ・ソースの使用方法

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

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

  • データ・ソース名: JDBCデータ・ソースの名前は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、そのリソース以外のすべてのJDBCシステム・リソース(データ・ソースを含む)間で一意の名前にする必要があります。名前の競合を避けるために、データ・ソースの名前は、その他の構成オブジェクト(サーバー、アプリケーション、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど)の名前の間でも一意にする必要があります。特定のアプリケーションにスコープ設定されたJDBCアプリケーション・モジュールの場合、データ・ソースの名前は、同様にスコープ設定されたJDBCデータ・ソース間で一意にする必要があります。
  • データ・ソース・スコープ: データ・ソースのスコープを選択し、スコープを「グローバル」(ドメイン・レベル)または既存のリソース・グループまたはリソース・グループ・テンプレートに設定できます。
  • JNDI名: 単一の名前または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成します。単一のJDBC接続プールを指す複数のデータ・ソースを含む従来の構成のかわりに、multi-JNDI-namedデータ・ソースを使用できます。『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。
  • ドライバ: JDBCリプレイ・ドライバ対応のリプレイ・ドライバか、XAまたは非XA Thinドライバを選択します。

    ノート:

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

親トピック: Active GridLinkデータ・ソースの構成

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

WebLogic Server管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic Serverにより、JDBCドライバの種類に応じて特定のトランザクション・オプションが自動的に選択されます。WebLogic JDBCデータ・ソースでは、XA、非XA、グローバル・トランザクションのオプションがサポートされています。

データ・ソースをサポートするようにトランザクションを構成する方法の詳細は、「JDBCデータ・ソース・トランザクション・オプション」を参照してください

親トピック: Active GridLinkデータ・ソースの構成

接続プロパティの構成

接続プロパティは、データ・ソースとDBMSとの間の接続を構成するために使用します。一般的な属性には、サービス名、データベース名、ホスト名、ポート番号、ユーザー名とパスワードがあげられます。

ノート:

サービス名の使用方法:

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

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

親トピック: Active GridLinkデータ・ソースの構成

接続プロパティの入力

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

完全な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に設定します。

サポートされるActive GridLinkデータ・ソース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_COUNT, RETRY_DELAY, CONNECT_TIMEOUTを入力します。

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

  • RETRY_COUNT は、接続試行を終了するまでに、ADDRESSリストが横断する回数の指定に使用します。デフォルト値は0です。FAILOVER=onでSCANリスナーを使用中に、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属性を使用すると、追加の構成情報をテストできます。

親トピック: Active GridLinkデータ・ソースの構成

ONSクライアントの構成

「ONSクライアント構成」を使用すると、データ・ソースをOracle FANイベントにサブスクライブして、処理できるようになります。ONSノード・リストを構成する場合、値を指定せず、自動ONSによるONS構成の実行を許可することをお薦めします。ただし、Oracleウォレットおよびパスワードを指定する必要がある場合や、ONSトポロジを明示的に指定する場合など、一定の場合には明示的にONS構成を設定する必要があります。

WLSTを使用してONSクライアントを構成することもできます。例については、「WLSTを使用したONSクライアントの構成」を参照してください

管理コンソールのデータ・ソースのサマリー・ページでONSクライアントを構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのONSクライアント・パラメータの構成を参照してください。

その他の考慮事項

一般に、WebLogic Serverデータ・ソースの初期容量の設定が0に設定されている場合、WebLogic Serverは起動時にDBMS接続を作成しません。Auto-ONSが設定されているActive GridLinkデータソースの場合、WebLogic Serverは起動時に1度DBMSに接続してONS情報を取得する必要があります。

親トピック: Active GridLinkデータ・ソースの構成

FANイベントの有効化

Oracle Fast Application Notification (FAN)イベントにサブスクライブして処理できるようにデータ・ソースを構成するには、「FANの有効化」を選択します。

ONSホストおよびポートの構成

OnsNodeList値を構成する場合、単一ノード・リストまたはプロパティ・ノード・リストという2つの方法を使用できます。どちらも使用できますが、両方は使用できません。WebLogic ServerのOnsNodeListに等号(=)が含まれる場合、プロパティ・ノード・リストであると仮定されます。

どちらのタイプのノード・リストでも、FAN通知にアクセスするため、ホスト名のかわりに単一クライアント・アクセス名(SCAN)アドレスを使用できます。SCANアドレスの詳細は、「SCANアドレス」を参照してください。

次を使用してOnsNodeList値を構成するには:

  • 単一ノード・リスト - ONSベースのFANイベントを受信するためのONSデーモン・リスニング・アドレスおよびポートのカンマ区切りのリストを指定します。たとえば、rac1:6200,rac2:6200となります。AGLデータ・ソースを作成するときに管理コンソールの「ONSホストとポート」フィールドに単一ノード・リストを入力できます。

  • プロパティ・ノード・リスト - 複数のレコードを含む文字列を指定します(各レコードがキーと値のペアで構成され、末尾が改行('\n')文字です)。たとえば、nodes.1=rac1:6200,rac2:6200となります。データ・ソースを作成するときに「ONSホストとポート」フィールドにプロパティ・ノード・リストを入力することはできません。かわりに、このフィールドは空白のままにする必要があります。データ・ソースの作成が終了した後に、そのデータ・ソースの設定ページにある「構成: ONS」タブでプロパティ・ノード・リストを入力できます。

プロパティ・ノード・リストには次のキーを指定できます。

  • nodes.id—リモートONSサーバーの一意のトポロジを表すノードのリスト。idは、ノード・リストの一意の識別子を指定します。重複するエントリは無視されます。いずれかのリストで構成されているノードのリストに、同じクライアントの他のリストで構成されているノードを含めることはできません(これを行うと、重複する通知が送信および配信されます)。リストの書式は、コロンで区切られたONSデーモン・リスニング・アドレスとポートのペアのカンマ区切りのリストです。

  • maxconnections.id—ONSサーバーが保持する最大同時接続数を指定します。idはこのパラメータが適用されるノード・リストを指定します。デフォルトは3です

  • active.id: trueの場合、リストはアクティブになり、構成された数のONSサーバーに対して接続が自動的に確立されます。falseの場合、リストは非アクティブになり、アクティブなリストの接続を1つも確立できない場合にのみ、フェイルオーバー・リストとして使用されます。非アクティブなリストは、一度に1つのアクティブなリストのフェイルオーバーとしてのみ機能でき、アクティブなリストで単一の接続が再確立されると、フェイルオーバー・リストは非アクティブに戻ります。リストのフェイルオーバー後にクライアントがパブリッシュした通知のみがフェイルオーバー・リストに送信されることに注意してください。idは、このパラメータが適用されるノード・リストを指定します。デフォルトはtrueです

  • remotetimeout —各リモート・サーバーに対する接続のタイムアウト期間(ミリ秒)。リモート・サーバーがこのタイムアウト期間内に応答しない場合、接続は閉じられます。デフォルト値は30秒です

ノート:

walletfileとwalletpasswordの文字列がサポートされますが、WebLogic Serverでは、これらの値に対する別の構成要素としてOnsWalletFileとOnsWalletPasswordEncryptedがあります。
セキュアなONSクライアント通信

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

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

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

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

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

親トピック: Active GridLinkデータ・ソースの構成

Oracleパラメータの構成

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

親トピック: Active GridLinkデータ・ソースの構成

WLSTを使用したONSクライアントの構成

WLSTを使用してONSクライアントを構成します。

次のコード部分は、Active GridLinkデータ・ソースのOracleパラメータの設定例です。 

cd('/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName + '/JDBCOracleParams/' + dsName)
cmo.setFanEnabled(true)
cmo.setOnsNodeList('nodes.1=rac1:6200,rac2:6200\nmaxconnections.1=3\n')

ONSクライアントの構成の詳細は、「ONSクライアントの構成」を参照してください。

親トピック: Active GridLinkデータ・ソースの構成

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

親トピック: Active GridLinkデータ・ソースの使用方法

Active GridLink接続プール機能の構成

アプリケーションは、プールからの接続を使用して、その接続を使用後にプールに返します。接続のプーリングにより、アプリケーション用のデータベース接続を作成するという負担のかかるタスクを排除して、パフォーマンスを向上できます。接続プールには、SQLを使用したデータベース接続の初期化に加え、接続プールに関連付けられたJDBCドライバの機能およびシステム・プロパティを制御できるオプションがあります。

ノート:

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

詳細は、JDBCデータ・ソース: 構成: 接続プール(Oracle WebLogic Server管理コンソール・オンライン・ヘルプ)およびJDBCConnectionPoolParamsBean (『Oracle WebLogic Server MBeanリファレンス』)を参照してください。

JDBCデータ・ソースでは、次の接続プール・オプションを使用できます:

親トピック: Active GridLinkデータ・ソースの使用方法

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

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

ノート:

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

親トピック: Active GridLink接続プール機能の構成

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

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

ノート:

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

親トピック: Active GridLink接続プール機能の構成

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

親トピック: Active GridLink接続プール機能の構成

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

WebLogic Serverドメイン内のJDBCデータ・ソースで、接続プールの属性を適切に構成すると、アプリケーションとシステムのパフォーマンスを向上できます。

「データ・ソース接続プールのチューニング」を参照してください

親トピック: Active GridLinkデータ・ソースの使用方法

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

Active GridLinkデータ・ソースのモニタリングおよびデバッグについて学習します。

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

親トピック: Active GridLinkデータ・ソースの使用方法

実行時統計の表示

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

親トピック: Active GridLink JDBCリソースのモニタリング

JDBCOracleDataSourceRuntimeMBean

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

親トピック: 実行時統計の表示

JDBCOracleDataSourceInstanceRuntimeMBean

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

親トピック: 実行時統計の表示

ONSDaemonRuntimeMBean

ONSDaemonRuntimeMBeanには、Active GridLinkデータ・ソースに関連付けられた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のデバッグ機能を有効化すると、アプリケーションで発生した特定の問題を追跡できるようになります。

親トピック: Active GridLink JDBCリソースのモニタリング

JDBCのデバッグ範囲

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

  • DebugJDBCRAC - Active GridLinkデータ・ソース・ライフサイクル、ユニバーサル接続プール・コールバックおよび接続情報を出力します。

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

  • DebugJDBCReplay - JDBCリプレイ・ドライバのリプレイ情報をトレースします。

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

UCP JDKロギング

UCP JDKロギングを有効化するには、『Oracle Universal Connection Pool for JDBC開発者ガイド』のUCPでのロギングの概要を参照してください。

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

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

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

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

ONSデバッグを有効化するには、Java Util Loggingを構成する必要があります。これを行うには、コマンド行で次のプロパティを設定します。
-Doracle.ons.debug=true

Java Platform Standard Edition API仕様のjava.util.loggingに関する項を参照してください。

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

Active GridLinkデータ・ソースは、高速アプリケーション通知(FAN)を有効化せずに構成して使用することもできます。この構成では、2回連続して接続テストに失敗すると、RACノードへの接続が無効化されます。接続テストが成功すると、接続が確立されます。

ノート:

これはオラクル社の標準的な推奨事項ではありません。

TestConnectionsOnReserveを有効化することをお薦めします。構成済のファイアウォールが、このプロトコルを遮断する場合は、FANをオフにすることが必要になる場合があります。

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

表4-2 Active GridLinkの機能(「FANの有効化」がFalseの場合)

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

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

はい

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

はい

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

いいえ

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

いいえ

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

いいえ

正常なシャットダウン

いいえ

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

いいえ

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

はい

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

はい

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

いいえ

ActiveGridlink属性の理解

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

ノート:

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

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

親トピック: Active GridLinkデータ・ソースの使用方法

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

Active GridLinkデータ・ソースを使用する場合の例外のキャッチと処理、および接続の作成方法を理解することにより、Active GridLinkデータ・ソースを使用するためのベスト・プラクティスについて学習します。

親トピック: Active GridLinkデータ・ソースの使用方法

例外のキャッシュと処理

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

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

Active GridLinkデータ・ソースを使用する接続の作成

この項では、Active GridLinkデータ・ソースの接続の変更点について要約します。FANとONSは有効化されていることを前提にしています:

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

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

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

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

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

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

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

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

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

Oracle RACクラスタの使用時にマルチ・データ・ソースではなくActive GridLinkデータ・ソースを使用する利点がいくつかあります。

利点は、次のとおりです:

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

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

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

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

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

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

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

  • DataGuardのようなHA構成の利点をフル活用します。詳細は、Oracle Technology Network (http://www.oracle.com/technetwork/middleware/weblogic/learnmore/index.html)で、「Oracle WebLogic Serverと可用性の高いOracle Database: Oracle Integrated Maximum Availability Solution」を参照してください。.

親トピック: Active GridLinkデータ・ソースの使用方法

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

単純な手動プロセスを使用して、Active GridLinkデータ・ソースからマルチ・データ・ソースに移行できます。

親トピック: Active GridLinkデータ・ソースの使用方法

マルチ・データ・ソースからの移行に伴うアプリケーションの変更

アプリケーションに対しては、なにも変更する必要はありません。標準的なアプリケーションは、JNDIのマルチ・データ・ソースを検索し、そのマルチ・データ・ソースを使用して接続を取得します。マルチ・データ・ソースと同じJNDI名をActive GridLinkデータ・ソースに指定すると、アプリケーションでJNDIのデータ・ソース名を使用するプロセスはまったく同じになります。

親トピック: マルチ・データ・ソースからActive GridLinkへの移行

マルチ・データ・ソースからの移行に伴う構成の変更

構成にのみ変更が必要になります。Active GridLinkデータ・ソース(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への移行

基本的な移行ステップ

次の項では、マルチ・データ・ソースからActive GridLinkデータ・ソースに移行する際に必要な基本ステップについて説明します:

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

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

    • マルチ・データ・ソースと同じJNDI名を付けます。

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

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

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

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

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

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

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

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

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

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

親トピック: マルチ・データ・ソースからActive GridLinkへの移行

Active GridLinkデータ・ソースでのデータベース停止時間の管理

Oracle RACデータベース環境で、Active GridLinkデータ・ソースを使用してデータベースの停止時間を処理するいくつかの方法を学習します。

親トピック: Active GridLinkデータ・ソースの使用方法

データベースの停止に対応するActive GridLink構成

Active GridLinkデータ・ソースが次のように構成されていることを確認します:

  • 高速アプリケーション通知(FAN)が有効です。FANは、データベース・サービス、インスタンス、データベース自体、およびクラスタを構成するノードの状態変更に関する迅速な通知を行います。これにより、アプリケーションにエラーを返すことなく、計画メンテナンス中に作業を排出できます。

  • 自動ONSまたは明示的に定義されたONS構成を使用しています。「ONSクライアント構成」を参照してください。

  • 動的データベース・サービスを使用しています。管理サービスまたはPDBサービスを使用して接続しないでください。これらは、管理目的専用であり、FANではサポートされません。

  • テスト接続が有効です。停止の状況によっては、停止イベントが処理される前に接続が流用されている場合、アプリケーションは、古い接続を取得する可能性があります。たとえば、この状況は、着信接続リクエストと同時にソケットが閉じられたときに、クリーン・インスタンスの停止で発生することがあります。アプリケーションがエラーを受信することを避けるには、接続プールで接続チェックを有効にする必要があります。この場合、test-connections-on-reserveをtrueに設定し、test-table (Oracleの推奨値はSQL ISVALID)を設定する必要があります。

  • SCAN使用が最適化されています。データベース・ドライバ12.1.0.2以上では、最適化としてADDRESSLISTのURL設定LOAD_BALANCE=TRUEを設定し、SCANアドレス用にDNSから返されるSCAN IPアドレスを強制的に並べ替えます。

12.1.0.2より前のデータベース・ドライバでは、接続プロパティoracle.jdbc.thinForceDNSLoadBalancing=trueを使用します。SCANアドレスを参照してください。

親トピック: Active GridLinkデータ・ソースでのデータベース停止時間の管理

計画停止の手順

計画停止時間の場合、その主な目標は、データベース・サーバーでメンテナンスが進行中であっても、アプリケーションを中断することなくスケジュール済メンテナンスを管理することです。この目標を達成するには、次のことが必要です。

  • 透過的スケジュール済メンテナンス - データベース・サーバーのスケジュール済メンテナンス・プロセスが、アプリケーションに対して透過的であることが保証されます。

  • セッション排出 - データベース・サーバーでメンテナンスのためにインスタンスを停止する場合、セッション排出によって、そのノードでインスタンスを使用しているすべての作業が完了し、アイドル・セッションが削除されることが保証されます。セッションは、処理中の作業に影響を与えることなく排出されます。

メンテナンス目的で(システム内またはシステム間でのソフトウェアとハードウェアのアップグレード、修理、変更、移行など)、使用されているサービスは、WebLogic Serverアプリケーションの操作および可用性を中断することなく、一度に1回または複数回正常に停止されます。FAN DOWNイベントが発生すると、Active GridLinkは、メンテナンスの対象となる1つ以上のインスタンスからセッションを排出します。ターゲット・データベース・インスタンスで実行されている非シングルトン・サービスを停止するか(それらがまだ残りの実行中のインスタンスで使用可能であると仮定)、シングルトン・サービスをターゲット・インスタンスから別のインスタンスに再配置する必要があります。サービスが排出されると、インスタンスは、アプリケーション・エラーなしで停止されます

次のステップでは、計画メンテナンス・プロセスの概要を示します。

  1. メンテナンスの対象となるインスタンスでDBAがトリガーしたDOWNイベントが検出されます。
  2. 1つ以上のターゲット・インスタンスからセッションを排出します。
  3. データベース・サーバーでスケジュール済メンテナンスを実行します。
  4. アップグレードした1つ以上のノードで操作を再開します。
データベース・サーバーと中間層の両方で操作を調整する必要のあるマルチ・データ・ソースとは異なり、Active GridLinkはデータベースと連携することで、それらの操作すべてがデータベース・サーバーから管理できるようになりプロセスが簡略化されます。表4-3は、データベース・サーバーで実行されるステップと中間層での対応する応答を示しています。

表4-3 Active GridLink計画メンテナンスのためにデータベース・サーバーで実行されるステップ

ステップ番号 データベース・サーバーのステップ コマンド 中間層の応答

1.

-forceなしで非シングルトン・サービスを停止するか、シングルトン・サービスを再配置します。

–serverオプションを省略すると、インスタンスのすべてのサービスに影響します。

$ srvctl stop service –db db_name -service service_name -instance instance_name

または

$ srvctl relocate service –db db_name -service service_name -oldinst oldins -newinst newinst

サービスのFAN計画停止(reason=USER)イベントは、サービスが使用できなくなったため、接続を排出する必要があることを接続プールに通知します。停止されたサービスのアイドル接続は、即座に解放されます。使用中の接続は、アプリケーションから返された(論理的に閉じられた)ときに解放されます。新しい接続は、サービスを提供する他のインスタンスおよびデータベースで予約されます。このFANアクションは、アプリケーションを中断することなく、インスタンスからのセッションの排出を開始します。

2.

停止したサービスを無効化して、自動的に再起動されないようにします。サービスの無効化はオプションです。このステップは、アクションが完了するまでサービスの自動的な再起動が禁止されるメンテナンス・アクションに推奨されます。

$ srvctl disable service –db db_name -service service_name -instance instance_name

新しい接続は、停止または無効化されたサービスに中間層で関連付けられません。

3.

セッションの排出を許可します。

該当なし

所要時間は、アプリケーションに応じて異なります。長時間実行される問合せになることもあります。バッチ・プログラムは、定期的に接続を返して新しい接続を取得するように記述されていない可能性があります。メンテナンスの前にバッチを排出することをお薦めします。

4.

長時間実行されるセッションをチェックします。トランザクション切断を使用してこれらのセッションを終了します。セッションの排出を待機します。問合せを再度実行して、セッションが残っているかどうかをチェックできます。

SQL> select count(*) from (select 1 from v$sessionwhere service_name in upper('service_name') union all select 1 from v$transaction where status = 'ACTIVE' )

SQL> exec dbms_service.disconnect_session( 'service_name', DBMS_SERVICE.POST_TRANSACTION)

中間層の接続はエラーを受け取ります。JDBCリプレイ・ドライバを使用している場合、別のインスタンスで新しい接続に対して操作を自動的にリプレイすることで、アプリケーションからエラーを隠蔽できます。それ以外の場合、アプリケーションはSQLExceptionを受け取ります。

5.

ステップ1から4を繰り返します。

計画メンテナンスの対象となるすべてのサービスで繰り返します

 該当なし

6.

immediateオプションを使用してデータベース・インスタンスを停止します。

$ srvctl stop instance –db db_name -instance instance_name -stopoption immediate

データベースとサービスが再起動されるまで中間層に影響はありません。

7.

オプションで、メンテナンス中に自動的に再起動しないようにインスタンスを無効化します。

このステップは、メンテナンス中にサービスを再開できないメンテナンス操作向けです。

$ srvctl disable instance –db db_name -instance instance_name

 該当なし

8.

スケジュール済メンテナンス作業(パッチ、修理および変更)を実行します。

 該当なし

 該当なし

9.

インスタンスを有効化して起動します。

$ srvctl enable instance –db db_name -instance instance_name

$ srvctl start instance –db db_name -instance instance_name

 該当なし

10.

サービスを有効化して起動します。サービスが起動されて実行中であることを確認します。

$ srvctl enable service –db db_name -service service_name -instance instance_name

$ srvctl start service –db db_name -service service_name -instance instance_name

サービスのFAN UPイベントは、新しいインスタンスが使用可能になったため、次回のリクエストの送信時にこのインスタンスでセッションを作成できることを接続プールに通知します。セッションの自動リバランスが開始します。

次の図は、計画停止時間の前後での、あるサービスの2つのOracle RACインスタンスに対する接続の配分を示しています。接続ワークロードが、両方のインスタンス間で50対50から100対0に移行していることがわかります。言い換えると、RAC_INST_1は、ビジネス操作に影響を与えることなくメンテナンスのために停止できます。

図4-6 2つのOracle RACインスタンス間での接続の配分


図4-6の説明が続きます
「図4-6 2つのOracle RACインスタンス間での接続の配分」の説明

親トピック: Active GridLinkデータ・ソースでのデータベース停止時間の管理

計画外停止

計画外停止が発生する場合、いくつかの相違点があります。

  • データベース・サーバーのコンポーネントに障害が発生すると、そのノードで実行されているインスタンス上ですべてのサービスが使用できなくなる可能性があります。障害が発生しているため、サービスの停止または無効化は行われません。

  • FAN計画外停止イベント(reason=FAILURE)が中間層に配信されます。

  • すべてのセッションが即座に閉じられるため、アプリケーションは、TCP/IPタイムアウトを待機することはありません。他のインスタンスの既存の接続は使用可能なままで、必要に応じてそれらのインスタンスに新しい接続が開かれます。

  • 接続の正常な排出は行われません。JDBCリプレイ・ドライバを使用するように構成されているサービスを使用するアプリケーションの場合、アクティブ・セッションが残存インスタンスでリストアされ、操作をリプレイすることでリカバリされるため、停止はアプリケーションから隠蔽されます。JDBCリプレイ・ドライバで保護されていない場合、インスタンスとアクティブに通信しているすべてのセッションがSQLExceptionを受信します。

親トピック: Active GridLinkデータ・ソースでのデータベース停止時間の管理

段階的排出

計画されたデータベース・メンテナンスの間、すべての接続を即時にクローズするのではなく、段階的にデータベース接続をクローズします。この戦略は、アプリケーションのパフォーマンスが不均一になることを防ぎます。

計画的なデータベースのメンテナンスが行われるときには、計画済停止のサービス・イベントがWebLogic Server JDBCデータ・ソースによって処理されます。デフォルトで、プール内の予約されていない接続はすべて即時にクローズされ、流用されている接続はプールに返された時点でクローズされます。この停止処理により、アプリケーションのパフォーマンスが不均一になる可能性があります。

  • 新しい接続を代替インスタンスに作成する必要があります。

  • 他のインスタンスでもログオン・ストームが発生する可能性があります。

この機能は、Oracle RACとともに実行されているActive GridLinkデータ・ソースのためにサポートされています。

排出タイムアウト期間の設定

接続プロパティweblogic.jdbc.drainTimeoutは、排出期間を秒数で定義すると認識されています。この値は、負でない整数である必要があります。 たとえば、次はデータソースを作成するWLSTスクリプトのサンプルです。 

jdbcSR = create(dsname, 'JDBCSystemResource')
jdbcResource = jdbcSR.getJDBCResource()
driverParams = jdbcResource.getJDBCDriverParams()
driverProperties = driverParams.getProperties()
drainprop = driverProperties.createProperty('weblogic.jdbc.drainTimeout')
drainprop.setValue('60')

Oracleデータベース12.2ドライバとOracleデータベース12.2サーバーで実行する場合、排出タイムアウトはデータベース・サーバー側でデータベース・サービスに-drain_timeoutを設定することで構成できます。 たとえば、リプレイ可能なサービスは次を使用して作成できます:

srvctl add service -db ORCL -service otrade -clbgoal SHORT  -preferred orcl1,orcl2 -rlbgoal SERVICE_TIME -failoverretry 30 -failoverdelay 10  -failovertype TRANSACTION -commit_outcome TRUE -replay_init_time 1800 -retention 86400 -notification TRUE -drain_timeout 60

接続プロパティとサーバー側の排出タイムアウトの両方がOracleデータベース12.2の構成に設定されている場合、サーバー側の値が優先されます。この値は、サービスが実行しているインスタンスの全部ではなく一部を停止するために、計画停止イベント中にのみ使用されます。 たとえば、

srvctl stop service -db ORCL -instance orcl2 -service otrade.example.com

排出期間が設定されないか0に設定されると、デフォルトで排出期間はなく、接続はただちにクローズされます。

値が小さいと移行は加速されますが、宛先ノードでのリクエストがコールド・バッファ・キャッシュをビットするためにアプリケーションで応答時間が長くなる可能性があります。値が大きいほど、移行はより段階的に行われ、宛先ノード上のバッファ・キャッシュに与えられるウォームアップ時間が増える結果、アプリケーションに対する影響が減りますが、全体的な移行期間は長くなります。

段階的排出処理

処理が開始するのは、Active GridLinkデータ・ソースに対して構成されたデータベース・サービスがsrvctl stop service -db dbname -instance instancename -service servicenameを使用して停止されたときです。

ノート:

すべてのサービスが停止している場合(たとえばインスタンス名が指定されていない場合)、排出は行われません。

  • 排出タイムアウトが設定されないか0に設定されると、排出期間はありません。予約されていない接続はただちにクローズされ、流用された接続はプールに返された時点でクローズされます。

  • 排出期間が指定されると、別のRACインスタンスでサービスが使用可能な場合にのみ有効になります。アクティブ/アクティブ・サービスの場合、排出は段階的です。アクティブ/パッシブ・サービスの場合、バージョン12.2のRACでは最初にサービスが再配置されるため、段階的排出もサポートされます。この機能は、Oracle DataGuardではプライマリ・アクティブ・サービスが一度に1つのみのため使用できません。

  • 代替インスタンスが使用可能な場合、排出タイムアウトが開始します。粒度および接続の削減は5秒間隔で行われます。合計接続数は、予約されていない接続の数と予約済の接続の数です。合計数を値"(排出期間/5)"で割って、間隔当たりに解放する接続の数が計算されます(1未満の場合、一部の間隔で接続が排出されないことがあります)。各5秒間隔の後、収集可能な接続が収集され、間隔数の接続が、予約されていないか、プールに返された時にクローズするとマークされている場合はクローズされます。最終間隔の後、インスタンスは停止とマークされます(モニター・ステータスに関して)。

  • データ・ソースが中断または停止されると、現在排出が行われているどのインスタンスでも排出が停止します。予約されていない接続はただちにクローズされ、流用された接続はプールに返された時点でクローズされます。

  • サービスが、そのサービスに対して排出が行われているインスタンスで再開すると排出は停止します。

  • サービスが、インスタンス名を指定しなかったか最後のインスタンスが停止したことによりすべてのインスタンスで停止すると、排出はすぺてのインスタンスで停止します。すべてのインスタンスに対して、予約されていない接続はただちにクローズされ、流用された接続はプールに返された時点でクローズされます。

  • あるインスタンスで排出が発生している場合、データ・ソース上の接続グラビテイション(ランタイム・ロード・バランシング情報に基づいた接続の再バランシング)は排出が完了するまで停止します。

  • サービスが停止すると、ロード・バランシング・アドバイザ(LBA)で、停止したサービスの割合が0である必要があることが示されます。 これにより、既存の接続を最初に他のインスタンスに割り当てることが優先されます。 他のインスタンスに接続が存在せず、停止したサービスに接続が存在する場合、接続を作成するかわりにその接続が選択されます。  これは、LBAまたはセッション・アフィニティを使用して作成した接続に適用されます。 XAアフィニティは、アフィニティ・コンテキストのインタンスに対して新しい接続を作成しようとし、新しい接続を作成できない場合は異なるインスタンスまたはブランチのみを使用します。

例

次の図は、インスタンス上のサービスが停止されたときの段階的排出の効果を示しています。このケースで、サービスはインスタンスbeadev2上で25:00の直後に停止されます。 ロード・バランシング・アドバイザ(LBA)が停止に応答するのは25:25頃であり、しばらく時間がかかること、またインスタンスbeadev2の割合が0へと変化することに注意してください。   WebLogic Serverは停止イベントをほとんど即座に受信して、処理を開始します。  段階的排出が構成されなかった場合、現在の容量のグラフには、容量がイベントの受信時にただちに0(またはアクティブ接続の数)に低下することが示されています。 かわりに、60秒の排出期間の5秒ごとに容量が段階的に低下していること、これに対応してbeadev1の容量が上昇していることがわかります。 合計容量は期間全体にわたって一定のままであることに注意してください。 

ノート:

これらのグラフは、接続を取得して少しの作業を実施し接続を解放するリクエストの疑似ワークロードから生成されたものです。 現実世界では、結果はそれほど完全ではない可能性があります。

図4-7 段階的排出

図4-7の説明が続きます
「図4-7 段階的排出」の説明

親トピック: Active GridLinkデータ・ソースの使用方法