Oracle® Fusion Middleware

WebLogic永続ストアの管理

12c (12.2.1.1.0)

E77381-01(原本部品番号:E75745-01)

2016年6月

このドキュメントでは、WebLogic永続ストアを構成およびモニターする方法について説明します。インストールされたWebLogic Serverの実装に携わるシステム管理者およびオペレータを対象としています。

Oracle Fusion Middleware WebLogic永続ストアの管理, 12c (12.2.1.1.0)

E77381-01

Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- このリリースでの新機能と変更された機能

2 WebLogic永続ストア

- 永続ストアとは

- 永続ストアの特長

- 高パフォーマンスのスループットとトランザクション・サポート

- ファイル・ストアとJDBC対応ストアの比較

- 永続ストアの高可用性

- サーバー全体の移行

- 自動サービス移行

- 高可用性ストレージ・ソリューション

- 永続ストアの制限事項と考慮事項

- 永続ストアの高可用性を有効にする場合の追加要件

3 デフォルト永続ストアの使用方法

- デフォルト永続ストアの使用方法

- デフォルト・ストアの場所

- デフォルト・ファイル・ストアの例

4 カスタム永続ストアの使用

- カスタム・ファイル・ストアとJDBCストアとは

- カスタム永続ストアを使用すべき状況

- カスタム永続ストアの作成方法

- カスタム永続ストアのパラメータの変更

5 カスタム・ファイル・ストアの使用

- カスタム(ユーザー定義)ファイル・ストアの作成

- カスタム・ファイル・ストアを構成する主な手順

- カスタム・ファイル・ストアの例

- 同期書込みポリシーの構成のガイドライン

- 直接書込み - キャッシュありポリシー

- 直接書込みポリシー

- キャッシュ・フラッシュ・ポリシー

- 無効ポリシー

6 JDBCストアの使用

- JDBC対応ストアの作成

- JDBC TLogストアの使用

- JDBC TLOGストアを構成する主な手順

- データ・ソースの選択

- JDBC TLOGストアの例

- 構成のガイドライン

- その他の考慮事項

- JDBC TLOGストア使用時のサーバー移行

- JDBC TLOGストアの監視

- JDBC TLOGストアの正常性状態を監視する方法

- トランザクション・ログ・ストア統計情報を監視する方法

- トランザクション・ログ・ストア接続を監視する方法

- セキュリティに関する考慮事項

- JDBCストアの使用

- JDBCストアを構成する主な手順

- JDBCストアの例

- サポートされるJDBCドライバ

- デフォルトおよびカスタムDDLファイルを使用したJDBCストア表の作成

- カスタムDDLファイルを使用したJDBCストア表の作成

- Oracle BLOBレコード列の有効化

- JDBCストア表の管理

- utils.Schemaユーティリティを使用したJDBCストア表の削除

- JDBCストアの再接続再試行の構成

- WLSTおよびJMX MBeanの使用

- コマンド行のシステム・プロパティの使用

- 再接続再試行のチューニングに関する重要な考慮事項

- JDBCストアの接続キャッシング・ポリシーの構成

- WLSTおよびJMX MBeanの使用

- コマンド行パラメータの使用

- JDBCストアの接続キャッシングの動作

- 接続キャッシング・ポリシーNONEのチューニングに関する重要な考慮事項

- JDBCストアの構成のガイドライン

- JDBCストアでの接頭辞の使い方

- JDBCストア表の規則

- 接頭辞名のフォーマットのガイドライン

- JDBCストア用のJDBCデータ・ソースの推奨設定

- 障害が発生したデータベースへの自動再接続

- Oracle DB2 Type 4 JDBCドライバの必要設定

- JDBCストアを使用したJMSトランザクションの処理

- JDBCストアのI/Oマルチスレッド処理の有効化

- Oracle Database用ストア表索引の再構築

- Oracle Database用リバース索引の構築

- Oracle Database用非リバース索引の構築

- 非Oracle Databaseでの競合の低減

7 WebLogic永続ストアの管理

- 永続ストアの管理

- Javaコマンド行を使用したストア管理

- ストア管理ヘルプの使用

- ファイル・ストアの内容のダンプ

- ファイル・ストアの圧縮

- WLSTを使用したストア管理

- ストア管理ヘルプの使用

- WLSTを使用したJDBCストアの内容のダンプ

- WLSTを使用したファイル・ストアの圧縮

- ファイル・ストア・データの保護

8 WebLogic永続ストアのモニター

- 永続ストアのモニター

- ストアのモニター

- ストア接続のモニター

はじめに

この項では、このガイド(『WebLogic永続ストアの管理』)で使用されるドキュメントのアクセシビリティ機能と表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この項では、このガイド(『WebLogic永続ストアの管理』)の内容と構成について説明します。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- このリリースでの新機能と変更された機能

ドキュメントの範囲および対象読者

このドキュメントでは、WebLogic Server環境を設計、構成、管理する方法について説明します。インストールされたWebLogic Serverの実装に携わるシステム管理者およびオペレータを対象としています。このドキュメントのスコープは、開発からテストおよび本番まで、ソフトウェア・プロジェクトのすべての段階に関連しています。

Java EE技術、Web技術、オブジェクト指向プログラミング技術、およびJavaプログラミング言語について読者が精通していることを前提としています。

このドキュメントの構成

このドキュメントの構成は次のとおりです。

- この章「概要とロードマップ」では、このガイドの構成および関連ドキュメントについて説明します。

- 「WebLogic永続ストア」では、WebLogic Serverの実行モデルについて解説し、実行キューへアプリケーションのアクセスを構成する手順について説明します。

- 「デフォルト永続ストアの使用」では、オーバーロード状態の検出、回避および回復について説明します。

- 「カスタム永続ストアの使用」では、使用中のネットワークに対するWebLogic Serverドメインの最適化について説明します。

- 「カスタム・ファイル・ストアの使用」では、WebLogic ServerをWebサーバーとして使用する方法について説明します。

- 「JDBCストアの使用」では、永続ストアの構成およびモニターについて説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込の高性能なストレージ・ソリューションを提供します。

- 「WebLogic永続ストアの管理」では、Oracle Virtual Assembly Builder用のWebLogic Serverイントロスペクション・プラグインについて説明します。このプラグインを使用して、単一のWebLogicドメインおよびそのドメインが存在するMiddlewareホーム・ディレクトリを調べることができます。

- 「WebLogic永続ストアのモニター」では、Oracle Virtual Assembly Builder用のWebLogic Serverイントロスペクション・プラグインについて説明します。このプラグインを使用して、単一のWebLogicドメインおよびそのドメインが存在するMiddlewareホーム・ディレクトリを調べることができます。

関連ドキュメント

- Oracle WebLogic Serverドメインの構成の理解

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプ

このリリースでの新機能と変更された機能

12.1.3以前のバージョンで公開された『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用に関する章は、移動してこの新しいマニュアルで再編成されました。

このリリースで導入されたWebLogic Serverの新機能の一覧については、『Oracle WebLogic Serverの新機能』 12.2.1.1.0を参照してください。

2 WebLogic永続ストア

この章では、WebLogic Server永続ストアを構成およびモニターする方法について説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。また、永続ストアを使用するJMSサービス・アーティファクトの高可用性を構成する方法についても説明します。

- 永続ストアとは

- 永続ストアの特長

- 高パフォーマンスのスループットとトランザクション・サポート

- ファイル・ストアとJDBC対応ストアの比較

- 永続ストアの高可用性

- 永続ストアの制限事項と考慮事項

永続ストアとは

永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。永続ストアは、ファイルベースのストアまたはデータベース内でJDBCでアクセス可能なストアへの永続性に対応しています。

表2-1に、永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムの多くを示します。永続ストアを使用する各サブシステムには、そのサブシステムを特定するための一意の接続IDが指定されます。

表2-1 永続ストアのユーザー

サブシステム/サービス

ストアとは

参照

診断サービス

ログ・レコード、データ・イベント、収集されたメトリック

『Oracle WebLogic Server診断フレームワークの構成と使用』のWLDF構成の理解に関する項

JMSメッセージ

永続メッセージ、恒久サブスクライバ

『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージング・モデルの理解に関する項

JMSページング・ストア

各JMSサーバーに1つ。ページされた永続メッセージと非永続メッセージ。

『Oracle WebLogic Server JMSリソースの管理』の基本JMSシステム・リソースの構成の主な手順に関する項

JTAトランザクション・ログ(TLOG)

サーバーによって調整された、完了していない可能性のあるコミット済みトランザクションに関する情報TLOGは、デフォルトの永続ストアまたはJDBC TLOGストアに保存できます。

- 『Oracle WebLogic Server JTAアプリケーションの開発』のトランザクションの管理に関する項

- JDBC TLogストアの使用

パス・サービス

メッセージのグループからメッセージング・リソースへのマッピング

『Oracle WebLogic Server JMSリソースの管理』のWebLogicパス・サービスの使用に関する項

ストア・アンド・フォワード(SAF)サービス・エージェント

SAF送信エージェントからSAF受信エージェントに再転送するメッセージ

『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項

Webサービス

信頼性のあるWebLogic Webサービスの呼出しによるSOAPリクエスト・メッセージおよびレスポンス・メッセージ

