| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3 JDBCデータ・ソースの管理 12c (12.1.3) E56266-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3 JDBCデータ・ソースの管理 12c (12.1.3) E56266-09 |
|
前 |
次 |
この章では、WebLogic Server 12.1.3で、マルチ・データ・ソースを構成および使用して、接続リクエスト時に、マルチ・データ・ソースと関連付けられた汎用データ・ソース間のロード・バランシングまたはフェイルオーバー処理を提供する方法について説明します。
マルチ・データ・ソースとは、汎用データ・ソースがJNDIツリーにバインドされるのと同じように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされる汎用データ・ソースのグループ周辺を抽象化したものです。アプリケーションは、汎用データ・ソースの場合と同じようにJNDIツリー上のマルチ・データ・ソースまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のマルチ・データ・ソースをルックアップし、その後データベース接続をリクエストします。マルチ・データ・ソースによって、マルチ・データ・ソース構成で選択されたアルゴリズム(ロード・バランシングまたはフェイルオーバー)に応じて、リクエストに対応するために使用する汎用データ・ソースが決定されます。
|
注意: Active GridLinkとマルチ・データ・ソースは、Oracle RACクラスタと連動するように設計されています。汎用データ・ソースをOracle RACクラスタとともに使用することはお薦めしません。「AGLとマルチ・データ・ソースの比較」を参照してください。 |
この項の内容は、次のとおりです。
マルチ・データ・ソースは、汎用データ・ソースのプールと考えることができます。マルチ・データ・ソースは、冗長なデータベースやOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムのノード間のフェイルオーバーまたはロード・バランシングに使用するのが最適です。
マルチ・データ・ソースの汎用データ・ソース・メンバー・リストは、動的な更新をサポートしています。これによって、Oracle RACなどを使用する環境で、再デプロイすることなく、データベース・ノードと対応する汎用データ・ソースを追加および削除でき、次のことができます。
スループットに応じてOracle RACクラスタを拡大および縮小します。「データベース・ノードの追加」を参照してください。
メンテナンスのためにOracle RACノードを停止します。「データベース・ノードの削除」を参照してください。
「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
|
注意: マルチ・データ・ソースは、データベース同士を同期させるものではありません。データベースの同期は、データの整合性が保たれるよう、WebLogic Serverの外部で適切に処理されることが前提となっています。データベース・ノードの追加および削除は、データベース管理者が手動で行う操作です。 |
データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに削除できます。この機能によって、メンテナンスのためにノードを停止したり、クラスタを縮小できます。次の手順に従って、データベース・ノードを停止します。
|
注意: これらの手順に失敗した場合、トランザクションがロールバックされる場合があります。 |
汎用データ・ソースをマルチ・データ・ソースから削除します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソース内の汎用データ・ソースの追加または削除に関する項を参照してください。
すべてのトランザクションの終了後に、汎用データ・ソースを一時停止します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの一時停止に関する項を参照してください。
すべてのトランザクションの終了後に、汎用データ・ソースを停止します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの停止に関する項を参照してください。
データベース・ノードを停止します。
データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに追加できます。この機能によって、メンテナンス後にノードを起動したり、クラスタを拡張できます。次の手順に従って、データベース・ノードを追加します。
データベース・ノードを再起動します。
汎用データ・ソースを再起動します。『Oracle WebLogic Server Administration Consoleオンライン・ヘルプ』のJDBCデータ・ソースの開始に関する項を参照してください。
汎用データ・ソースを再度マルチ・データ・ソースに追加します。『Oracle WebLogic Server Administration Consoleオンライン・ヘルプ』のJDBCマルチ・データ・ソース内のデータ・ソースの追加または削除に関する項を参照してください。
マルチ・データ・ソースを作成するには、まず汎用データ・ソースを作成し、次にWebLogic Server管理コンソールまたはWebLogic Scripting Toolでマルチ・データ・ソースを作成して、その後汎用データ・ソースをマルチ・データ・ソースに割り当てます。
マルチ・データ・ソースの作成方法は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソースの構成に関する項を参照してください。
マルチ・データ・ソースの構成時に作成される構成ファイルについては、「WebLogic ServerにおけるJDBCリソースの理解」を参照してください。また、「マルチ・データ・ソース・モジュールの作成」も参照してください。
マルチ・データ・ソースを設定する前に、マルチ・データ・ソースの主要な目的(フェイルオーバーまたはロード・バランシング)を指定する必要があります。アルゴリズムは、必要に応じて選択できます。
フェイルオーバー・アルゴリズムは、接続リクエストに応じるために使用する汎用データ・ソースの順序付けされたリストを提供します。通常、この種類のマルチ・データ・ソースに対する接続リクエストはすべて、リストの先頭にある汎用データ・ソースによって処理されます。データベース接続テストが失敗して接続を置換できなかったり、汎用データ・ソースが一時停止した場合には、リスト上の次の汎用データ・ソースから順次、接続が検索されます。
|
注意: このアルゴリズムでは、汎用データ・ソースの「予約時に接続をテスト」(TestConnectionsOnReserve)を有効化する必要があります。有効になっている場合は、最初の汎用データ・ソース内の接続をテストして、汎用データ・ソースが正常かどうかを確認します。接続がテストに失敗した場合は、マルチ・データ・ソースにリストされている次の汎用データ・ソースの接続が使用されます。TestConnectionsOnReserveの構成については、「データ・ソースの接続テスト・オプション」を参照してください。
JDBCは、きわめてステートフルなクライアントとDBMS間のプロトコルです。JDBCでは、DBMS接続とトランザクション状態が、DBMSプロセスとクライアント(ドライバ)間のソケットに直接関連付けられます。このため、使用中の接続のフェイルオーバーはサポートされません。 |
ロード・バランシング・マルチ・データ・ソースへの接続リクエストは、リスト内の任意の汎用データ・ソースから処理されます。マルチ・データ・ソースは、ラウンドロビン方式で接続リクエストに応じるための汎用データ・ソースを選択します。マルチ・データ・ソースは接続を提供する際に、最後に使用された汎用データ・ソースの直後にリストされている汎用データ・ソースからの接続を選択します。データベース接続テストが失敗して接続を置き換えられない場合や汎用データ・ソースが中断されている場合は、ロード・バランシング・アルゴリズムを使用するマルチ・データ・ソースも、リスト内の次の汎用データ・ソースにフェイルオーバーされます。
WebLogic Serverはマルチ・データ・ソース用のフェイルオーバー・アルゴリズムを備えており、汎用データ・ソースで障害(たとえば、データベース管理システムのクラッシュ)が発生しても、システムをそのまま稼働させることができます。ただし、システムを構成するときには、次の制限と要件を考慮する必要があります。
汎用データ・ソースは、汎用データ・ソースの「予約時に接続をテスト」(TestConnectionsOnReserve)機能を利用して、データベース接続が失われる時期を確認します。マルチ・データ・ソース内の、汎用データ・ソースの「予約時に接続をテスト」機能を有効化する必要があります。各接続をアプリケーションに渡す前に、それらの接続をWebLogic Serverでテストします。このフェイルオーバー・アルゴリズムの場合、マルチ・データ・ソースは接続テストの結果を使用して、マルチ・データ・ソース内の次の汎用データ・ソースにフェイルオーバーする時期を決定します。テストに失敗した場合、汎用データ・ソースは接続を再試行します。再試行も失敗した場合、マルチ・データ・ソースは次の汎用データ・ソースにフェイルオーバーします。
次の拡張により、マルチ・データ・ソースのフェイルオーバー処理が向上します。
接続リクエストのルーティングを拡張し、マルチ・データ・ソース内の自動的に無効化された(失効した)汎用データ・ソースからの接続のリクエストを回避します。「汎用データ・ソースの障害発生時における接続リクエストのルーティング機能の拡張」を参照してください。
マルチ・データ・ソース内の、障害が発生した汎用データ・ソースがリカバリした場合の自動的なフェイルバック。「マルチ・データ・ソース内の障害が発生した汎用データ・ソースがリカバリした場合の自動的な再有効化」を参照してください。
マルチ・データ・ソース内のビジー状態の汎用データ・ソースのフェイルオーバー。「マルチ・データ・ソース内のビジー状態の汎用データ・ソースのフェイルオーバーの有効化」を参照してください。
フェイルオーバー・アルゴリズムが設定されたマルチ・データ・ソースに対するフェイルオーバーのコールバック。「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。
いずれかのアルゴリズムを使用するマルチ・データ・ソースに対するフェイルバックのコールバック。「コールバックによるマルチ・データ・ソース・フェイルバックの制御」を参照してください。
マルチ・データ・ソース内の汎用データ・ソースで障害が発生したときのパフォーマンスを向上させるため、WebLogic Serverはプールされた接続が接続テストで失敗すると、汎用データ・ソースを自動的に無効化します。汎用データ・ソースが無効化されると、アプリケーションからその汎用データ・ソースに接続リクエストがルーティングされなくなります。そのかわりに、マルチ・データ・ソース内にリストされた、次に利用可能な汎用データ・ソースに接続リクエストがルーティングされます。
この機能を使用するには、汎用データ・ソース・テスト・オプション(特に「表名のテスト」および「予約時に接続をテスト」)がマルチ・データ・ソース内のすべての汎用データ・ソースに対して構成されていることが必要です。「データ・ソースの接続テスト・オプション」を参照してください。
マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、コールバック・ハンドラが呼び出されてから、リスト内の次の汎用データ・ソースにフェイルオーバーされます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。
接続に失敗して汎用データ・ソースが自動的に無効になった場合、マルチ・データ・ソースは、無効になった汎用データ・ソースからの接続を定期的にテストし、汎用データ・ソース(または基礎となるデータベース)がいつ再度有効になるかを決定します。汎用データ・ソースが使用可能になると、マルチ・データ・ソースが汎用データ・ソースを自動的に再有効化し、マルチ・データ・ソース・アルゴリズムおよび含まれる汎用データ・ソース・リスト内の汎用データ・ソースの位置によって、汎用データ・ソースにルーティングする接続リクエストを再開します。これらのテストの頻度は、マルチ・データ・ソースのテスト間隔属性によって制御されます。テスト頻度のデフォルト値は120秒です。そのため、特にこのオプションの値を設定しない場合は、マルチ・データ・ソースは無効化された汎用データ・ソースを120秒おきにテストします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCマルチ・データ・ソース: 構成: 一般」に関する項を参照してください。
WebLogic Serverは、手動で無効化した汎用データ・ソースに対して、テストも自動的な再有効化も行いません。テストは自動的に無効化された汎用データ・ソースに対してのみ行われます。
マルチ・データ・ソースに対してコールバック・ハンドラが登録されている場合、コールバック・ハンドラが呼び出されてから、汎用データ・ソースの再有効化が行われます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルバックの制御」を参照してください。
デフォルトでは、フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースの場合、データベース接続に対するリクエスト数が、マルチ・データ・ソース内の現在の汎用データ・ソースにある利用可能な接続数を超過すると、以降の接続リクエストが失敗します。
現在の汎用データ・ソースのすべての接続が使用されている場合にマルチ・データ・ソースがフェイルオーバーできるようにするには、WebLogic Server管理コンソールの「JDBCマルチ・データ・ソース: 構成: 一般」ページで「ビジー時はリクエストをフェイルオーバー」オプションを有効にします。(JDBCDataSourceParamsBeanのFailoverRequestIfBusy属性でも設定できます)。有効(trueに設定)の場合、現在の汎用データ・ソース内のすべての接続が使用中のとき、アプリケーションの接続リクエストはマルチ・データ・ソース内の次に使用可能な汎用データ・ソースにルーティングされます。無効(デフォルトのfalseに設定)の場合、接続リクエストのフェイルオーバーは行われません。
マルチ・データ・ソースの構成にConnectionPoolFailoverCallbackHandlerが含まれている場合は、コールバック・ハンドラが呼び出されてから、フェイルオーバーが行われます。詳細は、「コールバックによるマルチ・データ・ソース・フェイルオーバーの制御」を参照してください。
WebLogic Serverには、フェイルオーバー・アルゴリズムが設定されたマルチ・データ・ソースが、どのタイミングでマルチ・データ・ソース内の、あるJDBC汎用データ・ソースからの接続リクエストを、リスト内の次の汎用データ・ソースにフェイルオーバーするかを制御する、コールバック・ハンドラを登録できます。
フェイルオーバーを行うかどうか、またはいつ行うかをコールバック・ハンドラで制御することによって、データベースの準備や高可用性フレームワークとの通信といったシステム準備タスクを、フェイルオーバーの前に実行できるようになります。
コールバック・ハンドラは、マルチ・データ・ソースのフェイルオーバーのコールバック・ハンドラ属性を介して、マルチ・データ・ソースごとに登録されます。コールバック・ハンドラを適用する各マルチ・データ・ソースに、コールバック・ハンドラを登録する必要があります。また、ドメイン内のマルチ・データ・ソースごとに、別々のコールバック・ハンドラを登録できます。
マルチ・データ・ソース内のフェイルオーバーおよびフェイルバックの制御に使用されるコールバック・ハンドラには、weblogic.jdbc.extensions.ConnectionPoolFailoverCallbackインタフェースの実装が含まれている必要があります。マルチ・データ・ソースでリスト内の次の汎用データ・ソースにフェイルオーバーする必要がある場合や、以前に無効化された汎用データ・ソースが利用可能になった場合、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 - 呼出しの理由を示すコードです。
OPCODE_CURR_POOL_DEAD - WebLogic Serverによって、現在の汎用データ・ソースが停止していることが検出され、そのデータ・ソースが無効化されました。
OPCODE_CURR_POOL_BUSY - データ・ソース内のすべての汎用データベース接続が使用中です。(マルチ・データ・ソースの構成に、FailoverIfBusy=trueが必要です。「マルチ・データ・ソース内のビジー状態の汎用データ・ソースのフェイルオーバーの有効化」を参照してください。)
フェイルオーバーは接続リクエストと同期します。フェイルオーバーは、WebLogic Serverが接続リクエストに応じようとする場合にのみ発生します。
コールバック・ハンドラからの戻り値は、次の3種類のオプションのいずれかを示します。
OK - 処理を続行します。この場合、リスト内の次の汎用データ・ソースにフェイルオーバーすることを意味します。
RETRY_CURRENT - 接続リクエストを現在の汎用データ・ソースで再試行します。
DONOT_FAILOVER - 現在の接続リクエストの再試行も、フェイルオーバーも行いません。WebLogic Serverによってweblogic.jdbc.extensions.PoolUnavailableSQLExceptionがスローされます。
WebLogic Serverはコールバック・ハンドラによって返された値に従って処理を行います。
2番目の汎用データ・ソースで障害が発生すると、先のフェイルオーバーと同様に、マルチ・データ・ソース内の次に利用可能な汎用データ・ソースにフェイルオーバーを試行するために、コールバック・ハンドラが再度呼び出されます(データ・ソースが存在している場合)。
|
注意: 汎用データ・ソースを手動で無効化した場合、WebLogic Serverはコールバック・ハンドラを呼び出しません。 |
ロード・バランシング・アルゴリズムを使用するマルチ・データ・ソースの場合、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属性で決められている設定に従って、次のテスト・サイクル中に汎用データ・ソースの再有効化を試行し、そのプロセスの一部としてコールバック・ハンドラを呼び出します。
マルチ・データ・ソース内での汎用データ・ソースのリスト順は、非常に重要です。フェイルオーバー・アルゴリズムを使用するマルチ・データ・ソースは、常にマルチ・データ・ソース内の汎用データ・ソース・リストで最初に利用可能な汎用データ・ソースからの接続リクエストを処理しようとします。次のようなシナリオを想定してください。
フェイルオーバー・アルゴリズムを使用するMultiDataSource_1には、登録されたConnectionPoolFailoverCallbackHandlerがあり、DS1、DS2およびDS3という順序でリストされている、3つの汎用データ・ソースが含まれています。
DS1が無効化されると、MultiDataSource_1では接続リクエストがDS2にフェイルオーバーされます。
DS2が無効化されると、MultiDataSource_1では接続リクエストがDS3にフェイルオーバーされます。
しばらくすると、DS1が再び使用可能になり、コールバック・ハンドラによってWebLogic Serverによる汎用データ・ソースの再有効化が許可されます。以降の接続リクエストはDS1によって処理されます。これはDS1がマルチ・データ・ソース内にリストされた最初の汎用データ・ソースだからです。
続いてDS2が利用可能になり、コールバック・ハンドラによってWebLogic Serverによる汎用データ・ソースの再有効化が許可されても、汎用データ・ソースのリストでDS1はDS2の前にリストされているため、接続リクエストは引続きDS1によって処理されます。
接続リクエストに応じるために、マルチ・データ・ソースで使用されている汎用データ・ソースはすべて、マルチ・データ・ソースと同じサーバーおよびクラスタにデプロイされている必要があります。マルチ・データ・ソースは、常に同じサーバーにデプロイされている汎用データ・ソースを使用して、接続リストに応じます。マルチ・データ・ソースは、クラスタまたはドメイン内の他のサーバーへの接続リクエストのルーティングは行いません。
マルチ・データ・ソースをクラスタまたはサーバーにデプロイするには、サーバーまたはクラスタをデプロイ・ターゲットとして選択します。マルチ・データ・ソースをサーバーにデプロイすると、そのサーバーに、WebLogic Serverによってマルチ・データ・ソースのインスタンスが作成されます。マルチ・データ・ソースをクラスタにデプロイすると、クラスタ内の各サーバーに、WebLogic Serverによってマルチ・データ・ソースのインスタンスが作成されます。
手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースのターゲット指定とデプロイに関する項を参照してください。
