1. Oracle WebLogic Server JDBCデータ・ソースの管理
  2. JDBCデータ・ソース・タイプ

4 JDBCデータ・ソース・タイプ

Oracle WebLogic Serverには、汎用データ・ソースやマルチ・データ・ソースなど、様々なタイプのJDBCデータ・ソースが用意されています。JDBCデータ・ソースを構成して、WebLogicドメイン内のサーバーまたはクラスタにJDBCリソースをターゲット指定またはデプロイすることにより、データベース接続を構成できます。
  • デフォルト・データ・ソースの使用
    Oracleでは、Java EE 7準拠ランタイムで必要なデフォルト・データ・ソースを提供しています。この事前構成済データ・ソースは、WebLogic ServerとともにインストールされたDerbyデータベースにアクセスするためにアプリケーションで使用できます。
  • 汎用データ・ソースの使用
    汎用データ・ソースを使用すると、データベースにアクセスし、データベース接続を管理できます。汎用データ・ソースとその接続プールによって、効率的なシステム運用の維持を円滑にする接続管理プロセスが提供されます。
  • JDBCマルチ・データ・ソースの使用
    マルチ・データ・ソース(MDS)とは、汎用データ・ソースがJNDIツリーにバインドされるのと同じように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされる汎用データ・ソースのグループを抽象化したものです。MDSを構成して、接続リクエスト時に、そのMDSに関連付けられた汎用データ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供できます。
  • Active GridLinkデータ・ソースの使用
    Active GridLink (AGL)データ・ソースは、WebLogic ServerとOracleデータベース間の接続を提供します。Oracleデータベースは、オンプレミス・データベース・サービスとクラウド・データベース・サービスの両方を、Oracle Grid InfrastructureおよびOracle Clusterwareのクラスタ機能とともに提供します。
  • ユニバーサル接続プール・データ・ソースの使用
    ユニバーサル接続プール(UCP)データ・ソースは、Oracle Universal Connection Poolingを使用してOracle Databaseに接続するユーザー用のオプションとして提供されています。UCPは、Oracle WebLogic Server接続プーリングに対する代替接続プーリング・テクノロジを提供します。

デフォルト・データ・ソースの使用

Oracleでは、Java EE 7準拠ランタイムで必要なデフォルト・データ・ソースを提供しています。この事前構成済データ・ソースは、WebLogic ServerとともにインストールされたDerbyデータベースにアクセスするためにアプリケーションで使用できます。

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

デフォルト・データ・ソースとは

Oracleでは、Java EE 7準拠ランタイムで必要なデフォルト・データ・ソースを提供しています。

これには次のJNDI名でアクセスできます。

java:comp/DefaultDataSource

上記のメッセージは下のメッセージと同じです。

@Resource(lookup="java:comp/DefaultDataSource")
DataSource myDS;

データ・ソース・リソース参照をデフォルト・データ・ソースに明示的にバインドするには、resourceアノテーションのlookup要素またはresource-refデプロイメント記述子要素のlookup-name要素を使用できます。

ノート:

Derbyデータベースは、デフォルトではstartWebLogicコマンドによって起動されます。WebLogic Serverインスタンスの起動および停止の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』の「サーバーの起動と停止」を参照してください。

デフォルト・データ・ソースの特性

デフォルト・データ・ソースには、次の特性があります。

  • デプロイされているコンポーネントごとに使用できる必要があります。

  • デプロイ済コンポーネントでのみアクセス可能で、システム・リソースまたはスタンドアロン・デプロイメントであるデータ・ソースではアクセスできません。

  • 参照が行われた後にのみコンソールに表示されます。

  • 他のJava EEデプロイメントのように、コンポーネントごとにデプロイメントとして表示されます。

  • 構成できません。

  • 関連付けられたアプリケーションのライフサイクルを持ちます

デフォルト・データソースの構成

次の表では、WebLogic Serverのデフォルト・データ・ソースの定義を規定する構成設定を提供します。

表4-1 デフォルト・データ・ソースの構成

属性 値
名前 java:comp/DefaultDataSource
初期容量 0
最小容量 0
最大容量 15
クラス名 org.apache.derby.jdbc.ClientDataSource
ポート 1527
ホスト localhost
データベース名 DefaultDataSource
ユーザー なし
パスワード なし
トランザクション false
MaxStatements 0
MaxIdleTimeout 未設定

親トピック: デフォルト・データ・ソースの使用

カスタム・デフォルト・データ・ソースの定義

java:comp/DefaultDataSourceにバインドされたカスタム・データ・ソース記述子を定義するか、デフォルトのデータ・ソースをオーバーライドして別のJNDI名を指すようにすることで、カスタムのデフォルト・データ・ソースを実装できます。

参照:

コンポーネントのデプロイ後、コンポーネントでjava:comp/DefaultDataSourceを使用できない場合、WebLogic Serverの事前構成済デフォルト・データ・ソースをコンポーネントで使用できます。ただし、startWebLogic.sh スクリプトを実行する前に、DERBY_FLAG=false)を設定してDerbyデータベースを無効化した場合、WebLogic Serverの事前構成済デフォルト・データ・ソースは使用できません。

カスタム・デフォルト・データ・ソース・ディスクリプタの作成

事前構成済デフォルト・データ・ソースのかわりとなるjava:comp/DefaultDataSourceにバインドされたデータ・ソース・ディスクリプタを構成できます。たとえば、次にEARアプリケーションのJava EE 6の注釈を示します。 

@Stateless(mappedName="DSBean")
@DataSourceDefinition(name="java:comp/DefaultDataSource",
className="oracle.jdbc.OracleDriver",
portNumber=1521,
serverName="myServer",
databaseName="myDB",
user="a username",
password="a password",
transactional=false
)
public class DSBean implements DSInterface
. . .

デフォルト・データ・ソースのオーバーライド

別の既存のデータ・ソースを指し示すようにサーバーまたはサーバー・テンプレートの構成でデフォルト・データ・ソース属性のJNDI名を更新して、WebLogic Serverで提供される事前構成済デフォルト・データ・ソースをオーバーライドできます。

親トピック: デフォルト・データ・ソースの使用

デフォルト・データ・ソースを使用する場合の互換性の制限

デフォルトのデータ・ソースを使用する場合の制限について学習します。

Weblogic Server 12.2.1より前のリリースでは、WebLogic Serverは、res-refの名前を使用してJNDIのデータ・ソースをルックアップすることで、未解決のデータ・ソースres-ref参照を自動的に解決しようと試みます。この動作は、Java EE 7より前では定義されていません。このWebLogic Serverリリースでは、Java EE 7の定義に従ってデフォルト・データ・ソースを使用します。

親トピック: デフォルト・データ・ソースの使用

汎用データ・ソースの使用

汎用データ・ソースを使用すると、データベースにアクセスし、データベース接続を管理できます。汎用データ・ソースとその接続プールによって、効率的なシステム運用の維持を円滑にする接続管理プロセスが提供されます。

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

汎用データ・ソースとは

汎用データ・ソースを使用すると、データベースにアクセスし、データベース接続を管理できます。

各データ・ソースには、データ・ソースの作成時とサーバーの起動時に作成されるデータベース接続のプールが含まれています。アプリケーションは、JNDIツリーまたはローカル・アプリケーション・コンテキストでデータ・ソースをルックアップしてから、getConnection()を呼び出してデータ・ソースからデータベース接続を確保します。接続の使用後に、アプリケーションは、できるだけ早くconnection.close()を呼び出す必要があります。これにより、データベース接続をプールに戻して、他のアプリケーションが使用できるようにします。

親トピック: 汎用データ・ソースの使用

汎用データ・ソースの構成

このトピックでは、汎用データ・ソースの作成と構成に必要なステップについて説明します。

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

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

データ・ソース・スコープ: データ・ソースのスコープを選択し、スコープを「グローバル」(ドメイン・レベル)または既存のリソース・グループまたはリソース・グループ・テンプレートに設定できます。

JNDI名: 単一の名前または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成します。『Oracle WebLogic Server JNDIアプリケーションの開発』のクラスタ環境でのWebLogic JNDIの使い方を参照してください。

データベースのタイプ: 接続するデータベースのデータベース管理システム(DBMS)を選択できます。『Oracle WebLogic Serverの新機能』のサポートされている構成を参照してください。

JDBCドライバ: データベース接続の作成で優先されるJDBCデータベース・ドライバを選択する必要があります。ただし、コンソールでURLをテストする前に、そのURLが適切であることを確認してください。選択するドライバは、データ・ソースのデプロイ先のすべてのサーバーのclasspathに含まれている必要があります。