の信頼性のあるSOAPメッセージングの使用に関する項

EJBタイマー・サービス

EJBタイマー・オブジェクト。

『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEnterprise JavaBeansの理解に関する項

ストアの接続IDの詳細は、「ストア接続のモニター」を参照してください。

永続ストアの特長

永続ストアの主な特徴は以下のとおりです。

- 各サーバー・インスタンスのデフォルト・ファイル・ストアは構成不要です。

- すべてのサブシステムが同じサーバー・インスタンス、クラスタまたは移行可能ターゲットをターゲット指定している場合のみ、デフォルト・ストアおよびカスタム・ストアを複数のサブシステムで共有できます。

- 構成すると、JDBC TLOGストアには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報が格納されます。アプリケーションのニーズに応じて、TLOG情報をデフォルト・ストアまたはJDBC TLOGストアのどちらに保持するかを選択できます。「JDBC TLogストアの使用」を参照してください

- 高パフォーマンスのスループットとトランザクション・サポート

- パラメータを修正してカスタム・ファイル・ストアやJDBCストアを作成できる

- 永続ストアの統計情報と開いているストア接続をモニターできる

- クラスタリング環境では、サーバー全体レベルまたはサービス・レベルで、JDBC TLOGストアおよびカスタマイズしたストアを異常のあるサーバーからバックアップ・サーバーに移行できます。

- クラスタをターゲット指定している場合、永続ストアの高可用性パラメータによりJMSサービスの分散と高可用性の動作を制御します。移行可能ターゲットを構成する必要もなくなります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。

高パフォーマンスのスループットとトランザクション・サポート

永続ストアのパフォーマンス上の主な目標はスループットの向上です。すべてのサブシステムが同じサーバー・インスタンス、クラスタまたは移行可能ターゲットをターゲット指定している場合のみ、同じデフォルト・ストアまたはカスタム・ストアを複数のサブシステムで共有できます。

注意:

- JDBC TLOGストアは、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を保持する場合にのみ使用されます。他のサブシステムによって共有できません。

- JDBC TLOGストアではHA構成設定は許可されません。

この点が、永続ストアを使用するパフォーマンス上の利点です。なぜなら、同じストアを使用する複数のサービスに関係するトランザクションであっても、そのトランザクションのトランザクション・マネージャによって永続ストアが単一のリソースとして扱われるためです。たとえば、TLOG、JMSとEJBのタイマーが1つのファイル・ストアを共有し、JMSメッセージとEJBタイマーが単一のトランザクションで作成された場合、そのトランザクションは1フェーズとなり、リソースの書込みは1回しか発生しません。一方、2フェーズの場合であれば、リソースごとに2回ずつで合計4回のリソース書込みが発生し、加えてトランザクション・ログでのトランザクション・エントリの書込みが1回発生することになります。

ファイル・ストアおよびJDBCストアは、プロセスのクラッシュやハードウェアの電源障害が発生しても、コミットされた更新を失うことなく存続できます。コミットされていない更新は保持されるとは限りませんが、クラッシュ後にトランザクションが部分的に完了した状態で残されることはありません。

ファイル・ストアとJDBC対応ストアの比較

次に、ファイル・ストアとJDBC対応ストアの類似点と相違点を挙げます。

- デフォルトの永続ストアはファイル・ストアにしかできません。したがって、JDBCストアはデフォルトの永続ストアとしては使用できません。

- どちらもトランザクションのセマンティクスと保証を備えています。JDBCストアの書込みと同様、ファイル・ストアの書込みでもディスクへの保存が保証されており、単に中間キャッシュ(つまり、安全性が保障されないキャッシュ)に保存されるわけではありません。

- どちらも同じアプリケーション・インタフェースを備えています(アプリケーション・コードに違いがありません)。

- すべての条件が同じ場合、一般的にファイル・ストアの方がJDBCストアよりスループットが高くなります。

注意:

データベースが高速なディスクを備えたハイエンドのハードウェア上で実行され、WebLogic Serverがそれよりも低速なディスクを備えたハードウェア上で実行されている場合は、JDBCストアの方がパフォーマンスが良くなる場合もあります。

- 通常、ファイル・ストアの方が構成および管理が簡単であり、WebLogicのサブシステムが外部コンポーネントに依存する必要もありません。

- ファイル・ストアは、ネットワーク・トラフィックを生成しません。JDBCストアは、データベースがWebLogic Serverとは異なるマシンに存在する場合にネットワーク・トラフィックを生成します。

- JDBCストアの方が障害リカバリが容易。JDBCインタフェースが同じネットワーク上の任意のマシンからデータベースにアクセスできるからです。ファイル・ストアの場合、ディスクが共有または移行されている必要があります。

- 動的拡張性: カスタム論理永続ストアが構成されてクラスタにターゲット指定されている場合、デフォルトでは、システムは自動的に各クラスタ・メンバーに1つの物理インスタンスを作成し、そのインスタンスには監視目的で一意の名前が付けられます。これにより、ストアおよび関連JMSアーティファクトは、各クラスタ・メンバーで個別に構成する必要なく動的に拡張することができます。この動作は、システムが1つの物理インスタンスのみを作成し、それがクラスタ内で高可用になるように、変更することができます。『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。

永続ストアの高可用性

高可用性のために、WebLogic Serverは次の2つの移行オプションを提供します。

- サーバー全体の移行

- 自動サービス移行

サーバー全体の移行

永続ファイルベースのストア(デフォルトまたはカスタム)は、サーバー全体レベルの移行機能の一部としてその親サーバーとともに移行できます。この場合、サービス・レベルではなく、サーバー・レベルで自動または手動で移行できます。詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。ただし、ファイルベースのストアは、クラスタ内のすべてのサーバーからアクセスできる共有ディスク上に構成する必要があります。

自動サービス移行

ファイルベースのストアおよびJDBC対応ストアも、ストアを使用してデータを維持するJMS関連サービス(JMSサーバー、SAFエージェント、パス・サービスなど)のサービス・レベル移行の一部として移行できます。WebLogic Serverは、次の2つの方法で自動サービス移行をサポートしています。

- 簡略化されたJMSクラスタ構成の使用: これによりストアとストアを参照するすべてのJMSサービス・アーティファクトの両方に対する自動サービス移行が可能になります。構成設定はストアがクラスタに対してターゲット指定されるたびに有効になります。このモデルは、自動フェイルバック、動的ロード・バランシングおよびフェイルオーバーなどの拡張された高可用性機能を提供します。『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。

- 移行可能ターゲット構成の使用: このモデルでは、移行可能ターゲットは、関連JMSサービスのグループ化メカニズムとして機能し、グループ全体はクラスタ内の1つの物理サーバーのみでホストされます。

注意:

自動サービス移行の場合、従来の移行可能ターゲット・モデルのかわりに、簡略化されたJMSクラスタ構成を使用します。

これらの両方のモデルでは、ホストされている関連サービスは、ヘルス・モニター・サブシステムを使用することで、現在異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されます。クラスタのターゲット指定されたストアの場合、ストア・インスタンスが移行するときに、そのストア・インスタンスを参照しているすべての関連JMSサービス・インスタンスも移行されます。

このリリースでは、サービスレベル移行は、関連JMSサービス・アーティファクトとして、同じクラスタへストアをターゲット指定することで制御されます。『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。このタイプの移行はすべてのクラスタ・タイプ(構成済、動的および混在)でサポートされ、これにより移行可能ターゲット構成の必要はなくなります。このオプションは、JMSアーティファクトのサービス移行を制御するだけでなく、自動フェイルバックもサポートします。以前のリリースと同様に、関連JMSサービスを移行可能ターゲットにターゲット指定することにより、サービス・レベルの移行を有効にすることができます。移行可能ターゲットは、JMS関連サービスのグループ化として機能し、クラスタ内の1つの物理サーバーのみでホストされます。移行可能ターゲット・ベースの構成では、移行可能なターゲットによってホストされるJMSサービスは、定期的なサーバー・メンテナンスの一環としてオンデマンドで手動でも移行できます。

どちらの場合も、JMSサービスは、ヘルス・モニター・サブシステムを使用することで、現在異常のあるホスト・サーバーから正常なアクティブ・サーバーに自動的に移行されます。移行が実行されると、ストアと関連付けられている、またそのサーバーによってホストされているすべての固定サービスも移行されます。

サービス・レベルの移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項を参照してください。

クラスタまたは以降可能ターゲット・ベース・モデルでは、JMS関連サービスで、デフォルトのファイル・ストアを使用することはできません。したがって、カスタムのファイル・ストアまたはJDBCストアを構成し、関連付けたJMSサーバー、SAFエージェント、またはパス・サービスと同じ移行可能ターゲットにそのストアをターゲット指定する必要があります。

ベスト・プラクティスについては、「永続ストアの高可用性を有効にする場合の追加要件」を参照してください。

高可用性ストレージ・ソリューション

JMSサーバーまたはJTAトランザクション・ログの移行後に、リモート・マシンに存在する永続ストアにアクセスするアプリケーションがある場合は、以下の高可用性ストレージ・ソリューションのいずれかを実装する必要があります。

