| Oracle® Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション 11g リリース 1 (10.3.1) B55510-01 |
|
 戻る |
以下の節では、永続ストアをコンフィグレーションおよびモニタする方法について説明します。永続ストアは、永続性を必要とする WebLogic Server のサブシステムおよびサービスに対し、組み込みの高性能なストレージ ソリューションを提供します。
永続ストアは、永続性を必要とする WebLogic Server のサブシステムおよびサービスに対し、組み込みの高性能なストレージ ソリューションを提供します。たとえば、永続 JMS メッセージを格納したり、ストア アンド フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。永続ストアは、ファイルベースのストアまたは JDBC 対応データベースの永続性をサポートします。
表 6-1 に、永続ストアへの接続を作成できる WebLogic サービスおよびサブシステムの多くを示します。永続ストアを使用する各サブシステムには、そのサブシステムを特定するためのユニークな接続 ID が指定されます。
表 6-1 永続ストアのユーザ
| サブシステム/サービス | 格納対象 | 詳細についての参照先 |
|---|---|---|
|
診断サービス |
ログ レコード、データ イベント、収集されたメトリック |
『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』の「WLDF コンフィグレーションについて」 |
|
JMS メッセージ |
永続メッセージ、恒久サブスクライバ |
『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「WLDF コンフィグレーションについて」 |
|
JTA トランザクション ログ (TLOG) |
サーバによって調整された、完了していない可能性のあるコミット済みトランザクションに関する情報 |
『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「トランザクションの管理」 |
|
パス サービス |
メッセージのグループからメッセージング リソースへのマッピング |
『Oracle Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理』の「WebLogic パス サービスの使用」 |
|
ストア アンド フォワード (SAF) サービス エージェント |
SAF 送信エージェントから SAF 受信エージェントに再転送するメッセージ |
『Oracle Fusion Middleware Oracle WebLogic Server ストア アンド フォワードのコンフィグレーションと管理』の「ストア アンド フォワード サービスについて」 |
|
Web サービス |
信頼性のある WebLogic Web サービスの呼び出しによる SOAP 要求メッセージおよび応答メッセージ |
『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC を使用した Web サービスの高度な機能のプログラミング』の「Using Reliable SOAP Messaging」 |
|
EJB タイマー サービス |
EJB タイマー オブジェクト |
『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「エンタープライズ JavaBean について」 |
ストアの接続 ID の詳細については、「ストア接続のモニタ」を参照してください。
永続ストアの主な特徴は以下のとおりです。
各サーバ インスタンスのデフォルト ファイル ストアはコンフィグレーション不要
1 つのストアを複数のサブシステムで共有できる (ただし、すべてのサブシステムが同じサーバ インスタンスまたは移行可能な対象を対象指定していること)
高パフォーマンスのスループットとトランザクション サポート
パラメータを修正してカスタム ファイル ストアや JDBC ストアを作成できる
永続ストアの統計情報と開いているストア接続をモニタできる
クラスタ環境では、カスタマイズしたストアを、サーバ全体レベルまたはサービスレベルで異常のあるサーバからバックアップ サーバに移行できる
永続ストアのパフォーマンス上の主な目標はスループットの向上です。複数のサブシステムが同じサーバ インスタンスまたは移行可能な対象を対象指定していれば、これらのサブシステムで同じ永続ストアを共有できます。
この点が、永続ストアを使用するパフォーマンス上の利点です。なぜなら、同じストアを使用する複数のサービスに関係するトランザクションであっても、そのトランザクションのトランザクション マネージャによって永続ストアが単一のリソースとして扱われるためです。たとえば、JMS と EJB のタイマーが 1 つのストアを共有し、JMS メッセージと EJB タイマーが単一のトランザクションで作成された場合、そのトランザクションは 1 フェーズとなり、リソースの書き込みは 1 回しか発生しません。一方、2 フェーズの場合であれば、リソースごとに 2 回ずつで合計 4 回のリソース書き込みが発生し、加えてトランザクション ログでのトランザクション エントリの書き込みが 1 回発生することになります。
ファイル ストアおよび JDBC ストアは、プロセスのクラッシュやハードウェアの電源障害が発生しても、コミットされた更新を失うことなく存続できます。コミットされていない更新は保持されるとは限りませんが、クラッシュ後にトランザクションが部分的に完了した状態で残されることはありません。
以下に、ファイル ストアと JDBC ストアの類似点と相違点を挙げます。
デフォルトの永続ストアはファイル ストアにしかできない。したがって、JDBC ストアはデフォルトの永続ストアとしては使用できません。
トランザクション ログ (TLOG) はデフォルト ストアにのみ格納できる。
どちらもトランザクションのセマンティクスと保証を備えている。JDBC ストアの書き込みと同様、ファイル ストアの書き込みでもディスクへの保存が保証されており、単に中間キャッシュ (つまり、安全性が保障されないキャッシュ) に保存されるわけではありません。
どちらも同じアプリケーション インタフェースを備えている (アプリケーション コードに違いがない)。
すべての条件が同じ場合、一般的にファイル ストアの方が JDBC ストアよりスループットが高くなる。
|
注意 : データベースが高速なディスクを備えたハイエンドのハードウェア上で実行され、WebLogic Server がそれよりも低速なディスクを備えたハードウェア上で実行されている場合は、JDBC ストアの方がパフォーマンスが良くなる場合もあります。 |
通常、ファイル ストアの方がコンフィグレーションおよび管理が簡単であり、WebLogic のサブシステムが外部コンポーネントに依存する必要もない。
ファイル ストアは、ネットワーク トラフィックを生成しない。JDBC ストアは、データベースが WebLogic Server とは異なるマシンに存在する場合にネットワーク トラフィックを生成します。
JDBC ストアの方が障害回復が容易。JDBC インタフェースが同じネットワーク上の任意のマシンからデータベースにアクセスできるからです。ファイル ストアの場合、ディスクが共有または移行されている必要があります。
ファイル ストア データのセキュリティを確保するには、すべてのファイル ストア ディレクトリに適切なディレクトリ パーミッションを設定する必要があります。データの暗号化が必要な場合は、適切なサード パーティ暗号化ソフトウェアを使用する必要があります。
高可能性の点では、永続ファイルベースのストア (デフォルトまたはカスタム) は、「サーバ全体レベル」の移行機能の一部としてその親サーバとともに移行できます。この場合、サービスレベルではなく、サーバレベルで自動または手動で移行できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サーバ全体の移行」を参照してください。ただし、ファイルベースのストアは、クラスタ内の移行可能な対象サーバからアクセスできる共有ディスク上にコンフィグレーションする必要があります。
ファイルベースのストアおよび JDBC 対応ストアも、ストアを使用してデータを維持する JMS 関連サービス (ストア、JMS サーバ、SAF エージェント、パス サービスなど) の「サービスレベル」の移行の一部として移行できます。サービスレベルの移行は、JMS 関連サービスをグループ化した「移行可能対象」ごとに制御されます。移行可能対象は、クラスタ内のいずれか 1 つの物理サーバでホストされます。このようにホストされているサービスは、ヘルス モニタ サブシステムを使用することで、現在の異常のあるホスト サーバから正常でアクティブなサーバに自動的に移行できます。移行可能対象によってホストされる JMS サービスは、サーバ障害への対処として、または定期的なサーバ メンテナンスの一環として手動で移行できます。移行可能な対象を移行すると、その対象によってホストされているすべての固定サービスも移行されます。サーバレベルの移行の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サービスの移行」を参照してください。
移行可能な JMS 関連サービスで、デフォルトのファイル ストアを使用することはできません。したがって、カスタムのファイル ストアまたは JDBC ストアをコンフィグレーションし、関連付けた JMS サーバ、SAF エージェント、またはパス サービスと同じ移行可能対象にそのストアを対象指定する必要があります。
|
注意 : パス サービスの場合は、専用のカスタム ストアと移行可能対象を使用するのがベスト プラクティスです。 |
また、移行可能なファイル ストアは、クラスタ内の移行可能対象から使用できる共有ディスク上にコンフィグレーションするか、ファイル ストアのデータをバックアップ サーバに移行するための移行前/移行後スクリプトを使用できるようにしておく必要もあります。『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「JMS サービスで使用できるカスタム ストア」を参照してください。
JMS サーバまたは JTA トランザクション ログの移行後に、リモート マシンに存在する永続ストアにアクセスするアプリケーションがある場合は、以下の高可用性ストレージ ソリューションのいずれかを実装する必要があります。
ファイルベース ストア (デフォルトまたはカスタム) - デュアル ポート SCSI ディスクまたはストレージ エリア ネットワーク (SAN) などのハードウェア ソリューションを実装して、共有可能なディスクやリモート マシンからもファイル ストアを利用できるようにする。
|
注意 : ファイル ストアが切断されて再接続された場合、永続 JMS メッセージの送受信を正常に続行するには、ホスト サーバ インスタンスを再起動する必要があります。たとえば、ファイル ストアを含むファイル システムがアンマウントされた後再びマウントされた場合、ホスト サーバを再起動せずに永続 JMS メッセージを送信しようとすると JMS 例外が生成されます。 |
JDBC 対応ストア - JDBC ストアをコンフィグレーションし、JDBC を使用してこのストアにアクセスする。このストアは、別のサーバにあってもかまいません。その後、アプリケーションでは、データベース ベンダによって提供されるあらゆる高可用性ソリューションまたはフェイルオーバ ソリューションを利用することができます。また、JDBC ストアではマルチ データ ソースがサポートされるため、冗長なデータベースや Oracle Real Application Clusters (RAC) など、可用性の高いデータベース システムのノード間でのフェイルオーバが可能です。JDBC マルチ データ ソースの使用の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「JDBC マルチ データ ソースのコンフィグレーション」を参照してください。
あらゆる永続ストア - 高可用性クラスタ化ソフトウェアを使用する。たとえば、VERITAS™ Cluster Server は、WebLogic Server ベースのアプリケーション用の独創的な統合ソリューションを提供します。推奨される高可用性ソフトウェア ソリューションには、上記の他にも IBM HACMP などがあります。
管理サーバを含め、すべてのサーバ インスタンスには、コンフィグレーションが不要なデフォルトの永続ストアがあります。デフォルト ストアはファイルベースのストアで、サーバ インスタンスの data\store\default ディレクトリに格納された一連のファイルにデータを保持します。デフォルト ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ メカニズムを使用することで最適に動作するサブシステムから使用することができます。たとえば、永続ストアがコンフィグレーションされていない JMS サーバは、管理対象サーバ用のデフォルトのストアを使用して永続メッセージングをサポートします。
デフォルト ストアは、DefaultFileStoreMBean パラメータを直接操作してコンフィグレーションできます。この MBean がドメインのコンフィグレーション ファイルに定義されていない場合は、DefaultFileStoreMBean がデフォルト値で常に存在していることがコンフィグレーション サブシステムによって保証されます。
また、Administration Console を使用してデフォルト ストアのパラメータを変更することもできます。たとえば、デフォルトのディレクトリの場所や同期書き込みポリシーを変更できます。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「デフォルト ストアの設定の変更」を参照してください。
デフォルトのファイル ストアを使用するだけでなく、特定のニーズに合わせてカスタム ファイル ストアや JDBC ストアをコンフィグレーションすることもできます。詳細については、「カスタム ファイル ストアと JDBC ストアの使い方」を参照してください。唯一の例外は、JTA トランザクション ログ (TLOG) です。TLOG では、常にデフォルト ストアを使用します。これは、サーバの起動プロセスの初期に必ずトランザクション ログを使用するためです。TLOG の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「トランザクション ログ ファイル」を参照してください。
デフォルト ストアのデータは、ドメインのルート ディレクトリの servername サブディレクトリにある data\store\default ディレクトリに保持されます。
たとえば、デフォルト ファイル ストアのディレクトリ名が指定されていない場合、次のディレクトリがデフォルトになります。
MW_HOME\user_projects\domains\domain-name\servers\server-name\data\store\default
domainname はドメインのルート ディレクトリ (通常は c:\oracle\user_projects\domains\domainname) です。これは、WebLogic Server プログラム ファイルが格納されるディレクトリ (通常は c:\oracle\wlserver_10.3) に対応するディレクトリです。
ただし、DefaultFileStoreMBean パラメータを直接操作するか Administration Console を使用して、デフォルト ストアの格納場所を変更することもできます。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「デフォルト ストアの設定の変更」を参照してください。
デフォルトのファイル ストアを使用するだけでなく、特定のニーズに合わせてファイル ストアや JDBC ストアをコンフィグレーションすることもできます。デフォルト ファイル ストアと同様、カスタム ファイル ストアもディレクトリに格納された一連のファイルにデータを保持します。一方、カスタム ファイル ストアを作成して、特定のストレージ デバイスにデータを保持したり、ファイル ストアにアクセスする JMS サービスがクラスタ内の別のサーバ メンバーにストアを移行できるようにしたりすることも可能です。ファイル ストアのディレクトリをコンフィグレーションする場合は、そのファイル ストアが配置されているサーバ インスタンスにアクセスできるディレクトリを設定する必要があります。
JDBC ストアは、リレーショナル データベースをストレージとして使用している場合にコンフィグレーションできます。JDBC ストアを使用することで、指定の JDBC データ ストアを介してアクセスできる標準の JDBC 対応データベースに永続メッセージを格納できます。JDBC ストアのデータベース テーブルに格納されたデータには、WLStore という論理名が付けられます。データベースの高可用性とパフォーマンスをコンフィグレーションするかどうかは、データベース管理者の判断です。JDBC ストアでは、JMS サービスを自動または手動で移行する移行可能対象をサポートすることもできます。
永続ストアのコンフィグレーションの詳細については、「カスタム永続ストアを使用すべき状況」を参照してください。
WebLogic Server では、カスタム ファイル ストアや JDBC ストアを作成するためのコンフィグレーション オプションが用意されています。たとえば、次のような状況が考えられます。
ファイル ストアのファイルを特定のデバイスに配置する。
特定のサーバ インスタンスで、ファイル ストアの代わりに JDBC ストアを使用する。
クラスタ内のすべての物理ストアで同じ論理名を共有する。
異なるサービスを論理的に分けて、別々のファイルやテーブルを使用する (これにより、パフォーマンスは下がるが、管理や保守は容易になる)。
移行可能な JMS 関連サービスで、デフォルトの永続ストアを使用することはできない。したがって、カスタム ストアをコンフィグレーションし、移行可能な JMS サービスと同じ移行可能対象に対象指定する必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サービスの移行」を参照してください。
カスタム永続ストアは、以下の方法でコンフィグレーションできます。
Administration Console を使用してカスタム ファイル ストアまたは JDBC ストアをコンフィグレーションする。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「永続ストアのコンフィグレーション」を参照してください。
デフォルト永続ストアをホストするサーバ インスタンスのコンフィグレーション ファイル (config.xml) を直接編集する。
WebLogic Java Management Extensions (JMX) を使用して永続ストアを作成する。JMX は、ネットワーク上のリソースをモニタおよび管理するための Java EE ソリューションです。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』を参照してください。
WebLogic Server Scripting Tool (WLST) を使用して永続ストアを作成する。WLST は、WebLogic Server のインスタンスおよびドメインに対して、対話やコンフィグレーションの目的に使用するコマンドライン スクリプト インタフェースです。詳細については、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool ガイド』を参照してください。
WebLogic コンフィグレーション ウィザードを使用して、デフォルト永続ストアのオプションを変更する。コンフィグレーション ウィザードを使用して永続ストアをコンフィグレーションする方法の詳細については、『Oracle Fusion Middleware コンフィグレーション ウィザードを使用したドメインの作成』の「WebLogic ドメインの作成」を参照してください。
JDBC ストアのプレフィックスやファイル ストアのディレクトリなど、特定のカスタム ストアのコンフィグレーション オプションの変更において以下を実行する場合、サーバの再起動は必ずしも必要ではありません。
(カスタム ストアを使用する JMS サーバなど) 依存するサービスの対象を null に設定し、カスタム ストアの対象を null に設定します (サービスの対象を null に設定すると、暗黙的にサービスが停止します)。
カスタム ストアの対象を元の値に戻し、依存するリソースの対象を元の値に戻すことによってプロセスを元に戻します。
カスタム ストアと JMS サーバが移行可能対象を共有する場合、移行可能対象を管理的に再起動することができます。
以下の節では、カスタム ファイル ストアの例を示し、同期書き込みポリシーを選択する上でのコンフィグレーション ガイドラインについて説明します。
カスタム ファイル ストアを作成する場合は、デフォルトの FileStoreMBean パラメータを直接編集できます。Administration Console を使用してカスタム ファイル ストアを作成する方法の詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ファイル ストアの作成」を参照してください。
カスタム ファイル ストアを作成するための主な手順は次のとおりです。
ファイル ストアのデータを格納するディレクトリを作成します。
カスタム ファイル ストアを作成し、作成したディレクトリの場所を指定します。
カスタム ファイル ストアにアクセスするサブシステムまたは移行可能対象に、以下の方法でカスタム ファイル ストアを関連付けます。
JMS サーバの場合は、[コンフィグレーション : 全般] ページでカスタム ファイル ストアを選択します。
ストア アンド フォワード エージェントの場合は、[コンフィグレーション : 全般] ページでカスタム ファイル ストアを選択します。
パス サービスの場合は、[コンフィグレーション : 全般] ページでカスタム ファイル ストアを選択します。
ドメインのコンフィグレーション ファイルでのデフォルト ファイル ストアの定義例を示します。この例では、ファイルが /disk1/jmslog ディレクトリに保持されるように定義されています。
<file-store> <name>SampleFileStore</name> <target>myserver</target> <directory>/disk1/jmslog</directory> </file-store>
表 6-2 に、ファイル ストアの変更可能なコンフィグレーション パラメータについて簡単にまとめます。
表 6-2 ファイル ストアのコンフィグレーション オプション
| オプション | 必須/省略可能 | 機能 |
|---|---|---|
|
名前 |
必須 |
ファイル ストアの名前。ドメイン内のすべてのストアの間でユニークであることが必要。 |
|
対象 |
必須 |
ファイル ストアを対象指定するサーバ インスタンスまたは移行可能対象。複数のサブシステムが同じサーバ インスタンスまたは移行可能対象を対象指定していれば、これらのサブシステムで同じファイル ストアを共有できる。 注意 :JMS サービスで移行可能対象を使用する場合は、ファイル ストアを同じ移行可能対象に対象指定する必要がある。『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サービスの移行」を参照。 |
|
ディレクトリ |
必須 |
ファイル ストアを保持するディレクトリのファイル システム上のパス名。 注意 : ファイル ストアを移行可能対象に指定している場合、ストア ディレクトリは移行可能対象のすべての候補サーバ メンバーからアクセスできなければならない。高可用性を実現するためには、SAN (Storage Area Network) またはデュアル ポート SCSI ディスクを使用する。『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サービスの移行」を参照。 既存のファイル ストアのディレクトリを変更した場合、サーバの再起動は必ずしも必要ではない (「カスタム永続ストアのパラメータの変更」を参照)。 |
|
論理名 |
省略可能 |
必要に応じて、EJB などのサブシステムでモジュールをクラスタ全体にデプロイする場合に使用する。ただし、クラスタ内のサーバ インスタンスごとに別々の物理ストアが必要になる。このようなコンフィグレーションでは、各物理ストアに固有の名前を付けるが、すべての永続ストアで同じ論理名を共有する。 |
|
同期書き込みポリシー |
省略可能 |
必要に応じて、ファイル ストアがディスクにレコードをフラッシュする方法を定義する。指定できる値は、[Direct-Write](デフォルト)、[Cache-Flush]、および [Disabled]。 詳細については、「同期書き込みポリシーのコンフィグレーションのガイドライン」を参照。 |
Administration Console を使用してカスタム ファイル ストアをコンフィグレーションする方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ファイル ストアの作成」を参照してください。
デフォルトの [Direct-Write] ポリシーは、ほとんどのプラットフォームでサポートされます。また、このポリシーは、通常、[Cache-Flush] オプションよりも高速です。潜在的なパフォーマンスを引き出すために、ダイレクト I/O モードのストアによって自動的にネイティブ I/O wlfileio2 ドライバがロードされます。このドライバは、Windows、Solaris、HP、AIX、および Linux プラットフォームで使用することができます。
通常、デフォルト ポリシーから [Disabled] に変更すると、ファイル ストアのパフォーマンスは大幅に向上します。その代わり、オペレーティング システムがクラッシュしたり、ハードウェアの障害が発生したりした場合には、メッセージがトランザクション対応であっても、送信したメッセージが失われたり、同じメッセージを重複して受信したりする可能性があります。これは、書き込みがメモリにキャッシュされると、ディスクに正常に格納されるまで待機せず、すぐにトランザクションが完了するためです。オペレーティング システムでは通常のシャットダウン時に未処理の書き込みをすべてフラッシュするので、OS をシャット ダウンするだけではこうしたエラーは発生しません。こうしたエラーは、ビジー状態のサーバの電源を突然遮断することでエミュレートできます。
|
注意 : 実行中のファイル ストアの同期書き込みポリシーとドライバを確認するには、サーバ ログのBEA-280050 メッセージを参照してください。 |
以下の節では、JDBC ストアの例を示し、既存の DDL を使用した JDBC ストア用のデータベースの作成について説明します。また、DDL ファイルで Oracle blob レコード カラムを有効にする方法についても説明します。
JDBC ストアを作成する場合は、デフォルトの JDBCStoreMBean パラメータを直接編集できます。Administration Console を使用して JDBC ストアを作成する方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「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-3 に、JDBC ストアの変更可能なコンフィグレーション パラメータを示します。
表 6-3 JDBC ストアのコンフィグレーション オプション
| オプション | 必須/省略可能 | 機能 |
|---|---|---|
|
名前 |
必須 |
JDBC ストアの名前。ドメイン内のすべてのストアの間でユニークであることが必要。 |
|
対象 |
必須 |
JDBC ストアを対象指定するサーバ インスタンスまたは移行可能対象。複数のサブシステムが同じサーバ インスタンスまたは移行可能な対象を対象指定していれば、これらのサブシステムで同じ JDBC ストアを共有できる。 注意 :JMS サービスで移行可能対象を使用する場合は、JDBC ストアを同じ移行可能対象に対象指定する必要がある。『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サービスの移行」を参照。 |
|
データ ソース |
必須 |
ストアのデータベース テーブル ( 注意 : グローバル (XA) トランザクションをサポートするようにコンフィグレーションされた JDBC データ ソースは指定できない。したがって、非 XA JDBC ドライバを使用する JDBC データ ソースを指定しなければならない。また、このデータ ソースで [ロギング ラスト リソース] または [2 フェーズ コミットのエミュレート] を有効にすることはできない。この制約によって、JDBC ストアを使用するレイヤ サブシステムの XA 機能が使用できなくなるわけではない。たとえば、WebLogic JMS は、ファイル ストアや JDBC ストアを使用するかどうかに関係なく完全に XA 機能を使用できる。 |
|
プレフィックス名 |
省略可能 |
通常、JDBC ストアのテーブルのプレフィックスは 複数の JDBC ストアを使用する場合は、コンフィグレーションする JDBC ストアごとに 1 つのユニークなプレフィックスを設定する必要がある。プレフィックスを指定しないと、JDBC ストアのテーブル名は単に 既存の JDBC ストアのプレフィックスを変更した場合、サーバの再起動は必ずしも必要ではない (「カスタム永続ストアのパラメータの変更」を参照)。 |
|
論理名 |
省略可能 |
必要に応じて、EJB などの WebLogic Server サブシステムでモジュールをクラスタ全体にデプロイする場合に使用する。ただし、クラスタ内のサーバ インスタンスごとに別々の物理ストアが必要になる。このようなコンフィグレーションでは、各物理ストアに固有の名前を付けるが、すべての永続ストアで同じ論理名を共有する。 |
|
DDL ファイルからのテーブルの作成 |
省略可能 |
JDBC ストアのデータベース テーブル ( |
Administration Console を使用して JDBC ストアをコンフィグレーションする方法については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC ストアの作成」を参照してください。
JDBC ストアを使用する場合、JDBC ドライバを介してアクセスできるデータベースであればバッキング データベースにできます。WebLogic Server では、サポートされるデータベース用の一部の JDBC ドライバが自動的に検出されます。
これらのデータベースごとに対応する DDL (データ定義言語) ファイルがあり、MW_HOME\modules\com.bea.core.store.jdbc_1.0.0.0.jar ファイル内の weblogic/store/io/jdbc/ddl ディレクトリに格納されています。MW_HOME は、WebLogic Server の最上位のインストール ディレクトリです。
表 6-4 サポートされる 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 |
|
Pointbase |
pointbase.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)。
JDBC ストアを作成します。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC ストアの作成」を参照してください。
[コンフィグレーション] ページの [DDL ファイルからのテーブルの作成] オプションを使用して、作成したカスタム DDL ファイルを指定します (例 : /mydatabase.ddl)。
|
注意 : Windows システムの場合、絶対パス名には必ずドライブ文字を含めます。 |
Oracle データベースの場合は、oracle_blob.ddl ファイルを使用すると、レコード カラムの型がデフォルトの LONG RAW 型ではなく BLOB 型の JDBC ストア テーブルを作成できます。oracle_blob.ddl ファイルは、「サポートされる JDBC ドライバ」に示すように、WebLogic CLASSPATH にあらかじめコンフィグレーションされています。
JDBC ストアで Oracle BLOB DDL を使用するには
JDBC ストアを使用するサーバ インスタンスを停止します。
「JDBC ストア テーブルの管理」の説明に従って、現在の JDBC テーブルを削除します。
サーバ インスタンスを再起動します。
新しい JDBC ストアを作成します。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC ストアの作成」を参照してください。
[コンフィグレーション] ページの [DDL ファイルからのテーブルの作成] オプションで、oracle_blob.ddl ファイルの場所として /oracle_blob.ddl を指定します。
[完了] をクリックすると、JDBC ストアのバッキング テーブルが作成されます。
すでに Oracle の LONG RAW カラムに入っているデータを保持する必要がある場合は、この方法で BLOB に切り替えないようにしてください。このような場合は、SQL ALTER TABLE コマンドに関する Oracle ドキュメントを参照してください。
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-5 に utils.Schema のコマンドライン引数を示します。
表 6-5 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 スキーマによって Production カタログ内に作成され、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 のデフォルトの Test Table Name の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「データソースの接続テスト オプション」を参照してください。データベースを再接続する際の試行回数の設定については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「接続作成の再試行の有効化」を参照してください。
JDBC ストアとして使用するデータ ソースで DB2 用の WebLogic Type 4 JDBC ドライバを使用する場合は、JMS の内部的なバッチ処理の要件を満たすため、BatchPerformanceWorkaround プロパティを「true」に設定する必要があります。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Type 4 JDBC ドライバ ガイド』の「パフォーマンスに関する考慮事項」を参照してください。
JDBC ストアは、グローバル (XA) トランザクションをサポートするようにコンフィグレーションされた JDBC データ ソースを使用するようにコンフィグレーションすることはできません。JDBC ストアは、非 XA JDBC ドライバを使用する JDBC データ ソースを使用する必要があります。また、このデータ ソースで [ロギング ラスト リソース] または [2 フェーズ コミットのエミュレート] を有効にすることはできません。この制約によって、JDBC ストアを使用するレイヤ サブシステムの XA 機能が使用できなくなるわけではありません。たとえば、WebLogic JMS は、ファイル ストアや JDBC ストアを使用するかどうかに関係なく完全に XA 機能を使用できます。
JDBC ストアは、XAResource インタフェースを実装しているため、JDBC ストア自体のリソース マネージャとして動作し、JDBC ドライバ レベルより上位のトランザクションを処理します。つまり、ストア自体が XAResource を実装し、メッセージがデータベースに格納されている場合でもそのデータベースに依存せずにトランザクションを処理します。
このため、JDBC ストアとデータベース (JMS メッセージが格納されているデータベースと同じ場合でも) を使用する場合、それは常に 2 フェーズ コミット トランザクションになります。
JDBC ストアと併用する場合の JMS トランザクションの使用の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「WebLogic JMS によるトランザクションの使い方」を参照してください。
パフォーマンスは、以下の方法で向上させることもできます。
データベース作業に使用する JDBC データ ソースを、JMS 送り先と同じサーバ上に配置する。この場合、トランザクションは依然として 2 フェーズですが、より小さいネットワーク オーバーヘッドで処理されます。
JDBC ストアの代わりにファイル ストアを使用する。
通常同じトランザクション内で呼び出されるサービスが複数あれば、これらのサービスが同じストアを共有するようにコンフィグレーションする。
データベース操作を直接実行するアプリケーションで、同じトランザクション内のストア サービス (JMS など) が呼び出される場合は、データベース操作用にロギング ラスト リソース (LLR) を有効にした JDBC データ ソースを使用することを検討する。
LLR による最適化を使用すると、トランザクションは 2 フェーズ コミット プロトコルに従いますが、データベース操作は単一のローカル トランザクションで処理されるため、トランザクション全体のパフォーマンスは向上します。LLR による最適化の使用の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「ロギング ラスト リソース トランザクション オプションについて」を参照してください。
既存の各永続ストアおよび開かれている各ストア接続の統計情報をモニタできます。
永続ストアは、開かれている各永続ストア接続についても PersistentStoreConnectionRuntimemMBean を登録します。以下のオプションが用意されています。
表 6-7 永続ストア接続の実行時オプション
| オプション | 機能 |
|---|---|
|
CreateCount |
この接続に対して発行された作成リクエストの数 |
|
ReadCount |
この接続に対して発行された読み取りリクエストの数 |
|
UpdateCount |
この接続によって発行された更新リクエストの数 |
|
DeleteCount |
この接続によって発行された削除リクエストの数 |
|
ObjectCount |
この接続に含まれるオブジェクトの数 |
表 6-8 に、永続ストアへ続を作成できる WebLogic サービスおよびサブシステムの実行時プレフィックス名のほとんどを示します。
表 6-8 永続ストアの実行時プレフィックス名
| サブシステム/サービス | 実行時プレフィックス名 |
|---|---|
|
デプロイメント |
weblogic.deploy.internal
|
|
診断サービス |
weblogic.diagnostics.internal
|
|
EJB タイマー サービス |
weblogic.ejb.timer.internal
|
|
JMS サービス |
JMS サーバ weblogic.messaging.jmsServer.internal
JMS 恒久サブスクライバ weblogic.messaging.jmsServer.durablesubs.internal
|
|
JTA トランザクション ログ (TLOG) |
weblogic.transaction.internal
|
|
パス サービス |
weblogic.messaging.PathService.internal
|
|
SAF サービス |
SAF エージェント weblogic.messaging.SAFAgent@server1.internal
SAF 恒久サブスクライバ weblogic.messaging.SAFAgent@server1.durablesubs.internal
|
|
Web サービス |
weblogic.wsee.server.store.internal
|
WebLogic ストア管理ユーティリティを使用すると、WebLogic 永続ストアのトラブルシューティングを行うことができます。ストア ユーティリティで操作できるのは、実行中のサーバ インスタンスによって開かれていないストアのみです。このユーティリティは、Java コマンドラインまたは WebLogic Scripting Tool (WLST) から実行できます。詳細については、「Java コマンドラインを使用したストア管理」および「WLST を使用したストア管理」を参照してください。
ストア管理の最も一般的な使用例は、サイズを減らすためにファイル ストアを圧縮する場合や、トラブルシューティングを目的としてファイル ストアまたは JDBC ストアの内容を XML ファイルにダンプする場合です。これらの使用例については後ほど説明します。
表 6-9 に、Java および WLST で使用できるストア管理コマンドを示します。
表 6-9 永続ストアの管理オプション
| Java コマンド | WLST メソッド | 機能 |
|---|---|---|
help |
helpstore |
使用できるコマンド、使用方法、使用例を表示する。 |
compact |
compactstore |
ファイル ストアによって占有されているスペースを圧縮およびデフラグする。このコマンドはオフラインでのみ機能し、JDBC ストアには使用できない。 注意 : ファイル ストアの圧縮は、通常、ファイル ストアが再び現在のサイズになるとわかっている場合は必要ない。ファイル ストアは、削除したレコードによって解放されたスペースを自動的に再利用し、新しいレコードに対して内部スペースが足りない場合にのみ展開する。また、ファイル ストアは通常、ほとんどの永続レコードは存続期間が短いため、断片化されない。 |
openfile |
openfilestore |
それ以降の処理のために既存のファイル ストアを開く。ファイル ストアが存在しない場合は、 |
openjdbc |
openjdbcstore |
それ以降の処理のために既存の JDBC ストアを開く。JDBC ストアが存在しない場合は、開かれた状態の新しい JDBC ストアが作成される。 |
dump |
dumpstore |
ストアまたは接続の内容を、人間が読み取れる形式でユーザ指定の XML ファイルにダンプする。XML ファイルの形式は、永続ストアの診断イメージで使用する形式と同じ。 |
list |
liststore |
ストア名、開かれているストア、またはストア内の接続を一覧表示する。 |
なし |
getstoreconns |
指定したストア内の接続のリストを返す (スクリプト アクセス用)。 |
なし |
getopenstores |
開かれているストアのリストを返す (スクリプト アクセス用)。 |
opts |
なし |
ストア管理ツールの呼び出しオプションを一覧表示する。 |
verbose |
なし |
追加情報 (スタック トレースなど) の表示を制御する。 |
close |
closestore |
開かれているストアを閉じる。 |
quit |
exit |
ストア管理セッションを終了する。 |
永続ストアは、ファイル システム (ファイル ストア) または JDBC 対応のデータベース (JDBC ストア) によってバッキングできます。openfile/openfilestore() オプションと openjdbc/openjdbcstore() オプションを除けば、これら 2 種類のストアを操作するオプションに違いはありません。
ほとんどのコマンドとメソッドはストア名に対して実行でき、それ以外のコマンドやメソッドも接続名に対して実行できます。ストア接続は、永続ストア内のレコードの論理グループです。たとえば、JMS および JTA サブシステムでは、それぞれに対応するレコードが同じストア内の別々の接続に永続化されます。
永続ストア管理ユーティリティを 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 インタフェースには、Java コマンドラインにはないメソッドがいくつか用意されています。たとえば、WLST のスクリプトで使用できる getopenstores や getstoreconns は、適切な Java オブジェクトを返します。
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 のデフォルト値を使用することもできます。省略可能なパラメータのデフォルト値は、コマンド固有のヘルプに一覧表示されます。
ここでは、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 コマンドでストアを閉じる必要があります。
ここでは、mystores ディレクトリ内でファイル ストア ファイルによって占有されているスペースを、compactstore メソッド (dir,tempdir='null') を使用して圧縮する WLST スクリプトの例を示します。
> wls:/offline> compactstore('c:\mystores','c:\tmpmystore.dir')
compactstore() メソッドは、開かれていないファイル ストアに対してのみ使用できます。「dir」ソース ディレクトリ内のファイルを格納するストアはすべて閉じておく必要があります。また、「tempdir」一時ディレクトリには、少なくともソース ディレクトリと同程度の余分なスペースが必要です。一時ディレクトリとして、ソース ディレクトリ内のディレクトリを指定することはできません。圧縮が正常に完了すると、新たに圧縮されたストア ファイルが mystores ディレクトリに格納されます。さらに、tmpmystore ディレクトリの下にユニークな名前の新しいディレクトリが作成され、圧縮前のストア ファイルが格納されます。
永続ストアには以下の制限があります。
永続ファイル ストアは、2 つのサーバ インスタンスから同時に開くことはできない。同時に開くと、ファイル内のデータが破損するおそれがあります。永続ストアは、同時に開かれたことが検知できたときにはエラーを返そうとしますが、この状態が必ず検知できるとは限りません。管理者の責任において、複数のサーバが同じ永続ストアに同時にアクセスを試みない環境でのみ永続ストアを使用するようにしてください (名前とディレクトリが同じ 2 つのファイル ストアは「同じストア」とみなされます)。
データが破損するので、2 つの JDBC ストアで同じデータベース テーブルを共有することはできない。
永続ストアは、任意の破損に対応できない可能性がある。ディスク ファイルが任意のデータで上書きされた場合の結果がどうなるかは不確定です。ストアから矛盾したデータが返されたり、ストアをまったく回復できなくなったりするおそれがあります。
ディスクが一杯になると、ファイル ストアから例外が返されることがある。しかし、ディスク スペースが使用可能になると例外を送出されなくなり、通常の処理が再開します。また、これまでに説明したとおり、永続ストア内のデータはそのまま残されます。