WebLogic Server管理コンソールに一覧表示されたすべてのJDBCドライバが、WebLogic Serverに付属している(またはclasspathにすでに含まれている)わけではありません。JDBCドライバの種類を参照してください。

これらのすべてのドライバは、weblogic.jarマニフェスト・ファイルで参照されるため、サーバーのclasspathに明示的に定義されている必要はありません。

データベースへの接続に使用するJDBCドライバを決定する際には、目的の環境で様々なベンダーのドライバを試してみることが必要です。通常、JDBCドライバのパフォーマンスは、アプリケーションで使用するSQLコードやJDBCドライバの実装など、様々な要因に応じて変化します。『Oracle WebLogic Serverの新機能』のサポートされている構成を参照してください。

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

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

テスト・オプションの構成

データ・ソースのデータベース接続テスト・オプションを設定すると、データベース接続を正常な状態に維持できるようになります。これは、アプリケーションの安定稼働につながります。

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

「データベース接続のテスト」を使用すると、データ・ソース構成をファイナライズする前に、表名またはSQL文を使用してデータベース接続をテストできます。必要に応じて、Properties属性とSystem Properties属性を使用すると、追加の構成情報をテストできます。Oracle FMW管理コンソール・オンライン・ヘルプのJDBCデータ・ソースのテスト・オプションの構成を参照してください。

Oracleパラメータの構成

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

JDBCデータ・ソースのターゲット指定

新しいJDBCデータ・ソースのデプロイ先に、1つ以上のターゲットを選択します。ターゲットを選択していない場合でもデータ・ソースは作成されますが、デプロイされません。そのデータ・ソースは、接続を取得する前にデプロイする必要があります。Target JDBC data sources (Oracle WebLogic Server管理コンソール・オンライン・ヘルプ)およびWebLogic ServerでのJDBCドライバの使用方法を参照してください。

親トピック: 汎用データ・ソースの使用

JDBCマルチ・データ・ソースの使用

マルチ・データ・ソース(MDS)とは、汎用データ・ソースがJNDIツリーにバインドされるのと同じように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされる汎用データ・ソースのグループを抽象化したものです。MDSを構成して、接続リクエスト時に、そのMDSに関連付けられた汎用データ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供できます。

汎用データ・ソースの詳細は、汎用データ・ソースの使用を参照してください。

アプリケーションは、汎用データ・ソースの場合と同じようにJNDIツリー上のMDSまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のMDSをルックアップし、その後データベース接続をリクエストします。MDSによって、MDS構成で選択されたアルゴリズム(ロード・バランシングまたはフェイルオーバー)に応じて、リクエストに対応するために使用する汎用データ・ソースが決定されます。

ノート:

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

  • マルチ・データ・ソースとは
    マルチ・データ・ソースは、Oracle Real Application Clusters(Oracle RAC)など、可用性の高いデータベース・システムのノード間のフェイルオーバーまたはロード・バランシングに使用されます。MDSソースの汎用データ・ソース・メンバー・リストは、動的な更新をサポートしています。この機能により、Oracle RAC環境では、データベース・ノードおよび対応する汎用データ・ソースを再デプロイメントなしで追加および削除し、スループットに応じてRACクラスタを拡大/縮小し、メンテナンスのためにOracle RACノードを停止できます。
  • マルチ・データ・ソースの構成
    このトピックで説明するステップを実行して、マルチ・データ・ソースを作成および構成します。
  • マルチ・データ・ソース・フェイルオーバー機能の拡張
    マルチ・データ・ソースでのフェイルオーバー処理を改善する方法について学習します。
  • マルチ・データ・ソースでの計画データベース・メンテナンス
    マルチ・データ・ソースで使用されるデータベース・サーバーで、サービスの中断なしに計画されたメンテナンスを処理する方法を学習します。
  • データ・ソースの停止
    データ・ソースを停止する場合、まずデータ・ソースを中断してから、関連するリソース(接続など)を解放します。

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

マルチ・データ・ソースとは

マルチ・データ・ソースは、Oracle Real Application Clusters(Oracle RAC)など、可用性の高いデータベース・システムのノード間のフェイルオーバーまたはロード・バランシングに使用されます。MDSソースの汎用データ・ソース・メンバー・リストは、動的な更新をサポートしています。この機能により、Oracle RAC環境では、データベース・ノードおよび対応する汎用データ・ソースを再デプロイメントなしで追加および削除し、スループットに応じてRACクラスタを拡大/縮小し、メンテナンスのためにOracle RACノードを停止できます。

ノート:

マルチ・データ・ソースは、データベース同士を同期させるものではありません。データベースの同期は、データの整合性が保たれるよう、WebLogic Serverの外部で適切に処理されることが前提となっています。

データベース・ノードの追加および削除は、データベース管理者が手動で行う操作です。

  • データベース・ノードの追加
    データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに追加できます。この機能によって、メンテナンス後にノードを起動したり、クラスタを拡張できます。
  • データベース・ノードの削除
    データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに削除できます。この機能によって、メンテナンスのためにノードを停止したり、クラスタを縮小できます。

親トピック: JDBCマルチ・データ・ソースの使用

データベース・ノードの追加

データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに追加できます。この機能によって、メンテナンス後にノードを起動したり、クラスタを拡張できます。

次のステップに従って、データベース・ノードを追加します。

  1. データベース・ノードを再起動します。
  2. 汎用データ・ソースを再起動します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの開始を参照してください。
  3. 汎用データ・ソースを再度マルチ・データ・ソースに追加します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソース内のデータ・ソースの追加または削除を参照してください。
データベース・ノードの削除

データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに削除できます。この機能によって、メンテナンスのためにノードを停止したり、クラスタを縮小できます。

次のステップに従って、データベース・ノードを停止します。

ノート:

これらのステップに失敗した場合、トランザクションがロールバックされる場合があります。

  1. 汎用データ・ソースをマルチ・データ・ソースから削除します。『Oracle WebLogic Server Administration Consoleオンライン・ヘルプ』のJDBCマルチ・データ・ソース内のデータ・ソースの追加または削除に関する項を参照してください。
  2. すべてのトランザクションの終了後に、汎用データ・ソースを中断します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの中断を参照してください。
  3. すべてのトランザクションの終了後に、汎用データ・ソースを停止します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの停止を参照してください。
  4. データベース・ノードを停止します。

マルチ・データ・ソースの構成

このトピックで説明するステップを実行して、マルチ・データ・ソースを作成および構成します。

  1. 汎用データ・ソースを作成します。汎用データ・ソースの使用を参照してください。

  2. WebLogic Server管理コンソールまたはWebLogicスクリプト・ツールを使用して、マルチ・データ・ソースを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソースの構成を参照してください。

  3. 汎用データ・ソースをマルチ・データ・ソースに割り当てます。

    マルチ・データ・ソースの構成時に作成される構成ファイルについては、WebLogic ServerにおけるJDBCリソースの理解およびマルチ・データ・ソース・モジュールの作成を参照してください。

ノート:

一般に、WebLogic Serverデータ・ソースの初期容量の設定がゼロに設定されている場合、WebLogic Serverは起動時にDBMS接続を作成しません。しかし、LLRデータ・ソースのマルチ・データ・ソースを起動するために、WebLogic Serverは起動時に接続を作成してDBMSがRACかどうかを確認します。汎用のLLRマルチ・データ・ソースの場合、すべてのデータ・ソースが使用可能である必要がありますが、RACを使用している場合は1つのノードのみがLLR処理用にアクセス可能である必要があります。

  • マルチ・データ・ソース・アルゴリズムの選択
    マルチ・データ・ソースを設定する前に、マルチ・データ・ソースの主要な目的(フェイルオーバーまたはロード・バランシング)を決める必要があります。アルゴリズムは、必要に応じて選択できます。
  • マルチ・データ・ソースのフェイルオーバーの制限と要件
    WebLogic Serverはマルチ・データ・ソース用のフェイルオーバー・アルゴリズムを備えており、汎用データ・ソースで障害(たとえば、データベース管理システムのクラッシュ)が発生しても、システムをそのまま稼働できます。ただし、マルチ・データ・ソースの構成時に考慮する必要がある特定の制限と要件があります。
  • コールバックによるマルチ・データ・ソース・フェイルオーバーの制御
    コールバック・ハンドラをWebLogic Serverに登録できます。これにより、フェイルオーバー・アルゴリズムが設定されたMDSが、接続リクエストをMDS内の1つのJDBC汎用データ・ソースからリスト内の次の汎用データ・ソースにフェイルオーバーするタイミングが制御されます。
  • サーバーおよびクラスタへのJDBCマルチ・データ・ソースのデプロイ
    接続リクエストに応じるために、マルチ・データ・ソースで使用されている汎用データ・ソースはすべて、マルチ・データ・ソースと同じサーバーおよびクラスタにデプロイされている必要があります。マルチ・データ・ソースは、常に同じサーバーにデプロイされている汎用データ・ソースを使用して、接続リストに応じます。マルチ・データ・ソースは、クラスタまたはドメイン内の他のサーバーへの接続リクエストのルーティングは行いません。

