| Oracle® Fusion Middleware WebLogic永続ストアの管理 12c (12.2.1.1.0) E77381-01 |
|
 前 |
 次 |
次の項では、JDBC対応ストアを構成および使用する方法について説明します。
JDBC TLogストア: トランザクション・ログ(TLOGs)をデータベースに保持します。「JDBC TLogストアの使用」を参照してください
JDBCストア: WebLogic Serverインスタンス・サービスとサブシステム情報をデータベースに保持します(ただし、TLOGは除きます)。「JDBCストアの使用」を参照してください
JDBC TLOGストアを構成すると、トランザクション・ログをデータベースに保持できます。これには次の利点があります。
基本データベースのレプリケーションとHA特性を活用できます。
データベースの状態とTLOGを簡単に同期できるため、災害からのリカバリを簡素化できます。
実行するトランザクション・ログを新しい場所に移行(コピー)する必要がないため、トランザクション・リカバリ・サービスの移行が向上します。
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ストアの正常性を検証する試行を実行するまでの最大待機時間(秒単位)。 |
|
1000 |
ストアがシャットダウンしてそのストアを待機しているすべての操作のブロックが解除される前に、JDBCストアの再接続再試行、またはTLOG-in-DBストアでのデータベースへの接続の再確立の試行が行われる時間(ミリ秒)。 |
|
200 |
接続再試行期間中の再接続試行間の時間(ミリ秒)。 |
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とデータベース間のネットワークにアクセスし、データの妨害、閲覧、または改変などが行われる可能性があります。
「ファイル・ストア・データの保護」を参照してください。
次の項では、JDBCストアの例を示し、既存のDDL、カスタムDDLを使用したJDBCストア用のデータベースの作成について説明します。DDLファイルでOracle blobレコード列を使用にする方法について説明します。
デフォルトのJDBCStoreMBeanパラメータを直接変更してJDBCストアを作成できます。WebLogic Server管理コンソールを使用してJDBCストアを作成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項を参照してください。
JDBCストアで接頭辞を使用する場合の構成ガイドライン、および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テンプレート・ファイルをコピーし、使用するデータベースに合わせて編集できます。
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ストアの再接続再試行期間は、ストアがシャットダウンして再起動が必要になる前に、WebLogic JDBCストアまたはTLOG in-DBストアがデータベースへの接続を再試行する時間を示します。ストアの再試行期間は、コマンド行のシステム・プロパティ、MBeanおよびWLSTを使用して構成できます。
JDBCストアの再接続再試行期間は、ストアがシャットダウンして再起動が必要になる前に、JDBCストアの再接続再試行、またはTLOG-in-DBストアのデータベース・リクエストの再試行に必要とする時間の長さを制御します。JDBCストアの再接続再試行間隔は、接続再試行期間中の再接続試行間の時間の長さ(ミリ秒)を制御します。JDBCストアの再接続再試行期間および間隔を構成するには、JDBCStoreMBeanおよびTransactionLogJDBCStoreMBeanで使用可能なReconnectRetryPeriodMillis属性およびReconnectRetryIntervalMillis属性を使用できます。再試行属性の詳細は、Oracle WebLogic Server MBeanリファレンスを参照してください。
カスタムJDBCストアの再接続再試行とTLOG-in-DBストアの再試行期間および間隔を構成するには、WebLogic Serverのコマンド行でシステム・プロパティを設定できます。-DwebLogic.store.jdbc.RecnnectRetryPeriodMillis=<millis>オプションおよび-Dweblogic.store.jdbc.ReconnectRetryIntervalMillis=<millis>オプションは、WebLogic Serverドメインで使用可能なJDBCストアの再接続再試行期間および間隔を指定します。
-Dweblogic.store.jdbc.ReconnectRetryPeriodMillis=<millis>システム・プロパティは、レガシー・プロパティ-Dweblogic.store.jdbc.IORetryDelayMillis=<millis>または-Dweblogic.jms.store.JMSJDBCIORetryDelay=<seconds>をオーバーライドします(同じコマンド行に設定されている場合)。再試行期間プロパティを設定しない場合は、レガシー・プロパティが有効になります。
非推奨に関する注意事項: JDBCストアのすべての再接続再試行コマンド行プロパティは、12.2.1.0から非推奨となり、今後のリリースで削除される可能性があります。12.2.1.0以降では、かわりにMBean属性を使用してこれらの値を設定することをお薦めします。
JDBCストアの再接続再試行期間を構成するときは、次の事項を考慮することが重要です。
ストアの再試行が失敗する前の経過時間の合計は、構成されている再試行期間の2倍以上になることがあります。
再試行期間が長すぎると、この期間中にWebLogic Serverアプリケーションおよびクライアント・アプリケーションがロックアップされることがあるため、最大値ではなく、最大15秒くらいのより耐性のある再試行期間を構成することをお薦めします。
JDBCストアの再接続再試行のチューニングは、トランザクションのチューニングと整合するように構成してください。
JDBCストアに関連するアプリケーション・トランザクションが、データベースの障害からJDBCストアが正常に回復することを待機してタイムアウトしないように、JTAトランザクションのタイムアウトが再試行期間よりも長くなるようにチューニングすることを検討してください。ドメインのデフォルトのトランザクション・タイムアウトは30秒であり、JTAMBeanのTimeoutSeconds属性を使用してチューニングできます。また、トランザクションのタイムアウトはアプリケーションごとにチューニングできます。
WebLogicのトランザクション・システムは、JDBCストアがJTAMBean MaxXACallMillis属性(デフォルトは1200000ミリ秒/2分)の時間を超えて応答しない場合、JDBCストアがトランザクションに参加できるように一時的に停止します。ストアが応答しないとJTAが判断すると、MaxResourceUnavailableMillis(デフォルトは1800000ミリ秒/30分)の時間が経過するまで、ストアがトランザクションに参加できるようになりません。このため、MaxXACallMillisをJDBCストアの再接続再試行期間の少なくとも2倍にすることをお薦めします。
TLOG-in-DBストアに再試行期間を構成する場合は、TransactionLogJDBCStoreMBean MaxRetrySecondsBeforeTLOGFail設定の半分よりも小さく設定してください。そうしないと、TLOG-inストアでTLOGFail設定より長く障害が遅延することがあります。
一部のトランザクション設定は秒単位で構成しますが、JDBCストアの再接続再試行期間はミリ秒単位で構成します。
デフォルトでは、WebLogic JDBCストアは、データ・ソースから2つのJDBC接続を取得し、ストアが存続している間、それらの接続をキャッシュします。必要に応じて、JDBCストアの接続キャッシング・ポリシーをチューニングし、キャッシュされるJDBC接続の数を減らすことができます。
JDBCストアの接続キャッシング・ポリシー設定は、キャッシュするJDBC接続の数を制御します。接続キャッシング・ポリシーを構成するには、JDBCStoreMBeanおよびTransactionLogJDBCStoreMBeanで使用可能なConnectionCachingPolicy属性を使用します。ConnectionCachingPolicy属性に有効な値は、DEFAULT、MINIMALおよびNONEです。有効な値の詳細は、Oracle WebLogic Server MBeanリファレンスおよび表6-5を参照してください。
注意:
NONEポリシーを使用する場合は、サーバーがデッドロックしないように追加のチューニングが必要となります。JDBCストアの接続キャッシング・ポリシーNONEのチューニングの詳細は、接続キャッシング・ポリシーNONEのチューニングに関する重要な考慮事項を参照してください。JDBCストアの接続キャッシング・ポリシーを構成するには、WebLogic Serverのコマンド行でシステム・プロパティを設定します。-Dweblogic.store.jdbc.ConnectionCachingPolicyオプションは、WebLogic Serverドメインで使用可能なWebLogic JDBCストア接続を指定します。このポリシーに設定できる有効な値の詳細は表6-5を参照してください。
注意:
weblogic.store.jdbc.ConnectionCachingPolicyシステム・プロパティは12.2.1.1.0から非推奨となり、今後のリリースで使用できなくなる可能性があります。かわりにWLSTまたはMBeanを使用して接続ポリシーを構成することをお薦めします。JDBCストアの接続キャッシング・ポリシーNONEのチューニングの詳細は、接続キャッシング・ポリシーNONEのチューニングに関する重要な考慮事項を参照してください。
NONEポリシーを使用する場合は、サーバーがデッドロックしないように追加のチューニングが必要となります。JDBCストアの接続キャッシング・ポリシーNONEのチューニングの詳細は、接続キャッシング・ポリシーNONEのチューニングに関する重要な考慮事項を参照してください。
JDBCストアの接続キャッシングの動作は、接続キャッシング・ポリシー設定およびワーカー数設定の組合せによって判断されます。次の表は、各組合せで予期される動作を示しています。
表6-5 JDBCストアの接続キャッシング・ポリシーの動作
接続キャッシング・ポリシー |
ワーカー数=1の場合のキャッシュされる接続 |
ワーカー数>1の場合のキャッシュされる接続 |
説明 |
DEFAULT |
2 |
2+ワーカー数 |
デフォルトでは、各JDBCストア・インスタンスは、ストアが存続している間、2つのデータベース接続をキャッシュします。 JDBCストアのワーカー数に2より大きい数が構成されている場合、ストアは各ワーカーに追加の接続を開きます。 |
MINIMAL |
1 |
1+ワーカー数 |
各JDBCストア・インスタンスは、ストアが存続している間、単一のデータベース接続をキャッシュします。JDBCのワーカー数に2以上が構成されている場合、ストアは各ワーカーに1つの接続を開きます。 同時実行性が低いメッセージング・シナリオの場合、この設定のパフォーマンスは |
NONE |
0 |
該当なし |
各JDBCストア・インスタンスは、必要に応じてデータ・ソースから接続を取得し、終了時にその接続を解放します。
警告: WebLogic Serverがデッドロックする危険を避けるために、接続キャッシング・ポリシーNONEのJDBCストアに専用のデータ・ソースを構成することをお薦めします。 |
JDBCストアの接続キャッシング・ポリシーにNONEを設定する場合は、次のチューニングの考慮事項に留意することが重要です。
専用のデータ・ソースを使用してデッドロックを回避します - JDBCストアの接続キャッシング・ポリシーにNONEを設定する場合は、JDBCストアが専用のデータ・ソースを使用するように構成することをお薦めします。NONEポリシーのJDBCストアでは、データ・ソースをアプリケーションまたはストア以外のサービスと共有するように構成した場合、サーバーがデッドロックするか、最終的に障害が発生することがあります。
たとえば、次の手順を実行するアプリケーションについて考えてみてください。
データ・ソース接続を取得します。
同じデータ・ソースを使用するNONEポリシーのJDBCストアを持つJMSサーバーを介して永続的なJMSメッセージを送信します。
データ・ソース接続を閉じます。
手順1でデータ・ソース接続プールの最後の使用可能な接続が取得されたために、NONEポリシーのJDBCストアが同じプールから接続を取得できるようになるまで、手順2でJMS送信呼び出しがブロックされることがあります。これが問題であるのは、他のすべてのアプリケーションも手順2でブロックされている可能性があり(このため、接続を解放するために手順3に進めるアプリケーションがない)、手順2はいくら待っても接続を取得できない可能性があるためです。この問題によって、サーバーまたはクライアントに多数のスタック・スレッドができたり、接続の取得を試行するために待機した時間が長すぎるためにJDBCストアが最終的にシャットダウンしたりすることがあります。
データ・ソース接続プールが十分な大きさになるようにチューニングします - JDBCストアはそれに依存するサービス(JMSなど)を最初に初期化するときに複数の同時接続を使用します。このため、データ・ソース・プールはそのプールを使用しているJDBCストアの数より大きく拡張できるように構成する必要があります。
データ・ソース接続のテストを有効にしてチューニングします - データ・ソース接続のテストを有効にすると、データベース・アクセスの障害時にJDBCストアに回復力が備わります。ただし、パフォーマンスが重要な場合は、NONEポリシーのJDBCストアのパフォーマンスが低下するため、データ・ソース接続のテストを頻繁に行わないでください。一般に、データ・ソースのReserve設定のTest Connectionを有効にし、データ・ソースのSeconds to Trust値およびIdle Pool Connection値をゼロより大きく、JDBCストアのConnection Retry Interval Millis値より小さい値に設定することをお薦めします。詳細は、Oracle WebLogic Server JDBCデータ・ソースの管理のデータ・ソースの接続テスト・オプションに関する項を参照してください。
プリペアド文のキャッシング・パフォーマンスをモニターおよびチューニングします - データ・ソースまたはJDBCドライバのプリペアド文のキャッシュ・サイズが小さすぎると、NONEで構成されたJDBCストアのパフォーマンスが低下することがあります。キャッシュの失敗によってパフォーマンスが低下しているかどうかを確認するには、負荷がかかったときにプリペアド文のキャッシュ・アクティビティをモニターします。このモニターでは、キャッシュ・ヒットが頻繁に発生してキャッシュの失敗は少ないはずですが、多数のキャッシュの失敗が示されている場合は、キャッシュ・サイズを増やしてください。
GridLinkを使用したOracle RACのパフォーマンスをモニターし、必要な場合はチューニングします。Oracle RACをGridLinkドライバとともに使用したときに、NONEポリシーのJDBCストアのパフォーマンスが他のポリシーと比べて低い場合、可能性のある回避策は次のとおりです。
GridLinkデータ・ソースのかわりに複数のデータ・ソースを使用します。
リバース索引を使用してJDBCストア表を再構築します。構築の詳細は、Oracle Database用ストア表索引の再構築を参照してください。
注意:
前述のすべての考慮事項に注意深く従っても、NONEポリシーのパフォーマンスはMINIMALポリシーまたはDEFAULTポリシーよりも明らかに低くなることがあります。次の項では、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スクリプトを使用し、必要に応じてストア表索引を再構築します。「JDBCストアでの接頭辞の使い方」で説明したように、各スクリプトの<Store Table Name>をストア表名に置き換えます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;
/