- ファイル・ベース・ストア(デフォルトまたはカスタム) - デュアルポートSCSIディスクまたはストレージ領域ネットワーク(SAN)などのハードウェア・ソリューションを実装して、共有可能ディスクやリモート・マシンからもファイル・ストアを利用できるようにします。

注意:

ファイル・ストアが切断されて再接続された場合、永続JMSメッセージの送受信を正常に続行するには、ホスト・サーバー・インスタンスを再起動する必要があります。たとえば、ファイル・ストアを含むファイル・システムがアンマウントされた後再びマウントされた場合、ホスト・サーバーを再起動せずに永続JMSメッセージを送信しようとするとJMS例外が生成されます。

- JDBC対応ストア - JDBCストアまたはJDBC TLOGストアを構成し、JDBCを使用してこのストアにアクセスします。このストアは、別のサーバーに存在する場合もあります。そのあと、アプリケーションでは、データベース・ベンダーによって提供されるあらゆる高可用性ソリューションまたはフェイルオーバー・ソリューションを利用できます。また、JDBCストアではGridLinkデータ・ソースおよびマルチ・データ・ソースがサポートされるため、Oracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムのノード間でのフェイルオーバーが可能です。詳細は、次を参照してください。

- 『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCマルチ・データ・ソースの構成に関する項

- 『Oracle WebLogic Server JDBCデータ・ソースの管理』のGridLinkデータ・ソースの使用に関する項

- 任意の永続ストア - WebLogic Serverベースのアプリケーション用の即時利用可能な統合ソリューションを提供する、高可用性クラスタリング・ソフトウェアを使用します。

永続ストアの制限事項と考慮事項

永続ストアには以下の制限があります:

- 永続ファイル・ストアは、2つのサーバー・インスタンスから同時に開かないでください。同時に開いた場合、ファイル内のデータが破損しないという保証はありません。可能であれば永続ストアはこの場合にエラーを戻そうとしますが、この状態を必ず検知できるとはかぎりません。管理者の責任において、複数のサーバーが同じ永続ストアに同時にアクセスを試みない環境でのみ永続ストアを使用するようにしてください。(名前とディレクトリが同じである場合、2つのファイル・ストアは「同じストア」とみなされます。)

- データが破損するので、2つのJDBCストアで同じデータベース表を共有することはできません。

- 永続ストアは、任意の破損に対応できない可能性があります。ディスク・ファイルが任意のデータで上書きされた場合の結果がどうなるかは不確定です。ストアから矛盾したデータが戻されたり、ストアをまったく回復できなくなったりするおそれがあります。

- ディスクが一杯になると、ファイル・ストアから例外が戻されることがあります。しかし、ディスク・スペースが使用可能になると例外をスローされなくなり、通常の処理が再開します。また、これまでに説明したとおり、永続ストア内のデータはそのまま残されます。

- MySQLをJDBCストア用のバッキング・データベースとして使用する場合は、安全な書込み機能を備えているInnoDBエンジンの使用をお薦めします。MyISAMエンジンが使用されていると、データが失われる場合があります。

永続ストアの高可用性を有効にする場合の追加要件

永続ストアの高可用性を有効にする場合には次の要件が適用されます。

- ストアに依存するすべての関連JMSサービス・アーティファクトは、同じクラスタまたは移行可能ターゲットにターゲット指定される必要があります。

- 高可用性用に構成されたファイル・ストアは、クラスタ内のすべてのサーバーからアクセスできる共有ディスク上に構成する必要があります。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。

3 デフォルト永続ストアの使用方法

この章では、WebLogic Server永続ストアを構成およびモニターする方法について説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。

- デフォルト永続ストアの使用方法

- デフォルト・ストアの場所

- デフォルト・ファイル・ストアの例

デフォルト永続ストアの使用方法

管理サーバーを含め、すべてのサーバー・インスタンスには、構成が不要なデフォルトの永続ストアがあります。デフォルト・ストアはファイルベースのストアで、サーバー・インスタンスのdata\store\defaultディレクトリに格納された一連のファイルにデータを保持します。デフォルト・ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト・ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができます。たとえば、永続ストアが構成されていないJMSサーバーは、管理対象サーバー用のデフォルトのストアを使用して永続メッセージングをサポートします。

デフォルト・ストアは、DefaultFileStoreMBeanパラメータを直接操作して構成できます。このMBeanがドメインの構成ファイルで定義されていない場合は、DefaultFileStoreMBeanには、構成サブシステムによってデフォルト値が確保されます。

また、WebLogic Server管理コンソールを使用してデフォルト・ストアのパラメータ(デフォルトのディレクトリの場所、同期書込みポリシーなど)を変更できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルト・ストアの設定の変更に関する項を参照してください。

デフォルト・ストアの場所

デフォルト・ストアのデータは、ドメインのルート・ディレクトリのservernameサブディレクトリにあるdata\store\defaultディレクトリに保持されます。

たとえば、デフォルト・ファイル・ストアのディレクトリ名が指定されていない場合、次のディレクトリがデフォルトになります。

ORACLE_HOME\user_projects\domains\domain-name\servers\server-name\data\store\default

domainnameはドメインのルート・ディレクトリ(通常は c:\oracle\user_projects\domains\domainname)です。これは、WebLogic Serverプログラム・ファイルが格納されるディレクトリ(通常は c:\oracle\wlserver_12.1)に対応するディレクトリです。

ただし、DefaultFileStoreMBeanパラメータを直接操作するか、WebLogic Server管理コンソールを使用してデフォルト・ストアの場所を変更できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルト・ストアの設定の変更に関する項を参照してください。

デフォルト・ファイル・ストアの例

ドメインの構成ファイルでのデフォルト・ファイル・ストアの定義例を示します。この例では、デフォルトのディレクトリと同期書込みポリシーの設定がオーバーライドされています。

<server
<name>myserver</name>
<default-file-store>
<directory>C:/store</directory>
<synchronous-write-policy>Disabled</synchronous-write-policy>
</default-file-store>
</server>

4 カスタム永続ストアの使用

この章では、WebLogic Server永続ストアを構成およびモニターする方法について説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。

- カスタム・ファイル・ストアとJDBCストアとは

- カスタム永続ストアを使用すべき状況

- カスタム永続ストアの作成方法

- カスタム永続ストアのパラメータの変更

カスタム・ファイル・ストアとJDBCストアとは

デフォルトのファイル・ストアを使用するだけでなく、特定のニーズに合わせてファイル・ストアやJDBCストアを構成することもできます。デフォルト・ファイル・ストアと同様、カスタム・ファイル・ストアもディレクトリに格納された一連のファイルにデータを保持します。一方、カスタム・ファイル・ストアを作成して、特定のストレージ・デバイスにデータを保持したり、ファイル・ストアにアクセスするJMSサービスがクラスタ内の別のサーバー・メンバーにストアを移行できるようにしたりすることも可能です。ファイル・ストアのディレクトリを構成する場合は、そのファイル・ストアが配置されているサーバー・インスタンスにアクセスできるディレクトリを設定する必要があります。

JDBCストアは、リレーショナル・データベースをストレージとして使用している場合に構成できます。JDBCストアを使用することで、指定のJDBCデータ・ソースを介してアクセスできる標準のJDBC対応データベースに永続メッセージを格納できます。JDBCストアのデータベース表に格納されたデータには、WLStoreという論理名が付けられます。データベースの高可用性とパフォーマンスを構成するかどうかは、データベース管理者の判断です。JDBCストアでは、JMSサービスを自動または手動で移行する移行可能ターゲットをサポートすることもできます。

永続ストアの構成の詳細は、「カスタム永続ストアを使用すべき状況」を参照してください。

カスタム永続ストアを使用すべき状況

WebLogic Serverでは、カスタム・ファイル・ストアやJDBC対応のストアを作成するための構成オプションが用意されています。たとえば、次のような操作を一時的に行う場合があります。

- ファイル・ストアのファイルを特定のデバイスに配置します。

- 特定のサーバー・インスタンスで、ファイル・ストアの代わりにJDBCストアを使用します。トランザクション・ログを保持する場合は、JDBC TLOGストアを使用します。「JDBC TLogストアの使用」を参照してください

- クラスタ内のすべての物理ストアで同じ論理名を共有します。

- 異なるサービスを論理的に分けて、別々のファイルや表を使用します。(これにより、パフォーマンスは下がりますが、管理や保守は容易になります。)

- 移行可能なJMS関連サービスでは、デフォルトの永続ストアは使用できません。したがって、カスタム・ストアを構成し、移行可能なJMSサービスと同じ移行可能なターゲットにターゲット指定する必要があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項を参照してください。

カスタム永続ストアの作成方法

カスタム永続ストアは、次の方法で構成できます。

- WebLogic Server管理コンソールを使用する。カスタム・ファイル・ストアまたはJDBCストアを構成する場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの永続ストアの構成に関する項を参照してください。JDBC TLOGストアを構成する場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・ログ・ストアの構成に関する項を参照してください。

- 永続ストアをホストするサーバー・インスタンスの構成ファイル(config.xml)を直接編集します。

