この章には次の項が含まれます:
現在の環境では、基盤になるソフトウェア・レイヤー、ハードウェア・レイヤー、通信レイヤーおよび記憶域レイヤーの停止について、アプリケーション開発者が明確に対処する必要があります。そのため、アプリケーション開発は複雑化し、機能停止はユーザーに対して表面化します。たとえば、ユーザーに対して送信ボタンを2回クリックしないように警告するアプリケーションがあります。その警告を見落としたユーザーは、意図しないうちに商品を2回購入したり、同じ請求書に対して複数回の支払を実行してしまうことがあります。
アプリケーション・コンティニュイティ(リプレイとも呼ばれる)は、GridLinkデータ・ソースと汎用データ・ソースに対応するアプリケーションに依存しない汎用のインフラストラクチャであり、アプリケーション側からの作業の回復を可能にし、多くのシステム障害、通信障害およびハードウェア障害をマスクします。つまり、エンド・ユーザーのトランザクションは、時差なしに1回で実行されるようになります。エンド・ユーザーがサービスの中断を認識するとしても、継続しても意味のない機能停止の場合に限られます。
次に示す各項では、アプリケーション・コンティニュイティの構成方法と使用方法について説明します。
計画済停止か計画外停止かにかかわらず、次に示すデータベース・サービスの損失による停止については、アプリケーション・コンティニュイティによりデータベース・セッションが再構築されます。高速アプリケーション通知またはリカバリ可能なORACLE
エラーで停止が識別されると、Oracleドライバは次のように動作します。
新しいデータベース・セッションを確立して、未処理の状態を解消します。
コールバックが登録されている場合は、コールバックを発行して、そのセッションの初期状態をアプリケーションが再確立できるようにします。
リクエスト中に累積した保存済の履歴を実行します。
Oracleドライバは、リプレイ・コールのタイミングを判断します。コールは、アプリケーションがデータベースの状態を変更する方法に応じて経時的に処理されるか、遅延処理の実装を使用して処理されます。リプレイは、Oracle 12c Database Serverで制御されます。リプレイが承認されるようにするには、リプレイされるコールごとに、元のコールの実行中にアプリケーションで表示されていて潜在的に使用されていたクライアントの表示状態とまったく同じ状態を返す必要があります。
次の項では、WebLogicアプリケーションでアプリケーション・コンティニュイティを使用する際の要件と考慮事項について説明します。
Oracle 12c JDBCドライバとデータベースは必須です。「Oracle 12cデータベースの使用」を参照してください
アプリケーション・コンティニュイティは、読取りトランザクションと読取り/書込みトランザクションをサポートします。XAトランザクションは、サポートされていません。アプリケーション・コンティニュイティ対応のOracleドライバなど、非XAドライバを使用するトランザクションをサポートする場合は、Oracle WebLogic Server JDBCデータ・ソースの管理の非XA JDBCドライバによるグローバル・トランザクションの有効化を参照してください。
注意:
アプリケーションでconnection.setAutoCommit(false)
をコールして、トランザクション・セマンティクスの分断化と環境でのアプリケーション・コンティニュイティの無効化を防止してください。
非推奨のoracle.sql.*
具体クラスはサポートされていません。該当部分は、それに対応するoracle.jdbc.*
インタフェースまたはjava.sql.*
インタフェースのどちらかを使用するように変更する必要があります。標準のjava.sql.*
インタフェースの使用をお薦めします。Oracle WebLogic Server JDBCアプリケーションの開発のOracle JDBCタイプのAPI拡張機能の使用方法を参照してください。
アプリケーション・コンティニュイティは、中間結果をメモリーに格納することで動作します。アプリケーションは、この機能なしで実行するよりも実行速度が遅くなり、より大量のメモリーが必要になります。
アプリケーション・コンティニュイティ機能には、追加の制限事項と例外事項があります。これらは、アプリケーションがリプレイを使用できるかどうかに影響することがあります。詳細は、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ドライバを使用するようにデータ・ソースを構成するには、次のいずれかの方法を使用します。
新しいデータ・ソースを作成する場合は、構成ウィザードのドロップダウン・メニューからデータベース・ドライバを選択するように求められたときに、対象の環境でアプリケーション・コンティニュイティをサポートする適切なOracleドライバを選択します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアプリケーション・コンティニュイティの有効化を参照してください。
管理コンソールで既存のデータ・ソースを編集する場合は、「接続プール」タブを選択して、「ドライバ・クラス名」をoracle.jdbc.replay.OracleDataSourceImpl
に変更してから、「保存」をクリックします。
テキスト・エディタまたはWLSTでデータ・ソースを作成または編集する場合は、JDBCドライバをoracle.jdbc.replay.OracleDataSourceImpl
に設定します。
「要件および考慮事項」を参照してください
次の各項では、接続コールバックの使用方法について説明します。
接続初期化コールバックを作成する場合は、アプリケーションに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管理コンソール・オンライン・ヘルプのアプリケーション・コンティニュイティの有効化を参照してください。
WLDataSource
インタフェースには、ConnectionInitializationCallback
の登録を解除するためのunregisterConnectionInitializationCallback()
メソッドが用意されています。次の例は、初期化コールバックの削除方法を示しています。
. . . import weblogic.jdbc.extensions.WLDataSource; ((WLDataSource)ds).unregisterConnectionInitializationCallback(); . . .
WebLogic Server管理コンソールで、データ・ソースの「Oracle」タブにあるReplayInitiationTimeout
属性を使用すると、接続のリプレイ・セッション・コンテキストをタイムアウトにして終了するまでに、データ・ソースでアプリケーション・コンティニュイティのリプレイ処理に許容する時間を設定できます。
WebLogic HTTPリクエスト・タイムアウトを使用するアプリケーションの場合は、ReplayInitiationTimeout
が適切に設定されていることを確認してください。
ReplayInitiationTimeout
の値はHTTPセッション・タイムアウトの値と等しくなるように設定して、HTTPセッション全体がリプレイ・セッションでカバーされるようにする必要があります。デフォルトのReplayInitiationTimeout
とデフォルトのHTTPセッション・タイムアウトは、どちらも3600秒です。
HTTPタイムアウト値がReplayInitiationTimeout
値よりも長い場合、リプレイ・イベントはHTTPセッション全体には使用できなくなります。
HTTPタイムアウト値がReplayInitiationTimeout
値よりも短い場合は、アプリケーション側で接続を閉じてリプレイ・セッションを終了する必要があります。
アプリケーション・コンティニュイティは、次のコードを使用することで、接続単位で無効化できます。
. . . if (connection instanceof oracle.jdbc.replay.ReplayableConnection) { ((oracle.jdbc.replay.ReplayableConnection)connection).disableReplay(); } . . .
アプリケーション・コンティニュイティをデータベース・サービス・レベルで無効化するには、サービスのフェイルオーバー・タイプをNONEに変更します。次に例を示します。
srvctl modify service -d mydb -s myservice -e NONE
アプリケーション・コンティニュイティをデータ・ソース・レベルで無効化するには、ReplayINitializationTimeoutを0に設定します。0 (ゼロ)秒に設定すると、リプレイ処理(フェイルオーバー)は無効化されます(beginおよびendRequestは引き続き呼び出されます)。
アプリケーション・コンティニュイティ処理のロギングを有効化するには、次の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ドライバ・デバッグを有効化するには、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 7 API仕様のjava.util.loggingを参照してください。
ここでは、アプリケーション・コンティニュイティの実行時統計について説明します。
アプリケーション・コンティニュイティ(またはリプレイ)の統計は、汎用データ・ソースおよびActive GridLinkデータ・ソースのJDBCReplayStatisticsRuntimeMBeanを通じて使用できます。
JDBCReplayStatisticsRuntimeMBean
の特徴:
汎用データ・ソースおよびActive GridLinkデータ・ソースで使用できます。マルチ・データ・ソース(MDS)、プロキシ・データ・ソースおよびUCPデータ・ソースでは使用できません(NULLが返されます)。
12.1.0.2以降のOracle Thinドライバとともに実行する場合のみ使用できます。これより前のドライバ・バージョンでは使用できません(NULLが返されます)。
データ・ソースがリプレイ・ドライバを使用するように構成されている場合のみ使用できます。非リプレイ・ドライバ(OracleドライバやXAドライバなど)では使用できません(NULLが返されます)。
初期設定された統計はありません(それらは-1に初期化されます)。MBeanのrefreshStatistics()
操作を呼び出して、取得の前に統計を更新する必要があります。
注意:
統計のリフレッシュは、負荷の高い操作です。プール全体がロックされ、統計を集計するために予約済および未予約の接続がすべて調査されます。この操作を頻繁に実行すると、データ・ソースのパフォーマンスが影響を受けます。パフォーマンスは、統計をクリアする場合にも影響を受ける可能性があります。表10-1は、JDBCReplayStatisticsRuntimeMBeanを使用してアクセスできる統計を示しています。
表10-1 JDBCReplayStatisticsRuntimeMBeanの実行時統計
名前 | 説明 |
---|---|
TotalRequests |
正常に送信されたリクエストの合計数。 |
TotalCompletedRequests |
完了したリクエストの合計数 |
TotalCalls |
実行済JDBCコールの合計数。 |
TotalProtectedCalls |
アプリケーション・コンティニュイティで保護された実行済JDBCコールの合計数。 |
TotalCallsAffectedByOutages |
停止の影響を受けるJDBCコールの合計数。これには、ローカル・コールと、データベース・サーバーへのラウンドトリップを含むコールの両方が含まれます。 |
TotalCallsTriggeringReplay |
リプレイをトリガーしたJDBCコールの合計数。リプレイは一部のリクエストで無効化されることがあるため、すべてのコールが停止トリガー・リプレイの影響を受けるわけではありません。 |
TotalCallsAffectedByOutagesDuringReplay |
リプレイの実行中に停止の影響を受けるJDBCコールの合計数。停止は、カスケードされ、リプレイの進行中にコールが複数回起動する可能性があります。アプリケーション・コンティニュイティは、最大再試行制限に到達していないかぎり、これが発生するとリプレイを自動的に再試行します。 |
SuccessfulReplayCount |
成功したリプレイの合計数。リプレイの成功により、停止はアプリケーションから隠蔽されます。 |
FailedReplayCount |
失敗したリプレイの合計数。 リプレイが失敗すると、元の例外に関連付けられた失敗の理由とともに、アプリケーションに元のSQLRecoverableExceptionが再スローされます。アプリケーションは、理由を取得するためにgetNextExceptionを呼び出すことができます。 |
ReplayDisablingCount |
リプレイが無効化された合計回数。 リクエストの実行中にリプレイが無効化されると、そのリクエストの残りのコールは、アプリケーション・コンティニュイティによって保護されなくなります。停止によって残りのコールのいずれかが起動すると、リプレイは試行されず、アプリケーションはSQLRecoverableExceptionを受け取ります。 |
TotalReplayAttempts |
リプレイ試行の合計数。アプリケーション・コンティニュイティは、リプレイの失敗時に自動的に再試行するため、この数は、リプレイをトリガーしたJDBCコールの数を超える可能性があります。 |
Oracle WebLogic Server MBeanリファレンスのJDBCReplayStatisticsRuntimeMBeanに関する項
Oracle JDBC Java APIリファレンスのReplayableConnection.StatisticsReportType
例10-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()
例10-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; }
ConnectionInitializationCallbackの実行中、最初の接続初期化とリプレイ中の再初期化の間に、接続操作のリプレイがいつ行われるかをアプリケーションが知っていることが必要になる場合があります。WLConnectionインタフェースのgetReplayAttemptCount()メソッドを使用して、接続上でリプレイが試行される回数を取得することができます。
接続が最初に初期化される際、これは0に設定されます。以降のリプレイで接続が初期化される際には、0より大きい値に設定されます。
注意:
このカウンタは、リプレイが可能になってから試行され、様々な理由で失敗した(その後接続が有効でなくなった)リプレイの回数のみを示します。非リプレイ・ドライバの場合は、常に0が返されます。例10-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())); } } }
データベース常駐接続プーリング(DRCP)により、Oracleデータベースに常駐する複数のWeb層および中間層のデータ・ソースで、データベース・サーバーの処理とセッションをプールできるようになります。Database Resident Connection Pooling (DRCP)を参照してください(http://www.oracle.com/technetwork/articles/oracledrcp11g-1-133381.pdf
)。
次の各項では、WebLogic ServerでのDRCPの使用と構成について説明します。
次の項では、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をサポートするようにデータ・ソースを構成するには:
新しいデータ・ソースを作成する場合は、データ・ソースの構成ウィザードの追加構成プロパティの下にある「接続プロパティ」タブで、「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>
データソース定義に、oracle.jdbc.DRCPConnectionClass
接続プロパティまたはPOOLED
URLのどちらか一方のみが含まれている場合、WebLogic Serverは構成エラーをスローします。この検証は、コンソールで接続リスナーをテストするとき、システム・ブート中にデータソースをデプロイするとき、またはデータソースをターゲット指定するときに実行されます。
TestConnectionsOnReserve=true
を設定して、MAX_THINK_TIME
による問題を最小化します。「DRCP対応データベースの構成」を参照してください
TestFrequencySeconds
には、INACTIVITY_TIMEOUT
よりも小さい値を設定します。「DRCP対応データベースの構成」を参照してください
DRCPをサポートするようにOracleデータベースを構成するには:
DRCPは、データベース側で有効化する必要があります。DRCPの有効化には、次のコマンドを使用します。
SQL> DBMS_CONNECTION_POOL.CONFIGURE_POOL('SYS_DEFAULT_CONNECTION_POOL')
SQL> EXECUTE DBMS_CONNECTION_POOL.START_POOL();
次に示すサーバー・プール構成のパラメータは、適切に設定する必要があります。
MAXSIZE
: プール内の最大プール・サーバー数。デフォルト値は40です。接続プールでは、プールされたサーバーの5%が認証用に確保され、プールされたサーバーの少なくとも1つは認証用に常時確保されます。このパラメータを設定する場合は、認証と接続の両方に十分なプール・サーバーがあることを確認します。
MAXSIZE
には、DRCPを使用する最大のWebLogic接続プールのサイズを設定してください。
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データソース接続にアクセスするときに、ソケット例外などのエラーを受け取る可能性があります。
Global Data Services (GDS)により、分散データベース環境でシームレスな集中管理を提供するグローバル・サービスが使用できるようになります。グローバル・サーバーは、複数のRACおよび単一インスタンスのOracleデータベースをData GuardやGoldenGateなどのレプリケーション技術で相互接続して、それら全体でのロード・バランシング、フォルト・トレランスおよびリソース使用率を自動化します。
次の各項では、WebLogic ServerのGDSに対する要件と構成について説明します。
次の項では、WebLogic ServerでGlobal Database Servicesを使用する際の要件と考慮事項について説明します。
Oracle 12c JDBCドライバとデータベースは必須です。「Oracle 12cデータベースの使用」を参照してください
単一のSCANアドレスを使用して、複数のGlobal Service Manger (GSM)アドレスを置換することはできません。
更新操作が適切に処理されるようにするには、プライマリ・データベースでのみ有効になる更新用のサービスを定義する必要があります。
プライマリ・データベースとセカンダリ・データベースに配置される読取り専用操作のサービスは個別に定義してください。
1つのURLに定義できるサービスは1つに限られ、1つのデータソース構成に定義できるURLは1つになるため、一方のデータソースを更新サービス用に定義し、もう一方のデータソースを読取り専用サービス用に定義する必要があります。
更新操作が更新データソースで処理され、読取り専用操作が読取り専用データソースで処理されるように、アプリケーションを作成する必要があります。
WebLogic Server管理コンソールを使用して、GridLinkデータ・ソースを作成します。このデータ・ソースでは、GDS接続を提供するように変更したURLを使用します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC Active GridLinkデータ・ソースの作成を参照してください。
GDS URLの接続情報は、RACクラスタの接続情報と類似しています。これには、次の基本情報が含まれています。
サービス名(グローバル・サービス名)
Global Service Managerのアドレス/ポートのペア
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 Database管理者ガイド』のOracleプラガブル・データベースの管理に関する項を参照してください。
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');
アプリケーション・コンティニュイティと併用するようにサービスを設定するには、サービスを適切に構成する必要があります。次に、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は、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();
初めてプールの接続を作成するときには、CDB内の特定のPDBに関連付けられたサービスを含むURLを使用して接続を作成します。同じCDB内では、動的なPDBの変更が可能です。PDBを変更するには、次のSQL文を実行します。
ALTER SESSION SET CONTAINER = name;
コンテナの変更後は、次の項目が変更できなくなります。
RACインスタンス
接続オブジェクト
WebLogicの接続ライフサイクル(enabled
/disabled
/destroyed
)
WebLogicの接続属性。
それ以外の接続に関する状態は、PDB間での情報の漏洩を防止するために消去されます。
構成後には、次の項目がリセットされます。
アプリケーション・コンティニュイティ(リプレイ)
DRCP
client identifier
プロキシ・ユーザー
接続収集コールバック。
ALTER SESSION SET CONTAINER
を使用してテナント間で切替えを行う場合、新しいPDBでどのユーザー・サービスに切り替えるかを示すメカニズムが現在ありません。かわりに、そのテナントのPDBサービスが使用されます。PDBサービスは、各PDB用に作成される管理サービスです(したがって、各PDBには少なくとも1つの管理サービスがあります)。これは管理サービスであり、ユーザー・レベルのサービス機能はサポートされていません。将来のデータベース・リリースでは、ユーザー・サービスを許可することによって、こうした制限は削除される予定です。
データベース・リリース12.1でテナントの切替えを使用する場合、WebLogic Serverには他にも次の制限事項があります。
XAトランザクションおよびグローバル・トランザクションはサポートされません。
FANはサポートされません。FANはサポートされませんが、ただしActive GridLinkにより、複数のRACインスタンスの単一のデータソース・ビューという利点が得られ、また接続ロード・バランシングを使用して再構成を行うことなく接続が利用可能なため、新しいインスタンスで接続を予約する機能が得られます。メトリックがサポートされないため、この接続ロード・バランシングはセッションの数だけに基づいています。Active GridLinkデータ・ソースによるテナントの切替えを使用する場合は、「FANの有効化」
をfalse
に設定する必要があります。ランタイム・ロード・バランシングは、既存の接続を最適に予約するためには(ローカルでもグローバル・データ・サービスでも)使用できません。かわりに、接続の割当てにはラウンドロビンを使用します。これは、ランタイム・ロード・バランシングの情報が利用不可であるため接続グラビティションがサポートされていないことも意味します。セッション・アフィニティはサポートされません。(自動ONSを含めて) ONSはサポートされず、このことは、Global Data ServicesやActive Data Guardのような機能にも影響を与えます。WebLogicでは、インスタンスが停止しているかどうかを確認するために、DOWNイベントを受信するかわりに接続テストが使用されます。これがAGLにとって意味することの詳細は、FAN通知を使用しないActive GridLinkデータ・ソースの使用を参照してください。トランザクション・アフィニティはFANに基づいていないため影響を受けません。汎用データ・ソースには(FANを使用しないため)この制限は適用されません。
DRCPはサポートされません。接続が、データベースに存在するリクエストしたテナントと一致しない接続プールから選択された場合は、エラーが発生します(サービスの切替えはDRCPでサポートされていません)。WebLogic Serverは接続を選択する際にテナントとの一致を行わないため、有効な接続が選択されている保証はありません。
アプリケーション・コンティニュイティはサポートされません。必要な属性(FAILOVER_TYPE=TRANSACTION
およびCOMMIT_OUTCOME=true
)をPDBサービスで設定できません。
プロキシ認証はサポートされていません。java.sql.SQLException "ORA-01017: invalid username/password"
がスローされます。
サービスに基づく多くのデータベース機能(サービスに基づく管理操作、サービスベースのメトリック、Enterprise Managerのトップ・コンシューマ、データベース・サービスベースのアラート、ユーザー・サービスへのパラレル問合せの制限など)が使用できません。