親トピック: JDBCマルチ・データ・ソースの使用

マルチ・データ・ソース・アルゴリズムの選択

マルチ・データ・ソースを設定する前に、マルチ・データ・ソースの主要な目的(フェイルオーバーまたはロード・バランシング)を決める必要があります。アルゴリズムは、必要に応じて選択できます。

フェイルオーバー

フェイルオーバー・アルゴリズムでは、接続リクエストに応じるために使用する汎用データ・ソースの順序付けされたリストを指定します。通常、この種類のマルチ・データ・ソースに対する接続リクエストはすべて、リストの先頭にある汎用データ・ソースによって処理されます。データベース接続テストが失敗して接続を置換できなかったり、汎用データ・ソースが中断した場合には、リスト上の次の汎用データ・ソースから順次、接続が検索されます。

ノート:

このアルゴリズムでは、汎用データ・ソースの「予約時に接続をテスト」(TestConnectionsOnReserve)を有効化する必要があります。有効になっている場合は、最初の汎用データ・ソースの接続をテストして、汎用データ・ソースが正常かどうかを確認します。接続のテストが失敗した場合は、マルチ・データ・ソースにリストされている次の汎用データ・ソースの接続が使用されます。TestConnectionsOnReserveの構成については、「データ・ソースの接続テスト・オプション」を参照してください。

JDBCは、きわめてステートフルなクライアントとDBMS間のプロトコルです。JDBCでは、DBMS接続とトランザクション状態が、DBMSプロセスとクライアント(ドライバ)間のソケットに直接関連付けられます。このため、使用中の接続のフェイルオーバーはサポートされません。

ロード・バランシング

ロード・バランシング・マルチ・データ・ソースへの接続リクエストは、リスト内の任意の汎用データ・ソースで処理されます。MDSは、接続リクエストに応じるための汎用データ・ソースをラウンドロビン方式で選択します。MDSは接続を提供する際に、最後に使用された汎用データ・ソースの直後にリストされている汎用データ・ソースの接続を選択します。データベース接続テストが失敗して接続を置き換えられない場合や汎用データ・ソースが中断されている場合も、ロード・バランシング・アルゴリズムを使用するマルチ・データ・ソースは、リスト内の次の汎用データ・ソースにフェイルオーバーします。

マルチ・データ・ソースのフェイルオーバーの制限と要件
WebLogic Serverはマルチ・データ・ソース用のフェイルオーバー・アルゴリズムを備えており、汎用データ・ソースで障害(たとえば、データベース管理システムのクラッシュ)が発生しても、システムをそのまま稼働できます。ただし、マルチ・データ・ソースの構成時に考慮する必要がある特定の制限と要件があります。
予約時の接続テストによるフェイルオーバーの有効化

汎用データ・ソースは、データベース接続が失われたときに把握できるように、汎用データ・ソースの「予約時に接続をテスト」(TestConnectionsOnReserve)機能を利用します。マルチ・データ・ソース内の汎用データ・ソースの「予約時に接続をテスト」機能を有効化する必要があります。各接続をアプリケーションに渡す前に、それらの接続をWebLogic Serverでテストします。このフェイルオーバー・アルゴリズムの場合、マルチ・データ・ソースは接続テストの結果を使用して、マルチ・データ・ソース内の次の汎用データ・ソースにフェイルオーバーする時期を決定します。テストに失敗した場合、汎用データ・ソースは接続を再試行します。再試行も失敗した場合、マルチ・データ・ソースは次の汎用データ・ソースにフェイルオーバーします。

使用中の接続に対するフェイルオーバーの実施不可能

予約後に接続が失敗する可能性もありますが、これについてはアプリケーションで処理する必要があります。WebLogic Serverでは、アプリケーションで使用中に失敗した接続をフェイルオーバーさせることはできません。接続の使用中に障害が発生した場合、アプリケーション・コードでは、障害が発生した接続を閉じて、新しい接続でトランザクションを最初から再起動する必要があります。

コールバックによるマルチ・データ・ソース・フェイルオーバーの制御

コールバック・ハンドラをWebLogic Serverに登録できます。これにより、フェイルオーバー・アルゴリズムが設定されたMDSが、接続リクエストをMDS内の1つのJDBC汎用データ・ソースからリスト内の次の汎用データ・ソースにフェイルオーバーするタイミングが制御されます。

フェイルオーバーを行うかどうか、またはいつ行うかをコールバック・ハンドラで制御することによって、データベースの準備や高可用性フレームワークとの通信といったシステム準備タスクを、フェイルオーバーの前に実行できるようになります。

コールバック・ハンドラは、MDSの「フェイルオーバーのコールバック・ハンドラ」属性を介して、MDSごとに登録されます。コールバック・ハンドラを適用する各MDSに、コールバック・ハンドラを登録する必要があります。また、ドメイン内のMDSごとに、別々のコールバック・ハンドラを登録できます。

コールバック・ハンドラの要件

マルチ・データ・ソース内のフェイルオーバーおよびフェイルバックの制御に使用されるコールバック・ハンドラには、weblogic.jdbc.extensions.ConnectionPoolFailoverCallbackインタフェースの実装が含まれている必要があります。マルチ・データ・ソースでリスト内の次の汎用データ・ソースにフェイルオーバーする必要がある場合や、以前に無効化された汎用データ・ソースが利用可能になった場合、WebLogic ServerではConnectionPoolFailoverCallbackインタフェースのallowPoolFailover()メソッドがコールされ、次に定義されている3つのパラメータ(currPool、nextPoolおよびopcode)の値が渡されます。WebLogic Serverはコールバック・ハンドラからの戻り値を待機し、その後タスクが完了されます。

アプリケーションは、次に定義されているOK、RETRY_CURRENTまたはDONOT_FAILOVERを戻す必要があります。アプリケーションはフェイルオーバーおよびフェイルバックの個々の状況を処理する必要があります。

「weblogic.jdbc.extensions.ConnectionPoolFailoverCallback」インタフェースを参照してください。

ノート:

「フェイルオーバーのコールバック・ハンドラ」はオプションです。マルチ・データ・ソースの構成にコールバック・ハンドラが指定されていなければ、WebLogic Serverは操作(フェイルオーバーまたは無効化された汎用データ・ソースの再有効化)を続行します。

コールバック・ハンドラの構成

フェイルオーバーおよびフェイルバック機能に関連付けられたマルチ・データ・ソース構成の属性は2つあります:

  • フェイルオーバーのコールバック・ハンドラ(ConnectionPoolFailoverCallbackHandler) - マルチ・データ・ソースのフェイルオーバーのコールバック・ハンドラを登録するには、マルチ・データ・ソースの構成にこの属性の値を追加します。値には、com.bea.samples.wls.jdbc.MultiDataSourceFailoverCallbackApplicationなどの絶対名を指定する必要があります。フェイルオーバーのコールバック・ハンドラを設定するには、WebLogic Server管理コンソールを使用ます(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのフェイルオーバーのコールバック・ハンドラの登録を参照)。またはWLSTを使用してマルチ・データ・ソース用のJDBCDataSourceParamsBeanで設定できます。

  • テスト頻度(TestFrequencySeconds) - マルチ・データ・ソースによる、無効化された(レスポンスのない)汎用データ・ソースが利用可能になったかどうかのチェック頻度を制御します。詳細は、「マルチ・データ・ソース内の障害が発生した汎用データ・ソースがリカバリした場合の自動的な再有効化」を参照してください。

フェイルオーバーの仕組み

WebLogic Serverは、現在の汎用データ・ソースで接続テストが失敗した場合や、FailoverRequestIfBusyが有効化されているときに現在の汎用データ・ソース内のすべての接続が使用中の場合に、接続リクエストをリスト内の次の汎用データ・ソースにフェイルオーバーしようとします。