- WebLogic Java Management Extensions (JMX)を使用して永続ストアを作成します。JMXはネットワーク上のリソースをモニターおよび管理するためのJava EEソリューションです。詳細は、を参照してください。

- WebLogic Scripting Tool (WLST)を使用して永続ストアを作成します。WLSTは、WebLogic Serverインスタンスとドメインに対して、相互作用や構成のために使用するコマンド行スクリプト・インタフェースです。詳細は、『WebLogic Scripting Toolの理解』を参照してください。

- WebLogic構成ウィザードを使用して、デフォルト永続ストアのオプションを変更します。構成ウィザードを使用して永続ストアを構成する方法の詳細は、『WebLogic構成ウィザードによるドメインの作成』のWebLogicドメインの作成に関する項を参照してください。

カスタム永続ストアのパラメータの変更

JDBCストアの接頭辞やファイル・ストアのディレクトリなど、特定のカスタム・ストアの構成オプションの変更において次を実行する場合、サーバーの再起動は必ずしも必要ではありません。

1. (カスタム・ストアを使用するJMSサーバーなど)依存するサービスのターゲットをnullに設定し、カスタム・ストアのターゲットをnullに設定します。(サービスのターゲットをnullに設定すると、暗黙的にサービスが停止します。)

2. カスタム・ストアのターゲットを元の値に戻し、依存するリソースのターゲットを元の値に戻すことによってプロセスを元に戻します。

カスタム・ストアとJMSサーバーが移行可能ターゲットを共有する場合、移行可能ターゲットを管理的に再起動することができます。

5 カスタム・ファイル・ストアの使用

この章では、WebLogic Serverでカスタム・ファイル・ストアを構成する方法について説明します。次の項が含まれます:

- カスタム(ユーザー定義)ファイル・ストアの作成

- カスタム・ファイル・ストアを構成する主な手順

- カスタム・ファイル・ストアの例

- 同期書込みポリシーの構成のガイドライン

カスタム(ユーザー定義)ファイル・ストアの作成

次の項では、カスタム・ファイル・ストアの例を示し、同期書込みポリシーを選択する上での構成ガイドラインについて説明します。

カスタム・ファイル・ストアを作成する場合は、デフォルトのFileStoreMBeanパラメータを直接変更できます。WebLogic Server管理コンソールを使用してカスタム・ファイル・ストアを作成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのファイル・ストアの作成に関する項を参照してください。

カスタム・ファイル・ストアを構成する主な手順

カスタム・ファイル・ストアを作成するための主な手順は次のとおりです。

1. ファイル・ストアのデータを格納するディレクトリを作成します。

2. カスタム・ファイル・ストアを作成し、作成したディレクトリの場所を指定します。

3. カスタム・ファイル・ストアにアクセスするサブシステムまたは移行可能ターゲットに、以下の方法でカスタム・ファイル・ストアを関連付けます。

- JMSサーバーの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。

- ストア・アンド・フォワード・エージェントの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。

- パス・サービスの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。

カスタム・ファイル・ストアの例

ドメインの構成ファイルでのデフォルト・ファイル・ストアの定義例を示します。この例では、ファイルが/disk1/jmslogディレクトリに保持されるように定義されています。

<file-store>
<name>SampleFileStore</name>
<target>myserver</target>
<directory>/disk1/jmslog</directory>
</file-store>

表5-1に、ファイル・ストアの変更可能な構成パラメータについて簡単にまとめます。

表5-1 カスタム・ファイル・ストアの構成オプション

オプション

必須

機能

名前

○

ファイル・ストアの名前。ドメイン内のすべてのストアの間で一意であることが必要です。

ターゲット

○

ファイル・ストアをターゲット指定するサーバー・インスタンス、クラスタまたは移行可能ターゲット。複数のサブシステムが同じサーバー・インスタンスまたは移行可能ターゲットをターゲット指定していれば、これらのサブシステムで同じファイル・ストアを共有できます。

注意:

- クラスタを使用してJMSサーバーをホストしている場合は、JMSサーバーが使用するクラスタと同じクラスタにファイル・ストアをターゲット指定する必要がある。参照

- JMSサービスで移行可能対象を使用する場合は、ファイル・ストアを同じ移行可能対象に対象指定する必要がある。『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項を参照してください。

ディレクトリ

○

ファイル・ストアを保持するディレクトリのファイル・システム上のパス名。

注意: ファイル・ストアに移行可能なターゲットを指定する場合、ストア・ディレクトリは移行可能なターゲットのすべての候補サーバー・メンバーからアクセスできる必要があります。最高レベルの可用性を実現するには、SAN(ストレージ領域ネットワーク)またはデュアルポートSCSIディスクのいずれかを使用してください。『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項を参照してください。

既存のファイル・ストアのディレクトリを変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。

CacheDirectory

×

この設定は、Direct-Write-With-Cacheファイル・ストアの同期書込みポリシーにのみ適用されます。「同期書込みポリシーの構成のガイドライン」を参照してください

論理名

×

必要に応じて、EJBなどのサブシステムでモジュールをクラスタ全体にデプロイする場合に使用します。ただし、クラスタ内のサーバー・インスタンスごとに別々の物理ストアが必要になります。このような構成では、各物理ストアに固有の名前を付けますが、すべての永続ストアで同じ論理名を共有します。

同期書込みポリシー

×

個別の書込み操作の永続性を含む、ファイル・ストアのIO動作を定義します。指定できる値は、直接書込み(デフォルト)、直接書込み - キャッシュあり、キャッシュ・フラッシュ、および無効です。

詳細は、「同期書込みポリシーの構成のガイドライン」を参照してください。

WebLogic Server管理コンソールを使用してカスタム・ファイル・ストアを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのファイル・ストアの作成に関する項を参照してください。

同期書込みポリシーの構成のガイドライン

ファイル・ストアで使用できる複数の同期書込みポリシーがあります。同期書込みポリシーでは、ファイル・ストアの書込み操作の動作が決まります。環境に最適で、実行時のパフォーマンスや万が一のクラッシュ発生後のデータ整合性のニーズを満たすポリシーを選択する必要があります。同期書込みポリシーのチューニングとパフォーマンスおよびファイル・ストアの他のオプションの詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のWebLogic永続ストアのチューニングに関する項を参照してください。

注意:

実行中のカスタム・ファイル・ストアまたはデフォルト・ファイル・ストアの同期書込みポリシーとドライバを表示するには、サーバー・ログのWL-280008およびWL-280009メッセージを確認してください。

直接書込み - キャッシュありポリシー

ほとんどのシナリオでは、直接書込み - キャッシュありポリシーをご使用をお薦めします。このポリシーを選択すると、WebLogic Serverは、ネイティブなI/O wlfileioドライバを使用して、ファイル・ストアの構成のDirectory属性で定義された場所に格納される一連のプライマリ・ファイルに同期的に書き込みます。また、WebLogic Serverは、ファイル・ストアの構成のCacheDirectory属性で定義された場所にある、対応するキャッシュ・ファイルにも非同期に書き込みます。これは、OSメモリーにより、プライマリ・データ・ファイル用の出力バッファとしてキャッシュ・ファイル・ブロックをキャッシュすることで、暗示的に実行されます。キャッシュ・ファイルは、実行時と起動時のパフォーマンスの最適化、およびリカバリのために使用されます。ネイティブ・ファイル・ドライバによる直接的な書込みおよび対応するキャッシュ・ファイルの組合の使用により、ディスクへの書込みが最も安全に実施され、全体的に最良のパフォーマンスが実現されます。

このオプションでは、他のポリシーの約2倍のディスク領域が使用され、ファイルは2つの場所に格納されます。これらの場所のディスク領域の割当を考慮し、両方の場所を確保しておく必要が場合があります。

Direct-Write-With-Cacheポリシーでファイルの場所を構成する場合は、高可用性(サーバー全体の移行またはサービスの自動移行)のために構成する場合であっても、CacheDirectory属性の場所はローカル・ディレクトリである必要があります。キャッシュ・ファイルはパフォーマンスの最適化のためにのみ使用されます。メッセージの実際の永続ストレージは、ファイル・ストアの構成のDirectory属性によって定義されます。移行されたWebLogic ServerインスタンスまたはJMSサービスは、移行後にこのディレクトリのみを使用できる必要があります。障害時リカバリの場合も同様ですが、Directory場所で定義されたファイルをバックアップ・サイトにレプリケートする必要があります。

注意:

ファイル・ストアのネイティブwlfileioドライバがロードできない場合は、ストアは代替の特化されたDirect-Writeポリシー・モードで自動的に実行されます。実行中のカスタム・ファイル・ストアまたはデフォルト・ファイル・ストアの構成済と実際の同期書込みポリシーとドライバを表示するには、サーバー・ログでWL-280008とWL-280009メッセージを確認してください。

以前のバージョンのMicrosoft Windowsでは、WindowsのデフォルトのWrite Cache Enabled設定を使用すると、ストレージ・デバイスの同期書込みの完了は正しく報告されません。システム・クラッシュや停電が発生したときは、レコードやメッセージが失われたり、重複されたりするからです。これにより、直接書込み(デフォルト)または直接書込み - キャッシュありポリシーで構成されたファイル・ストアを含む、トランザクション製品(Oracleに固有でない)のトランザクション・セマンティクスが違反されます。ストレージ・デバイスの物理的な機能を超える高い永続メッセージ/トランザクション・スループットの場合、この問題が現れます。この問題を対処するには、Microsoftが提供するパッチを適用するか、WindowsのWrite Cache Enabled設定を無効にするか、または電源保護のあるストレージ・デバイスを使用します。http://support.microsoft.com/kb/281672およびhttp://support.microsoft.com/kb/332023を参照してください。

