| Oracle® Fusion Middleware WebLogic永続ストアの管理 12c (12.2.1) E72544-01 |
|
 前 |
 次 |
この章では、WebLogic Server永続ストアを構成およびモニターする方法について説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。
次の項では、JDBC対応ストアを構成および使用する方法について説明します。
JDBC TLogストア: トランザクション・ログ(TLOGs)をデータベースに保持します。「JDBC TLogストアの使用」を参照してください。
JDBCストア: WebLogic Serverインスタンス・サービスとサブシステム情報をデータベースに保持します(ただし、TLOGは除きます)。「JDBCストアの使用」を参照してください。
JDBC TLOGストアを構成すると、トランザクション・ログをデータベースに保持できます。これには次の利点があります。
基本データベースのレプリケーションとHA特性を活用できます。
データベースの状態とTLOGを簡単に同期できるため、災害からのリカバリを簡素化できます。
実行するトランザクション・ログを新しい場所に移行(コピー)する必要がないため、トランザクション・リカバリ・サービスの移行が向上します。
JDBC TLOGストアを作成するための主な手順は次のとおりです。
JDBCストアへのインタフェースとなるJDBCデータ・ソース、GridLinkデータ・ソースまたはマルチ・データ・ソースを作成します。「データ・ソースの選択」を参照してください。
JDBC TLOGストアを作成し、これを手順1で作成したJDBCデータ・ソース、GridLinkデータ・ソースまたはマルチ・データ・ソースに関連付けます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・ログ・ストアの構成に関する項を参照してください。
オプション。接頭辞オプションに、構成するJDBC TLOGストア表ごとに1つの一意の値を構成することを強くお薦めします。
高可用性のため、データ・ソースをバックアップ・サーバーで利用できるようにします。第6章「JDBC TLOGストア使用時のサーバー移行」を参照してください。
ご使用のWebLogic Serverライセンスとアプリケーションのニーズに応じて、次のデータ・ソース・タイプのいずれかを選択できます。
汎用データ・ソース - 『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの作成に関する項およびOracle RACでの接続時間フェイルオーバーの使用に関する項を参照してください。
GridLinkデータ・ソース - 『Oracle WebLogic Server JDBCデータ・ソースの管理』のGridLinkデータ・ソースの使用に関する項を参照してください。
マルチ・データ・ソース - 完全にレプリケーションされたゼロ・レイテンシ・データベース(Oracle RACなど)によってバックアップされます。『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCマルチ・データ・ソースの作成に関する項およびOracle RACでのマルチ・データ・ソースの使用に関する項を参照してください。
ドメインの構成ファイルでのJDBC TLOGストアの定義例を示します。この例では、JDBCデータ・ソースMyDataSourceを使用しており、論理名が指定されています。
<server>
<transaction-log-jdbc-store>
<data-source>MyDataSource</data-source>
<prefix-name>TLOG_MS1</prefix-name>
<create-table-ddl-file>myDDL/myCreateTable.sql</create-table-ddl-file>
<max-retry-seconds-before-tlog-fail>120</max-retry-seconds-before-tlog-fail>
</transaction-log-jdbc-store>
</server>
表6-1に、JDBC TLOGストアの変更可能な構成パラメータを示します。
表6-1 JDBC TLOGストアの構成オプション
| オプション | 必須 | 機能 |
|---|---|---|
|
○ |
ストアのデータベース表( 注意: JDBCストアでは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があり、「グローバル・トランザクションのサポート」が無効になっている必要があります。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。 |
|
|
× |
通常、JDBCストアの表の接頭辞は 複数のJDBCストアを使用する場合は、構成するJDBCストアごとに1つの一意の接頭辞を設定する必要があります。接頭辞を指定しないと、JDBCストアの表名は単に 既存のJDBCストアの接頭辞を変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。 |
|
|
× |
JDBCストアのデータベース表( |
|
|
デフォルトは20です。 |
データベースを呼び出すごとに削除される最大表行数。 |
|
|
バッチごとに挿入(最大) |
デフォルトは20です。 |
データベースを呼び出すごとに挿入される最大表行数。 |
|
デフォルトは20です。 |
データベースを呼び出すごとに削除される最大表行数。 |
|
|
デフォルトは300です。 |
WebLogic ServerがJDBC TLogストア障害からのリカバリを試行する最大時間(秒単位)。この期間後でもストアを使用できない場合は、WebLogic Serverによって正常性状態がHEALTH_FAILEDに設定されます。値が0の場合は、WebLogic Serverによって再試行は実行されず、ただちに正常性状態がHEALTH_FAILEDに設定されます。 |
|
|
デフォルトは60です。 |
トランザクションの処理中にWebLogic ServerがJDBC TLogストア障害からのリカバリを試行するまでの最大待機時間(秒単位)。この期間後でもストアを使用できない場合は、影響を受けるトランザクションはWebLogic Serverによってロールバックされます。値が0の場合は、WebLogic Serverによって再試行は実行されず、ただちにトランザクションはロールバックされます。実際の最大値は、 |
|
|
デフォルトは5です。 |
ストア障害発生後に、WebLogic ServerがTLOGストアの正常性を検証する試行を実行するまでの最大待機時間(秒単位)。 |
WebLogic Server管理コンソールを使用してJDBC TLOGストアを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・ログ・ストアの構成に関する項を参照してください。
次の項では、JDBC TLOGストアの構成に関するガイドラインを示します。
JDBC TLOGストアをターゲットにできるのは、グローバル・スコープ(アプリケーション・スコープではありません)のデータ・ソースのみです。
1台のWebLogic Serverごとに構成できるJDBC TLOGストアの数は1つのみです。逆に、複数のWebLogic Serverで1つのJDBC TLOGストアを共有できません。
JDBC TLOGストアを構成する必要があります。デフォルトでは、TLOG情報をサーバーのデフォルト永続ストアに保持するよう設定されています。
XA JDBCドライバを使用するよう構成されたデータ・ソースや、グローバル・トランザクションをサポートするよう構成されたデータ・ソースは使用できません。非XAデータ・ソースを使用します。
JDBC対応ストアに関する一般ルールについては、「JDBCストアの構成のガイドライン」を参照してください。
次の項では、JDBC TLOGストアの動作と制約に関する追加の考慮事項について説明します。
TLOG情報の保存に使用されるデータベースは、サーバー起動時に使用可能な状態である必要があります。データベースが使用できない場合は、WebLogic Serverインスタンスの起動が失敗します。
JDBC TLOGストアを使用し、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を保持できるのは、JTAサブシステムのみです。それ以外のシステムはJDBC TLOGストアにアクセスできません。
JDBC TLOGストアを使用してもLLR動作は変更されません。JDBC TLOGストアはLLRの有無に関係なく使用できます。LLRトランザクションと連動して使用すると、情報をコミットするトランザクションはLLR表に保存されますが、チェックポイント・レコードとヒューリスティック・ログはJDBC TLOGストアに保存されます。
TLOGストアのタイプが別のタイプに変更されたり、場所が別の場所に変更される場合、変更内容は再起動後にのみ有効となり、古いストア内に保留中のすべてのトランザクションは新しいストアにコピーされません。TLOGストアのストア・タイプまたは場所を変更する前に、保留中のトランザクションがないことを確認する必要があります。
JDBC TLOGストアが使用できない場合、JTAの正常性状態はFAILEDに遷移し、あらゆるグローバル・トランザクションは失敗します。同様に、サーバーのライフサイクルもFAILEDに変更されます。JTAトランザクション・リカバリ・システムは、可能な場合は一時的なランタイム・エラーからの復旧を試行し、インダウト・トランザクションを解決します。「JDBC TLOGストア使用時のサーバー移行」を参照してください。
TLOGの保存に使用されるデータベースが破損しているため復旧できない場合、保留中のトランザクション情報はすべて失われます。
JDBC TLOGストアによって使用されるデータベースの表または行がなんらかの理由でデータベース内でロックされている場合、データベース管理者が手動でこのロック状態を解除する必要があります。これを行わないと、JTAサブシステムはブロックされ、ロックを解除するまで一時停止状態となります。また、ロックによる例外が発生します。JTAサブシステムは、ロックを解除するか、またはMaxRetrySecondsBeforeTLOGFailの値が超過するまで、正常に実行されません。
|
注意: ロックされたローカル・トランザクションに関する機能は、データベースの種類によって異なります。一部のデータベースでは、データベースのロック状態をただちに解決することが難しい場合があります。アプリケーション環境で基本的な行ロックの問題が発生する場合は、詳細情報についてデータベース管理者に連絡する必要があります。 |
WebLogic Serverでは、JDBC TLOGストアの使用時にトランザクション・リカバリ・サービスの移行について、手動および自動の両方で実行する機能をサポートしています。JDBC TLOGストアによって使用されるデータ・ストアは、プライマリ・サーバー・インスタンスとバックアップ・サーバー・インスタンスの両方でターゲットにする必要があります。クラスタ内のすべてのサーバー・インスタンスをデータ・ソースのターゲットに指定することをお薦めします。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のサーバーで障害が発生した場合のトランザクション・リカバリに関する項を参照してください。
トランザクション・ログ・ストアの統計および開かれている各ストア接続の統計情報をモニターできます。永続ストアをモニターする方法の詳細は、「WebLogic永続ストアのモニター」を参照してください。
WebLogic ServerでJDBC TLOGストアを使用するように構成すると、次の形式の名前を使用して重要ではないサブシステムとしてストアは正常性管理システムに登録されます。
PersistentStore.TLOG_servername
ここで、servernameは、プライマリTLOGストアをホストしているWebLogic Server インスタンスの名前を示します。
WebLogic Server管理コンソールでJDBC TLOGストアのヘルス状態を監視できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーのヘルス監視に関する項を参照してください。
WebLogic Server管理コンソールでトランザクション・ログ・ストア統計情報を監視できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーのトランザクション・ログ統計情報の表示に関する項を参照してください。
WebLogic Server管理コンソールでトランザクション・ログ・ストア接続統計情報を監視できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのTLOGストア接続の統計情報の表示に関する項を参照してください。
JDBC TLOGストア表をはじめ、アプリケーション環境は適切に保護します。これを怠ると、次の現象が発生する可能性があります。
悪意を持って、あるいは意図せずに情報を削除します。このような削除によって、トランザクション情報が損失し、影響を受けるグローバル・トランザクションがヒューリスティックに完了されます。
悪意を持って、あるいは意図せずに情報を改変します。このような改変によって、予期しない動作が発生する可能性があります。
トランザクションの開始時や関与するリソース情報などの機密トランザクション情報を読み取ります。
データベース・インスタンスやデータベース・マシンにアクセスします。
JTAとデータベース間のネットワークにアクセスし、データの妨害、閲覧、または改変などが行われる可能性があります。
第7章「ファイル・ストア・データの保護」を参照してください。
次の項では、JDBCストアの例を示し、既存のDDL、カスタムDDLを使用したJDBCストア用のデータベースの作成について説明します。DDLファイルでOracle blobレコード列を使用にする方法について説明します。
デフォルトのJDBCStoreMBeanパラメータを直接変更してJDBCストアを作成できます。WebLogic Server管理コンソールを使用してJDBCストアを作成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項を参照してください。
JDBCストアで接頭辞を使用する場合の構成ガイドライン、およびJDBCデータ・ソースの推奨設定については、「JDBCストアの構成のガイドライン」を参照してください。
JDBCストアを作成するための主な手順は次のとおりです。
JDBCストアへのインタフェースとなるJDBCデータ・ソースまたはマルチ・データ・ソースを作成します。
JDBCストアを作成し、これをJDBCデータ・ソースまたはマルチ・データ・ソースに関連付けます。
接頭辞オプションに、構成するJDBCストア表ごとに1つの一意の値を構成することを強くお薦めします。
JDBCストアを使用するサブシステムに、JDBCストアを関連付けます。
JMSサーバーの場合は、「構成:全般」ページでJDBCストアを選択します。
ストア・アンド・フォワード・エージェントの場合は、「構成:全般」ページでJDBCストアを選択します。
パス・サービスの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。
ドメインの構成ファイルでのJDBCストアの定義例を示します。この例では、JDBCデータ・ソースMyDataSourceを使用しており、論理名が指定されています。
<jdbc-store> <name>SampleJDBCStore</name> <target>yourserver</target> <data-source>MyDataSource</data-source> <logical-name>Baz</logical-name> </jdbc-store>
表6-2に、JDBCストアの変更可能な構成パラメータを示します。
表6-2 JDBCストアの構成オプション
| オプション | 必須 | 機能 |
|---|---|---|
|
「名前」 |
○ |
JDBCストアの名前。ドメイン内のすべてのストアの間で一意であることが必要です。 |
|
ターゲット |
○ |
JDBCストアをターゲット指定するサーバー・インスタンス、クラスタまたは移行可能ターゲット。複数のサブシステムが同じサーバー・インスタンスまたは移行可能なターゲットをターゲット指定していれば、これらのサブシステムで同じJDBCストアを共有できます。 注意:
|
|
データ・ソース |
○ |
ストアのデータベース表( 注意: JDBCストアでは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があり、「グローバル・トランザクションのサポート」が無効になっている必要があります。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。 |
|
接頭辞名 |
× |
通常、JDBCストアの表の接頭辞は 複数のJDBCストアを使用する場合は、構成するJDBCストアごとに1つの一意の接頭辞を設定する必要があります。接頭辞を指定しないと、JDBCストアの表名は単に 既存のJDBCストアの接頭辞を変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。 |
|
論理名 |
× |
必要に応じて、EJBなどのWebLogic Serverサブシステムでモジュールをクラスタ全体にデプロイする場合に使用します。ただし、クラスタ内のサーバー・インスタンスごとに別々の物理ストアが必要になります。このような構成では、各物理ストアに固有の名前を付けますが、すべての永続ストアで同じ論理名を共有します。 |
|
DDLファイルからの表の作成 |
× |
JDBCストアのデータベース表( |
WebLogic Server管理コンソールを使用してJDBCストアを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項を参照してください。
JDBCストアを使用する場合、JDBCドライバを介してアクセスできるデータベースであればバッキング・データベースにできます。WebLogic Serverでは、サポートされるデータベース用の一部のドライバが自動的に検出されます。
これらのデータベースごとに対応するDDL(データ定義言語)ファイルがあり、ORACLE_HOME\wlserver\modules\com.bea.core.store.jdbc_1.0.0.0.jarファイル内のweblogic/store/io/jdbc/ddlディレクトリに格納されています。ORACLE_HOMEは、WebLogic Serverの最上位のインストール・ディレクトリです。
表6-3 サポートされるJDBCドライバと対応するDDLファイル
| データベース | DDLファイル |
|---|---|
|
IBM DB2 |
db2.ddl db2v6.ddl |
|
Informix |
informix.ddl |
|
Microsoft SQL (MSSQL) Server |
mssql.ddl |
|
MySQL |
mysql.ddl |
|
Oracle |
oracle.ddl oracle_blob.ddl oracle_blob_securefile.ddl |
|
Sybase |
sysbase.ddl |
DDLファイルは、JDBCストアのデータベース表(WLStore)を作成するためのSQLコマンド(末尾がセミコロン)を含むテキスト・ファイルです。したがって、このリストに含まれていないデータベースを使用する場合は、そのデータベースに合わせて既存のDDLファイルを編集します。詳細は、「カスタムDDLファイルを使用したJDBCストア表の作成」を参照してください。
「JDBCストア構成」ページには「DDLファイルからの表の作成」オプションがあります。このオプションを使用してJDBCストアのバッキング表(WLStore)の作成に使用する構成済のDDLファイルにアクセスできます。JDBCストアのバッキング表がすでに存在する場合、このオプションは無視されます。このオプションを使用するのは、未サポートのデータベース用に作成したカスタムDDLファイルを指定する場合や、以前のリリースのJMS JDBCストア表を最新のJDBCストア表にアップグレードする場合などです。
「DDLファイルからの表の作成」フィールドにDDLファイル名が指定されておらず、バッキング表が存在しないことがJDBCストアによって検出されると、データベース・ベンダー固有の構成済DDLファイルが実行され、自動的に表が作成されます(「サポートされるJDBCドライバ」を参照してください)。
「DDLファイルからの表の作成」フィールドにDDLファイル名が指定されており、バッキング表が存在しないことがJDBCストアによって検出されると、まずファイル・パスに指定したDDLファイルが検索され、見つからない場合はCLASSPATH内のDDLファイルが検索されます。ファイルが見つかった時点で、DDLファイル内のSQLが実行され、JDBCストアのバッキング表が作成されます。構成済のファイルが見つからず、既存の表も存在しない場合、JDBCストアは起動に失敗します。
「サポートされるJDBCドライバ」のリストにないデータベースを使用する場合は、既存のDDLテンプレート・ファイルをコピーし、使用するデータベースに合わせて編集できます。
JDKで用意されているJARユーティリティを使用すると、次のコマンドでDDLファイルを/weblogic/store/io/jdbc/ddlディレクトリに抽出できます。
jar xf com.bea.core.store.jdbc_1.0.0.0.jar /weblogic/store/io/jdbc/ddl
|
注意: weblogic/store/io/jdbc/ddlパラメータを省略すると、jarファイル全体が抽出されます。 |
使用しているデータベースに合わせてDDLファイルを編集します。SQLコマンドは複数行にわたって指定できます。末尾にはセミコロン(;)を付けます。シャープ記号(#)で始まる行はコメントです。
変更を保存し、新しいDDLの名前を適切な名前に変更します(例: mydatabase.ddl)。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項に従って、JDBCストアを作成します。
「構成」ページの「DDLファイルからの表の作成」オプションを使用して、カスタムDDLファイルを指定します(例: /mydatabase.ddl)。
|
注意: Windowsシステムの場合、フルパス名には必ずドライブ文字を含めます。 |
Oracleデータベースの場合は、oracle_blob.ddlファイルまたはoracle_blob_securefile.ddlファイルを使用してレコード列のタイプがデフォルトのLONG RAWタイプではなく、BLOBレコード列タイプのJDBCストア表を作成できます。oracle_blob.ddlは、Oracleベーシック・ファイルのBLOBの作成に使用され、oracle_blob_securefile.ddlファイルはOracleセキュア・ファイルのBLOBの作成に使用されます。両方のファイル・タイプは、「サポートされるJDBCドライバ」に示すように、WebLogic CLASSPATHにあらかじめ構成されています。
Oracleデータベース11gリリース2には、セキュア・ファイル用のゼロ・コピーI/Oパフォーマンス機能改善とBLOB用のロジカル・キャッシュが含まれます。これらの機能改善を使用すると、メッセージ・サイズが大きい場合やデータベースへのネットワーク接続速度が遅い場合に、JDBCストアによるスループットを向上できます。Oracle LONG RAWデータ型は、データベースへの接続速度が速い場合に、BLOBよりも通常はパフォーマンスが高くなっています。
|
注意: すでにOracleのLONG RAW列に入っているデータを保持する必要がある場合は、この方法でBLOBに切り替えないようにしてください。このような場合は、SQL ALTER TABLEコマンドに関するOracleドキュメントを参照してください。 |
JDBCストアでOracle BLOB DDLを使用するには
JDBCストアを使用するサーバー・インスタンスを停止します。
「JDBCストア表の管理」の説明に従って、現在のJDBC表を削除します。
サーバー・インスタンスを再起動します。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項に従って、新しいJDBCストアを作成します。
「全般的な構成」ページの「DDLファイルからの表の作成」フィールドで、次の場所を入力します。
oracle_blob.ddlファイルは、/oracle_blob.ddl
oracle_blob_securefile.ddlファイルは、/oracle_blob_securefile.ddl
「完了」をクリックすると、JDBCストアのバッキング表が作成されます。
Oracle BLOBを使用する場合、ThreeStepThreshold値をチューニングすると、パフォーマンスが向上することがあります。
JDBCストア・スキーマには、Oracle BLOB列(ベーシック・ファイルまたはセキュア・ファイル)が含まれ、JDBCストアによって、BLOBデータのサイズに基づいて次の実装のいずれかを使用してBLOBデータが自動的に設定されます。
JDBCストアによって、1回の手順でBLOBデータを含む行がストア表に直接挿入されます。関与するのが1回の手順のみであるため、JDBC一括挿入も採用されており、データ・サイズが小さい場合はこの方法が最高のパフォーマンスを発揮します。この実装は、挿入するBLOBデータがThreeStepThresholdの値以下の場合に使用されます。
JDBCストアによって、Oracle LOB APIを使用して、3段階でBLOBデータを含む行がストア表に直接挿入されます。この実装は、データ・サイズが大きい場合に良好なパフォーマンスを発揮します。この実装は、挿入するBLOBデータがThreeStepThresholdの値より大きい場合に使用されます。
ThreeStepThresholdのデフォルト値は200Kです。
JDBC utils.Schemaユーティリティを使用すると、既存のバージョンを削除することで新しいJDBCストア・データベース表(WLStore)を再生成できます。通常、この表は自動的に作成されるため、このユーティリティを実行する必要はありません。しかし、既存のJDBCストア・データベース表に障害が発生した場合は、utils.Schemaユーティリティを使用して削除できます。
utils.SchemaユーティリティはJavaプログラムで、以下の項目を指定するコマンド行引数をとります。
JDBCドライバ
データベース接続情報
データベース表を作成するSQLデータ定義言語(DDL)コマンドを含むファイルの名前
utils.Schemaコマンドを次のように入力します。
$ java utils.Schema url JDBC_driver [options] DDL_file
|
注意: utils.Schemaを実行するには、CLASSPATHにweblogic.jarファイルを指定する必要があります。 |
表6-4にutils.Schemaのコマンド・ライン引数を示します。
表6-4 utils.Schemaのコマンド・ライン引数
| 引数 | 説明 |
|---|---|
url |
データベース接続URL。この値は、JDBC仕様の定義に従ってコロン区切りのURLにします。 |
JDBC_driver |
JDBCドライバ・クラスの完全パッケージ名。 |
options |
省略可能なコマンド・オプション。 データベースの必要に応じて、以下のものを指定します。
|
DDL_file |
実行するSQLコマンドが記されたDDLテキスト・ファイルのフルパス名。詳細は、「サポートされるJDBCドライバ」を参照してください。 |
たとえば、次のコマンドでは、ユーザー名user1、パスワードfoobarで、OracleサーバーDEMOのMYWLStoreというJDBC表が削除されます。
$ echo "drop MYWLStore;" > drop.ddl $ java utils.Schema jdbc:weblogic:oracle:DEMO \ weblogic.jdbc.oci.Driver -u user1 -p foobar -verbose \ drop.ddl
次の項では、JDBCストアの接頭辞を使用する場合のガイドライン、JDBCストア用のWebLogic JDBCデータ・ソースの推奨設定、およびJDBCストアを使用したJMSトランザクションの処理について説明します。
JDBCストア・データベースには、WLStoreというデータベース表が含まれます。このデータベース表は、WebLogic Serverによって自動的に生成され、内部的に使用されます。JDBCストアには任意指定の接頭辞名パラメータがあり、これを使用するとより正確にデータベース表にアクセスできます。
特に次のような場合、JDBC WLStore表名用に接頭辞を構成するのがベスト・プラクティスです:
データベースに完全修飾名を指定する必要がある。(これについてデータベース管理者に確認する必要があります。)
複数のJDBCストアが同じ表を共有できないため、1つのデータベースを複数のJDBCストアのインスタンスで共有している。
データベースに多くの表が含まれている。接頭辞を設定することで、起動時にJDBCストアが検索する必要のある表の数が減少します。
データ損失を避けるため、次の規則に従ってください。
JDBCストアの各表名は一意である必要があります。
1つの表を複数のJDBCストアが共有すると、動作が不安定となり、データ損失のおそれがあります。
2つのデータベース表を1つの表に結合する方法はありません。
ほとんどのデータベースでは、JDBCストアのバッキング・データベース表の接頭辞名オプションを、構成したJDBCストアごとに次のフォーマットで設定する必要があります。これにより、JDBCストア表名の前に付加されたときに、有効な表名になります。
[[[catalog.]schema.]prefix]
[[[catalog.]schema.]prefix]フォーマット内の各ピリオド記号は重要です。通常、catalogはDBMSが参照するシステム表のセットを識別し、schemaは表オーナー(username)のIDに対応します。接頭辞を指定しないと、JDBCストアの表名は単にWLStoreとなり、データベースではJDBC接続の現在のユーザーに基づいて暗黙的にスキーマが決定されます。
たとえば、データベース管理者は、次のように本番データベースで販売部門用の固有の表を管理できます。
[[[Production.]JMSAdmin.]Sales]
この場合、表はJMSAdminスキーマによって本番カタログ内に作成され、SalesWLStoreという名前になります。
Oracleなどの一部のDBMSベンダーの場合、設定または選択するカタログがないので、このフォーマットは[[schema.]prefix]となります。詳細は、お使いのDBMSのドキュメントで表の完全修飾名に関する説明を参照してください。ただし、そのDBMSで指定されている構文が、このオプションに必要なフォーマットとは異なる場合があることに注意します。
|
注意: WLStore表がすでにデータベース内にある状態で接頭辞名の設定を変更した場合は、既存の表のデータの保持の面で注意が必要です。この場合、データベース管理者が既存のデータベース表の名前を変更して、新たに構成した表の名前に一致させる必要があります。 |
JDBCストアにJDBCデータ・ソースまたはマルチ・データ・ソースを使用する場合は、以下の設定を推奨します。
WebLogic Serverには、堅牢なJDBCデータ・ソースが用意されています。JDBC接続プールでは、障害が発生したデータベースがオンラインに復旧した場合、WebLogic Serverを再起動しなくても、自動的にこのデータベースとの再接続を確立できます。この機能を活用し、JDBCストアをより堅牢なものとして使用するには、JDBCストアに関連付けられているJDBCデータ・ソースの次のオプションを構成します。
TestConnectionsOnReserve="true" TestTableName="SYSTABLES" ConnectionCreationRetryFrequencySeconds="600"
JDBCのデフォルトのテスト対象の表名の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のデータ・ソースの接続テスト・オプションに関する項を参照してください。データベースを再接続する試行回数の設定の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の接続作成の再試行の有効化に関する項を参照してください。
JDBCストアでは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があり、「グローバル・トランザクションのサポート」が無効になっている必要があります。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。
JDBCストアは、XAResourceインタフェースを実装しているため、JDBCストア自体のリソース・マネージャとして動作し、JDBCドライバ・レベルより上位のトランザクションを処理します。つまり、ストア自体がXAResourceを実装し、メッセージがデータベースに格納されている場合でもそのデータベースに依存せずにトランザクションを処理します。
このため、JDBCストアとデータベース(JMSメッセージが格納されているデータベースと同じ場合でも)を使用する場合、それは常に2フェーズ・コミット・トランザクションになります。
JDBCストアでのJMSトランザクションの使用の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のWebLogic JMSでのトランザクションの使用に関する項を参照してください。
パフォーマンスは、以下の方法で向上させることもできます。
データベース作業に使用するJDBCデータ・ソースを、JMS宛先と同じサーバー上に配置します。この場合、トランザクションは依然として2フェーズですが、より小さいネットワーク・オーバーヘッドで処理されます。
JDBCストアの代わりにファイル・ストアを使用します。
通常同じトランザクション内で呼び出されるサービスが複数あれば、これらのサービスが同じストアを共有するように構成します。
データベース操作を直接実行するアプリケーションで、同じトランザクション内のストア・サービス(JMSなど)が呼び出される場合は、データベース操作用にロギング・ラスト・リソース(LLR)を有効にしたJDBCデータ・ソースを使用することを検討します。
LLRによる最適化を使用すると、トランザクションは2フェーズ・コミット・プロトコルに従いますが、データベース操作は単一のローカル・トランザクションで処理されるため、トランザクション全体のパフォーマンスは向上します。LLRによる最適化の使用の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のロギング・ラスト・リソース・トランザクション・オプションの理解に関する項を参照してください。
JDBCストアのI/O負荷が高い場合、複数のJDBC接続を使用してI/O操作を同時に処理するようJDBCストアを構成すると、パフォーマンスが向上します。
|
注意: 付加が軽い環境でI/Oマルチスレッド処理を有効化すると、実際にはパフォーマンスが低下する場合があります。アプリケーションを適切に調整することをお薦めします。 |
I/Oマルチスレッド処理を有効化するには、Worker Count属性を1より大きい整数値に設定します。構成プロパティのデフォルト値は1で、この状態ではオプションは無効になっています。Worker Count属性によって、JDBCストアがI/Oの処理に使用するワーカー・スレッド数が指定されます。各ワーカー・スレッドによって、ストアの開放時に構成済のデータ・ソース・プールからJDBC接続が1つ取得されます。多くの場合、マルチスレッド処理の利点は同時実行スレッド数が4つを超えると減少する傾向にあります。データベースへの接続速度が遅い場合、マルチスレッド処理によってパフォーマンスが向上しない場合があります。
|
注意: Worker Countを接続プールで使用可能な接続数が足りない値に設定すると、JDBCストアの開放に失敗します。 |
Worker Preferred Batch Size属性の値を変更すると、各ワーカー・スレッドの作業負荷を調整できます。この属性値を増加すると、各ワーカー・スレッドに割り当てられる作業負荷が徐々に増加します。作業負荷はストアのI/Oリクエストから構成されます。これらのリクエストはグループ化され、処理のために各JDBCワーカー・スレッドにプッシュされます。各I/Oリクエストのサイズが共通して非常に大きい場合(1 MBのJMSメッセージを保存するリクエストなど)、Worker Preferred Batch Sizeの値を小さく調整してパフォーマンスを向上させます。
I/Oマルチスレッド処理を有効にすると、ストアI/O処理を同時に実行するために複数のJDBC接続が使用されます。この結果、データベース・リソースの競合が発生する可能性があります。Oracle Database上の競合を低減するには、I/Oマルチスレッド処理の使用時に主キー索引をリバース・キー索引に再構築することをお薦めします。I/Oマルチスレッド処理を使用してから無効にする場合、主キー索引を非リバース・キー索引に再構築することをお薦めします。リバース・キー索引に関する詳細については、『Oracle Databaseの概念』の索引および索引が整理された表に関する項を参照してください。
次の基本手順を実行し、Oracle Database用ストア表索引を再構築します。
ストア・スキーマ名の下にあるOracle Databaseにログインします。ストア・スキーマ名は、データ・ソース・ユーザー名と同じでも異なっていても有効です。
『Oracle Database用リバース索引の構築』または「Oracle Database用非リバース索引の構築」に記載したPL/SQLスクリプトを使用し、必要に応じてストア表索引を再構築します。各スクリプト内の<Store Table Name>を、「JDBCストアでの接頭辞の使い方」に記載されているストア表名に置き換えます。PL/SQLの詳細は、Oracle Databaseの概念のPL/SQLサブプログラムの実行に関する項を参照してください。
|
注意: リバース索引はI/Oマルチスレッド処理に使用し、非リバース索引はシングル・スレッドI/Oに使用することをお薦めします。 |
ストア表索引をOracle Database用リバース索引として再構築するには、次のPL/SQLブロックをストア・データベース・ユーザーとして実行します。
declare
idx user_ind_columns.index_name%TYPE;
alter_stmt VARCHAR2(200);
begin
select index_name into idx from user_ind_columns where table_name =
<Store Table Name> and column_name = 'ID';
alter_stmt := 'alter index ' || idx || ' rebuild reverse';
dbms_output.put_line(alter_stmt);
execute immediate alter_stmt;
end;
/
ストア表索引をOracle Database用非リバース索引として再構築するには、次のPL/SQLブロックをストア・データベース・ユーザーとして実行します。
declare
idx user_ind_columns.index_name%TYPE;
alter_stmt VARCHAR2(200);
begin
select index_name into idx from user_ind_columns where table_name =
<Store Table Name> and column_name = 'ID';
alter_stmt := 'alter index ' || idx || ' rebuild noreverse';
dbms_output.put_line(alter_stmt);
execute immediate alter_stmt;
end;
/