コールバック機能を有効化するには、マルチ・データ・ソースの構成で「フェイルオーバーのコールバック・ハンドラ」を使用して、コールバック・ハンドラをWebLogic Serverに登録します。

フェイルオーバー・アルゴリズムを使用する場合、接続リクエストはリスト内の最初の汎用データ・ソースで処理されます。汎用データ・ソースの接続が接続テストに失敗すると、WebLogic Serverはその汎用データ・ソースを「レスポンスなし」としてマーク付けし、無効にします。コールバック・ハンドラが登録されている場合、WebLogic Serverは次の情報を渡してコールバック・ハンドラを呼び出し、戻り値を待機します。

  • currPool - フェイルオーバーの場合、データベース接続の提供に現在使用されている汎用データ・ソースの名前です。これは、「フェイルオーバー元」の汎用データ・ソースです。

  • nextPool - マルチ・データ・ソースにリストされた次の利用可能な汎用データ・ソースの名前です。フェイルオーバーの場合、これは「フェイルオーバー先」の汎用データ・ソースです。

  • opcode - 呼出しの理由を示すコードです。

フェイルオーバーは接続リクエストと同期します。フェイルオーバーは、WebLogic Serverが接続リクエストに応じようとする場合にのみ発生します。

コールバック・ハンドラからの戻り値は、次の3種類のオプションのいずれかを示します。

  • OK - 処理を続行します。この場合、リスト内の次の汎用データ・ソースにフェイルオーバーすることを意味します。

  • RETRY_CURRENT - 接続リクエストを現在の汎用データ・ソースで再試行します。

  • DONOT_FAILOVER - 現在の接続リクエストの再試行も、フェイルオーバーも行いません。WebLogic Serverによってweblogic.jdbc.extensions.PoolUnavailableSQLExceptionがスローされます。

WebLogic Serverはコールバック・ハンドラによって返された値に従って処理を行います。

2番目の汎用データ・ソースで障害が発生すると、先のフェイルオーバーと同様に、マルチ・データ・ソース内の次に利用可能な汎用データ・ソースにフェイルオーバーを試行するために、WebLogic Serverではコールバック・ハンドラが再度呼び出されます(データ・ソースが存在している場合)。

ノート:

汎用データ・ソースを手動で無効化した場合、WebLogic Serverはコールバック・ハンドラを呼び出しません。

ロード・バランシング・アルゴリズムを使用するマルチ・データ・ソースの場合、WebLogic Serverでは汎用データ・ソースが無効化されても、コールバック・ハンドラは呼び出されません。ただし、無効化された汎用データ・ソースを再有効化しようとする場合には、コールバック・ハンドラが呼び出されます。詳細は、次の項を参照してください。

サーバーおよびクラスタへのJDBCマルチ・データ・ソースのデプロイ
接続リクエストに応じるために、マルチ・データ・ソースで使用されている汎用データ・ソースはすべて、マルチ・データ・ソースと同じサーバーおよびクラスタにデプロイされている必要があります。マルチ・データ・ソースは、常に同じサーバーにデプロイされている汎用データ・ソースを使用して、接続リストに応じます。マルチ・データ・ソースは、クラスタまたはドメイン内の他のサーバーへの接続リクエストのルーティングは行いません。

マルチ・データ・ソースをクラスタまたはサーバーにデプロイするには、サーバーまたはクラスタをデプロイ・ターゲットとして選択します。マルチ・データ・ソースをサーバーにデプロイすると、そのサーバーに、WebLogic Serverによってマルチ・データ・ソースのインスタンスが作成されます。マルチ・データ・ソースをクラスタにデプロイすると、クラスタ内の各サーバーに、WebLogic Serverによってマルチ・データ・ソースのインスタンスが作成されます。

手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースのターゲット指定とデプロイを参照してください。

マルチ・データ・ソース・フェイルオーバー機能の拡張

マルチ・データ・ソースでのフェイルオーバー処理を改善する方法について学習します。

親トピック: JDBCマルチ・データ・ソースの使用

汎用データ・ソースの障害発生時における接続リクエストのルーティング機能の拡張

マルチ・データ・ソース内の汎用データ・ソースで障害が発生したときのパフォーマンスを向上させるため、WebLogic Serverはプールされた接続が接続テストで失敗すると、汎用データ・ソースを自動的に無効化します。汎用データ・ソースが無効化されると、WebLogic Serverでは、アプリケーションからその汎用データ・ソースに接続リクエストがルーティングされなくなります。そのかわりに、マルチ・データ・ソース内にリストされた、次に利用可能な汎用データ・ソースに接続リクエストがルーティングされます。

この機能を使用するには、汎用データ・ソース・テスト・オプション(特に「表名のテスト」および「予約時に接続をテスト」)がマルチ・データ・ソース内のすべての汎用データ・ソースに対して構成されていることが必要です。「データ・ソースの接続テスト・オプション」を参照してください

マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、WebLogic Serverでは、コールバック・ハンドラが呼び出されてから、リスト内の次の汎用データ・ソースにフェイルオーバーされます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。

マルチ・データ・ソース内の障害が発生した汎用データ・ソースがリカバリした場合の自動的な再有効化

接続に失敗して汎用データ・ソースが自動的に無効になった場合、マルチ・データ・ソースは、無効になった汎用データ・ソースからの接続を定期的にテストし、汎用データ・ソース(または基礎となるデータベース)が再び使用可能になったときに判別します。汎用データ・ソースが使用可能になると、マルチ・データ・ソースが汎用データ・ソースを自動的に再有効化し、その汎用データ・ソースへの接続リクエストのルーティングを再開します。これは、マルチ・データ・ソース・アルゴリズムと、含まれる汎用データ・ソース・リスト内の汎用データ・ソースの位置によって異なります。これらのテストの頻度は、マルチ・データ・ソースのテスト間隔属性によって制御されます。テスト頻度のデフォルト値は120秒です。そのため、特にこのオプションの値を設定しない場合は、マルチ・データ・ソースは無効化された汎用データ・ソースを120秒おきにテストします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソース: 構成: 全般を参照してください。

WebLogic Serverは、手動で無効化した汎用データ・ソースに対して、テストも自動的な再有効化も行いません。テストは自動的に無効化された汎用データ・ソースに対してのみ行われます。

マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、WebLogic Serverがコールバック・ハンドラをコールしてから、汎用データ・ソースを再有効化します。詳細は、「コールバックによるマルチ・データ・ソース・フェイルバックの制御」を参照してください。

マルチ・データ・ソース内のビジー状態の汎用データ・ソースのフェイルオーバーの有効化

デフォルトでは、フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースの場合、データベース接続に対するリクエスト数が、マルチ・データ・ソース内の現在の汎用データ・ソースにある利用可能な接続数を超過すると、以降の接続リクエストが失敗します。

現在の汎用データ・ソースのすべての接続が使用されている場合にマルチ・データ・ソースがフェイルオーバーできるようにするには、WebLogic Server管理コンソールの「JDBCマルチ・データ・ソース: 構成: 一般」ページで「ビジー時はリクエストをフェイルオーバー」オプションを有効にします。(JDBCDataSourceParamsBeanのFailoverRequestIfBusy属性でも設定できます)。有効(trueに設定)の場合、現在の汎用データ・ソース内のすべての接続が使用中のとき、アプリケーションの接続リクエストはマルチ・データ・ソース内の次に使用可能な汎用データ・ソースにルーティングされます。無効(デフォルトのfalseに設定)の場合、接続リクエストのフェイルオーバーは行われません。

マルチ・データ・ソースの構成にConnectionPoolFailoverCallbackHandlerが含まれている場合は、WebLogic Serverでは、コールバック・ハンドラがコールされてから、フェイルオーバーが行われます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。

コールバックによるマルチ・データ・ソース・フェイルバックの制御

マルチ・データ・ソースに対してフェイルオーバーのコールバック・ハンドラが登録されている場合、WebLogic Serverは、自動的に無効化された汎用データ・ソースを再有効化するときに、同じコールバック・ハンドラをコールします。無効化された汎用データ・ソースの再有効化を行うかどうか、またはいつ行うかをコールバックで制御することによって、データベースの準備や高可用性フレームワークとの通信といったシステム準備タスクを、汎用データ・ソースの再有効化の前に実行できるようになります。

コールバック・ハンドラの詳細は、次の項を参照してください。

フェイルバックの仕組み

