| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1) E70015-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1) E70015-01 |
|
前 |
次 |
この章では、JDBCデータ・ソースの構成方法とチューニング方法について説明します。
この章には次の項が含まれます:
WebLogic Serverでデータベース接続を構成するには、データ・ソースをWebLogicドメインに追加します。WebLogic JDBCデータ・ソースにより、データベースへのアクセスおよびデータベース接続管理が可能になります。各データ・ソースには、データ・ソースの作成時とサーバーの起動時に作成されるデータベース接続のプールが含まれています。アプリケーションは、JNDIツリーまたはローカル・アプリケーション・コンテキストでデータ・ソースをルックアップしてから、getConnection()を呼び出してデータ・ソースからデータベース接続を確保します。接続の使用後に、アプリケーションは、できるだけ早くconnection.close()を呼び出す必要があります。これにより、データベース接続をプールに戻して、他のアプリケーションが使用できるようにします。
WebLogic Serverは、次の5種類のデータ・ソースを提供します。
汎用データ・ソース - 汎用データ・ソースとその接続プールによって、効率的なシステム運用の維持を円滑にする接続管理プロセスが提供されます。アプリケーションや環境に適合するオプションをデータ・ソースで設定できます。
Active GridLink (AGL)データ・ソース - 1つ以上のOracle RACクラスタ内の1つ以上のノードに及ぶ接続プールを提供するデータ・ソース。これは、ノード全体にわたる接続の動的ロード・バランシングをサポートし、クラスタに対するノードの追加や削除を示すイベントを処理します。第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。
マルチ・データ・ソース(MDS) - マルチ・データ・ソースとは、汎用データ・ソースのグループに関する抽象化のことです。この抽象化により、ロード・バランシングやフェイルオーバー処理を実現します。第5章「JDBCマルチ・データ・ソースの構成」を参照してください。
プロキシ・データ・ソース - WebLogic Serverマルチテナント環境のデータベース間で切替えを実行できるデータ・ソース。第7章「Proxyデータ・ソースの使用」を参照してください。
ユニバーサル接続プール(UCP)・データ・ソース - UCPデータ・ソースは、Oracle Universal Connection Pooling (UCP)を使用してOracle Databaseに接続するユーザー用のオプションとして提供されています。UCPは、Oracle WebLogic Server接続プーリングに対する代替接続プーリング・テクノロジを提供します。詳細は、第8章「ユニバーサル接続プール・データ・ソースの使用」を参照してください。
WebLogicドメインにJDBCデータ・ソースを作成するには、WebLogic Server管理コンソール、Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)を使用します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの作成に関する項。
『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のWebLogic Server JDBCデータ・ソースに関する項
サンプルの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ツリーにバインドされるように、データ・ソースを構成します。詳細は、『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。
DBMSを選択します。サポート対象のデータベースの詳細は、『Oracle WebLogic Serverの新機能』 12.2.1のサポート対象の構成に関する項を参照してください。
WebLogic Server管理コンソールを使用してJDBCデータ・ソースを作成すると、JDBCドライバ・クラスの選択を求めるプロンプトが表示されます。WebLogic Server管理コンソールには、一般的なドライバ・クラス名の大部分が表示され、ほとんどの場合、ドライバの必要に応じたURLの作成が支援されます。ただし、コンソールでURLをテストする前に、そのURLが適切であることを確認してください。選択するドライバは、データ・ソースのデプロイ先のすべてのサーバーのclasspathに含まれている必要があります。WebLogic Server管理コンソールに一覧表示されたすべてのJDBCドライバが、WebLogic Serverに付属している(またはclasspathにすでに含まれている)わけではありません。
Oracle Thinドライバ
Oracle ThinドライバXA
Oracle Thinドライバ非XA
MySQL (非XA)
サード・パーティ製のJDBCドライバ(第17章「WebLogic ServerでのJDBCドライバの使用方法」を参照):
次に示すデータベース管理システム用の、WebLogicブランドのDataDirectドライバ(『Oracle WebLogic Server JDBCアプリケーションの開発』のWebLogicブランドのDataDirectドライバの使用に関する項を参照):
DB2
Informix
Microsoft SQL Server
Sybase
これらのすべてのドライバは、weblogic.jarマニフェスト・ファイルで参照されるため、サーバーのclasspathに明示的に定義されている必要はありません。
データベースへの接続に使用するJDBCドライバを決定する際には、目的の環境で様々なベンダーのドライバを試してみることが必要です。通常、JDBCドライバのパフォーマンスは、アプリケーションで使用するSQLコードやJDBCドライバの実装など、様々な要因に応じて変化します。
サポート対象のJDBCドライバの詳細は、『Oracle WebLogic Serverの新機能』 12.2.1のサポート対象の構成に関する項を参照してください。
|
注意: データ・ソースの作成時に、WebLogic Server管理コンソールに一覧表示されるJDBCドライバには、WebLogic Serverでの使用が保証されていないものもあります。JDBCドライバの一覧は、多数の使用可能なデータベース管理システムへの接続を円滑に作成するための利便性を目的として示されます。JDBCドライバを使用してデータ・ソースにデータベース接続を作成するには、データ・ソースをデプロイするサーバーごとにJDBCドライバをインストールする必要があります。WebLogic Server管理コンソールに一覧されるドライバは、データ・ソースの構成に役立つ既知の必須構成オプションとともに示されます。この一覧には、インストールされていないJDBCドライバも表示されます。ドライバのインストールには、システムのPathやClasspathなどの環境変数の設定が含まれることがあります。「WebLogic Serverとともにインストールされていないサード・パーティJDBCドライバの追加」を参照してください。JDBCドライバの更新に伴って、構成要件が変更されることがあります。WebLogic Server管理コンソールは、WebLogic Serverソフトウェアがリリースされた時点での既知の構成要件を使用します。JDBCドライバの構成オプションが変更されているときには、その構成オプションの手動でのオーバーライドが必要になる場合があります。その場合、データ・ソースの作成時またはデータ・ソースの作成後にプロパティのページでオプションをオーバーライドします。 |
WebLogic Server管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic ServerはJDBCドライバの種類に応じて特定のトランザクション・オプションを自動的に選択します。
XAドライバの場合、システムはグローバル・トランザクション処理のための「2フェーズ・コミット」プロトコルを自動的に選択します。
非XAドライバの場合、ローカル・トランザクションは定義によってサポートされ、WebLogic Serverは次のオプションを提示します。
グローバル・トランザクションのサポート: グローバル・トランザクションでデータ・ソースからの接続を使用する場合は、XAドライバを選択していないときにも、このオプションを選択します(デフォルトで選択済)。詳細は、「非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化」を参照してください。
「グローバル・トランザクションのサポート」を選択する場合は、グローバル・トランザクションを処理するときに、トランザクション・ブランチに使用するWebLogic Serverのプロトコルも選択する必要があります。
ロギング・ラスト・リソース: このオプションを選択すると、接続を使用するトランザクション・ブランチは、トランザクションのラスト・リソースとして処理され、ローカル・トランザクションとして処理されます。2フェーズ・コミット(2PC)トランザクションのコミット・レコードは、リソース自体の表に挿入され、その結果によりグローバル・トランザクションの準備フェーズの成功または失敗が決定されます。このオプションは、「2フェーズ・コミットのエミュレート」と比べて、パフォーマンス上の利点があり、データの安全性も向上しますが、いくつかの制限があります。「「ロギング・ラスト・リソース」トランザクション・オプションの理解」を参照してください。
|
注意: ロギング・ラスト・リソースは、マルチ・データ・ソースで使用したデータ・ソースについてはサポートされていません。ただし、「LLRデータ・ソースに関する管理上の考慮事項と制限事項」で説明するように、Oracle RACバージョン10gリリース2 (10gR2)以降で使用していたデータ・ソースを除きます。 |
2フェーズ・コミットのエミュレート: このオプションを選択すると、接続を使用するトランザクション・ブランチは、トランザクションの準備フェーズの結果として常に成功を戻します。これは、パフォーマンス上の利点がありますが、障害の状況によってはデータに危険が及びます。このオプションは、ヒューリスティックな状況に耐えられるアプリケーションでのみ使用してください。「2フェーズ・コミットのエミュレート・トランザクション・オプションの理解」を参照してください。
1フェーズ・コミット: このオプションを選択すると(デフォルトで選択済)、データ・ソースからの接続のみがグローバル・トランザクションに関与するようになり、そのトランザクションは1フェーズ・コミット最適化を使用して完了します。トランザクションに複数のリソースが関与していると、トランザクション・マネージャが1PCリソースのXAResource.prepareを呼び出したときに、例外がスローされます。
データ・ソースをサポートするようにトランザクションを構成する方法の詳細は、「JDBCデータ・ソース・トランザクション・オプション」を参照してください。
接続プロパティは、データ・ソースとDBMSとの間の接続を構成するために使用します。一般的な属性には、データベース名、ホスト名、ポート番号、ユーザー名とパスワードがあげられます。
|
注意: ホスト名を表すために、単一クライアント・アクセス名(SCAN)アドレスが使用できます。Oracle RAC 11.2以降を使用する場合は、次の点について考慮してください。
SCANアドレスの使用方法の詳細は、『Real Application Clusters管理およびデプロイメント・ガイド』の動的データベース・サービスでの自動ワークロード管理の概要に関する項を参照してください。 |
「データベース接続のテスト」を使用すると、データ・ソース構成をファイナライズする前に、表名またはSQL文を使用してデータベース接続をテストできます。必要に応じて、Properties属性とSystem Properties属性を使用すると、追加の構成情報をテストできます。
新しいJDBCデータ・ソースのデプロイ先に、1つ以上のターゲットを選択します。ターゲットを選択していない場合でもデータ・ソースは作成されますが、デプロイされません。そのデータ・ソースは、接続を取得する前にデプロイする必要があります。
各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オブジェクトで設定します。
WebLogic JDBCデータ・ソースは、システム・プロパティの値を使用したドライバ・プロパティの設定をサポートしています。各プロパティの値は、指定されたシステム・プロパティから実行時に導出されます。接続ベースのシステム・プロパティを構成するには、WebLogic Server管理コンソールを使用して、データ・ソース構成のSystem Properties属性を編集します。
システム・プロパティ値が設定されている場合、それは暗号化されたプロパティ値をオーバーライドし、次にその値が通常のプロパティ値をオーバーライドします(プロパティ名ごとに1つのプロパティ値のみを持つことができます)。
システム・プロパティ値には、表3-1にリストされた変数の1つを含めることができます。これらの1つ以上の変数がシステム・プロパティに含まれる場合、対応する値で置換されます。値が検出されない場合、置換は実行されません。これらのどの変数もシステム・プロパティで検出されない場合、値は、システム・プロパティ名として扱われます。
表3-1 JDBCデータ・ソースのシステム・プロパティ値でサポートされる変数
| 変数 | 値の説明 |
|---|---|
|
|
|
|
|
|
|
|
Javaシステム・プロパティ |
|
|
システム・プロパティ |
|
|
JDBCディスクリプタによるデータ・ソース名。パーティション名は含みません。 |
|
|
パーティション名またはDOMAIN |
|
|
WebLogic Serverサーバー・リスニング・ポート |
|
|
WebLogic ServerサーバーSSLリスニング・ポート |
|
|
WebLogic Serverサーバー名 |
|
|
WebLogic Serverドメイン名 |
次の例に、プロパティのサンプル・セットを示します。
<properties>
<property>
<name>user</name>
<sys-prop-value>user</sys-prop-value>
</property>
<property>
<name>v$session.osuser</name>
<sys-prop-value>${user.name}</sys-prop-value>
</property>
<property>
<name>v$session.process</name>
<sys-prop-value>${pid}</sys-prop-value>
</property>
<property>
<name>v$session.machine</name>
<sys-prop-value>${machine}</sys-prop-value>
</property>
<property>
<name>v$session.terminal</name>
<sys-prop-value>${datasourcename}</sys-prop-value>
</property>
<property>
<name>v$session.program</name>
<sys-prop-value>WebLogic ${servername} Partition ${partition}</sys-prop-value>
</property>
</properties>
この例の説明:
userは、-Duser=valueの値に設定されます
v$sessionの値は、表3-1の説明どおりに設定されます
たとえば、myserverで実行されているv$session.programは、WebLogic myserver Partition DOMAINに設定されます
各値には、次の長さ制限があることに注意してください。
osuser - 30
process - 24
machine - 64
terminal - 30
program - 48
WebLogic JDBCデータ・ソースは、暗号化された値を使用したドライバ・プロパティの設定をサポートしています。接続ベースの暗号化されたプロパティを構成するには、WebLogic Server管理コンソールを使用して、データ・ソース構成のEncrypted Properties属性を編集します。詳細は、「暗号化された接続プロパティの使用」を参照してください。
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()
次の各項では、詳細な接続プロパティのうち重要なプロパティについて重点的に説明します。
データ・ソースと通信するデータベース・サーバーに、接続でアクセスできなくなったことを示す致命的エラー・コードを定義できます。その接続は無効のマークが付けられて、プールから取り除かれますが、データ・ソースが中断されることはありません。これらのエラーには、サーバーがブートできなくなるデプロイメント・エラーおよび接続を接続プールに戻せなくなる接続エラーが含まれます。
SQLExceptionの範囲内の例外コード(sqlException.getErrorCode()によって取得される)として指定されているコードは、致命的エラーが発生して接続が機能しなくなったために、その接続が接続プールから削除されることを意味します。Oracleデータベースでは、次の致命的エラー・コードがWebLogic Serverに事前定義されており、構成ファイルに配置する必要はありません。
| エラー・コード | 説明 |
|---|---|
| 3113 | 通信チャネルでend-of-fileが検出されました |
| 3114 | Oracleに接続されていません |
| 1033 | Oracleの初期化またはシャットダウン中です |
| 1034 | Oracleは使用できません |
| 1089 | 即時シャットダウン処理中 - 操作はできません |
| 1090 | シャットダウン処理中 - 接続はできません |
| 17002 | I/O例外 |
DB2の場合は、次の致命的エラー・コードは事前定義されています: -4498、-4499、-1776、-30108、-30081、-30080、-6036、-1229、-1224、-1035、-1034、-1015、-924、-923、-906、-518、-514、58004。
Informixの場合、次の致命的エラー・コードは事前定義されています: -79735、-79716、-43207、-27002、-25580、-4499、-908、-710、43012。
WebLogic Server管理コンソールで致命的エラー・コードを定義する場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの致命的エラー・コードの定義に関する項を参照してください。
エディションベースの再定義(EBR)を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。これにより、データのアップグレード前とアップグレード後のビューが同時に存在できるため、ホット・アップグレード機能が実現します。その後、特定のセッションに使用するビューを指定できます。
詳細は、次を参照してください。
『Oracle Database開発ガイド』のエディションベースの再定義の使用に関する項を参照してください
ホワイト・ペーパー『エディションベースの再定義』(http://www.oracle.com/technetwork/database/features/availability/edition-based-redefinition-1-133045.pdf)
JDBC接続でEBRを使用する場合、次の2つのアプローチがあります。
データベース・サービスを使用してデータベースに接続し、そのサービスで最初のセッション・エディションが指定された場合、そのサービスの最初のセッション・エディションが接続の最初のセッション・エディションになります。このアプローチは、接続のオーバーヘッドが最小限になるため推奨されます。
データベース・サービスの作成または変更時に、その最初のセッション・エディションを指定できます。データベース・サービスを作成または変更にするには、srvctl add serviceまたはsrvctl modify serviceコマンドを使用することをお薦めします。サービスのデフォルトの最初のセッション・エディションを指定するには、-editionオプションを使用します。
別の方法として、DBMS_SERVICE.CREATE_SERVICEまたはDBMS_SERVICE.MODIFY_SERVICEプロシージャを使用してデータベース・サービスを作成または変更し、EDITION属性でサービスのデフォルトの最初のセッション・エディションを指定することもできます。
SQL文のALTER SESSION SET EDITIONを使用して、データベースに接続した後にセッション・エディションを変更します。セッション・エディションは、USE権限のある任意のエディションに変更することができます。ただし、エディションを変更すると、場合によってはセッションおよびデータベース・サーバーの状態の相当量を再生成する必要があります。セッションでエディションを変更するときに、DBMS_SESSION.RESET_PACKAGEを使用してこの状態の一部をクリーンアップすることをお薦めします。
エディションベースの再定義を使用する場合、新しいWebLogic Serverの機能は何も必要ありません。
EBRを使用するには、現在の環境が、以前のEDITIONを参照するデータ・ソースを持つ以前のバージョンのアプリケーションと、新しいEDITIONを参照するデータ・ソースを持つ新しいバージョンのアプリケーションで構成されている必要があります。WebLogic Serverアプリケーションの複数のバージョンを参照する場合、本番再デプロイメント機能でWebLogic Serverのバージョニングされたアプリケーションを使用する必要があります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用のアプリケーションの開発に関する項を参照してください。Oracle Database EBRとWebLogic Serverのバージョニングされたアプリケーションを組み合せることで、各機能を単独で使用するより全体の機能性が向上し、停止時間なしでアプリケーションをアップグレードできます。
バージョンを切り替えることができるように、最初にバージョニングされたデータベースとバージョニングされたアプリケーションを組み合せて実行する必要があります。WebLogic Serverアプリケーションをバージョニングするには、単純にMANIFEST.MFファイルにWeblogic-Application-Versionプロパティを追加します(これはデプロイメント時に指定することもできます)。
次のリストでは、Oracle Databaseエディションを使用するためにWebLogicデータ・ソースを構成できる様々な方法について説明します。
単一エディションを使用するパッケージ化されたデータ・ソース - データ・ソースを構成する場合の推奨方法は、すべてが自己包含型となるようにアプリケーションEARまたはWARファイルに格納されたパッケージ化データ・ソース・ディスクリプタを使用することです。これを行うことで、各データ・ソースで同じ名前を使用でき、エディションに基づいて変数名を使用するためにアプリケーションを変更する必要がなくなります。ディスクリプタのデータ・ソースURLは、適切なエディションに関連付けられたデータベース・サービスを参照する必要があります。なんらかの理由でデータベース・サービスのかわりにSIDを使用する場合(現在は非推奨)、別の方法として、データ・ソース・ディスクリプタの初期化SQLパラメータにSQL ALTER SESSION SET EDITION = nameを指定します。このSQL文は、データ・ソース・プールに新しい物理データベース接続が作成されるたびに実行されます。このアプローチでは、データ・ソースがデータベースの単一エディションと、そのエディションを使用するすべての接続を参照していることが前提です。
パッケージ化されたデータ・ソースを使用する場合、次の制限があることに注意してください。
ロギング・ラスト・リソース(LLR)でパッケージ化されたデータ・ソースを使用することはできません。システム・リソースを使用する必要があります。
バージョニングされたアプリケーションのglobal-transactions-protocolに対してEmulateTwoPhaseCommitを使用する場合、アプリケーション・スコープのパッケージ化されたデータ・ソースを使用することはできません。グローバル・スコープのデータ・ソースを使用する必要があります。
したがって、LoggingLastResourceまたはEmulateTwoPhaseCommitを使用する必要がある場合、このアプローチは使用できません。詳細は、「JDBCアプリケーション・モジュールの制限」を参照してください。
単一エディションを使用するシステム・リソース・データ・ソース - パッケージ化されたデータ・ソースのかわりにシステム・リソースを使用できます。この場合、各データ・ソースは、一意の名前およびJNDI名を持つ必要があります。アプリケーションは、実行時にその名前を柔軟に使用できる必要があります。たとえば、データ・ソースJNDI名をシステム・プロパティとして渡し、JNDIでデータ・ソースをルックアップするコードでその値を使用できます。
データ・ソースごとに1つのエディションを使用する場合のデメリットは、それがパッケージ化されたものでもシステム・リソースでも、より多くのデータベース接続が必要になることです。単一エディション・アプローチは、古いエディションと新しいエディションの実行期間が比較的短い場合に有効です。多くのデータ・ソースまたは接続(あるいはその両方)を使用するアプリケーションでは、これは実行可能なアプローチではありません。
複数エディションを使用するシステム・リソース・データ・ソース - 代替方法として、複数のエディションを参照するデータ・ソースを使用します。推奨構成では、引き続き単一のエディションに関連付けられたデータベース・サービスを使用します。ただし、接続は、接続の存続期間中に様々なエディションに再度関連付けられます。
予約ごとのエディションの設定による複数エディション - アプリケーションで、接続を取得するたびにデータベース・エディションを設定できます。毎回このコールを行うことに関連して多少のオーバーヘッド(データベース・サーバーへのラウンドトリップとセッションの設定)が発生し、接続が予約される場所では常にアプリケーション・コードを変更する必要があります。リプレイ・ドライバを使用する場合、この初期化はConnectionInitializationCallbackで実行する必要があります。詳細は、「接続コールバックの使用方法」を参照してください。
新しいエディションへの移行が行われる短い期間を対象に最適化するのではなく、通常の使用例を対象に最適化することが重要です。このアプローチでは、必要なエディション上にすべての接続が存在する通常の状況を対象に最適化されません。
接続ラベリングを使用した複数エディション - エディションを接続に関連付け、適切なエディションで接続を予約するよう試みることができます。プロパティで接続にタグ付けする場合の推奨方法は、接続ラベリングを使用することです。次に、アプリケーションは、接続ラベリングに関連付けられた部分を実装する必要があります。
接続が予約される場合、コンテキストで必要なエディションを決定する必要があります。
プロパティ(この場合はエディション)が一致しているかどうかを判別する照合メソッドが必要です。
SQL ALTER SESSION SET EDITION = nameを使用して接続がまだ照合されていない場合、接続を照合するラベリング初期化メソッドが必要です。
特に既存の接続のリストを排他的にスキャンして一致を検出する場合、接続ラベリングに関連するオーバーヘッドが発生します。これに対して、通常の使用例では、すべての接続が現在のエディションに一致するため、一致を検出する必要はありません。エディション間でスラッシングが発生し、一致を検出するために(または一致がないことを確認するために)検索時間が長くかかる可能性があるのは、移行時のみです。
WebLogic Serverには、Oracleドライバの使用時にデータ・ソースのパフォーマンスを向上できる、いくつかの属性が用意されています。詳細は、第10章「Oracleドライバおよびデータベースの詳細な構成」を参照してください。
ONSクライアントを構成して、汎用データ・ソースをAGLデータ・ソースに変更します。構成情報と追加の環境要件の詳細は、第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。
WebLogic Serverドメイン内のJDBCデータ・ソースで、接続プールの属性を適切に構成すると、アプリケーションとシステムのパフォーマンスを向上できます。詳細は、第20章「データ・ソース接続プールのチューニング」を参照してください。
複数のHOSTまたはOracle RACでのURLのSCANアドレスであるHOSTを使用して、汎用データ・ソースを使用できます。ただし、これらのURLパターンを使用すると、Oracle RACの停止に対するトランザクション処理、モニタリングおよび正常な処理を複雑化させる制限が発生します。
|
注意: Oracle RACデータベースでは、マルチ・データ・ソースまたはActive GridLinkを使用することをお薦めします。第6章「Active GridLinkデータ・ソースの使用方法」または付録C「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。 |
次の制限事項は、WebLogic Serverインスタンスが、プール内の接続に関連付けられたOracle RACインスタンスを認識しないために発生するものです。
汎用データ・ソースでは、マルチ・データ・ソースまたはActive GridLinkデータ・ソースが提供するプール内の単一インスタンスを無効化できません。Oracle RACインスタンスのいずれかが(計画的に、または計画外で)停止した場合、データ・ソースは停止したインスタンスに対して、プール内のすべての接続を個別に無効化しながらテストします。オーバーヘッドやアプリケーションの遅延が増大するだけでなく、プールでは複数の失敗が確認され、プール全体が無効化されることになります。プールが無効化されることを回避するには、「フラッシュされるまでのテストの失敗数」の値を0に設定します。詳細は、次を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: 接続プールに関する項のページ
Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項。
この構成には、JTAまたはグローバル・トランザクションは使用できません。WebLogic ServerはOracle RACインスタンスを認識しないので、トランザクション・アフィニティを保証できません。トランザクションが複数のサーバーにまたがる場合や、トランザクションを完了させるのに別の接続が使用されるような失敗が発生した場合、これは問題になります。トランザクションを完了させるために必要な追加の接続が同じOracle RACインスタンス内に存在しないために、トランザクション処理が失敗する可能性があります。
Oracle RACインスタンスに基づいて接続を監視することはできません。
ドライバ・レベル・フェイルオーバーを使用する汎用データ・ソースのかわりに、マルチ・データ・ソースまたはActive GridLinkデータ・ソースを使用することをお薦めします。
いくつかのデータベース・ドライバでは、URLで複数のデータベース・インスタンスを定義して、あるデータベースから次のデータベースにフェイルオーバーを行う機能がサポートされます。ドライバ・レベル・フェイルオーバーで汎用データ・ソースを使用することもできますが、いくつかの制限があります。これらの制限によって、データベース・インスタンスの停止に対するトランザクション処理、モニタリングおよび正常な処理が複雑化します。
次の制限事項は、WebLogic Serverインスタンスが、プール内の接続に関連付けられたデータベース・インスタンスを認識しないために発生するものです。
汎用データ・ソースでは、マルチ・データ・ソースが提供するプール内の単一インスタンスを無効化できません。データベース・インスタンスのいずれかが(計画的に、または計画外で)停止した場合、データ・ソースは停止したインスタンスに対して、プール内のすべての接続を個別に無効化しながらテストします。オーバーヘッドやアプリケーションの遅延が増大するだけでなく、プールでは複数の失敗が確認され、プール全体が無効化されることになります。プールが無効化されることを回避するには、「フラッシュされるまでのテストの失敗数」の値を0に設定します。詳細は、次を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: 接続プールに関する項のページ
Oracle WebLogic Server MBeanリファレンスのJDBCConnectionPoolParamsBeanに関する項
この構成には、JTAまたはグローバル・トランザクションは使用できません。WebLogic Serverはデータベース・インスタンスを認識しないので、トランザクション・アフィニティを保証できません。トランザクションが複数のサーバーにまたがる場合や、トランザクションを完了させるのに別の接続が使用されるような失敗が発生した場合、これは問題になります。トランザクションを完了させるために必要な追加の接続が同じデータベース・インスタンス内に存在しないために、トランザクション処理が失敗する可能性があります。
データベース・インスタンスに基づいて接続を監視することはできません。
