| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1.2.0) E82892-02 |
|
 前 |
 次 |
マルチ・データ・ソースとは、汎用データ・ソースが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の外部で適切に処理されることが前提となっています。データベース・ノードの追加および削除は、データベース管理者が手動で行う操作です。
データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに削除できます。この機能によって、メンテナンスのためにノードを停止したり、クラスタを縮小できます。次の手順に従って、データベース・ノードを停止します。
注意:
これらの手順に失敗した場合、トランザクションがロールバックされる場合があります。
データベース・ノードと対応する汎用データ・ソースを、再デプロイせずに追加できます。この機能によって、メンテナンス後にノードを起動したり、クラスタを拡張できます。次の手順に従って、データベース・ノードを追加します。
マルチ・データ・ソースを作成するには、まず汎用データ・ソースを作成し、次にWebLogic Server管理コンソールまたはWebLogic Scripting Toolでマルチ・データ・ソースを作成して、その後汎用データ・ソースをマルチ・データ・ソースに割り当てます。
マルチ・データ・ソースの作成方法は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCマルチ・データ・ソースの構成を参照してください。
マルチ・データ・ソースの構成時に作成される構成ファイルについては、「WebLogic ServerにおけるJDBCリソースの理解」を参照してください。また、「マルチ・データ・ソース・モジュールの作成」も参照してください。
注意:
一般に、WebLogic Serverデータ・ソースの初期容量の設定が0に設定されている場合、WebLogic Serverは起動時にDBMS接続を作成しません。しかし、LLRデータ・ソースのMultiDataSourceを起動するために、WebLogic Serverは起動時に接続を作成してDBMSがRACかどうかを確認します。汎用のLLR MultiDatasourceの場合、すべてのデータ・ソースが使用可能である必要がありますが、RACを使用している場合は1つのノードのみがLLR処理用にアクセス可能である必要があります。
マルチ・データ・ソースを設定する前に、マルチ・データ・ソースの主要な目的(フェイルオーバーまたはロード・バランシング)を指定する必要があります。アルゴリズムは、必要に応じて選択できます。
フェイルオーバー・アルゴリズムは、接続リクエストに応じるために使用する汎用データ・ソースの順序付けされたリストを提供します。通常、この種類のマルチ・データ・ソースに対する接続リクエストはすべて、リストの先頭にある汎用データ・ソースによって処理されます。データベース接続テストが失敗して接続を置換できなかったり、汎用データ・ソースが一時停止した場合には、リスト上の次の汎用データ・ソースから順次、接続が検索されます。
注意:
このアルゴリズムでは、汎用データ・ソースの「予約時に接続をテスト」(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データ・ソースのターゲット指定とデプロイを参照してください。
次の項では、WebLogicマルチ・データ・ソースによるアクセス時に、データベース・サーバーでサービスを中断せずに計画メンテナンスを処理する方法について説明します。
プロセスの概要
次の手順では、計画メンテナンス・プロセスの概要を示します。
ここでは、データ・ソースの停止のプロセスについて説明します。
データ・ソースを停止する場合、まずデータ・ソースを中断してから、接続を含む関連リソースを解放します。マルチ・データ・ソースのメンバー・データ・ソースが中断としてマークされると、マルチ・データ・ソースは、中断したプールから接続を取得しなくなります。かわりに、接続を予約するため、次のメンバー・データ・ソースに移動します。同時にマルチ・データ・ソース・リストのメンバー・データ・ソースをすべて停止しないことが重要です。すべてのメンバーが停止または失敗した場合、マルチ・データ・ソースへのアクセスは失敗し、アプリケーションは障害を認識します。
停止プロセスの最初の手順としてデータ・ソースを正常に中断すると、次の処理が発生します。
データ・ソースは、操作の開始時に即座に中断としてマークされ、そのデータ・ソースでそれ以上接続は作成されなくなります。
アイドル(非予約)接続は閉じられたものとしてマークされます。
中断操作のタイムアウト期間の経過後、プールに残っているすべての接続は中断としてマークされ、接続に対する任意の操作でデータ・ソースが中断していることを示す次の例外がスローされます。
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操作はありません。
これは、ロード・バランシングまたはフェイルオーバーによって構成されたマルチ・データ・ソースでも使用できます。
例5-1 WLSTの例
次のWLSTのスクリプト例は、中断タイムアウト期間を延長してから、ランタイムMBeanを使用してデータ・ソースを停止するように構成を編集する方法を示しています。このスクリプトは、すべてのWebLogic Serverサーバーおよびデータ・ソースの既存のフレームワークに統合する必要があります。
import sys, socket, os
hostname = socket.gethostname()
datasource='ds'
svr='myserver'
connect("weblogic","password","t3://"+hostname+":7001")
# Shutdown the data source 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を使用する場合、高可用性向けに構成できるように、データベースごとにアプリケーション・サービスを構成することをお薦めします。アプリケーション・サービスを使用することで、それを使用するためのデータ・ソースを起動せずに、単独でデータベースを起動できます。アプリケーション・サービスが明示的に起動されたら、管理者は、データ・ソースでデータベースを使用できるように設定できます。