WebLogic Serverでは、マルチ・データ・ソース内の自動的に無効化された汎用データ・ソースのステータスが定期的にチェックされます。(「マルチ・データ・ソース内の障害が発生した汎用データ・ソースがリカバリした場合の自動的な再有効化」を参照してください)無効化された汎用データ・ソースが使用可能になり、コールバック・ハンドラが登録されている場合、WebLogic Serverは次の情報をとともにコールバック・ハンドラをコールし、戻り値を待機します。

  • currPool - フェイルバックの場合、以前に無効化されて現在は再有効化が可能になっている汎用データ・ソースの名前です。

  • nextPool - フェイルバックの場合、これはNULLです。

  • opcode - 呼出しの理由を示すコードです。フェイルバックの場合、コードは常にOPCODE_REENABLE_CURR_POOLです。これは、currPoolに名前のある汎用データ・ソースが現在使用できることを示します。

フェイルバック(つまり、無効化された汎用データ・ソースを自動的に再有効化すること)は、フェイルオーバーが接続リクエストと同期しているものの、フェイルバックは接続リクエストと非同期であるという点で、フェイルオーバーとは異なります。

コールバック・ハンドラは、次の値のいずれかを戻す可能性があります。

  • OK - 処理を続行します。この場合、示された汎用データ・ソースを再有効化することを意味します。WebLogic Serverが、その汎用データ・ソースへの接続リクエストのルーティングを再開します。これは、マルチ・データ・ソース・アルゴリズムと、含まれる汎用データ・ソース・リスト内の汎用データ・ソースの位置によって異なります。

  • DONOT_FAILOVER - currPool汎用データ・ソースを再有効化しません。使用中の汎用データ・ソースで接続リクエストの処理を続行します。

WebLogic Serverはコールバック・ハンドラによって返された値に従って処理を行います。

コールバック・ハンドラがDONOT_FAILOVERを返した場合、WebLogic Serverはマルチ・データ・ソースの構成のTestFrequencySeconds属性で決められている設定に従って、次のテスト・サイクル中に汎用データ・ソースの再有効化を試行し、そのプロセスの一部としてコールバック・ハンドラをコールします。

マルチ・データ・ソース内での汎用データ・ソースのリスト順は、非常に重要です。フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースは、常にマルチ・データ・ソース内の汎用データ・ソース・リストで最初に利用可能な汎用データ・ソースで接続リクエストを処理しようとします。次のようなシナリオを想定してください。

  1. フェイルオーバー・アルゴリズムを使用するMultiDataSource_1には、登録されたConnectionPoolFailoverCallbackHandlerがあり、DS1、DS2およびDS3という順序でリストされている、3つの汎用データ・ソースが含まれています。

  2. DS1が無効化されると、MultiDataSource_1では接続リクエストがDS2にフェイルオーバーされます。

  3. DS2が無効化されると、MultiDataSource_1では接続リクエストがDS3にフェイルオーバーされます。

  4. しばらくすると、DS1が再び使用可能になり、コールバック・ハンドラによってWebLogic Serverによる汎用データ・ソースの再有効化が許可されます。以降の接続リクエストはDS1によって処理されます。これはDS1がマルチ・データ・ソース内にリストされた最初の汎用データ・ソースだからです。

  5. 続いてDS2が利用可能になり、コールバック・ハンドラによってWebLogic Serverによる汎用データ・ソースの再有効化が許可されても、汎用データ・ソースのリストでDS1はDS2の前にリストされているため、接続リクエストは引き続きDS1によって処理されます。

マルチ・データ・ソースでの計画データベース・メンテナンス

マルチ・データ・ソースで使用されるデータベース・サーバーで、サービスの中断なしに計画されたメンテナンスを処理する方法を学習します。

サービスの中断を回避するには、ローリング方式でデータベースを更新できるように、複数のデータベース・インスタンスが使用できる必要があります。Oracle RACクラスタおよびOracle GoldenGate (またはそれらの製品の組合せ)を使用すると、この目的を達成できます。(Oracle DataGuardは、サービスを中断しない計画メンテナンスに使用することはできません。)各データベース・インスタンスは、マルチ・データ・ソースの汎用データ・ソース・メンバーとして構成されます。このアプローチでは、アプリケーションが定期的にプールに接続を返すことが前提です。

プロセスの概要

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

  1. 中間層システムで、メンテナンスで停止されるOracle RACインスタンスに関連付けられたすべてのメンバー・データ・ソースを停止します。他のメンバーのために接続を予約できるように、各マルチ・データ・ソース・リストのデータ・ソースをすべて停止しないことが重要です。データ・ソースの停止が完了するのを待機します。参照:
  2. 必要に応じて、WebLogicデータ・ソースに関連付けられていない、データベース側の残りの接続を削減できます。この場合、Oracle Databaseサーバーでは、メンテナンスで停止されるインスタンスのアプリケーション・サービスの停止(または再配置)、リスナーの停止、データベース・インスタンスのサービスに対するトランザクション切断の発行などを行います。
  3. 適切なツールを使用してデータベース・インスタンスを停止します。
  4. 計画メンテナンスを実行します
  5. 適切なツールを使用してデータベース・インスタンスを再起動します。
  6. データベース・インスタンスでアプリケーションを使用する準備ができたら、サービスを起動します。
  7. 中間層システムで、メンバー・データ・ソースを起動します。Oracle WebLogic Server MBeanリファレンスのJDBCDataSourceRuntimeMBeanの起動操作に関する項を参照してください。

親トピック: JDBCマルチ・データ・ソースの使用

データ・ソースの停止

データ・ソースを停止する場合、まずデータ・ソースを中断してから、接続を含む関連リソースを解放します。

マルチ・データ・ソースのメンバー・データ・ソースが中断としてマークされると、マルチ・データ・ソースは、中断したプールから接続を取得しなくなります。かわりに、接続を予約するため、次のメンバー・データ・ソースに移動します。同時にマルチ・データ・ソース・リストのメンバー・データ・ソースをすべて停止しないことが重要です。すべてのメンバーが停止または失敗した場合、マルチ・データ・ソースへのアクセスは失敗し、アプリケーションは障害を認識します。

停止プロセスの最初のステップとしてデータ・ソースを正常に中断すると、次の処理が発生します。

  • データ・ソースは、操作の開始時に即座に中断としてマークされ、そのデータ・ソースでそれ以上接続は作成されなくなります。

  • アイドル(非予約)接続は閉じられたものとしてマークされます。

  • 中断操作のタイムアウト期間の経過後、プールに残っているすべての接続は中断としてマークされ、接続に対する任意の操作でデータ・ソースが中断していることを示す次の例外がスローされます。

    java.sql.SQLRecoverableException: Connection has been administratively disabled. Try later.

  • 残りのすべての接続は、その後閉じられます。それらが正常かどうかは、データ・ソースが再開されるまでわかりません。この場合、データベースが停止され、データ・ソースが再開された場合、プールの接続が正常ではないことがわかります。かわりに、無効な接続をすべて閉じるデータ・ソースの停止を実行します。

    停止操作は、同期的または非同期的に実行できます。非同期停止を実行する場合、デフォルトのタイムアウト期間は60秒です。このタイムアウト期間の値は、Inactive Connection Timeout Secondsを0 (ゼロ)以外の値に構成(または動的に設定)することで変更できます。非アクティブ・タイムアウト期間に上限はありません。ただし、実際の処理では、使用中(予約済)のリソースが10分の1秒ごとにチェックされるため、タイムアウト値が2時間に設定され、すべての予約済リソースが1秒後に解放されると、停止は1秒後に完了します。非同期操作を行う場合は、メソッドそのもにタイムアウト期間が指定されます。0に設定した場合、デフォルトが使用されます。デフォルトでは、Inactive Connection Timeout Seconds(設定されている場合)または60秒を使用します。タイムアウトを最小限にする場合は、値を1に設定します。タイムアウトを設定しない場合は、これを大きい値にします(非推奨)。

この停止操作は、同期的に実行されるため、使用できる非同期バージョンのMBean操作はありません。

これは、ロード・バランシングまたはフェイルオーバーによって構成されたマルチ・データ・ソースでも使用できます。

例4-1 WLSTの例

次のWLSTのスクリプト例は、中断タイムアウト期間を延長してから、ランタイムMBeanを使用してデータ・ソースを停止するように構成を編集する方法を示しています。このスクリプトは、すべてのWebLogic Serverサーバーおよびデータ・ソースの既存のフレームワークに統合する必要があります。

