| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1.2.0) E82892-02 |
|
 前 |
 次 |
この章には次の項が含まれます:
単一のAGLデータ・ソースにより、WebLogic Serverと、1つ以上のOracle RACクラスタが含まれるOracle Databaseサービスとの間の接続を提供します。Oracle Databaseサービスとは、共通属性を持つワークロードのことです。このサービスにより、管理者は単一のエンティティとしてワークロードを管理できます。AGLデータ・ソースの数は、Oracle RACクラスタのノード数に合わせるのではなく、データベース内でのサービス数の増加に合わせてスケールします。複数クラスタの高可用性サポートには、Data Guard、GoldenGate、Global Database Serviceなどがあります。
注意:
Active GridLinkとマルチ・データ・ソースは、Oracle RACクラスタと連動するように設計されています。汎用データ・ソースをOracle RACクラスタとともに使用することはお薦めしません。「AGLとマルチ・データ・ソースの比較」を参照してください
AGLデータ・ソースには、汎用データ・ソースの機能に加え、Oracle RACに対する次のサポートが含まれています。
AGLデータ・ソースは、高速接続フェイルオーバーを使用します。また、Oracle Notification Service (ONS)を使用したOracle RACイベントに応答します。これにより、AGLデータ・ソースの接続プールには確実に有効な接続(予約済の接続を含む)が格納されるようになり、接続のポーリングやテストの必要がなくなります。さらに、接続は使用可能になるときに、確実に新しいノード上に作成されるようになります。
AGLデータ・ソースでは、次の目的に高速接続フェイルオーバーを使用します。
高速な障害検出を提供する。
無効な接続を中断して、接続プールから削除する。
Oracle RACノードの計画済停止と計画外停止に対して正常なシャットダウンを実行する。「計画停止の手順」および「計画外停止」を参照してください
ノードの追加や削除などのトポロジの変化に適応する。
実行時の作業リクエストをアクティブなすべてのOracle RACインスタンスに分散する(クラスタへの再参加を含む)。
注意:
AGLデータ・ソースは、非推奨のFastConnectionFailoverEnabled接続プロパティをサポートしていません。このプロパティを有効化したXA接続を作成しようとすると、java.sql.SQLException: Can not use getXAConnection() when connection caching is enabledという例外が発生します。これは、このプロパティに対するドライバの高速接続フェイルオーバーの実装がXA接続をサポートしていないためです。
AGLデータ・ソースでは、ロード・バランシングを使用できます。AGLデータ・ソースは、データベースが発行するOracle FANイベントに基づいて、ランタイム接続ロード・バランシング(RCLB)を使用し、Oracle RACの各インスタンスに接続を分散します。つまり、データベースのトポロジに関係なく、データベースがAGLデータ・ソースを通じて接続のロード・バランシングを駆動するため、データ・ソースの構成が簡略化され、パフォーマンスが向上します。
ランタイム接続ロード・バランシングにより、WebLogic Serverでは次の事項が可能になります。
バック・エンド・ノードの能力(CPU、可用性、応答時間など)に応じた作業分散の調整。
Oracle RACトポロジの変更への対処。
高いパフォーマンスおよびスケーラビリティに対応するプール済接続の管理。
FANが有効化されていない場合、AGLデータ・ソースはラウンドロビン・ロード・バランシング・アルゴリズムを使用して、各Oracle RACノードに接続を割り当てます。
注意:
各接続は、AGLデータ・ソースで一定期間ごとにシャットダウンされます。様々なRACインスタンスに割り当てられた接続がFANロード・バランシング・アドバイザのランタイム・ロード・バランシングと一致しない場合は、過重インスタンスへの接続が破棄され、新しい接続が開かれます。このプロセスは、デフォルトでは30秒ごとに発生します。
この動作を調整するには、接続のリバランスが行われるまでシステムが待機する時間(秒)を指定するシステム・プロパティweblogic.jdbc.gravitationShrinkFrequencySecondsを使用します。値を0にすると、再バランシング処理が無効になります。
WebLogic Server GridLinkのアフィニティ・ポリシーは、RACクラスタの使用率を最大化して、パフォーマンスを向上するためのものです。次の項を参照してください。
同一のレコード・セットに対して繰り返される操作は、同一のRACインスタンスで処理することでWebアプリケーションのパフォーマンスが向上できます。オンライン・ショッピングやオンライン・バンキングなどのビジネス・アプリケーションは、このパターンの典型的な例としてあげられます。
AGLデータ・ソースは、セッション・アフィニティ・ポリシーを使用して、Webセッション(トランザクションを含む)ごとのすべてのデータベース操作が、RACクラスタの同一のOracle RACインスタンスに向けられるようにします。
注意:
コンテキストは、HTTPセッションに格納されます。これは、アプリケーションがHTTPセッションを各ウィンドウ(1つのブラウザ内または複数のブラウザ全体でのウィンドウ)にマップする方法に応じて異なります。
セッション・アフィニティ・ポリシーを使用するAGLデータ・ソースが、Webセッションのコンテキスト外からアクセスされると、そのアフィニティ・ポリシーはXAアフィニティ・ポリシーに変化します。「XAアフィニティ・ポリシー」を参照してください
AGLデータ・ソースは、AffEnabled属性を使用することでRACロード・バランシング・アドバイザ(LBA)をモニターして、RACクラスタのRACアフィニティが有効化されているかどうかを判断します。最初の接続リクエストはランタイム接続ロード・バランシング(RCLB)を使用してロード・バランシングされ、アフィニティ・コンテキストが割り当てられます。それ以降のすべての接続リクエストは、セッションが終了するかトランザクションが完了するまで、最初の接続のアフィニティ・コンテキストを使用して、同一のOracle RACインスタンスにルーティングされます。アフィニティは、データベース名、サービス名およびインスタンス名に基づいています。デフォルトでは、AGLデータ・ソースのセッション・アフィニティ・ポリシーは常に有効化されていますが、Webセッションのセッション・アフィニティは次の場合にアクティブになります。
Oracle RACが有効化されていてアクティブであり、サービスでRCLBが有効化されている。RCLBは、サービスのGOAL (CLB_GOALではありません)が、SERVICE_TIMEまたはTHROUGHPUTに設定されている場合に、サービスごとに有効化されます。
クラスタ待機時間において十分なパフォーマンスの向上があるとデータベースで判断され、ONSからの情報のペイロードに含まれるアフィニティ・フラグがTRUEに設定されている。
セッション・アフィニティを実装することに有効性がないとデータベースで判断された場合(高データベース可用性条件など)、データベースはロード・バランシング・アルゴリズムをデフォルトの作業割当てポリシーに戻して、ペイロード内のアフィニティ・フラグをFALSEに設定します。
複数のノード間で接続をロード・バランシングするために、次の2つのオプションがあります。
LOAD_BALANCE=onにして、複数の非SCANアドレスを使用する
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=myservice)))
1つのOracle単一クライアント・アクセス名(SCAN)アドレスを使用する
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=scanname)(PORT=scanport))(CONNECT_DATA=(SERVICE_NAME=myservice)))
SCANアドレスは、WebLogicコンソールで、TNSリスナーとONSリスナーの両方のホストを指定するために使用できます。SCANアドレスを含むAGLデータ・ソースは、Oracle RACのノードが追加または削除された場合でも変更する必要がないため、複数の非SCANアドレスを使用するよりもお薦めできます。ただし、SCANアドレスは、このアドレスを使用するようにデータベースを構成している場合にのみ使用できます。ご使用の環境に対して適切に構成されたSCAN URLについては、御社のネットワーク管理者に問い合せてください。
注意:
Oracle RAC 11.2以降を使用する場合は、次の点について考慮してください。
Oracle RACのリスナーがSCANに設定されていると、AGLデータ・ソース構成では、SCANアドレスのみが使用できるようになります。
Oracle RACのリスナーがList of Node VIPsに設定されていると、AGLデータ・ソース構成では、VIPアドレスのリストのみが使用できるようになります。
Oracle RACのリスナーがMix of SCAN and List of Node VIPsに設定されていると、AGLデータ・ソース構成では、SCANとVIPの両方のアドレスが使用できるようになります。
Real Application Clusters管理およびデプロイメント・ガイドの動的データベース・サービスでの自動ワークロード管理の概要。
ホワイト・ペーパー『Oracle Single Client Access Name (SCAN)』(http://www.oracle.com/technetwork/database/clustering/overview/scan-129069.pdf)
この機能を使用すると、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イベントを送信します。
WebLogicドメイン内にAGLデータ・ソースを作成する場合は、WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用します。
内容は次のとおりです。
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管理コンソールからデータ・ソースの構成ウィザードを使用して、データ・ソースを作成するために使用する基本手順の概要について説明します。
「JDBCデータ・ソースのプロパティ」には、データ・ソースのアイデンティティを決定するオプションと、データベース接続でデータを処理する方法を決定するオプションがあります。
JDBCデータ・ソースの名前は、WebLogicドメイン内でデータ・ソースを識別するために使用されます。システム・リソース・データ・ソースの場合、そのリソース以外のすべてのJDBCシステム・リソース(データ・ソースを含む)間で一意の名前にする必要があります。名前の競合を避けるために、データ・ソースの名前は、その他の構成オブジェクト(サーバー、アプリケーション、クラスタ、JMSキュー、JMSトピック、JMSサーバーなど)の名前の間でも一意にする必要があります。特定のアプリケーションにスコープ設定されたJDBCアプリケーション・モジュールの場合、データ・ソースの名前は、同様にスコープ設定されたJDBCデータ・ソース間で一意にする必要があります。
使用可能なスコープのリストからデータ・ソースのスコープを選択します。スコープは、「グローバル」(ドメイン・レベル)または既存の「リソース・グループ」や「リソース・グループ・テンプレート」に設定できます。
単一の名前または複数の名前でJNDIツリーにバインドされるように、データ・ソースを構成します。単一のJDBC接続プールを指す複数のデータ・ソースを含む従来の構成のかわりに、複数JNDI名のデータ・ソースを使用できます。詳細は、『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。
WebLogic Server管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic ServerはJDBCドライバの種類に応じて特定のトランザクション・オプションを自動的に選択します。
XAドライバの場合、システムはグローバル・トランザクション処理のための「2フェーズ・コミット」プロトコルを自動的に選択します。
非XAドライバ(リプレイ・ドライバ)の場合、ローカル・トランザクションは定義によってサポートされ、WebLogic Serverは次のオプションを提示します。
グローバル・トランザクションのサポート: グローバル・トランザクションでデータ・ソースからの接続を使用する場合は、XAドライバを選択していないときにも、このオプションを選択します(デフォルトで選択済)。詳細は、「非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化」を参照してください。
「グローバル・トランザクションのサポート」を選択する場合は、グローバル・トランザクションを処理するときに、トランザクション・ブランチに使用するWebLogic Serverのプロトコルも選択する必要があります。
ロギング・ラスト・リソース: このオプションを選択すると、接続を使用するトランザクション・ブランチは、トランザクションのラスト・リソースとして処理され、ローカル・トランザクションとして処理されます。2フェーズ・コミット(2PC)トランザクションのコミット・レコードは、リソース自体の表に挿入され、その結果によりグローバル・トランザクションの準備フェーズの成功または失敗が決定されます。このオプションは、「2フェーズ・コミットのエミュレート」と比べて、パフォーマンス上の利点があり、データの安全性も向上しますが、いくつかの制限があります。「「ロギング・ラスト・リソース」トランザクション・オプションの理解」を参照してください
2フェーズ・コミットのエミュレート: このオプションを選択すると、接続を使用するトランザクション・ブランチは、トランザクションの準備フェーズの結果として常に成功を戻します。これは、パフォーマンス上の利点がありますが、障害の状況によってはデータに危険が及びます。このオプションは、ヒューリスティックな状況に耐えられるアプリケーションでのみ使用してください。「2フェーズ・コミットのエミュレート・トランザクション・オプションの理解」を参照してください
1フェーズ・コミット: このオプションを選択すると(デフォルトで選択済)、データ・ソースからの接続のみがグローバル・トランザクションに関与するようになり、そのトランザクションは1フェーズ・コミット最適化を使用して完了します。トランザクションに複数のリソースが関与していると、トランザクション・マネージャが1PCリソースのXAResource.prepareを呼び出したときに、例外がスローされます。
データ・ソースをサポートするようにトランザクションを構成する方法の詳細は、「JDBCデータ・ソース・トランザクション・オプション」を参照してください
接続プロパティは、データ・ソースとDBMSとの間の接続を構成するために使用します。一般的な属性には、サービス名、データベース名、ホスト名、ポート番号、ユーザー名とパスワードがあげられます。
注意:
サービス名の使用方法:
データベース・ドメインを使用するときには、サービス名にドメイン名の接尾辞を付加する必要があります。たとえば、データベース名がdb.country.myCorp.comで、サービス名がmyserviceのときには、myservice.db.country.myCorp.comと入力する必要があります。
コンソールを使用すると、次のいずれかの方法で接続プロパティを入力できます。
「GridLinkデータ・ソース接続プロパティのオプション」ページで、「個別のリスナー情報の入力」を選択して、「次へ」をクリックします。接続のプロパティを入力します。次に例を示します。
「サービス名」にmyServiceを入力します。
「ホストとポート:」に、left: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)))
「GridLinkデータ・ソース接続プロパティのオプション」ページで、「完全なJDBC URLの入力」を選択して、「次へ」をクリックします。接続のプロパティを入力します。次に例を示します。
「完全なJDBC URL」に、JDBC URLを入力します。次に例を示します。
jdbc:oracle:thin:@( DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE=on) (FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=left)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=center)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=right)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=myService)))
SCANアドレスを使用することもできます。例: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=MyScanAddr-scn.myCompany.com)(PORT=1234)))(CONNECT_DATA=(SERVICE_NAME=myService)))
「データベース・ユーザー名」に、myDataBaseと入力します。
「パスワード」に、myPassword1と入力します。
必要に応じて、「プロトコル」をSDPに設定します。
ここでは、サポートされるAGLデータ・ソースURL形式について説明します。
AGLデータ・ソースは長いフォーマットのJDBC URLのみをサポートします。サポートされている長いフォーマットのパターンは次のようになります。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=[SCAN_VIP])(PORT=[SCAN_PORT])))(CONNECT_DATA=(SERVICE_NAME=[SERVICE_NAME])))
簡易接続(短い)フォーマットURLは、AGLデータ・ソースではサポートされていません。AGLデータ・ソースでの使用がサポートされていない簡易接続URLパターンの例を次に示します。
jdbc:oracle:thin:[SCAN_VIP]:[SCAN_PORT]/[SERVICE_NAME]
AGLデータソースURLに関する推奨事項
次の項では、AGLデータ・ソースURLを作成する際の一般的な推奨事項を示します。
単一のDESCRIPTIONを使用します。接続遅延を防ぐためにDESCRIPTION_LISTを避けます。
各RACクラスタまたはDataGuardデータベースに1つのADDRESS_LISTを使用します
すべてのADDRESS_LISTエントリが同じ値を使用するように、DESCRIPTIONレベルでRETRY_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が設定されているAGLデータソースの場合、WebLogic Serverは起動時に1度DBMSに接続してONS情報を取得する必要があります。
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)。WebLogic ServerでOracleウォレット・ファイルを使用するには、次の手順を実行する必要があります。
AGLデータ・ソース構成を変更して、SSL証明書とONSウォレット・パスワード(任意)が格納されているOracleウォレット・ファイルのディレクトリを含めます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのOracleウォレットを使用したセキュアなONSリスナーに関する項を参照してください。
Oracleウォレットの詳細は、Oracleウォレットの作成および管理を参照してください。
ソケット・ダイレクト・プロトコル(SDP)を使用する場合は、インフィニバンドを使用するようにデータベース・ネットワークを構成する必要があります。SDPは、SCANアドレスをサポートしていません。『Oracle Database Net Services管理者ガイド』のインフィニバンド接続の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)))
各JDBCデータ・ソースは、そのデータ・ソースのデプロイ時またはサーバーの起動時に作成されるJDBC接続のプールを1つ保持します。アプリケーションは、プールからの接続を使用して、その接続を使用後にプールに返します。接続のプーリングにより、アプリケーション用のデータベース接続を作成するという負担のかかるタスクを排除して、パフォーマンスを向上できます。
注意:
特定のOracle JDBC拡張機能は、プールされた接続の将来のユーザーが接続の動作を継承するという方法で、接続の動作を永続的に変更することが可能です。WebLogic Serverは、このようなタイプの呼出しに対して、可能な場合は接続の保護を試行します。
次の各項では、JDBCデータ・ソースの接続プール・オプションについて説明します。
次の項目を使用すると、さらに多くの情報を確認して、これらのオプションとその他の関連オプションを設定できます。
WebLogic Server管理コンソールの「JDBCデータ・ソース: 構成: 接続プール」ページ。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 接続: 接続プールを参照してください
JDBCConnectionPoolParamsBean。これは、JDBCDataSourceBeanの子MBeanです。
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を指定してはいけません。
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()
WebLogic Serverには、Oracleドライバの使用時にデータ・ソースのパフォーマンスを向上できる、いくつかの属性が用意されています。詳細は、「Oracleドライバおよびデータベースの詳細な構成」を参照してください
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クライアントの構成」を参照してください。
WebLogic Serverドメイン内のJDBCデータ・ソースで、接続プールの属性を適切に構成すると、アプリケーションとシステムのパフォーマンスを向上できます。詳細は、「データ・ソース接続プールのチューニング」を参照してください
次の各項では、GridLink JDBCオブジェクトのモニタリングについて説明します。
JDBCのモニタリングの詳細は、「WebLogic JDBCリソースのモニタリング」を参照してください
AGLデータ・ソースの実行時の統計は、WebLogic Server管理コンソールを使用するか、関連するランタイムMBeanを通じて表示できます。
JDBCOracleDataSourceRuntimeMBeanには、データ・ソース・インスタンスの現在の状態を取得するメソッドがあります。JDBCOracleDataSourceRuntimeMBeanには、データ・ソースの現在の状態を取得するメソッドと、データ・ソースに関する統計を取得するメソッドが用意されています。取得できる統計には、平均のアクティブな接続数、現在のアクティブな接続数、最大のアクティブな接続数などがあります。このMBeanは、AGLデータソース内でアクティブな各ノードに対する子のJDBCOracleDataSourceInstanceRuntimeMBeanも保持しています。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCOracleDataSourceRuntimeMBeanを参照してください。
JDBCOracleDataSourceInstanceRuntimeMBeanには、データ・ソース・インスタンスの現在の状態を取得するメソッドがあります。アクティブなONSリスナーごとに1つのインスタンスが存在します。auto-ONSを使用する構成では、管理者がONS文字列を構成していない場合は、これが使用可能なONSリスナーを検出する唯一の方法になります。詳細は、Oracle WebLogic Server MBeanリファレンスのJDBCOracleDataSourceInstanceRuntimeMBeanを参照してください。
ONSDaemonRuntimeMBeanには、AGLデータ・ソースに関連付けられたONSクライアント構成をモニタリングするメソッドがあります。
次に示すのは、ONS接続をテストするためのWLSTスクリプトです。この例では、Active GridLinkデータ・ソースの名前はgldsで、ターゲットはmyserverになっています。
connect(<wluser>, <wlpassword>, 't3://localhost:7001')
serverRuntime()
cd('JDBCServiceRuntime')
cd('myserver')
cd('JDBCDataSourceRuntimeMBeans')
cd('glds')
cd('ONSClientRuntime')
cd('glds')
cd('ONSDaemonRuntimes')
cd('glds_0')
cmo.ping()
詳細は、Oracle WebLogic Server MBeanリファレンスのONSDaemonRuntimeMBeanを参照してください。
WebLogic Serverのデバッグ機能を有効化すると、アプリケーションで発生した特定の問題を追跡できるようになります。
JDBCの登録済デバッグ範囲は、次のとおりです。
DebugJDBCRAC: AGLデータ・ソースのライフサイクル、UCPコールバックおよび接続情報に関する情報を出力します。
DebugJDBCONS: ONSクライアント情報(LBAイベント本体を含む)をトレースします。アクティブなONSリスナーごとに、1つのトレースを使用できます。auto-ONSを使用する構成では、管理者がONS文字列を構成していない場合は、これが使用可能なONSリスナーを確認する唯一の方法になります。
DebugJDBCReplay: アプリケーション・コンティニュイティのリプレイ情報をトレースします。
DebugJDBCUCP: UCPドライバからの下位レベルRAC情報をトレースします。
AGLデータ・ソースのデバッグ・プロパティを、コマンド行から適切に設定します。次に例を示します。
-Dweblogic.debug.DebugJDBCRAC=true -Dweblogic.debug.DebugJDBCONS=true -Dweblogic.debug.DebugJDBCUCP=true -Dweblogic.debug.DebugJDBCREPLAY=true
これらの値の設定は、静的であり、サーバー起動時にのみ使用されます。
-Djava.util.logging.config.file=configfile -Doracle.ons.debug=true
このコマンドで、configfileは、ログ出力のフォーマットとロギング・レベルを制御するために標準のJDKロギングで使用される構成プロパティ・ファイル・プロパティのパスとファイル名です。configfileに次の行を含める必要があります。
oracle.ons.level=FINEST
詳細は、Java Platform Standard Edition 7 API仕様のjava.util.loggingを参照してください。
AGLデータ・ソースは、高速アプリケーション通知(FAN)を有効化することなく構成して使用することもできます(ただし、これは推奨されていません)。この構成では、2回連続して接続テストに失敗すると、RACノードへの接続が無効化されます。接続テストが成功すると、接続が確立されます。TestConnectionsOnReserveを有効化することをお薦めします。構成済のファイアウォールが、このプロトコルを遮断する場合は、FANをオフにすることが必要になる場合があります。
次の表は、「FANの有効化」がfalseに設定されているときに使用できる、AGLデータ・ソースの機能を示しています。
表6-1 GridLinkの機能(「FANの有効化」がFalseの場合)
| Active GridLinkの機能 | 「FANの有効化」がFalseの場合に使用可能 |
|---|---|
RACクラスタへのアクセスのための単一データ・ソース構成 |
はい |
個別のRACクラスタ・インスタンスに対するランタイムMBean |
はい |
ランタイム・ロード・バランシング(RLB)を使用した接続ロード・バランシング |
いいえ |
高速アプリケーション通知 |
いいえ |
高速接続フェイルオーバー(FCF) |
いいえ |
正常なシャットダウン |
いいえ |
グラビテイション (接続の再バランシング) |
いいえ |
ONSクライアント・サポート(パスワードおよび暗号化されたウォレットの構成を含む) |
はい |
トランザクション・アフィニティ |
はい |
セッション・アフィニティ |
いいえ |
WebLogic Server 12.1.2以降では、ActiveGridlink属性を使用して、データ・ソース構成がAGLデータ・ソースであることを明示的に宣言します。これは、WebLogic Server管理コンソールでGridLinkデータ・ソースを作成するときに、自動的に有効化されます。WLSTを使用してデータ・ソース構成を作成する場合は、ActiveGridlink=trueを設定する必要があります。
注意:
WebLogic Server 12.1.2より以前のリリースとの後方互換性を維持するために、FanEnabled=trueまたはOnsNodeListがNULL以外のときには、データ・ソース構成は常にAGLデータ・ソース構成になります。この場合、ActiveGridlink値は無視されます。
従来のデータ・ソース構成は、アップグレード処理時に更新されません。高速アプリケーション通知(FAN)を有効化することなくRACクラスタにアクセスするために、従来のAGLデータ・ソースを更新する必要がある場合は、編集またはWLSTを使用して構成内でActiveGridlink=trueを設定します。
次の各項では、AGLデータ・ソースを使用する際のベスト・プラクティスについて説明します。
アプリケーションは、すべての例外をキャッシュして処理する必要があります。AGLデータ・ソースを使用するアプリケーションは、流用された接続でJDBC操作を実行するときに、IO socket read errorなどの例外を予期しておく必要があります。接続の有効性を検査して、必要なときには再接続することがベスト・プラクティスになります。接続の例外は、FANイベントの到着前にドライバが停止を検出した場合や、接続のクリーンアップの結果として発生することがあります。計画外停止イベントの場合は、その停止の影響を受けるすべての接続が、接続プールによって中断されます。
この項では、AGLの接続の変更点について要約します。FANとONSは有効化されていることを前提にしています。
構成済の初期容量に基づいて、最初にプールに接続が追加されます。これには、リスナーに基づいた接続時間のロード・バランシングが使用されます。これが正しく機能するには、複数の非SCANアドレスにLOAD_BALANCE=ONを指定するか、SCANを使用する必要があります。
ランタイム・ロード・バランシングに基づいて必要に応じて、接続がプールに追加されます。ただし、これは、トランザクションまたはWebセッションの最後のリクエストにアフィニティを提供するインスタンスに接続が追加された場合、XAアフィニティまたはWebセッション・アフィニティによりオーバーライドされます。
計画済停止イベントが発生すると、そのインスタンスの未使用の接続はすぐに解放され、使用中の接続はプールに返された時点で解放されます。
計画外停止イベントが発生すると、そのインスタンスのすべての接続がすぐに破棄されます。
起動イベントが発生すると、新しいインスタンスに接続が事前に作成されます。
グラビテイションの縮小が発生すると、負荷の高いインスタンス(期間単位)で未使用の接続が1つ破棄されます。
通常の縮小が発生すると、最小容量になるまで未使用接続の半数が破棄されます。このとき、負荷(期間単位)は考慮されません。
AGLは、RACクラスタのサポートに対応したマルチ・データ・ソース(MDS)の上位実装です。次の項では、AGLデータ・ソースの利点に関する追加情報について説明します。AGLの利点は、次のとおりです。
単一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」を参照してください。
.RAC接続対応のマルチ・データ・ソース(MDS)は、2005年からWebLogic Serverでサポートされています。Oracle RACが普及するに従い、MDSも広く使用されるようになりました。2011年初頭にActive GridLink (AGL)が導入されたことで、多くのMDSユーザーがAGLに移行しています。自動化されたアップグレード・パッチは存在しませんが、目的の環境にAGLを手動で実装するプロセスは簡単です。「AGLとマルチ・データ・ソースの比較」を参照してください
アプリケーションに対しては、なにも変更する必要はありません。標準的なアプリケーションは、JNDIのMDSを検索し、そのMDSを使用して接続を取得します。MDSと同じJNDI名をAGLに指定すると、アプリケーションでJNDIのデータ・ソース名を使用するプロセスはまったく同じになります。
構成にのみ変更が必要になります。AGLデータ・ソースは、MDSからの情報と、単一のAGL記述子で結合されたメンバー汎用データ・ソースで構成されています。唯一必要になる追加情報は、RACクラスタに関するOracle Notification Service (ONS)の構成です。多くの場合、ONS情報はMDSで使用されていたものと同じホスト名で構成されていて、唯一の追加情報はポート番号です。このポート番号は、SCANアドレスを使用することで簡略化できます。
MDS記述子には、多量の情報は含まれていません。主な構成要素は、次のとおりです。
JNDI名。アプリケーションに対する透過性を維持するためには、これを新しいAGLデータ・ソース名にする必要があります。MDSをAGLデータ・ソースと同時に実行するときには、AGLデータ・ソースに新しいJNDI名を付ける必要がありますが、その場合はアプリケーションも新しいJNDI名を使用するように更新する必要があります。
メンバー汎用データ・ソースのリストは、AGLデータ・ソースの構成に必要な残りの情報を提供します。
各メンバー汎用データ・ソースは、それぞれに独自のURLを持ちます。「Oracle RACでのマルチ・データ・ソースの使用」で説明するように、次のパターンになります。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=
(PROTOCOL=TCP)(HOST=host1-vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))
各メンバーは、独自のホスト/ポートのペアを持ちます。各メンバーは、同一のサービスを持つことがあり、多くの場合、別々のホストの同じポートを持ちます。AGLデータ・ソースのURLは、ホスト/ポートのペアで構成されています。次に例を示します。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=host1-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2-vip)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=dbservice))
これには、複数のホストや仮想IP (VIP)のアドレスではなく、Oracle単一クライアント・アクセス名(SCAN)アドレスを使用するようにしてください。SCANアドレスは、より簡単でノードの変更がクラスタ透過的になります。SCANアドレスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。次に例を示します。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=scanaddress)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=dbservice))
「アルゴリズムのタイプ」は無視します。
次の項では、MDSからAGLに移行する際に必要な基本手順について説明します。
WebLogic Server管理コンソールを使用して、MDSと汎用データ・ソースを構成から削除します。
WebLogic Server管理コンソールを使用して、単一のAGLデータ・ソースを追加します。
MDSと同じJNDI名を付けます。
どの汎用データ・ソースを使用していたかに応じて、XAドライバまたは非XAドライバを選択します。
完全なURLを入力します。詳細は、「マルチ・データ・ソースからの移行に伴う構成の変更」を参照してください
ユーザーとパスワードを設定します。これは、MDSメンバーに使用していたものと同じ内容にする必要があります。
「GridLinkデータソース接続のテスト」ページで、「すべてのリスナーのテスト」をクリックして、新しいURLを検証します。
ONS接続の情報を入力します。1つ以上のhost:portペアを指定します。例: host1-vip:6200またはscanaddress:6200。可能な場合は、単一のSCANアドレスとポートを使用します。「FANの有効化」が選択されていることを確認します。
ONS接続をテストします。
データ・ソースをデプロイします。
AGLデータ・ソースを編集して、追加パラメータを構成します。
新しいデータ・ソースの作成中には構成できないデータ・ソースのパラメータが多数あります。多くの場合、MDSで使用していたパラメータ設定値を使用できます。競合が発生した場合は、その競合を解決してから、環境に応じた適切な設定値を選択する必要があります。
WebLogic Server管理コンソールを使用してAGLデータ・ソースを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC GridLinkデータ・ソースの構成を参照してください。
ここでは、AGLによるデータベース停止時間の管理について説明します。
次の項では、Oracle RACデータベース環境のActive GridLinkデータ・ソースでデータベース停止時間を処理する方法について説明します。
データベースの停止に対応するActive GridLink構成
計画停止の手順
計画外停止
ここでは、データベース停止に対するActive GridLink構成方法について説明します。
AGLデータ・ソースが次のように構成されていることを確認します。
高速アプリケーション通知(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イベントが発生すると、AGLは、メンテナンスの対象となる1つ以上のインスタンスからセッションを排出します。ターゲット・データベース・インスタンスで実行されている非シングルトン・サービスを停止するか(それらがまだ残りの実行中のインスタンスで使用可能であると仮定)、シングルトン・サービスをターゲット・インスタンスから別のインスタンスに再配置する必要があります。サービスが排出されると、インスタンスは、アプリケーション・エラーなしで停止されます
次の手順では、計画メンテナンス・プロセスの概要を示します。
表6-2 AGL計画メンテナンスのためにデータベース・サーバーで実行される手順
| 手順番号 | データベース・サーバーの手順 | コマンド | 中間層の応答 |
|---|---|---|---|
1. |
-forceなしで非シングルトン・サービスを停止するか、シングルトン・サービスを再配置します。 –serverオプションを省略すると、インスタンスのすべてのサービスに影響します。 |
または
|
サービスのFAN計画停止(reason=USER)イベントは、サービスが使用できなくなったため、接続を排出する必要があることを接続プールに通知します。停止されたサービスのアイドル接続は、即座に解放されます。使用中の接続は、アプリケーションから返された(論理的に閉じられた)ときに解放されます。新しい接続は、サービスを提供する他のインスタンスおよびデータベースで予約されます。このFANアクションは、アプリケーションを中断することなく、インスタンスからのセッションの排出を開始します。 |
2. |
停止したサービスを無効化して、自動的に再起動されないようにします。サービスの無効化はオプションです。この手順は、アクションが完了するまでサービスの自動的な再起動が禁止されるメンテナンス・アクションに推奨されます。 |
|
新しい接続は、停止または無効化されたサービスに中間層で関連付けられません。 |
3. |
セッションの排出を許可します。 |
|
所要時間は、アプリケーションに応じて異なります。長時間実行される問合せになることもあります。バッチ・プログラムは、定期的に接続を返して新しい接続を取得するように記述されていない可能性があります。メンテナンスの前にバッチを排出することをお薦めします。 |
4. |
長時間実行されるセッションをチェックします。トランザクション切断を使用してこれらのセッションを終了します。セッションの排出を待機します。問合せを再度実行して、セッションが残っているかどうかをチェックできます。 |
|
中間層の接続はエラーを受け取ります。アプリケーション・コンティニュイティを使用している場合、別のインスタンスで新しい接続に対する操作を自動的にリプレイすることで、アプリケーションからエラーを隠蔽できます。それ以外の場合、アプリケーションはSQLExceptionを受け取ります。 |
5. |
手順1から4を繰り返します。 |
計画メンテナンスの対象となるすべてのサービスで繰り返します |
|
6. |
immediateオプションを使用してデータベース・インスタンスを停止します。 |
|
データベースとサービスが再起動されるまで中間層に影響はありません。 |
7. |
オプションで、メンテナンス中に自動的に再起動しないようにインスタンスを無効化します。 この手順は、メンテナンス中にサービスを再開できないメンテナンス操作向けです。 |
|
|
8. |
スケジュール済メンテナンス作業(パッチ、修理および変更)を実行します。 |
|
|
9. |
インスタンスを有効化して起動します。 |
|
|
10. |
サービスを有効化して起動します。サービスが起動されて実行中であることを確認します。 |
|
サービスのFAN UPイベントは、新しいインスタンスが使用可能になったため、次回のリクエストの送信時にこのインスタンスでセッションを作成できることを接続プールに通知します。セッションの自動リバランスが開始します。 |
計画停止時間の前後に2つのOracle RACインスタンス間で行われるサービスの接続の配分を示しています。接続ワークロードが、両方のインスタンス間で50対50から100対0に移行していることがわかります。言い換えると、RAC_INST_1は、ビジネス操作に影響を与えることなくメンテナンスのために停止できます。
ここでは、計画外停止について説明します。
計画外停止が発生する場合、いくつかの相違点があります。
データベース・サーバーのコンポーネントに障害が発生すると、そのノードで実行されているインスタンス上ですべてのサービスが使用できなくなる可能性があります。障害が発生しているため、サービスの停止または無効化は行われません。
FAN計画外停止イベント(reason=FAILURE)が中間層に配信されます。
すべてのセッションが即座に閉じられるため、アプリケーションは、TCP/IPタイムアウトを待機することはありません。他のインスタンスの既存の接続は使用可能なままで、必要に応じてそれらのインスタンスに新しい接続が開かれます。
接続の正常な排出は行われません。アプリケーション・コンティニュイティを使用するように構成されているサービスを使用するアプリケーションの場合、アクティブ・セッションが残存インスタンスでリストアされ、操作をリプレイすることでリカバリされるため、停止はアプリケーションから隠蔽されます。アプリケーション・コンティニュイティで保護されていない場合、インスタンスとアクティブに通信するセッションは、SQLExceptionを受信します。
計画メンテナンスが発生した場合、計画停止サービス・イベントがWebLogic Serverデータベースにより処理されます。デフォルトで、プール内の予約されていない接続はすべてクローズされ、流用された接続はプールに返された時点でクローズされます。これにより、次の理由でパフォーマンスが変動する可能性があります。
新しい接続を代替インスタンスに作成する必要があります。
その他のインスタンスでログオン・ストームを引き起こす可能性もあります。
接続をすべてただちにクローズするのではなく、段階的に排出することをお薦めします。アプリケーションは、接続がクローズされる排出期間の長さを定義できます。
この機能は、Oracle RACで実行されるAGLデータソースでサポートされています。
排出タイムアウト期間の設定
接続プロパティ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.us.oracle.com
排出期間が設定されないか0に設定されると、デフォルトで排出期間はなく、接続はただちにクローズされます。
値が小さいと移行は加速されますが、宛先ノードでのリクエストがコールド・バッファ・キャッシュをビットするためにアプリケーションで応答時間が長くなる可能性があります。値が大きいほど、移行はより段階的に行われ、宛先ノード上のバッファ・キャッシュに与えられるウォームアップ時間が増える結果、アプリケーションに対する影響が減りますが、全体的な移行期間は長くなります。
段階的排出処理
処理は、AGLデータストアに対して構成されたデータベース・サービスが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"の容量に対応する上昇があることがわかります。 合計容量は期間全体にわたって一定のままであることに注意してください。 注意:
これらのグラフは、接続を取得して少しの作業を実施し接続を解放するリクエストの疑似ワークロードから生成されたものです。 現実世界では、結果はそれほど完全ではない可能性があります。