直接書込みポリシー

Direct-Writeポリシーを選択すると、WebLogic Serverでは、ネイティブのI/O wlfileioドライバを使用して、ファイル・ストアの構成のDirectory属性で定義された場所にあるプライマリ・ファイルのセットに同期に書き込まれます。このポリシーはDirect-Write-With-Cacheポリシーより処理速度が遅いが、少ないディスク領域を使用し、管理する環境の考慮事項もより少ないです。通常は、Direct-Writeポリシーの処理速度はCache-Flushポリシーより速いです。

注意:

以前のバージョンのMicrosoft Windowsでは、WindowsのデフォルトのWrite Cache Enabled設定を使用すると、ストレージ・デバイスの同期書込みの完了は正しく報告されません。システム・クラッシュや停電が発生したときは、レコードやメッセージが失われたり、重複されたりするからです。これにより、直接書込み(デフォルト)または直接書込み - キャッシュありポリシーで構成されたファイル・ストアを含む、トランザクション製品(Oracleに固有でない)のトランザクション・セマンティクスが違反されます。ストレージ・デバイスの物理的な機能を超える高い永続メッセージ/トランザクション・スループットの場合、この問題が現れます。この問題を対処するには、Microsoftが提供するパッチを適用するか、WindowsのWrite Cache Enabled設定を無効にするか、または電源保護のあるストレージ・デバイスを使用します。http://support.microsoft.com/kb/281672およびhttp://support.microsoft.com/kb/332023を参照してください。

キャッシュ・フラッシュ・ポリシー

キャッシュ・フラッシュポリシーを選択すると、WebLogic Serverでは、オペレーティング・システムとストレージ・デバイスのデフォルトのファイル書込み動作が有効になります。デフォルトのファイル書込み動作では、基本的にキャッシングとファイルの書込みのスケジューリングを行いますが、トランザクションが完了する前にキャッシュのディスクへのフラッシュを強制します。書込みがすべてディスクにフラッシュされるまで、トランザクションが完了できません。このポリシーは信頼性と拡張性があり、同時ユーザーの増加に対応できます。このポリシーは、トランザクションが安全ですが、通常のユース・ケースの場合は(同時プロデューサやコンシューマが多数の場合を除く)、実行時のパフォーマンスが直接書込みポリシーより低くなります。

無効ポリシー

無効ポリシーを選択すると、WebLogic Serverはオペレーティング・システムとストレージ・デバイスのデフォルト・ファイル書込み動作に依存します。ほとんどの場合は、ファイル書込みはメモリーにキャッシュされ、ディスクに直接書き込まれることはなく、書込みはスケジューリングされます。通常は、無効ポリシーは、ファイル・ストアのパフォーマンスを大幅に向上しますが、オペレーティング・システムのクラッシュまたはハードウェア障害に伴い、送信メッセージの紛失や受信メッセージの重複が生成する可能性があります。トランザクションは、ディスクへの書込みを待機することなく、書込みがメモリーにキャッシュされた時点で完了するためです。オペレーティング・システムの正常シャットダウンや、WebLogic Serverプロセスの中断でこのような障害が発生することはありません。オペレーティング・システムは、正常シャットダウンの際にすべての未処理の書込みをフラッシュするためです。ビジー・サーバーの電源を突然切断すると、このようなのエラーが発生します。

6 JDBCストアの使用

この章では、WebLogic Server永続ストアを構成およびモニターする方法について説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。

- JDBC対応ストアの作成

- JDBC TLogストアの使用

- JDBCストアの使用

JDBC対応ストアの作成

次の項では、JDBC対応ストアを構成および使用する方法について説明します。

- JDBC TLogストア: トランザクション・ログ(TLOGs)をデータベースに保持します。「JDBC TLogストアの使用」を参照してください

- JDBCストア: WebLogic Serverインスタンス・サービスとサブシステム情報をデータベースに保持します(ただし、TLOGは除きます)。「JDBCストアの使用」を参照してください

JDBC TLogストアの使用

JDBC TLOGストアを構成すると、トランザクション・ログをデータベースに保持できます。これには次の利点があります。

- 基本データベースのレプリケーションとHA特性を活用できます。

- データベースの状態とTLOGを簡単に同期できるため、災害からのリカバリを簡素化できます。

- 実行するトランザクション・ログを新しい場所に移行(コピー)する必要がないため、トランザクション・リカバリ・サービスの移行が向上します。

JDBC TLOGストアを構成する主な手順

JDBC TLOGストアを作成するための主な手順は次のとおりです。

1. JDBCストアへのインタフェースとなるJDBCデータ・ソース、GridLinkデータ・ソースまたはマルチ・データ・ソースを作成します。「データ・ソースの選択」を参照してください

2. JDBC TLOGストアを作成し、これを手順1で作成したJDBCデータ・ソース、GridLinkデータ・ソースまたはマルチ・データ・ソースに関連付けます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・ログ・ストアの構成に関する項を参照してください。

3. オプション。接頭辞オプションに、構成するJDBC TLOGストア表ごとに1つの一意の値を構成することを強くお薦めします。

4. 高可用性のため、データ・ソースをバックアップ・サーバーで利用できるようにします。「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 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ストアの構成オプション

オプション

必須

機能

データ・ソース

○

ストアのデータベース表(WLStore)にアクセスするために、このJDBCストアによって使用されるJDBCデータ・ソースまたはマルチ・データ・ソース。このデータ・ソースまたはマルチ・データ・ソースは、JDBCストアと同じサーバー・インスタンスにターゲット指定される必要があります。

注意: JDBCストアでは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があり、「グローバル・トランザクションのサポート」が無効になっている必要があります。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。

接頭辞名

×

通常、JDBCストアの表の接頭辞は[[[catalog.]schema.]prefix]というフォーマットで指定します。

複数のJDBCストアを使用する場合は、構成するJDBCストアごとに1つの一意の接頭辞を設定する必要があります。接頭辞を指定しないと、JDBCストアの表名は単にWLStoreとなり、データベースではJDBC接続の現在のユーザーに基づいて暗黙的にスキーマが決定されます。また、2つのJDBCストアで同じデータベース表を共有することはできません。詳細は、「JDBCストアでの接頭辞の使い方」を参照してください。

既存のJDBCストアの接頭辞を変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。

DDLファイルからの表の作成

×

JDBCストアのデータベース表(WLStore)を作成するために、オプションで、サポートされるDDLファイルで使用されます。JDBCストアのデータベース表がすでに存在する場合は、このオプションは無視されます。詳細は、「デフォルトおよびカスタムDDLファイルを使用したJDBCストア表の作成」を参照してください。

バッチごとに削除(最大)

デフォルトは20です。

データベースを呼び出すごとに削除される最大表行数。

バッチごとに挿入(最大)

デフォルトは20です。

データベースを呼び出すごとに挿入される最大表行数。

ステートメントごとに削除(最大)

デフォルトは20です。

データベースを呼び出すごとに削除される最大表行数。

MaxRetrySecondsBeforeTLogFail

デフォルトは300です。

WebLogic ServerがJDBC TLogストア障害からのリカバリを試行する最大時間(秒単位)。この期間後でもストアを使用できない場合は、WebLogic Serverによって正常性状態がHEALTH_FAILEDに設定されます。値が0の場合は、WebLogic Serverによって再試行は実行されず、ただちに正常性状態がHEALTH_FAILEDに設定されます。

MaxRetrySecondsBeforeTXRollback

デフォルトは60です。

トランザクションの処理中にWebLogic ServerがJDBC TLogストア障害からのリカバリを試行するまでの最大待機時間(秒単位)。この期間後でもストアを使用できない場合は、影響を受けるトランザクションはWebLogic Serverによってロールバックされます。値が0の場合は、WebLogic Serverによって再試行は実行されず、ただちにトランザクションはロールバックされます。実際の最大値は、MaxRetrySecondsBeforeTLogFailの現在の値よりも小さくなります。

RetryIntervalSeconds

デフォルトは5です。

ストア障害発生後に、WebLogic ServerがTLOGストアの正常性を検証する試行を実行するまでの最大待機時間(秒単位)。

1000

ストアがシャットダウンしてそのストアを待機しているすべての操作のブロックが解除される前に、JDBCストアの再接続再試行、またはTLOG-in-DBストアでのデータベースへの接続の再確立の試行が行われる時間(ミリ秒)。ReconnectRetryPeriodMillisを使用して構成できる最小値は200であり、最大値は300000です。JDBCストアの再接続再試行の詳細は、JDBCストアの再接続再試行の構成を参照してください。

reconnectRetryIntervalMillis

200