import sys, socket, os
hostname = 'hostname'
datasource='ds'
svr='myserver'
connect("weblogic","password","t3://"+hostname+":7001")
# Shutdown the data source serverRuntime()
serverRuntime()
cd('/JDBCServiceRuntime/' + svr + '/JDBCDataSourceRuntimeMBeans/' +datasource )
task = cmo.shutdown(10000)
while (task.isRunning ()): 
      print 'SHUTTING DOWN' 
      java.lang.Thread.sleep(2000) 
      print 'Datasource task is in status' + task.getStatus()
exit()
$ java weblogic.WLST myscript2.py
Intializing Weblogic Scripting Tool (WLST)...
Welcome to WebLogic Server Administration Scripting Shell
....
Location changed to serverRuntime tree.
This is a read-only tree with ServerRuntimeMBean as the root. For more help, use help('serverRuntime').
SHUTTING DOWN
Datasource task is in status
SUCCESS
Datasource task is in status
SUCCESS
Exiting WebLogic Scripting Tool.

重要な考慮事項

次のリストで、計画メンテナンスの実行時に考慮する必要のある問題について説明します。

  • マルチ・データ・ソースでデータベース・サービスを使用している場合、マルチ・データ・ソースを中断または停止する前にデータベース・サービスを停止または再配置することはできません。それを行うと、マルチ・データ・ソースは、現在存在しないサービスへの接続を作成する可能性があり、データベースが停止している場合と同様の応答をしてすべての接続を強制終了し、正常な停止が行われません。マルチ・データ・ソースを中断することで、関連するインスタンスで新しい接続が作成されないことが保証されるため、サービスを停止する必要はありません。(マルチ・データ・ソースは、このインスタンスでのみ接続を作成することに注意してください。再配置されても、別のインスタンスでは接続を作成しません。)また、マルチ・データ・ソースを中断することで、すべての接続に対する操作が停止されるため、マルチ・データ・ソース・プールに残っているどのセッションでも後続の処理は発生しません(トランザクションは完了しません)。

  • マルチ・データ・ソース・アルゴリズムによって強制適用されるXAアフィニティに関する問題が発生することがあります。Oracle RACインスタンスでXAブランチが作成されると、同じインスタンスですべての追加ブランチが作成されます。Oracle RACではインスタンス間のXAがサポートされますが、準備フェーズの前にアプリケーションが直面する重要な制限があり、マルチ・データ・ソースによって、すべての操作が同じインスタンス上で発生するように強制されます。正常な中断操作が開始すると同時に、メンバー・データ・ソースは中断としてマークされ、そこでそれ以上接続は割り当てられなくなります。グローバル・トランザクションを使用するアプリケーションが、中断しているデータ・ソースで別のブランチを開始しようとすると、接続を取得できずにトランザクションは失敗します。複数のWebLogic ServerにまたがるXAトランザクションの場合、中断は正常に行われません。この問題は、2フェーズ・コミットのエミュレートまたは1フェーズ・コミット(すべての作業に単一の接続を使用)およびロギング・ラスト・リソース(LLR)には適用されません。

  • なんらかの理由で、その時点ですべての接続が無効化されるデータ・ソースの中断とリソースの解放を分離する必要がある場合、中断の後にforceShutdownを実行できます。強制停止を使用して、2回目の待機期間を回避する必要があります。このプロセスの使用はお薦めできません。

  • データベースの停止時にデータ・ソースの正常な停止を行うには、データ・ソースを含める必要があります。データ・ソースを停止してからデータベースを停止するこのプロセスでは、中間層とデータベース・サーバー処理の間で調整が必要です。マルチ・データ・ソースのかわりにActive GridLinkを使用すると処理が簡略化されます。「Active GridLinkデータ・ソースの使用方法」を参照してください

  • Oracle Databaseを使用する場合、高可用性向けに構成できるように、データベースごとにアプリケーション・サービスを構成することをお薦めします。アプリケーション・サービスを使用することで、それを使用するためのデータ・ソースを起動せずに、単独でデータベースを起動できます。アプリケーション・サービスが明示的に起動されたら、管理者は、データ・ソースでデータベースを使用できるように設定できます。

親トピック: JDBCマルチ・データ・ソースの使用

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にすると、再バランシング処理が無効になります。

GridLinkアフィ二ティ

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

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

同一のレコード・セットに対して繰り返される操作は、同一の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の両方のアドレスが使用できるようになります。

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

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

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イベントを送信します。

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

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

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

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

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

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

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

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トランザクションをサポートしていません。

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

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

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

接続プロパティの構成

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

ノート:

サービス名の使用方法:

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

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

接続プロパティの入力

「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属性を使用すると、追加の構成情報をテストできます。

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情報を取得する必要があります。

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つ以上のターゲットを選択できます。ターゲットを選択していない場合でもデータ・ソースは作成されますが、デプロイされません。そのデータ・ソースは、後でデプロイする必要があります。

Oracleパラメータの構成

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

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

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を使用しないでください。

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

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

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

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

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

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

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

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

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

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

実行時統計の表示

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

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

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データ・ソースの使用方法

