6 Oracleドライバおよびデータベースの詳細な構成
- JDBCリプレイ・ドライバ
JDBCリプレイ・ドライバ(アプリケーション・コンティニュイティ・ドライバとも呼ばれる)は、Active GridLinkおよび汎用データ・ソースに対応する、アプリケーションに依存しない汎用インフラストラクチャです。これによって、アプリケーションの観点からの作業の回復が可能になり、多くのシステム障害、通信障害およびハードウェア障害がマスクされます。 - データベース常駐接続プーリング
データベース常駐接続プーリング (DRCP)により、Oracleデータベースに常駐する複数のWeb層および中間層のデータ・ソースで、データベース・サーバーの処理とセッションをプールできるようになります。 - グローバル・データ・サービス
グローバル・データ・サービス(GDS)により、分散データベース環境でシームレスな集中管理を提供するグローバル・サービスが使用できるようになります。グローバル・サーバーは、複数のRACおよび単一インスタンスのOracleデータベースをData GuardやGoldenGateなどのレプリケーション技術で相互接続して、それら全体でのロード・バランシング、フォルト・トレランスおよびリソース使用率を自動化します。 - プラガブル・データベースを使用するコンテナ・データベース
コンテナ・データベース(CDB)はOracleデータベース機能の1つであり、多数のデータベースを、単一CDBに含まれる複数のプラガブル・データベース(PDB)を使用して単一データベースに統合することにより、多数のデータベースを持つ場合のオーバーヘッドを最小限に抑えます。 - サービス切替え
サービス切替えの制限について学習します。
JDBCリプレイ・ドライバ
JDBCリプレイ・ドライバ(アプリケーション・コンティニュイティ・ドライバとも呼ばれる)は、Active GridLinkおよび汎用データ・ソースに対応する、アプリケーションに依存しない汎用インフラストラクチャです。これによって、アプリケーションの観点からの作業の回復が可能になり、多くのシステム障害、通信障害およびハードウェア障害がマスクされます。
現在の環境では、基盤になるソフトウェア・レイヤー、ハードウェア・レイヤー、通信レイヤーおよび記憶域レイヤーの停止について、アプリケーション開発者が明確に対処する必要があります。そのため、アプリケーション開発は複雑化し、機能停止はユーザーに対して表面化します。たとえば、ユーザーに対して送信ボタンを2回クリックしないように警告するアプリケーションがあります。その警告を見落としたユーザーは、意図しないうちに商品を2回購入したり、同じ請求書に対して複数回の支払を実行してしまうことがあります。
JDBCリプレイ・ドライバのセマンティクスにより、エンド・ユーザー・トランザクションが、時間どおりに1回だけ実行されることが保証されます。エンド・ユーザーがサービスの中断を認識するとしても、継続しても意味のない機能停止の場合に限られます。
次の各トピックでは、JDBCリプレイ・ドライバの構成方法と使用方法について説明します:
- JDBCリプレイ・ドライバの仕組み
- 要件および考慮事項
- JDBCリプレイ・ドライバの構成
- JDBCリプレイ・ドライバの実行時統計の表示
- JDBCリプレイ・ドライバの監査
- Oracle 12cデータベースでのJDBCリプレイ・ドライバの制限事項
親トピック: Oracleドライバおよびデータベースの詳細な構成
JDBCリプレイ・ドライバの仕組み
計画されたものかどうかにかかわらず、データベース・サービスの欠落による停止の後では、JDBCリプレイ・ドライバによりデータベース・セッションが再構築されます。高速アプリケーション通知またはリカバリ可能なORACLE
エラーによって停止が識別されると、Oracleドライバが次を行います:
-
新しいデータベース・セッションを確立して、未処理の状態をクリアします。
-
コールバックが登録されている場合は、コールバックを発行して、そのセッションの初期状態をアプリケーションが再確立できるようにします。
-
リクエスト中に累積した保存済の履歴を実行します。
Oracleドライバは、リプレイ・コールのタイミングを判断します。コールは、アプリケーションがデータベースの状態を変更する方法に応じて経時的に処理されるか、遅延処理の実装を使用して処理されます。リプレイは、Oracle 12c Database Serverで制御されます。リプレイが承認されるようにするには、リプレイされるコールごとに、元のコールの実行中にアプリケーションで表示されていて潜在的に使用されていたクライアントの表示状態とまったく同じ状態を返す必要があります。
親トピック: JDBCリプレイ・ドライバ
要件および考慮事項
次の項では、JDBCリプレイ・ドライバ(アプリケーション・コンティニュイティとも呼ばれる)をWebLogicアプリケーションに対して使用する際の要件と考慮事項について説明します:
-
Oracle 12c JDBCドライバとデータベースは必須です。「Oracle 12cデータベースの使用」を参照してください
-
JDBCリプレイ・ドライバでは、XA接続上の非XAトランザクション(ローカル・トランザクション)の読取りトランザクションと読取り/書込みトランザクションがサポートされます。グローバル・トランザクションに参加するJDBCリプレイ・ドライバにはOracleドライバをお薦めしません。
ノート:
- アプリケーション・コンティニュイティは、接続でXAトランザクションが使用されるとサイレントに無効化されます。
- アプリケーションで
connection.setAutoCommit(false)
をコールして、環境でのトランザクション・セマンティクスの分断化とJDBCリプレイ・ドライバの無効化を防止してください。
-
非推奨の
oracle.sql.*
具体クラスはサポートされていません。該当部分は、それに対応するoracle.jdbc.*
インタフェースまたはjava.sql.*
インタフェースのどちらかを使用するように変更する必要があります。標準のjava.sql.*
インタフェースの使用をお薦めします。Oracle WebLogic Server JDBCアプリケーションの開発のOracle JDBCタイプのAPI拡張機能の使用方法を参照してください。 -
JDBCリプレイ・ドライバは、中間結果をメモリーに格納することで機能します。アプリケーションは、この機能なしで実行するよりも実行速度が遅くなり、より大量のメモリーが必要になります。
- WebLogicの文キャッシュがJDBCリプレイ・ドライバに対して構成されている場合は、そのキャッシュは接続がリプレイされるたびにクリアされます。
-
JDBCリプレイ・ドライバ機能には、その他の制限事項と例外事項があります。これらは、アプリケーションがリプレイを使用できるかどうかに影響することがあります。詳細は、『Oracle Database JDBC開発者ガイド』のJavaのアプリケーション・コンティニュイティを参照してください。
-
データ・ソースのURLで指定されるデータベース・サービスは、フェイルオーバー・タイプに
TRANSACTION
を設定し、-commit_outcome
パラメータにTRUE
を設定して構成する必要があります。たとえば:srvctl modify service -d mydb -s myservice -e TRANSACTION -commit_outcome TRUE -rlbgoal SERVICE_TIME -clbgoal SHORT
親トピック: JDBCリプレイ・ドライバ
JDBCリプレイ・ドライバの構成
このトピックでは、環境にJDBCリプレイ・ドライバを実装する方法について説明します。
- JDBCリプレイ・ドライバのドライバの選択
- 接続コールバックの使用方法
- リプレイのタイムアウトの設定
- 接続でのJDBCリプレイ・ドライバの無効化
- JDBCリプレイ・ドライバのロギングの構成
- JDBCドライバ・デバッグの有効化
親トピック: JDBCリプレイ・ドライバ
JDBCリプレイ・ドライバのドライバの選択
適切なJDBCドライバを使用するようにデータ・ソースを構成するには、次のいずれかの方法を使用します。
-
新しいデータ・ソースを作成する場合は、構成ウィザードのドロップダウン・メニューからデータベース・ドライバを選択するように求められたときに、対象の環境でJDBCリプレイ・ドライバをサポートする適切なOracleドライバを選択します。『Oracle WebLogic Server Administration Consoleオンライン・ヘルプ』のアプリケーション・コンティニュイティの有効化に関する項を参照してください。
-
管理コンソールで既存のデータ・ソースを編集する場合は、「接続プール」タブを選択して、「ドライバ・クラス名」を
oracle.jdbc.replay.OracleDataSourceImpl
に変更してから、「保存」をクリックします。 -
テキスト・エディタまたはWLSTでデータ・ソースを作成または編集する場合は、JDBCドライバを
oracle.jdbc.replay.OracleDataSourceImpl
に設定します。
「要件および考慮事項」を参照してください
親トピック: JDBCリプレイ・ドライバの構成
接続コールバックの使用方法
初期化コールバックの作成
接続初期化コールバックを作成する場合は、アプリケーションにoracle.ucp.jdbc.ConnectionInitializationCallback
インタフェースのinitialize(java.sql.Connection connection)
メソッドを実装する必要があります。コールバックは、接続プールごとに1つのみ作成できます。
ラベリング・コールバックが接続プールに登録されていると、コールバックは無視されます。それ以外の場合、コールバックはプールから接続がチェックアウトされるたびに実行されます。また、リカバリ可能なエラーに続くリプレイ時に再接続が成功するたびに実行されます。実行時とリプレイ時に同じコールバックを使用することで、リプレイ時には、元のセッションが確立されたときに使用されたものと完全に同じ初期化が使用されるようになります。コールバックの呼出しが失敗すると、その接続についてのリプレイは無効になります。
ノート:
接続初期化コールバックは、クライアント(JDBC over RMI)ではサポートされません。
一度登録した接続コールバックは、Oracleドライバがなくても呼び出されます。
次の例では、単純な初期化コールバックの実装を示します。
. . . import oracle.ucp.jdbc.ConnectionInitializationCallback ; . . . class MyConnectionInitializationCallback implements ConnectionInitializationCallback { public MyConnectionInitializationCallback() { } public void initialize(java.sql.Connection connection) throws SQLException { // Re-set the state for the connection, if necessary } }
親トピック: 接続コールバックの使用方法
初期化コールバックの登録
WLDataSource
インタフェースには、初期化コールバックを登録するためのregisterConnectionInitializationCallback(ConnectionInitializationCallback callback)
メソッドが用意されています。1つの接続プールに登録できるコールバックは1つのみです。次の例は、MyConnectionInitializationCallback
クラスに実装されている初期化コールバックの登録方法を示しています。
. . . import weblogic.jdbc.extensions.WLDataSource; . . . MyConnectionInitializationCallback callback = new MyConnectionInitializationCallback(); ((WLDataSource)ds).registerConnectionInitializationCallback(callback); . . .
また、コールバックは、WebLogic Server管理コンソールからデータ・ソースの「Oracle」タブで、「接続初期化コールバック」属性にコールバック・クラスを入力することでも登録できます。実行時にコールバックを設定するのではなく、このコールバック属性を構成するようにしてください。『Oracle WebLogic Server Administration Consoleオンライン・ヘルプ』のアプリケーション・コンティニュイティの有効化に関する項を参照してください。
親トピック: 接続コールバックの使用方法
初期化コールバックの登録解除
WLDataSource
インタフェースには、ConnectionInitializationCallbackの登録を解除するための
unregisterConnectionInitializationCallback()メソッドが用意されています。次の例は、初期化コールバックの削除方法を示しています。
. . . import weblogic.jdbc.extensions.WLDataSource; ((WLDataSource)ds).unregisterConnectionInitializationCallback(); . . .
親トピック: 接続コールバックの使用方法
リプレイのタイムアウトの設定
WebLogic Server管理コンソールで、データ・ソースの「Oracle」タブにあるReplayInitiationTimeout
属性を使用して、データ・ソースでJDBCリプレイ・ドライバの処理に費やす時間を設定できます。この時間が経過すると、接続のリプレイ・セッション・コンテキストがタイムアウトして終了します。
WebLogic HTTPリクエスト・タイムアウトを使用するアプリケーションの場合は、ReplayInitiationTimeout
が適切に設定されていることを確認してください。
-
ReplayInitiationTimeout
の値はHTTPセッション・タイムアウトの値と等しくなるように設定して、HTTPセッション全体がリプレイ・セッションでカバーされるようにする必要があります。デフォルトのReplayInitiationTimeout
とデフォルトのHTTPセッション・タイムアウトは、どちらも3600秒です。
-
HTTPタイムアウト値が
ReplayInitiationTimeout
値よりも長い場合、リプレイ・イベントはHTTPセッション全体には使用できなくなります。 -
HTTPタイムアウト値が
ReplayInitiationTimeout
値よりも短い場合は、アプリケーション側で接続を閉じてリプレイ・セッションを終了する必要があります。
親トピック: JDBCリプレイ・ドライバの構成
接続でのJDBCリプレイ・ドライバの無効化
JDBCリプレイ・ドライバは、次を使用して接続ごとに無効にできます:
. . . if (connection instanceof oracle.jdbc.replay.ReplayableConnection) { ((oracle.jdbc.replay.ReplayableConnection)connection).disableReplay(); } . . .
JDBCリプレイ・ドライバをデータベース・サービス・レベルで無効化するには、サービスのフェイルオーバー・タイプをNONEに変更します。たとえば:
srvctl modify service -d mydb -s myservice -e NONE
ReplayINitializationTimeoutを0に設定するとJDBCリプレイ・ドライバをデータ・ソース・レベルで無効化することもできます。0 (ゼロ)秒に設定すると、リプレイ処理(フェイルオーバー)は無効化されます(beginおよびendRequestは引き続き呼び出されます)。
親トピック: JDBCリプレイ・ドライバの構成
JDBCリプレイ・ドライバのロギングの構成
JDBCリプレイ・ドライバ処理のロギングを有効にするには、次のWebLogicプロパティを使用します:
-Dweblogic.debug.DebugJDBCReplay=true
-Djava.util.logging.config.file=
configfile
を使用して、ログ出力のフォーマットとロギング・レベルを制御します(configfile
は、標準JDKのロギングで使用される構成ファイル・プロパティのパスとファイル名です)。次に、SimplFormatter
を使用する構成ファイルの例を示します。この例では、ロギング・レベルをFINEST
に設定しています:
handlers = java.util.logging.ConsoleHandler java.util.logging.ConsoleHandler.level = ALL java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter #OR - use other formatters like the ones below #java.util.logging.ConsoleHandler.formatter = java.util.logging.XMLFormatter #java.util.logging.ConsoleHandler.formatter = oracle.ucp.util.logging.UCPFormatter #OR - use FileHandler instead of ConsoleHandler #handlers = java.util.logging.FileHandler #java.util.logging.FileHandler.pattern = replay.log #java.util.logging.FileHandler.limit = 3000000000 #java.util.logging.FileHandler.count = 1 #java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter oracle.jdbc.internal.replay.level = FINEST
『Oracle WebLogic ServerにデプロイされたアプリケーションへのWebLogicロギング・サービスの追加』を参照してください。
親トピック: JDBCリプレイ・ドライバの構成
JDBCドライバ・デバッグの有効化
JDBCドライバ・デバッグを有効化するには、Java Util Loggingを構成する必要があります。これを行うには、コマンド行で次のプロパティを設定します。
-Djava.util.logging.config.file=configfile
-Doracle.jdbc.Trace=true
このコマンドで、configfile
は、ログ出力のフォーマットとロギング・レベルを制御するために標準のJDKロギングで使用される構成プロパティ・ファイル・プロパティのパスとファイル名です。
configfile
には、次の行のいずれかが含まれる必要があります。
-
oracle.jdbc.internal.replay.level=FINEST
- リプレイ・デバッグ -
oracle.jdbc.level = FINEST
- 標準JDBCデバッグ
詳細は、Java Platform Standard Edition API仕様のjava.util.loggingを参照してください。
親トピック: JDBCリプレイ・ドライバの構成
JDBCリプレイ・ドライバの実行時統計の表示
JDBCリプレイ・ドライバの統計は、Active GridLinkおよび汎用データ・ソースではJDBCReplayStatisticsRuntimeMBean
を使用して入手できます。
JDBCReplayStatisticsRuntimeMBean
の特徴:
-
Active GridLinkおよび汎用データ・ソースで使用できます。ユニバーサル接続プールおよびマルチ・データ・ソースでは使用できません(nullが返されます)。
-
12.1.0.2以降のOracle Thinドライバとともに実行する場合のみ使用できます。これより前のドライバ・バージョンでは使用できません(NULLが返されます)。
-
データ・ソースがJDBCリプレイ・ドライバを使用するように構成されている場合のみ使用できます。非リプレイ・ドライバでは使用できません(nullが返されます)。
-
初期設定された統計はありません(それらは-1に初期化されます)。MBeanの
refreshStatistics()
操作を呼び出して、取得の前に統計を更新する必要があります。
ノート:
統計のリフレッシュは、負荷の高い操作です。プール全体がロックされ、統計を集計するために予約済および未予約の接続がすべて調査されます。この操作を頻繁に実行すると、データ・ソースのパフォーマンスが影響を受けます。パフォーマンスは、統計をクリアする場合にも影響を受ける可能性があります。表6-1は、JDBCReplayStatisticsRuntimeMBean
を使用してアクセスできる統計を示しています。
表6-1 JDBCReplayStatisticsRuntimeMBeanの実行時統計
名前 | 説明 |
---|---|
|
正常に送信されたリクエストの合計数。 |
|
完了したリクエストの合計数 |
|
実行済JDBCコールの合計数。 |
|
JDBCリプレイ・ドライバで保護された実行済JDBCコールの合計数。 |
|
停止の影響を受けるJDBCコールの合計数。これには、ローカル・コールと、データベース・サーバーへのラウンドトリップを含むコールの両方が含まれます。 |
|
リプレイをトリガーしたJDBCコールの合計数。リプレイは一部のリクエストで無効化されることがあるため、すべてのコールが停止トリガー・リプレイの影響を受けるわけではありません。 |
|
リプレイの実行中に停止の影響を受けるJDBCコールの合計数。停止は、カスケードされ、リプレイの進行中にコールが複数回起動する可能性があります。JDBCリプレイ・ドライバは、最大再試行制限に到達していないかぎり、これが発生するとリプレイを自動的に再試行します。 |
|
成功したリプレイの合計数。リプレイの成功により、停止はアプリケーションから隠蔽されます。 |
|
失敗したリプレイの合計数。 リプレイが失敗すると、元の例外に関連付けられた失敗の理由とともに元の |
|
リプレイが無効化された合計回数。 リクエストの実行中にリプレイが無効化されると、そのリクエストの残りのコールは、JDBCリプレイ・ドライバによって保護されなくなります。停止によって残りのコールの1つが起動されると、リプレイは試行されず、アプリケーションは |
|
リプレイ試行の合計数。JDBCリプレイ・ドライバは、リプレイの失敗時に自動的に再試行するため、この数は、リプレイをトリガーしたJDBCコールの数を超える可能性があります。 |
詳細は、JDBCReplayStatisticsRuntimeMBean (『Oracle WebLogic Server MBeanリファレンス』)およびReplayableConnection.StatisticsReportType (『Oracle JDBC Java APIリファレンス』)を参照してください。
例6-1 WLSTのサンプル
WLSTを使用してランタイムMBeanの統計にアクセスできます。次のサンプルのWLSTスクリプトは、JDBCReplayStatisticsRuntimeMBean
の情報を出力する方法を示しています。
import sys, socket, os
hostname = socket.gethostname()
datasource='JDBC GridLink Data Source-0'
svr='myserver'
connect("weblogic","password","t3://"+hostname+":7001")
serverRuntime()
cd('/JDBCServiceRuntime/' + svr + '/JDBCDataSourceRuntimeMBeans/' +
datasource + '/JDBCReplayStatisticsRuntimeMBean/' +
datasource + '.ReplayStatistics')
cmo.refreshStatistics()
ls()
total=cmo.getTotalRequests()
cmo.clearStatistics()
例6-2 Javaのサンプル
次のJavaの例は、JDBCReplayStatisticsRuntimeMBean
を使用して統計を公開する方法を示しています。
import javax.naming.NamingException;
import javax.management.AttributeNotFoundException;
import javax.management.MBeanServer;
import javax.management.InstanceNotFoundException;
import javax.management.ReflectionException
import javax.management.ObjectName;
import javax.management.MalformedObjectNameException;
import javax.management.MBeanAttributeInfo;
import javax.management.MBeanOperationInfo;
import javax.management.MBeanException;
import javax.management.MBeanParameterInfo;
import weblogic.management.runtime.JDBCReplayStatisticsRuntimeMBean;
public void printReplayStats(String dsName) throws Exception {
MBeanServer server = getMBeanServer();
ObjectName[] dsRTs = getJdbcDataSourceRuntimeMBeans(server);
for (ObjectName dsRT : dsRTs) {
String name = (String) server.getAttribute(dsRT, "Name");
if (name.equals(dsName)) {
ObjectName mb = (ObjectName)server.getAttribute(dsRT,
"JDBCReplayStatisticsRuntimeMBean");
server.invoke(mb, "refreshStatistics", null, null);
MBeanAttributeInfo[] attributes =
server.getMBeanInfo(mb).getAttributes();
for (int i = 0; i < attributes.length; i++) {
if (attributes[i].getType().equals("java.lang.Long")) {
System.out.println(attributes[i].getName()+"="+
(Long) server.getAttribute(mb, attributes[i].getName()));
}
}
}
}
}
MBeanServer getMBeanServer() throws Exception {
InitialContext ctx = new InitialContext();
MBeanServer server = (MBeanServer) ctx.lookup("java:comp/env/jmx/runtime");
return server;
}
ObjectName[] getJdbcDataSourceRuntimeMBeans(MBeanServer server)
throws Exception {
ObjectName service = new ObjectName(
"com.bea:Name=RuntimeService,Type=weblogic.management.mbeanservers.runtime .RuntimeServiceMBean");
ObjectName serverRT = (ObjectName) server.getAttribute(service,
"ServerRuntime");
ObjectName jdbcRT = (ObjectName) server.getAttribute(serverRT,
"JDBCServiceRuntime");
ObjectName[] dsRTs = (ObjectName[]) server.getAttribute(jdbcRT,
"JDBCDataSourceRuntimeMBeans");
return dsRTs;
}
親トピック: JDBCリプレイ・ドライバ
JDBCリプレイ・ドライバの監査
場合によっては、ConnectionInitializationCallback
の実行中、リプレイ時の最初の接続初期化と再初期化の間で、接続操作のリプレイがいつ行われるかをアプリケーションが認識する必要があります。WLConnectionインタフェースの getReplayAttemptCount()
メソッドを使用すると、接続上でリプレイが試行される回数を取得できます。
接続が最初に初期化される際、これは0に設定されます。以降のリプレイで接続が初期化される際には、0より大きい値に設定されます。
ノート:
このカウンタは、リプレイが可能になってから試行され、様々な理由で失敗した(その後接続が有効でなくなった)リプレイの回数のみを示します。非リプレイ・ドライバの場合は、常に0が返されます。例6-3 WLSTのサンプル
接続を初期化するサンプルのコールバック・クラスを次に示します。ここでは、現在の操作またはトランザクションに関係付けられているアプリケーション識別子を取得するためのメカニズムがあることを前提としています。
import java.sql.SQLException;
import java.util.Date;
import java.text.SimpleDateFormat;
import java.util.Properties;
import weblogic.jdbc.extensions.WLConnection;
import oracle.ucp.jdbc.ConnectionInitializationCallback;
public class callback implements ConnectionInitializationCallback {
final String idLabel = "GUUID";
public callback() {
}
public void initialize(java.sql.Connection conn) throws SQLException {
if (((WLConnection)conn).getReplayAttemptCount() == 0) {
// first time - initialize the label value
((WLConnection)conn).applyConnectionLabel(idLabel, Application.getGuuid());
// Get the id from somewhere and store it in the connection label
} else {
Properties props = ((WLConnection)conn).getConnectionLabels();
String value = props.getProperty(idLabel);
System.out.println("Transaction '"+value+"' is getting replayed at " + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(new
Date()));
}
}
}
親トピック: JDBCリプレイ・ドライバ
Oracle 12cデータベースでのJDBCリプレイ・ドライバの制限事項
次の項では、Oracle Databaseリリース12cでJDBCリプレイ・ドライバを使用する場合の制限について説明します:
-
データベース常駐接続プーリングはサポートされていません。Webリクエストはリプレイされません。訂正が発生した場合は、元の
java.sql.SQLRecoverableException
がスローされます。 -
ALTER SESSION SET CONTAINER
を使用したPDBテナント切替えと併用できません。
親トピック: JDBCリプレイ・ドライバ
データベース常駐接続プーリング
データベース常駐接続プーリング(DRCP)により、Oracleデータベースに常駐する複数のWeb層および中間層のデータ・ソースで、データベース・サーバーの処理とセッションをプールできるようになります。
『JDBC開発者ガイド』のデータベース常駐接続プールを参照してください。
要件および考慮事項
次の項では、WebLogicアプリケーションでDRCPを使用する際の要件と考慮事項について説明します:
-
Oracle 12c JDBCドライバとデータベースは必須です。「Oracle 12cデータベースの使用」を参照してください
-
WebLogicの文キャッシュがDRCPとともに構成されている場合、接続が
close()
でプールに返されるたびにそのキャッシュはクリアされます。 -
WebLogic Serverのデータ・ソースは、DRCP接続での接続ラベリングをサポートしていないため、
SQLException
がスローされます。たとえば、WLDataSource
のプロパティにgetConnection
を使用したり、LabelableConnection
のメソッドが呼び出されると、例外が生成されます。ただし、WLDataSource
のregisterConnectionLabelingCallback
およびremoveConnectionLabelingCallback
は許可されています。 -
WebLogic Serverは、システム・プロパティとしての
oracle.jdbc.DRCPConnectionClass
の定義をサポートしていません。これは、接続プロパティとしてデータ・ソース記述子で定義する必要があります。 -
DRCPの効果を高めるには、アプリケーションが処理の完了後にできるだけ早く接続プールに接続を返す必要があります。接続を保持して収集を使用すると、DRCPの使用が無意味になります。
-
DRCPを使用する場合、JDBCプログラムは、接続に対して操作を実行する前にサーバーにアタッチする必要があります。また、他の接続がプールされたセッションを使用できるように、サーバーからデタッチする必要があります。デフォルトでは、JDBCプログラムがサーバーにアタッチしている場合、それは実際にはセッションを予約しませんが、予約を返して次のデータベース・ラウンドトリップまで遅延させます。結果として、後続のデータベース操作は、セッションを予約できないために失敗する可能性があります。これが発生することを避けるため、サーバーへのアタッチ後にデータベースへのラウンドトリップを強制するネットワーク・タイムアウト値があります。これが発生すると、ネットワーク・タイマーは設定解除されます。デフォルトのネットワーク・タイムアウトは、10,000ミリ秒です。これを別の値に設定するには、システム・プロパティ
weblogic.jdbc.attachNetworkTimeout
を設定します。このプロパティは、アタッチの実行とデータベース・ラウンドトリップの返却を待機するタイムアウト(ミリ秒)です。0に設定すると、サーバー・アタッチに関する追加処理は実行されません。
DRCPの構成の詳細は、『Oracle® Database管理者ガイド』のデータベース常駐接続プーリングの構成を参照してください。
親トピック: データベース常駐接続プーリング
DRCPの構成
DRCPに対応するように環境でデータソースおよびデータベースを構成する必要があります。
DRCP対応データ・ソースの構成
DRCPをサポートするようにデータ・ソースを構成するには:
-
新しいデータ・ソースを作成する場合は、データ・ソースの構成ウィザードの追加構成プロパティの下にある「接続プロパティ」タブで、
「oracle.jdbc.DRCPConnectionClass」
フィールドにDRCP接続クラスを入力します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC汎用データ・ソースの作成とJDBC Active GridLinkデータ・ソースの作成を参照してください。結果として、データ・ソースは次のようになります。
-
作成された短縮形のURLに、接尾辞
:POOLED
が追加されます。たとえば:jdbc:oracle:thin:@//host:port/service_name:POOLED
-
サービス形式のURLの場合は、
CONNECT_DATA
要素の(SERVICE_NAME=name)
パラメータの後に(SERVER=POOLED)
が追加されます。 -
DRCP接続クラスの値/名前ペアは、「接続プール」タブに接続プロパティとして表示されます。たとえば:
oracle.jdbc.DRCPConnectionClass=myDRCPclass
。
-
-
管理コンソールで既存のデータ・ソースを編集する場合は、「接続プール」タブを選択して、次の手順を実行します。
-
「URL」を変更して、接尾辞
:POOLED
を含めます。サービスURLの場合は、(SERVER=POOLED)
を含めます。 -
接続のプロパティを更新して、DRCP接続クラスの値/名前ペアを含めます。たとえば:
oracle.jdbc.DRCPConnectionClass=myDRCPclass
。 -
「保存」をクリックします。
-
-
テキスト・エディタまたはWLSTを使用して、データ・ソースを作成または編集する場合は、次の手順を実行します。
-
URL
要素を変更して、接尾辞:POOLED
を含めます。サービスURLの場合は、(SERVER=POOLED)
を含めます。例:<url>jdbc:oracle:thin:@host:port:service:POOLED</url>
-
接続のプロパティを更新して、DRCP接続クラスの値/名前ペアを含めます。たとえば:
<properties> <property> <name>aname</name> <value>avalue</value> </property> <property> <name>oracle.jdbc.DRCPConnectionClass</name> <value>myDRCPclass</value> </property> </properties>
-
-
DataSource
リソース定義にoracle.jdbc.DRCPConnectionClass
接続プロパティまたはPOOLED
URL (両方ではない)が存在する場合、WebLogic Serverによって構成エラーがスローされます。この検証が実行されるのは、コンソールで接続リスナーをテストするとき、システム・ブート中にDataSource
をデプロイするとき、またはDataSource
をターゲット指定するときです。 -
TestConnectionsOnReserve=true
を設定して、MAX_THINK_TIME
による問題を最小化します。「DRCP対応データベースの構成」を参照してください -
TestFrequencySeconds
には、INACTIVITY_TIMEOUT
よりも小さい値を設定します。「DRCP対応データベースの構成」を参照してください
親トピック: DRCPの構成
DRCP対応データベースの構成
DRCPをサポートするようにOracleデータベースを構成するには:
-
DRCPは、次を使用してデータベース側で有効化する必要があります:
SQL> DBMS_CONNECTION_POOL.CONFIGURE_POOL('SYS_DEFAULT_CONNECTION_POOL')
SQL> EXECUTE DBMS_CONNECTION_POOL.START_POOL();
-
次に示すサーバー・プール構成のパラメータは、適切に設定する必要があります。
-
MAXSIZE
: プール内の最大プール・サーバー数。デフォルト値は40です。接続プールでは、プールされたサーバーの5%が認証用に確保され、プールされたサーバーの少なくとも1つは認証用に常時確保されます。このパラメータを設定する場合は、認証と接続の両方に十分なプール・サーバーがあることを確認します。場合によっては、DRCPを使用する最大のWebLogic接続プールのサイズを
MAXSIZE
に設定する必要があります。 -
INACTIVITY_TIMEOUT
: プール内のプール・サーバーがアイドル状態を維持する最大時間(秒単位)。この時間を過ぎると、サーバーは終了される。デフォルト値は300です。サーバー・プールのサイズがMINSIZE
の場合には、このパラメータは適用されません。WebLogicデータ・ソースから確保した接続が使用されていない場合は、非アクティブのタイムアウトが発生して、DRCP接続が解放されます。
INACTIVITY_TIMEOUT
を適切に設定するか、使用されない接続はWebLogicデータ・ソースに返すようにしてください。TestFrequencySeconds
を使用して、未使用の接続がタイムアウトにならないようにすることもできます。 -
MAX_THINK_TIME
: クライアントがプールからプール・サーバーを取得した後で非アクティブ状態でいられる最大時間(秒単位)。クライアント・アプリケーションが、プールからプール・サーバーを取得した後、MAX_THINK_TIME
で指定した時間内にデータベース・コールを発行しない場合、プール・サーバーは解放されてクライアント接続が終了します。デフォルト値は120です。WebLogicデータ・ソースから確保した接続は、
MAX_THINK_TIME
以内にアクティビティがないと、その接続は解放されます。Test Connections On Reserve
を設定するか(「予約済の接続のテスト」を参照)、MAX_THINK_TIME
を適切に設定します。接続テストのオーバーヘッドを最小限に抑えるには、SecondstoTrustanIdlePoolConnection
に、MAX_THINK_TIME
よりも小さい合理的な値を設定します。「データ・ソース接続プールのチューニング」を参照してください
サーバー・プールの構成パラメータが環境で正しく設定されていない場合、WebLogicデータ・ソース接続にアクセスしたときに、データ・ソース接続が終了し、アプリケーションでソケット例外などのエラーを受信する可能性があります。
-
親トピック: DRCPの構成
グローバル・データ・サービス
グローバル・データ・サービス(GDS)により、分散データベース環境でシームレスな集中管理を提供するグローバル・サービスが使用できるようになります。グローバル・サーバーは、複数のRACおよび単一インスタンスのOracleデータベースをData GuardやGoldenGateなどのレプリケーション技術で相互接続して、それら全体でのロード・バランシング、フォルト・トレランスおよびリソース使用率を自動化します。
要件および考慮事項
WebLogic Serverでグローバル・データ・サービスを使用する際には、次の要件と考慮事項に対処してください:
-
Oracle 12c JDBCドライバとデータベースは必須です。「Oracle 12cデータベースの使用」を参照してください
-
単一のSCANアドレスを使用して、複数のグローバル・サービス・マネージャ(GSM)アドレスを置換することはできません。
-
更新操作が適切に処理されるようにするには、プライマリ・データベースでのみ有効になる更新用のサービスを定義する必要があります。
-
プライマリ・データベースとセカンダリ・データベースに配置される読取り専用操作のサービスは個別に定義します。
-
1つのURLに定義できるサービスは1つに限られ、1つのデータ・ソース構成に定義できるURLは1つになるため、一方のデータ・ソースを更新サービス用に定義し、もう一方のデータ・ソースを読取り専用サービス用に定義する必要があります。
-
更新操作が更新データ・ソースで処理され、読取り専用操作が読取り専用データ・ソースで処理されるように、アプリケーションを作成する必要があります。
親トピック: グローバル・データ・サービス
GDS接続対応のActive GridLinkデータ・ソースの作成
WebLogic Server管理コンソールを使用して、グローバル・データ・サービス(GDS)接続を提供するために変更したURLを使用するActive GridLinkデータ・ソースを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC Active GridLinkデータ・ソースの作成を参照してください。
GDS URLの接続情報は、RACクラスタと類似しており、次の基本情報が含まれます:
-
サービス名(グローバル・サービス名)
-
グローバル・サービス・マネージャのアドレス/ポートのペア
-
CONNECT_DATA
パラメータのGDSリージョン
次に、サンプルURLを示します。
jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS_LIST=(LOAD_BALANCE=ON)(FAILOVER=ON) (ADDRESS=(HOST=myHost1.com)(PORT=1111)(PROTOCOL=tcp)) (ADDRESS=(HOST=myHost2.com)(PORT=2222)(PROTOCOL=tcp))) (CONNECT_DATA=(SERVICE_NAME=my.gds.cloud)(REGION=west)))
親トピック: グローバル・データ・サービス
プラガブル・データベースを使用するコンテナ・データベース
コンテナ・データベース(CDB)はOracleデータベース機能の1つであり、多数のデータベースを、単一CDBに含まれる複数のプラガブル・データベース(PDB)を使用して単一データベースに統合することにより、多数のデータベースを持つ場合のオーバーヘッドを最小限に抑えます。
『Oracle Enterprise Managerライフサイクル・マネージメント管理者ガイド』のプラガブル・データベースの管理に関する項を参照してください。
PDBアクセス対応サービスの作成
PDBへのアクセスは、WebLogic Serverデータ・ソースに対して完全に透過的になります。その他のデータベースと同様に、サービスを含むURLを使用してアクセスします。サービスは、PDBに関連付けられている必要があります。これは、SQLPlusで、セッションをPDBに関連付けて、サービスを作成し、そのサービスを開始することで作成できます。
alter session set container = cdb1_pdb1; -- configure service for each PDB execute dbms_service.create_service('replaytest_cdb1_pdb1.regress.rdbms.dev.us.myCompany.com','replaytest_cdb1_pdb1.regress.rdbms.dev.us.myCompany.com'); execute DBMS_SERVICE.START_SERVICE('replaytest_cdb1_pdb1.regress.rdbms.dev.us.myCompany.com');
JDBCリプレイ・ドライバと併用するようにサービスを設定するには、サービスを適切に構成する必要があります。たとえば、SQLPlus:
declare params dbms_service.svc_parameter_array ; begin params('goal') := 'service_time' ; params('commit_outcome') := 'true' ; params('aq_ha_notifications') := 'true' ; params('failover_method') := 'BASIC' ; params('failover_type') := 'TRANSACTION' ; params('failover_retries') := 60 ; params('failover_delay') := 2 ; dbms_service.modify_service('replaytest_cdb1_pdb1.regress.rdbms.dev.us.myCompany.com', params); end; /
親トピック: プラガブル・データベースを使用するコンテナ・データベース
DRCPおよびCDB/PDB
DRCPは、PDBでは使用できません。CDBにのみ関連付ける必要があります。構成する場合は、CDBを指すようにセッションを設定して、DRCPプールを開始します。たとえば:
alter session set container = cdb$root; execute dbms_connection_pool.configure_pool('SYS_DEFAULT_CONNECTION_POOL'); execute dbms_connection_pool.start_pool();
親トピック: プラガブル・データベースを使用するコンテナ・データベース
JDBCを使用したPDBの設定
初めてプールの接続を作成するときには、CDB内の特定のPDBに関連付けられたサービスを含むURLを使用して接続を作成します。同じCDB内では、動的なPDBの変更が可能です。PDBを変更するには、次のSQL文を実行します。
ALTER SESSION SET CONTAINER = name SET SERVICE servicename;
SET SERVICE servicename
を指定すると、アプリケーションによって明示的なサービスが構成され、名前が付けられます。これによって、ロード・バランシング・アドバイザリ、セッション・アフィニティ、高速アプリケーション通知、JDBCリプレイ・ドライバおよびプロキシ認証のサポートが可能になります。これらの機能は、SET SERVICE servicename句なしでは使用できません。
コンテナの変更後は、次の項目が変更できなくなります。
-
RACインスタンス
-
接続オブジェクト
-
WebLogicの接続ライフサイクル(
enabled
/disabled
/destroyed
) -
WebLogicの接続属性。
それ以外の接続に関する状態は、PDB間での情報の漏洩を防止するためにクリアされます。
構成後には、次の項目がリセットされます。
-
JDBCリプレイ・ドライバ
-
DRCP
-
クライアント識別子
-
プロキシ・ユーザー
-
接続収集コールバック
ノート:
DRCPは、PDB切替えではサポートされていません親トピック: プラガブル・データベースを使用するコンテナ・データベース
サービスの切替え
サービス切替えの制限について学習します。
WebLogic Serverによるサービスの切替えの制限事項は次のとおりです。
- サービスの切替えは、サービスが提供される場所に影響を与えません。
- サービスの切替えは、そのインスタンスでサービスが公開されている場合にのみ許可されます。
- サービスの切替えは、リクエストの境界でのみ許可されます。これは、JDBCリプレイ・ドライバが正しく動作するために必要です。
- サービスの切替えは、最上位のコールで(ユーザー・コールがアクティブでないとき)のみ許可されます。
- サービス切替えは、データベース常駐接続プーリングではサポートされていません。
- オープン・トランザクション、ローカルまたはXAが存在する場合、サービス切替えによってエラーが返されます。
- 切替えで設定されたサービス属性は、以前の使用から引き継がれることはありません。アプリケーションはセッションを適切に設定する必要があります。
- サービスの切替えは、CDB環境と同様に非CDB環境でもサポートされます。非CDB環境では、コンテナは変更できません。
- 以前のバージョンと同様に、切替えの間にサービス名は変更される可能性がありますが、インスタンス名は変更されません。
- XAアフィニティは、
service_name
、database_name
、instance_name triple
の3つに基づいています。サービスが変更されるとき、XAアフィニティは強制されません。
ノート:
汎用、Active GridLinkおよびユニバーサル接続プール・データ・ソースには制限があります。Fast Application Notificationおよび高速接続フェイルオーバー(FCF)はサービス・ベースです。データ・ソースが作成されると、構成されているサービス名に対してサブスクリプションが設定されます。データ・ソースは、インスタンスとサービスの起動および停止のイベントを受信します。アプリケーションがサービスを切り替えると、新しいサービス名に対するサービスの起動および停止のイベントは受信されなくなります。段階的排出およびスケジュールされたメンテナンスは、インスタンスが停止される前に接続を排出できるようにサービスを停止することに基づいているため、スケジュールされたメンテナンス(計画済停止)はアプリケーション・サービスの切替えでは機能しません。インスタンスが停止すると、停止イベントが処理され、接続がクローズされます。WebLogic Serverの共有プールでは、複数のサブスクリプションと、その結果として生じる高速アプリケーション通知サービスのイベントが適切に管理されます。親トピック: Oracleドライバおよびデータベースの詳細な構成