接続再試行期間中の再接続試行間の時間(ミリ秒)。ReconnectRetryIntervalMillisを使用して構成できる最小値は100であり、最大値は10000です。JDBCストアの再接続再試行の詳細は、JDBCストアの再接続再試行の構成を参照してください。

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の値が超過するまで、正常に実行されません。

注意:

ロックされたローカル・トランザクションに関する機能は、データベースの種類によって異なります。一部のデータベースでは、データベースのロック状態をただちに解決することが難しい場合があります。アプリケーション環境で基本的な行ロックの問題が発生する場合は、詳細情報についてデータベース管理者に連絡する必要があります。

JDBC TLOGストア使用時のサーバー移行

WebLogic Serverでは、JDBC TLOGストアの使用時にトランザクション・リカバリ・サービスの移行について、手動および自動の両方で実行する機能をサポートしています。JDBC TLOGストアによって使用されるデータ・ストアは、プライマリ・サーバー・インスタンスとバックアップ・サーバー・インスタンスの両方でターゲットにする必要があります。クラスタ内のすべてのサーバー・インスタンスをデータ・ソースのターゲットに指定することをお薦めします。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のサーバーで障害が発生した場合のトランザクション・リカバリに関する項を参照してください。

JDBC TLOGストアのモニター

トランザクション・ログ・ストアの統計および開かれている各ストア接続の統計情報をモニターできます。永続ストアをモニターする方法の詳細は、「WebLogic永続ストアのモニター」を参照してください

JDBC TLOGストアの正常性状態を監視する方法

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ストアの使用

次の項では、JDBCストアの例を示し、既存のDDL、カスタムDDLを使用したJDBCストア用のデータベースの作成について説明します。DDLファイルでOracle blobレコード列を使用にする方法について説明します。

デフォルトのJDBCStoreMBeanパラメータを直接変更してJDBCストアを作成できます。WebLogic Server管理コンソールを使用してJDBCストアを作成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項を参照してください。

JDBCストアで接頭辞を使用する場合の構成ガイドライン、およびJDBCデータ・ソースの推奨設定については、「JDBCストアの構成のガイドライン」を参照してください。

JDBCストアを構成する主な手順

JDBCストアを作成するための主な手順は次のとおりです。

1. JDBCストアへのインタフェースとなるJDBCデータ・ソースまたはマルチ・データ・ソースを作成します。

2. JDBCストアを作成し、これをJDBCデータ・ソースまたはマルチ・データ・ソースに関連付けます。

3. 接頭辞オプションに、構成するJDBCストア表ごとに1つの一意の値を構成することを強くお薦めします。

4. JDBCストアを使用するサブシステムに、JDBCストアを関連付けます。

- JMSサーバーの場合は、「構成:全般」ページで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ストアを共有できます。

注意:

- クラスタを使用してJMSサーバーをホストしている場合は、JMSサーバーが使用するクラスタと同じクラスタにJDBCストアをターゲット指定する必要がある。『Oracle WebLogic Server JMSリソースの管理』の動的にクラスタ化されたJMSの構成に関する項を参照してください。

- JMSサービスで移行可能対象を使用する場合は、JDBCストアを同じ移行可能対象に対象指定する必要がある。『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項を参照してください。

データ・ソース

○

ストアのデータベース表(WLStore)にアクセスするために、このJDBCストアによって使用されるJDBCデータ・ソースまたはマルチ・データ・ソース。このデータ・ソースまたはマルチ・データ・ソースは、JDBCストアと同じターゲットにターゲット指定される必要があります。

注意: JDBCストアでは、非XA JDBCドライバを使用するJDBCデータ・ソースを使用する必要があり、「グローバル・トランザクションのサポート」が無効になっている必要があります。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。

接頭辞名

×

通常、JDBCストアの表の接頭辞は[[[catalog.]schema.]prefix]というフォーマットで指定します。

複数のJDBCストアを使用する場合は、構成するJDBCストアごとに1つの一意の接頭辞を設定する必要があります。接頭辞を指定しないと、JDBCストアの表名は単にWLStoreとなり、データベースではJDBC接続の現在のユーザーに基づいて暗黙的にスキーマが決定されます。また、2つのJDBCストアで同じデータベース表を共有することはできません。詳細は、「JDBCストアでの接頭辞の使い方」を参照してください。

既存のJDBCストアの接頭辞を変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。

論理名

×

必要に応じて、EJBなどのWebLogic Serverサブシステムでモジュールをクラスタ全体にデプロイする場合に使用します。ただし、クラスタ内のサーバー・インスタンスごとに別々の物理ストアが必要になります。このような構成では、各物理ストアに固有の名前を付けますが、すべての永続ストアで同じ論理名を共有します。

DDLファイルからの表の作成

×

JDBCストアのデータベース表(WLStore)を作成するために、オプションで、サポートされるDDLファイルで使用されます。JDBCストアのデータベース表がすでに存在する場合は、このオプションは無視されます。詳細は、「デフォルトおよびカスタムDDLファイルを使用したJDBCストア表の作成」を参照してください。

WebLogic Server管理コンソールを使用してJDBCストアを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項を参照してください。

サポートされる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ストア表の作成」を参照してください。

デフォルトおよびカスタム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ストアは起動に失敗します。

カスタムDDLファイルを使用したJDBCストア表の作成

「サポートされるJDBCドライバ」のリストにないデータベースを使用する場合は、既存のDDLテンプレート・ファイルをコピーし、使用するデータベースに合わせて編集できます。

1. 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ファイル全体が抽出されます。