例外のキャッシュと処理

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

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

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

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

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

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

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

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

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

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

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データ・ソース(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データ・ソースに移行する際に必要な基本ステップについて説明します:

  • 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データ・ソースでのデータベース停止時間の管理

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アドレスを参照してください。

計画停止の手順

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

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

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

メンテナンス目的で(システム内またはシステム間でのソフトウェアとハードウェアのアップグレード、修理、変更、移行など)、使用されているサービスは、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インスタンス間での接続の配分」の説明
計画外停止

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

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

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

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

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

段階的排出

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

計画的なデータベースのメンテナンスが行われるときには、計画済停止のサービス・イベントが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データ・ソースの使用方法

ユニバーサル接続プール・データ・ソースの使用

ユニバーサル接続プール(UCP)データ・ソースは、Oracle Universal Connection Poolingを使用してOracle Databaseに接続するユーザー用のオプションとして提供されています。UCPは、Oracle WebLogic Server接続プーリングに対する代替接続プーリング・テクノロジを提供します。

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

ユニバーサル接続プール・データ・ソースとは

ユニバーサル接続プール・データ・ソースは、UCPを使用してOracle Databaseに接続するユーザー用のオプションとして提供されています。UCPは、Oracle WebLogic Server接続プーリングに対する代替接続プーリング・テクノロジを提供します。

ノート:

通常、Oracleデータベースとの接続を確立するために、汎用データ・ソース、マルチ・データ・ソースまたはActive GridLinkデータ・ソースをOracle WebLogic Serverで使用することをお薦めします。

UCPデータ・ソースを使用する場合、WebLogic Serverでは次のサポートが提供されます:

  • 汎用データ・ソース、マルチ・データ・ソースまたはActive GridLinkデータ・ソースの代替データ・ソースとしての構成。

  • データ・ソースのデプロイおよびアンデプロイ。

  • 基本的なモニタリングおよび統計:

    • ConnectionsTotalCount

    • CurrCapacity

    • FailedReserveRequestCount

    • ActiveConnectionsHighCount

    • ActiveConnectionsCurrentCount

  • Oracle簡易ドライバ、XAドライバおよびJDBCリプレイ・ドライバ対応ドライバでの動作保証。

UCPデータ・ソースでは、次の機能はサポートされません:

  • WebLogic Serverトランザクション・マネージャ(1フェーズ、LLR、JTS、JDBC TLog、決定子リソースなど)

  • 追加のライフサイクル操作(中断、再開、停止、強制停止、開始など)。

  • 任意の接続プールの汎用サポート。

  • Oracle WebLogic Serverセキュリティ・オプション。

  • 前にリストされているもの以外のJDBCドライバ。

  • JMS、リース、EJBなどのOracle WebLogic Serverデータ操作。

  • UCPデータ・ソースに対するRMIアクセス。

UCPデータ・ソースの実装は、疎結合されており、アプリケーションによる新しいUCP機能の使用をサポートするためにucp.jarを切り替えることができます。UCPデータ・ソースは、アプリケーション・スコープ環境/アプリケーション・パッケージ化環境またはスタンドアロン・モジュール環境ではサポートされません。

Oracle Universal Connection Poolの詳細は、『Oracle Universal Connection Pool for JDBC開発者ガイド』を参照してください。

親トピック: ユニバーサル接続プール・データ・ソースの使用

ユニバーサル接続プール・データ・ソースの作成

WebLogicドメインにユニバーサル接続プール・データ・ソースを作成する場合、WebLogic Server管理コンソール、WebLogic Scripting Tool (WLST)またはFusion Middleware Controlを使用できます。

Fusion Middleware Controlを使用してユニバーサル接続プール・データ・ソースを作成する手順は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のJDBCユニバーサル接続プール・データ・ソースの作成を参照してください。

WebLogic Server管理コンソールとWLSTによる方法については、次の各項を参照してください。

親トピック: ユニバーサル接続プール・データ・ソースの使用

WebLogic Server管理コンソールでのUCPの構成

WebLogic Server管理コンソールでユニバーサル接続プール(UCP)データ・ソースを作成する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユニバーサル接続プール・データ・ソースの作成を参照してください。この手順には、データ・ソースの構成ウィザードにアクセスする方法も含まれます。

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

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

「JDBCデータ・ソースのプロパティ」セクションには、データ・ソースのアイデンティティとデータベース接続でのデータの処理方法を決定するオプションが含まれます。これらのプロパティを構成するためのガイドラインは、次のとおりです。

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

  • スコープ - 使用可能なスコープのリストからデータ・ソースのスコープを選択します。スコープは、「グローバル」(ドメイン・レベル)または既存の「リソース・グループ」や「リソース・グループ・テンプレート」に設定できます。

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

  • 「データベースのタイプ」および「ドライバ」 - UCPデータ・ソースは、Thin XA、非XAおよびJDBCリプレイ・ドライバという3つのOracleドライバで動作保証されています。メニューから必要なドライバを選択します。

表4-4に、ドライバとJDBC接続ファクトリのサポートされる組合せを示します

表4-4 UCPデータ・ソースでサポートされるドライバと接続ファクトリの組合せ

ドライバ ファクトリ(ConnectionFactoryClassName)
oracle.ucp.jdbc.PoolDataSourceImpl (デフォルト) oracle.ucp.jdbc.PoolDataSourceImpl
oracle.ucp.jdbc.PoolXADataSourceImpl oracle.jdbc.xa.client.OracleXADataSource
oracle.ucp.jdbc.PoolDataSourceImpl oracle.jdbc.replay.OracleDataSourceImpl

ノート:

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

表4-4のリストにある非XAドライバを表のXAファクトリと一緒に指定すると、エラーが発生します。表に含まれない値を指定しても、それらは検証されません。

jdbc-driver-paramsにdriver-nameが指定されていない場合、デフォルトでoracle.ucp.jdbc.PoolDataSourceImplに設定されます。

サポートされるドライバ名を指定したが、ConnectionFactoryClassName接続プロパティを指定しないと、表4-4の対応するエントリが使用されます。サポートされるドライバ名を指定しない場合、エラーが生成されます。

接続プロパティの設定

接続プロパティは、データ・ソースとDBMSとの間の接続を構成するために使用します。管理コンソールでUCPデータ・ソースの接続プロパティを入力する場合、2つの方法があります。

ウィザードの「接続プロパティ」ページには、UCPドライバに使用できるすべての接続プロパティが表示されるため、適切な値を入力できます。別の方法として、「データベース接続のテスト」ページの「プロパティ」テキスト・ボックスに、propertyName=valueという書式を使用して直接プロパティを入力することで、プロパティを構成できます。「接続プロパティ」ページで入力した値は、「プロパティ」テキスト・ボックスにすでにリストされています。

表4-5では、UCPデータ・ソースで構成できる接続プロパティについて説明します。UCPのプロパティの詳細は、次を参照してください: クラスPoolDataSourceImpl(『Oracle Universal Connection Pool for JDBC Java APIリファレンス』)。属性は、PoolDataSourceImplクラスのセッターによって決定されます。set接頭辞なしの属性名を使用してください。名前の大文字と小文字は区別されません。

表4-5 ユニバーサル接続プールのプロパティ

プロパティ タイプ 説明

AbandonedConnectionTimeout

int

中止接続タイムアウトを設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。デフォルトは0です。

ConnectionFactoryClassName

String

接続ファクトリのクラス名を設定します。

ConnectionFactoryProperties

name=value

接続ファクトリの複数の接続ファクトリ・プロパティを設定します。

ConnectionFactoryProperty

name=value

接続ファクトリの1つの接続ファクトリ・プロパティを設定します。

ConnectionHarvestMaxCount

int

接続収集の発生時に収集できる接続の最大数を設定します。

ConnectionHarvestTriggerCount

int

接続プールの接続収集が発生するときに使用可能な接続の数を設定します。

ConnectionLabelingHighCost

int

接続ラベリングで接続を高コストとして識別するコスト値を設定します。

ConnectionPoolName

String

接続プール名を設定します。

ConnectionProperties

name=value

接続ファクトリの複数の接続プロパティを設定します。

ConnectionProperty

name=value

接続ファクトリの1つの接続プロパティを設定します。

ConnectionWaitTimeout

int

使用中の接続をクライアントが解放するまでの待機時間(秒)を設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。デフォルトは3です。

DatabaseName

String

データベース名を設定します。

DataSourceName

String

データ・ソース名を設定します。

Description

String

データ・ソースの説明を設定します。

FastConnectionFailoverEnabled

Boolean

このプール対応のデータ・ソースを使用してアクセスされる接続プールの高速接続フェイルオーバー(FCF)を有効化します。有効な値は、trueおよびfalseです。

HighCostConnectionReuseThreshold

int

接続ラベリングの高コストの接続再使用しきい値を設定します。

InactiveConnectionTimeout

int

非アクティブ接続タイムアウトを設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。デフォルトは0です。

InitialPoolSize

int

初期プール・サイズを設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。これを最大プール・サイズより大きい値に設定すると無効になります。デフォルトは0です。

LoginTimeout

int

ログイン・タイムアウトを設定します。

MaxConnectionReuseCount

int

接続再使用数プロパティを設定します。

MaxConnectionReuseTime

long

接続再使用時間プロパティを設定します。

MaxIdleTime

int

プールで使用可能な接続のアイドル・タイムアウトを設定します。

MaxPoolSize

int

接続の最大数を設定します。

有効値の範囲は、1からInteger.MAX_VALUEまでです。デフォルトはInteger.MAX_VALUEです。

MaxStatements

int

接続でプールするかキャッシュできる文の最大数を設定します。

MinPoolSize

int

接続の最小数を設定します。

有効値の範囲は、0からInteger.MAX_VALUEまでです。これを最大プール・サイズより大きい値に設定すると無効になります。デフォルトは0です。

NetworkProtocol

String

データ・ソース・ネットワーク・プロトコルを設定します。

ONSConfiguration

String

リモートONSサブスクリプションに使用される構成文字列を設定します。

Password

String

接続を取得するためのパスワードを設定します。

PortNumber

int

データベース・ポート番号を設定します。

PropertyCycle

int

プロパティ・サイクル(秒)を設定します。

RoleName

String

データ・ソース・ロール名を設定します。

ServerName

String

データベース・サーバー名を設定します。

SQLForValidateConnection

String

SQLForValidateConnectionプロパティの値(SQL)を設定します。

TimeoutCheckInterval

int

timeoutCheckInterval (秒)を設定します。

TimeToLiveConnectionTimeout

int

接続を使用中のままにできる最大時間(秒)を設定します。

URL

String

データベースへの接続を取得するためにデータ・ソースで使用するURLを設定します。

User

String

接続を取得するためのユーザー名を設定します。

ValidateConnectionOnBorrow

Boolean

流用した接続を最初に検証するかどうかを設定します。有効な値は、true およびfalseです。

ノート:

通常の文字列リテラルに加え、システム・プロパティと暗号化プロパティがサポートされます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

jdbc-driver-params URLが設定されている場合、URLプロパティは無視されます。encrypted-passwordが設定されている場合、パスワード・プロパティは無視されます。

属性ConnectionFactoryProperty、ConnectionFactoryProperties、ConnectionPropertyおよびConnectionFactoryPropertiesは、「name1=value1,name2=value2...」という形式の値を受け入れます。

データベース接続のテスト

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

ターゲットの選択

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

WLSTを使用したUCPの構成

他のデータ・ソース・タイプを作成するのと同じ方法で、WebLogic Scripting Tool (WLST)を使用してUCPデータ・ソースを作成できます。ただし、UCPデータ・ソースのほうが属性は少なくなります。

UCPデータ・ソースの構成要素は、次のとおりです。

  • name

  • datasource-type=UCP

  • jdbc-driver-params url

  • jdbc-driver-params property - user

  • jdbc-driver-params password-encrypted

  • jdbc-data-source-params jndi-name

  • jdbc-driver-params other properties

WebLogic Serverデータ・ソース・ディスクリプタからの他の要素は、認識されません。他の要素を指定しても、無視されます。

例4-2に、UCPデータ・ソースを作成するためのサンプルWLSTスクリプトを示します

例4-2 UCPデータ・ソースを作成するためのサンプルWLSTスクリプト 

import sys, socket
import os
hostname = socket.gethostname()
connect("username","password","t3://"+hostname+":7001")
edit()
startEdit()
serverName="AdminServer"
serverBean = getMBean('/Servers/'+serverName)
host='%s.us.example.com' %hostname
print 'Creating UCP datasource'
domain = getMBean("/")
startEdit()
resourceName='ucpDS'
print "Creating datasource ds in domain"
systemResource=domain.createJDBCSystemResource(resourceName)
systemResource.setName(resourceName)
jdbcResource=systemResource.getJDBCResource()
jdbcResource.setName(resourceName)
jdbcResource.setDatasourceType('UCP')
driverParams=jdbcResource.getJDBCDriverParams()
driverParams.setDriverName('oracle.ucp.jdbc.PoolDataSourceImpl')
driverParams.setUrl('jdbc:oracle:thin:@dbhost:1521/otrade')
properties = driverParams.getProperties()
properties.createProperty('user', 'dbuser')
properties.createProperty('ConnectionFactoryClassName', 'oracle.jdbc.pool.OracleDataSource')
driverParams.setPassword('PASSWD')
jdbcDataSourceParams=jdbcResource.getJDBCDataSourceParams()
jdbcDataSourceParams.addJNDIName(resourceName)
jdbcDataSourceParams.setGlobalTransactionsProtocol('None')
cd('/SystemResources/' + resourceName )
set('Targets',jarray.array([ObjectName('com.bea:Name=' + serverName + ',Type=Server')], ObjectName))
save()
activate()

ノート:

このサンプルWLSTスクリプトは、汎用データ・ソースを作成するためにも使用できます。これはUCPデータ・ソースの基礎としてWebLogic Serverに用意されています。:
EXAMPLES_HOME\wl_server\examples\src\examples\wlst\online\jdbc_data_source_creation.py

ここでEXAMPLES_HOMEは、WebLogic Serverのコード・サンプルを構成するディレクトリです。WebLogic Scripting Toolの理解のWLSTオンライン・サンプル・スクリプトを参照してください。

ユニバーサル接続プール・マルチテナント共有プールのサポート

この機能を使用するには、UCPデータ・ソースをJVMにロードする前に、ユニバーサル接続プール(UCP) MT共有プールのサポートXML構成ファイルのURIをoracle.UCP.jdbc.xmlConfigFileシステム・プロパティを使用して指定する必要があります。

これは、Weblogic Serverの起動時にコマンドラインに設定できます。これでは不都合な場合もあるため、XmlConfigFile接続プロパティを設定することもできます。接続プロパティによる方法を使用する場合は、たとえそれがXMLファイルを使用していなくても、WebLogic Serverで構成されているすべてのUCPデータ・ソースに対して設定する必要があります。そのフォーマットは通常、file:///path/file.xmlのようなものです。

Universal Connection Pool開発者ガイドの「データベース・シャーディングのUCP共有プールの概要」を参照してください。

共有プール機能を使用する場合、次のものを除き、データ・ソースのすべての属性が無視されます。

  • 名前 – データ・ソースの名前

  • データ・ソース・タイプ – UCP

  • ドライバのクラス名 – oracle.ucp.jdbc.PoolDataSourceImplまたはoracle.ucp.jdbc.PoolXADataSourceImpl

  • DataSourceFromConfigurationプロパティ – XMLファイル内のデータ・ソース名

  • XmlConfigFileプロパティ – システム・プロパティとして設定されていない場合は、オプションでXMLファイルのURIを設定

  • JNDI名 - データ・ソース・オブジェクトがマップされているJNDI名

    例:

    import sys, socket
import os
hostname = socket.gethostname()
connect("weblogic","server_password","t3://"+hostname+":7001")
edit()
startEdit()
serverName="myserver"
print 'Creating UCP datasource'
domain = getMBean("/")
startEdit()
resourceName='ds5'
print "Creating datasource ds in domain"
systemResource=domain.createJDBCSystemResource(resourceName)
systemResource.setName(resourceName)
jdbcResource=systemResource.getJDBCResource()
jdbcResource.setName(resourceName)
jdbcResource.setDatasourceType('UCP')
driverParams=jdbcResource.getJDBCDriverParams()
driverParams.setDriverName('oracle.ucp.jdbc.PoolDataSourceImpl')
properties = driverParams.getProperties()
properties.createProperty('DataSourceFromConfiguration', 'pds1')
properties.createProperty('XmlConfigFile', 'file:///SharedPoolDemo.xml')
jdbcDataSourceParams=jdbcResource.getJDBCDataSourceParams()
jdbcDataSourceParams.addJNDIName(resourceName)
cd('/SystemResources/' + resourceName )
set('Targets',jarray.array([ObjectName('com.bea:Name=' + serverName + ',Type=Server')], ObjectName))
save()
activate()
    UCPのXMLファイルは次のようになります: 
    <?xml version="1.0" encoding="UTF-8"?> 
<ucp-properties> 
<connection-pool  
connection-pool-name="pool1"  
connection-factory-class-name="oracle.jdbc.pool.OracleDataSource" 
url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=dbhost)(PORT=5521))(CONNECT_DATA=
(SERVICE_NAME=dbhostservice)))"  
user="system"  
password="manager"  
initial-pool-size="4" 
min-pool-size="2" 
 max-pool-size="10"  
shared="true"
  >  
<data-source data-source-name="pds1" 
 user="system" 
 password="manager" 
 service="pdb1_service" 
 description="pdb1 data source"
  />  
<data-source data-source-name="pds2"   
user="system"  
 password="manager"   
service="pdb2_service"  
 description="pdb2 data source"  
/> 
</connection-pool> 
</ucp-properties>

親トピック: ユニバーサル接続プール・データ・ソースの使用

ユニバーサル接続プールJDBCリソースのモニタリング

WebLogic Sever管理コンソールまたはJDBCUCPDataSourceRuntimeMBeanやJDBCDataSourceRuntimeMBeanを使用するユニバーサル接続プールJDBCリソースのモニタリングについて学習します。

JDBCUCPDataSourceRuntimeMBeanには、データ・ソースの現在の状態を取得するメソッドと、データ・ソースに関する統計を取得するメソッドが用意されています。取得できる統計には、平均のアクティブな接続数、現在のアクティブな接続数、最大のアクティブな接続数などがあります。このMBeanは、JDBCDataSourceRuntimeMBeanを拡張して、JDBCサービスから他のJDBC MBeanのリストとともにそれを返すことができるようにします。Oracle WebLogic Server MBeanリファレンスのJDBCUCPDataSourceRuntimeMBeanを参照してください。

実行時の統計に加え、テストに成功すると、testPool()操作はNULLを返しますが、それ以外の場合はエラー文字列を返します(他のデータ・ソース・タイプと同様)。プールのテストが実行されるのは、検証用に実行するSQL文字列(SELECT 1 from DUALなど)がSQLForValidateConnectionに設定されている場合のみです。操作の残りは、アクションを実行しません。

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

親トピック: ユニバーサル接続プール・データ・ソースの使用

Oracle Shardingのサポート

シャーディングは、独立したデータベース間でデータが水平にパーティション化されるデータ階層アーキテクチャです。

Oracle Shardingは12.2のUCPで使用可能であり、ネイティブのUCPデータ・ソース機能を使用してWebLogic Serverによって表に現れます。『Oracle Shardingの使用』のOracle Shardingの概要を参照してください。

JNDI参照を使用してUCPデータ・ソースにアクセスすると、次のJavaコードのようにシャーディングAPIを使用できます: 

import javax.naming.Context;
import javax.naming.InitialContext;
import java.sql.Connection;
import oracle.ucp.jdbc.PoolDataSource;

Context cts = new InitialContext();

/// Look up the data source using JNDI
PoolDatasource pds = (PoolDataSource) ctx.lookup("shardDataSource");

 // Create a key corresponding to sharding key columns, to access the correct shard
OracleShardingKey key = pds.createShardingKeyBuilder().subkey(100, JDBCType.NUMERIC).build();

 // Fetch a connection to the shard corresponding to the key
Connection conn = pds.createconnectionBuilder().shardingKey(key).build();

 // Use the above connection for performing shard specific operations

親トピック: ユニバーサル接続プール・データ・ソースの使用