2. 使用しているデータベースに合わせてDDLファイルを編集します。SQLコマンドは複数行にわたって指定できます。末尾にはセミコロン(;)を付けます。シャープ記号(#)で始まる行はコメントです。

3. 変更を保存し、新しいDDLの名前を適切な名前に変更します(例: mydatabase.ddl)。

4. Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項に従って、JDBCストアを作成します。

5. 「構成」ページの「DDLファイルからの表の作成」オプションを使用して、カスタムDDLファイルを指定します(例: /mydatabase.ddl)。

注意:

Windowsシステムの場合、フルパス名には必ずドライブ文字を含めます。

Oracle BLOBレコード列の有効化

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を使用するには

1. JDBCストアを使用するサーバー・インスタンスを停止します。

2. 「JDBCストア表の管理」の説明に従って、現在のJDBC表を削除します。

3. サーバー・インスタンスを再起動します。

4. Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項に従って、新しいJDBCストアを作成します。

5. 「全般的な構成」ページの「DDLファイルからの表の作成」フィールドで、次の場所を入力します。

- oracle_blob.ddlファイルは、/oracle_blob.ddl

- oracle_blob_securefile.ddlファイルは、/oracle_blob_securefile.ddl

6. 「完了」をクリックすると、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ストア表の管理

JDBC utils.Schemaユーティリティを使用すると、既存のバージョンを削除することで新しいJDBCストア・データベース表(WLStore)を再生成できます。通常、この表は自動的に作成されるため、このユーティリティを実行する必要はありません。しかし、既存のJDBCストア・データベース表に障害が発生した場合は、utils.Schemaユーティリティを使用して削除できます。

utils.SchemaユーティリティはJavaプログラムで、以下の項目を指定するコマンド行引数をとります。

- JDBCドライバ

- データベース接続情報

- データベース表を作成するSQLデータ定義言語(DDL)コマンドを含むファイルの名前

utils.Schemaユーティリティを使用したJDBCストア表の削除

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

省略可能なコマンド・オプション。

データベースの必要に応じて、以下のものを指定します。

- ユーザー名とパスワードを次のように指定します。

-u <username> -p <password>

- JDBCデータベース・サーバーのドメイン・ネーム・サーバー(DNS)名。次のように指定します。

-s <dbserver>

-verboseオプションも指定可能です。このオプションを指定すると、utils.Schemaは実行時にSQLコマンドをエコーします。

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ストアまたはTLOG in-DBストアがデータベースへの接続を再試行する時間を示します。ストアの再試行期間は、コマンド行のシステム・プロパティ、MBeanおよびWLSTを使用して構成できます。

WLSTおよびJMX MBeanの使用

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ストアの再接続再試行期間はミリ秒単位で構成します。

JDBCストアの接続キャッシング・ポリシーの構成

デフォルトでは、WebLogic JDBCストアは、データ・ソースから2つのJDBC接続を取得し、ストアが存続している間、それらの接続をキャッシュします。必要に応じて、JDBCストアの接続キャッシング・ポリシーをチューニングし、キャッシュされるJDBC接続の数を減らすことができます。

- WLSTおよびJMX MBeanの使用

- コマンド行パラメータの使用

WLSTおよびJMX MBeanの使用

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ストアの接続キャッシングの動作

JDBCストアの接続キャッシングの動作は、接続キャッシング・ポリシー設定およびワーカー数設定の組合せによって判断されます。次の表は、各組合せで予期される動作を示しています。

表6-5 JDBCストアの接続キャッシング・ポリシーの動作

接続キャッシング・ポリシー

ワーカー数=1の場合のキャッシュされる接続

ワーカー数>1の場合のキャッシュされる接続

説明

DEFAULT

2

2+ワーカー数

デフォルトでは、各JDBCストア・インスタンスは、ストアが存続している間、2つのデータベース接続をキャッシュします。

JDBCストアのワーカー数に2より大きい数が構成されている場合、ストアは各ワーカーに追加の接続を開きます。

MINIMAL

1

1+ワーカー数

各JDBCストア・インスタンスは、ストアが存続している間、単一のデータベース接続をキャッシュします。JDBCのワーカー数に2以上が構成されている場合、ストアは各ワーカーに1つの接続を開きます。

同時実行性が低いメッセージング・シナリオの場合、この設定のパフォーマンスはDEFAULTより劣ることがあります。

NONE

0

該当なし

各JDBCストア・インスタンスは、必要に応じてデータ・ソースから接続を取得し、終了時にその接続を解放します。

NONE設定はJDBCストアのワーカー数が2以上の場合は互換性がなく、構成検証の例外となります。この設定のパフォーマンスはDEFAULTまたはMINIMALより劣ります。

警告: WebLogic Serverがデッドロックする危険を避けるために、接続キャッシング・ポリシーNONEのJDBCストアに専用のデータ・ソースを構成することをお薦めします。

接続キャッシング・ポリシーNONEのチューニングに関する重要な考慮事項

JDBCストアの接続キャッシング・ポリシーにNONEを設定する場合は、次のチューニングの考慮事項に留意することが重要です。

- 専用のデータ・ソースを使用してデッドロックを回避します - JDBCストアの接続キャッシング・ポリシーにNONEを設定する場合は、JDBCストアが専用のデータ・ソースを使用するように構成することをお薦めします。NONEポリシーのJDBCストアでは、データ・ソースをアプリケーションまたはストア以外のサービスと共有するように構成した場合、サーバーがデッドロックするか、最終的に障害が発生することがあります。
たとえば、次の手順を実行するアプリケーションについて考えてみてください。

1. データ・ソース接続を取得します。

2. 同じデータ・ソースを使用するNONEポリシーのJDBCストアを持つJMSサーバーを介して永続的なJMSメッセージを送信します。

3. データ・ソース接続を閉じます。

- 手順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ストアの接頭辞を使用する場合のガイドライン、JDBCストア用のWebLogic JDBCデータ・ソースの推奨設定、およびJDBCストアを使用したJMSトランザクションの処理について説明します。

JDBCストアでの接頭辞の使い方

JDBCストア・データベースには、WLStoreというデータベース表が含まれます。このデータベース表は、WebLogic Serverによって自動的に生成され、内部的に使用されます。JDBCストアには任意指定の接頭辞名パラメータがあり、これを使用するとより正確にデータベース表にアクセスできます。

特に次のような場合、JDBC WLStore表名用に接頭辞を構成するのがベスト・プラクティスです:

- データベースに完全修飾名を指定する必要がある。(これについてデータベース管理者に確認する必要があります。)

- 複数のJDBCストアが同じ表を共有できないため、1つのデータベースを複数のJDBCストアのインスタンスで共有している。

- データベースに多くの表が含まれている。接頭辞を設定することで、起動時に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データ・ソースの推奨設定

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データ・ソースの管理』の接続作成の再試行の有効化に関する項を参照してください。

Oracle DB2 Type 4 JDBCドライバの必要設定

JDBCストアとして使用するデータ・ソースでDB2用のOracle Type 4 JDBCドライバを使用する場合は、JMSの内部的なバッチ処理の要件を満たすため、BatchPerformanceWorkaroundプロパティを「true」に設定する必要があります。

JDBCストアを使用したJMSトランザクションの処理

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操作を同時に処理するよう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の値を小さく調整してパフォーマンスを向上させます。

Oracle Database用ストア表索引の再構築

I/Oマルチスレッド処理を有効にすると、ストアI/O処理を同時に実行するために複数のJDBC接続が使用されます。この結果、データベース・リソースの競合が発生する可能性があります。Oracle Database上の競合を低減するには、I/Oマルチスレッド処理の使用時に主キー索引をリバース・キー索引に再構築することをお薦めします。I/Oマルチスレッド処理を使用してから無効にする場合、主キー索引を非リバース・キー索引に再構築することをお薦めします。リバース・キー索引に関する詳細については、『Oracle Databaseの概念』の索引および索引が整理された表に関する項を参照してください。

次の基本手順を実行し、Oracle Database用ストア表索引を再構築します。

1. ストア・スキーマ名の下にあるOracle Databaseにログインします。ストア・スキーマ名は、データ・ソース・ユーザー名と同じでも異なっていても有効です。

2. 『Oracle Database用リバース索引の構築』または「Oracle Database用非リバース索引の構築」に記載したPL/SQLスクリプトを使用し、必要に応じてストア表索引を再構築します。「JDBCストアでの接頭辞の使い方」で説明したように、各スクリプトの<Store Table Name>をストア表名に置き換えますPL/SQLの詳細については、Oracle DatabaseコンセプトのPL/SQLサブプログラムの実行に関する項を参照してください。

注意:

リバース索引はI/Oマルチスレッド処理に使用し、非リバース索引はシングル・スレッドI/Oに使用することをお薦めします。

Oracle Database用リバース索引の構築

ストア表索引を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用非リバース索引の構築

ストア表索引を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;
/

非Oracle Databaseでの競合の低減

非Oracle Databaseで競合を低減する方法については、データベース・プロバイダのドキュメントを参照してください。

7 WebLogic永続ストアの管理

この章では、管理ユーティリティの使用方法とストア・データの保護方法について説明します。

- 永続ストアの管理

- ファイル・ストア・データの保護

永続ストアの管理

WebLogicストア管理ユーティリティを使用すると、管理者はWebLogic永続ストアのトラブルシューティングを行うことができます。ストア・ユーティリティは、実行中のサーバー・インスタンスによって現在開かれていないストアのみで動作します。このユーティリティは、Javaコマンド行またはWebLogic Scripting Tool (WLST)から実行できます。詳細は、「Javaコマンド行を使用したストアの管理」および「WLSTを使用したストアの管理」を参照してください。

ストア管理の最も一般的な使用例は、サイズを減らすためにファイル・ストアを圧縮する場合や、トラブルシューティングを目的としてファイル・ストアまたはJDBCストアの内容をXMLファイルにダンプする場合です。これらの使用例については後ほど説明します。

表7-1に、JavaおよびWLSTで使用できるストア管理コマンドを示します。

表7-1 永続ストアの管理オプション

Javaコマンド

WLSTメソッド

機能

help

helpstore

使用できるコマンド、使用方法、使用例を表示します。

compact

compactstore

ファイル・ストアによって占有されているスペースを圧縮およびデフラグします。このコマンドはオフラインでのみ機能し、JDBCストアには使用できません。

注意:ファイル・ストアの圧縮は、通常、ファイル・ストアが再び現在のサイズになるとわかっている場合は必要ありません。ファイル・ストアは、削除したレコードによって解放されたスペースを自動的に再利用し、新しいレコードに対して内部スペースが足りない場合にのみ展開します。また、ファイル・ストアは通常、ほとんどの永続レコードは存続期間が短いため、断片化されません。

openfile

openfilestore

それ以降の処理のために既存のファイル・ストアを開きます。ファイル・ストアが存在しない場合は、-createパラメータに基づいて、開かれた状態の新しいファイル・ストアが作成されます。

openjdbc

openjdbcstore

それ以降の処理のために既存のJDBCストアを開きます。JDBCストアが存在しない場合は、開かれた状態の新しいJDBCストアが作成されます。

dump

dumpstore

ストアまたは接続の内容を、人間が読取れる形式でユーザー指定のXMLファイルにダンプします。XMLファイルの形式は、永続ストアの診断イメージで使用する形式と同じです。

list

liststore

ストア名、開かれているストア、またはストア内の接続を一覧表示します。

n/a

getstoreconns

指定したストア内の接続のリストを戻します(スクリプト・アクセス用)。

n/a

getopenstores

開かれているストアのリストを戻します(スクリプト・アクセス用)。

opts

n/a

ストア管理ツールの呼出しオプションを一覧表示します。

verbose

n/a

追加情報(スタック・トレースなど)の表示を制御します。

close

closestore

開かれているストアを閉じます。

quit

exit

ストア管理セッションを終了します。

永続ストアは、ファイル・システム(ファイル・ストア)またはJDBC対応のデータベース(JDBCストア)によってバッキングできます。openfile/openfilestore()オプションとopenjdbc/openjdbcstore()オプションを除けば、これら2種類のストアを操作するオプションに違いはありません。

ほとんどのコマンドとメソッドはストア名に対して実行でき、それ以外のコマンドやメソッドも接続名に対して実行できます。ストア接続は、永続ストア内のレコードの論理グループです。たとえば、JMSおよびJTAサブシステムでは、それぞれに対応するレコードが同じファイル・ストア内の別々の接続に永続化されます。

Javaコマンド行を使用したストア管理

Javaコマンド行から永続ストア管理ユーティリティを起動するには、次のように入力します。

> java weblogic.store.Admin
> storeadmin->

ストア管理ヘルプの使用

helpと入力すると、使用できるストア管理コマンドの詳細な説明と、典型的なコマンド使用例が表示されます。次に示す例は、ストア名、開かれているストア、またはストア内の接続を一覧表示するlistコマンドについての包括的なヘルプです。

storeadmin->help list
Command:
list
Description:
lists store names, open stores, or connections in a store
Usage:
list [-store storename|-dir dir]
Examples:
list #lists all opened stores by storename
list -store store1 #lists all connections in store1
list -dir dir1 #lists all storenames found in dir1

ファイル・ストアの内容のダンプ

ここでは、一連のストア管理コマンドを使用して、myfilestoreに指定したファイル・ストアの内容を、人間が読取れるXMLファイル形式で一時ディレクトリにエクスポートする例を示します。この例では、ストアの接続名や実際のレコードの内容はダンプされません。これらをダンプするには、-connパラメータや-deepパラメータを指定する必要があります。

> storeadmin-> list -dir .
> storeadmin-> openfile -store myfilestore -dir .
> storeadmin-> dump -store myfilestore -out d:\tmp\filestore1-out
> storeadmin-> close -store myfilestore

listコマンドは、現在のディレクトリ内にあるすべてのストア名を表示します。dumpやlist (開かれているストアを一覧表示する場合のみ)などの管理機能を呼び出す前に、まずopenfileコマンドやopenjdbcコマンドを実行してファイルやJDBCストアを開く(または作成して開く)必要があります。開かれているストアの管理操作が完了したら、closeコマンドでストアを閉じる必要があります。

ファイル・ストアの圧縮

ここでは、mystoresディレクトリ内でファイル・ストアによって占有されるスペースを、compactコマンドを使用して圧縮する例を示します。

> storeadmin->compact -dir c:\mystores -tempdir c:\tmp

compactコマンドは、開かれていないファイル・ストアに対してのみ実行できます。-dirソース・ディレクトリ内のファイルを格納するストアはすべて閉じておく必要があります。また、「tempdir」一時ディレクトリには、少なくともソース・ディレクトリと同程度の余分なスペースが必要です。一時ディレクトリとして、ソース・ディレクトリ内のディレクトリを指定することはできません。圧縮が正常に完了すると、新たに圧縮されたストア・ファイルがmystoresディレクトリに格納されます。さらに、tmpディレクトリの下に一意の名前の新しいディレクトリが作成され、圧縮前のストア・ファイルが格納されます。

WLSTを使用したストア管理

WLSTインタフェースには、Javaコマンド行にはないメソッドが用意されています。たとえば、関連するJavaオブジェクトを戻し、WLSTのスクリプトで使用できるgetopenstoresおよびgetstoreconnsなどです。

注意:

このリリースでは、WebLogic Scripting Tool (WLST)をオフラインで使用する場合には、ThreeStepThreshold、Worker CountおよびWorker Preferred Batch Sizeはサポートされません。

ストア管理ヘルプの使用

WLSTから永続ストア管理ユーティリティにアクセスするには、次のように入力します。

> java weblogic.WLST

helpstore()と入力すると、使用できるストア管理コマンドの詳細な説明と、典型的なコマンド使用例が表示されます。次に示す例は、ストア名、開いているストア、またはストア内の接続を一覧表示するlistコマンドについてのヘルプです。

> wls:/offline> helpstore(liststore)
lists storenames, opened stores, or connections (for interactive access)
Parameters store and dir cannot both be specified concurrently.

Usage: liststore(store='null',dir='null')

@param store [optional] a previously opened JDBC or File store's name.
If store is specified, all connections in the store are listed.
@param dir [optional] directory for which to list available store names
If dir is specified, all store names in the directory are listed.

If neither store nor dir are specified, all open store names are listed.
@return 1 on success, 0 on failure

なお、等号記号=が付いているパラメータは省略可能です。たとえば、compactstoreメソッドは、compactstore(dir='storename', tempdir='/tmp')のように呼び出すこともできますが、compactstore(store='storename')のように呼び出してtempdirのデフォルト値を使用することもできます。省略可能なパラメータのデフォルト値は、コマンド固有のヘルプに一覧表示されます。

WLSTを使用したJDBCストアの内容のダンプ

ここでは、dumpstoreメソッド(store、outfile、conn='null'、deep='false')を使用して、myJDBCStoreというJDBCストアの内容を、人間が読めるXMLファイル形式でmystoredump-out.xmlというファイルにエクスポートする例を示します。この例では、ストアの接続名や実際のレコードの内容はダンプされません。これらをダンプするには、オプションのconnとdeepパラメータを指定する必要があります。

> wls:/offline>
openjdbcstore('myJDBCStore', 'oracle.jdbc.OracleDriver',
'jdbc:oracle:thin:@test2k31:1521:test120a', './wlstoreadmin-dump.props',
'jmstest', 'jmstest', '', 'jdbcstoreprefix')
dumpstore('myJDBCStore', 'mystoredump-out')
closestore('myJDBCStore')

dumpstoreやliststore (開かれているストアを一覧表示する場合のみ)などの管理機能を呼び出す前に、まずopenjdbcstoreメソッドやopenfilestoreメソッドを使用してストアを開く(または作成して開く)必要があります。開かれているストアの管理操作が完了したら、closestoreコマンドでストアを閉じる必要があります。

WLSTを使用したファイル・ストアの圧縮

ここでは、compactstoreメソッド(dir,tempdir='null')を使用してmystoresディレクトリ内でファイル・ストアのファイルによって占有されるスペースを圧縮するWLSTスクリプトの例を示します。

> wls:/offline> compactstore('c:\mystores','c:\tmpmystore.dir')

compactstore()メソッドは、開かれていないファイル・ストアに対してのみ使用できます。「dir」ソース・ディレクトリ内のファイルを格納するストアはすべて閉じておく必要があります。また、「tempdir」一時ディレクトリには、少なくともソース・ディレクトリと同程度の余分なスペースが必要です。一時ディレクトリとして、ソース・ディレクトリ内のディレクトリを指定することはできません。圧縮が正常に完了すると、新たに圧縮されたストア・ファイルがmystoresディレクトリに格納されます。さらに、tmpmystoreディレクトリの下に一意の名前の新しいディレクトリが作成され、圧縮前のストア・ファイルが格納されます。

ファイル・ストア・データの保護

ファイル・ストア・データのセキュリティを確保するには、すべてのファイル・ストア・ディレクトリに適切なディレクトリ許可を設定する必要があります。データの暗号化が必要な場合は、適切なサード・パーティ暗号化ソフトウェアを使用する必要があります。

8 WebLogic永続ストアのモニター

この章では、WebLogic Server永続ストアのモニター方法について説明します。

- 永続ストアのモニター

- ストアのモニター

- ストア接続のモニター

永続ストアのモニター

既存の各永続ストアおよび開かれている各ストア接続の統計情報をモニターできます。

ストアのモニター

各永続ストアは、実行時にはPersistentStoreRuntimeMBeanインスタンスによって表わされます。次のオプションが用意されています。

表8-1 永続ストアの実行時オプション

オプション

機能

CreateCount

この永続ストアに対して発行された作成リクエストの数

ReadCount

この永続ストアに対して発行された読込みリクエストの数

UpdateCount

この永続ストアによって発行された更新リクエストの数

DeleteCount

この永続ストアによって発行された削除リクエストの数

ObjectCount

この永続ストアに含まれるオブジェクトの数

Connections

この永続ストアのアクティブな接続の数

PhysicalWriteCount

永続ストアがそのデータを恒久ストレージにフラッシュした回数

ストア接続のモニター

永続ストアは、開かれている各永続ストア接続についてもPersistentStoreConnectionRuntimemMBeanを登録します。以下のオプションが用意されています。

表8-2 永続ストア接続の実行時オプション

オプション

機能

CreateCount

この接続に対して発行された作成リクエストの数

ReadCount

この接続に対して発行された読取りリクエストの数

UpdateCount

この接続によって発行された更新リクエストの数

DeleteCount

この接続によって発行された削除リクエストの数

ObjectCount

この接続に含まれるオブジェクトの数

表8-3に、永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムのランタイム接頭辞名の大部分を示します。

表8-3 永続ストアのランタイム接頭辞名

サブシステム/サービス

ランタイム接頭辞名

デプロイメント

weblogic.deploy.internal

internalはデプロイメント接続の名前

診断サービス

weblogic.diagnostics.internal

internalは診断アーカイブ接続の論理名

EJBタイマー・サービス

weblogic.ejb.timer.internal

internalは、サーバー・インスタンス内で一意に特定されるEJBデプロイメント

JMSサービス

JMSサーバー:

weblogic.messaging.jmsServer.internal

internalはJMSサーバー接続の名前

JMS恒久サブスクライバ:

weblogic.messaging.jmsServer.durablesubs.internal

internalは恒久サブスクライバ接続の名前

JTAトランザクション・ログ(TLOG)

weblogic.transaction.internal

internalはTLOG接続の名前

パス・サービス

weblogic.messaging.PathService.internal

internalはパス・サービス接続の名前

SAFサービス

SAFエージェント

weblogic.messaging.SAFAgent@server1.internal

internalはSAFエージェント接続の名前

SAF恒久サブスクライバ:

weblogic.messaging.SAFAgent@server1.durablesubs.internal

internalは恒久サブスクライバ接続の名前

Webサービス

weblogic.wsee.server.store.internal

internalはWebサービス接続の名前

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。