|
|
以下の節では、永続ストアをコンフィグレーションおよびモニタする方法について説明します。永続ストアは、永続性を必要とする WebLogic Server のサブシステムおよびサービスに対し、組み込みの高性能なストレージ ソリューションを提供します。
永続ストアは、永続性を必要とする WebLogic Server のサブシステムおよびサービスに対し、組み込みの高性能なストレージ ソリューションを提供します。たとえば、永続 JMS メッセージを格納したり、ストア アンド フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。永続ストアは、ファイルベースのストアまたは JDBC 対応データベースの永続性をサポートします。
表 6-1 に、永続ストアへの接続を作成できる WebLogic サービスおよびサブシステムの多くを示します。永続ストアを使用する各サブシステムには、そのサブシステムを特定するためのユニークな接続 ID が指定されます。
ストアの接続 ID の詳細については、「ストア接続のモニタ」を参照してください。
永続ストアのパフォーマンス上の主な目標はスループットの向上です。複数のサブシステムが同じサーバ インスタンスまたは移行可能な対象を対象指定していれば、これらのサブシステムで同じ永続ストアを共有できます。
この点が、永続ストアを使用するパフォーマンス上の利点です。なぜなら、同じストアを使用する複数のサービスに関係するトランザクションであっても、そのトランザクションのトランザクション マネージャによって永続ストアが単一のリソースとして扱われるためです。たとえば、JMS と EJB のタイマーが 1 つのストアを共有し、JMS メッセージと EJB タイマーが単一のトランザクションで作成された場合、そのトランザクションは 1 フェーズとなり、リソースの書き込みは 1 回しか発生しません。一方、2 フェーズの場合であれば、リソースごとに 2 回ずつで合計 4 回のリソース書き込みが発生し、加えてトランザクション ログでのトランザクション エントリの書き込みが 1 回発生することになります。
ファイル ストアおよび JDBC ストアは、プロセスのクラッシュやハードウェアの電源障害が発生しても、コミットされた更新を失うことなく存続できます。コミットされていない更新は保持されるとは限りませんが、クラッシュ後にトランザクションが部分的に完了した状態で残されることはありません。
以下に、ファイル ストアと JDBC ストアの類似点と相違点を挙げます。
| 注意 : | データベースが高速なディスクを備えたハイエンドのハードウェア上で実行され、WebLogic Server がそれよりも低速なディスクを備えたハードウェア上で実行されている場合は、JDBC ストアの方がパフォーマンスが良くなる場合もあります。 |
ファイル ストア データのセキュリティを確保するには、すべてのファイル ストア ディレクトリに適切なディレクトリ パーミッションを設定する必要があります。データの暗号化が必要な場合は、適切なサード パーティ暗号化ソフトウェアを使用する必要があります。
高可能性の点では、永続ファイルベースのストア (デフォルトまたはカスタム) は、「サーバ全体レベル」の移行機能の一部としてその親サーバとともに移行できます。この場合、サービスレベルではなく、サーバレベルで自動または手動で移行できます。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「サーバおよびサービスの移行について」を参照してください。ただし、ファイルベースのストアは、クラスタ内の移行可能な対象サーバからアクセスできる共有ディスク上にコンフィグレーションする必要があります。
ファイルベースのストアおよび JDBC 対応ストアも、ストアを使用してデータを維持する JMS 関連サービス (ストア、JMS サーバ、SAF エージェント、パス サービスなど) の「サービスレベル」の移行の一部として移行できます。サービスレベルの移行は、JMS 関連サービスをグループ化した「移行可能対象」ごとに制御されます。移行可能対象は、クラスタ内のいずれか 1 つの物理サーバでホストされます。移行可能対象によってホストされる JMS サービスは、サーバ障害への対処として、または定期的なサーバ メンテナンスの一環として手動で移行できます。移行可能な対象を移行すると、その対象によってホストされているすべての固定サービスも移行されます。サービスレベルの移行の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「サービスレベルの移行」を参照してください。
移行可能な JMS 関連サービスで、デフォルトのファイル ストアを使用することはできません。したがって、カスタムのファイル ストアまたは JDBC ストアをコンフィグレーションし、関連付けた JMS サーバ、SAF エージェント、またはパス サービスと同じ移行可能対象にそのストアを対象指定する必要があります。
| ヒント : | パス サービスの場合は、専用のカスタム ストアと移行可能対象を使用するのがベスト プラクティスです。 |
また、移行可能なファイル ストアは、クラスタ内の移行可能対象から使用できる共有ディスク上にコンフィグレーションするか、ファイル ストアのデータをバックアップ サーバに移行するための移行前/移行後スクリプトを使用できるようにしておく必要もあります。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「JMS サービスで使用できるカスタム ストア」を参照してください。
JMS サーバまたは JTA トランザクション ログの移行後に、リモート マシンに存在する永続ストアにアクセスするアプリケーションがある場合は、以下の高可用性ストレージ ソリューションのいずれかを実装する必要があります。
| 注意 : | ファイル ストアが切断されて再接続された場合、永続 JMS メッセージの送受信を正常に続行するには、ホスト サーバ インスタンスを再起動する必要があります。たとえば、ファイル ストアを含むファイル システムがアンマウントされた後再びマウントされた場合、ホスト サーバを再起動せずに永続 JMS メッセージを送信しようとすると JMS 例外が生成されます。 |
管理サーバを含め、すべてのサーバ インスタンスには、コンフィグレーションが不要なデフォルトの永続ストアがあります。デフォルト ストアはファイルベースのストアで、サーバ インスタンスの data\store\default ディレクトリに格納された一連のファイルにデータを保持します。デフォルト ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ メカニズムを使用することで最適に動作するサブシステムから使用することができます。たとえば、永続ストアがコンフィグレーションされていない JMS サーバは、管理対象サーバ用のデフォルトのストアを使用して永続メッセージングをサポートします。
デフォルト ストアは、DefaultFileStoreMBean パラメータを直接操作してコンフィグレーションできます。この MBean がドメインのコンフィグレーション ファイルに定義されていない場合は、DefaultFileStoreMBean がデフォルト値で常に存在していることがコンフィグレーション サブシステムによって保証されます。
また、Administration Console を使用してデフォルト ストアのパラメータを変更することもできます。たとえば、デフォルトのディレクトリの場所や同期書き込みポリシーを変更できます。詳細については、Administration Console オンライン ヘルプの「デフォルト ストアの設定の変更」を参照してください。
デフォルトのファイル ストアを使用するだけでなく、特定のニーズに合わせてカスタム ファイル ストアや JDBC ストアをコンフィグレーションすることもできます。詳細については、「カスタム ファイル ストアと JDBC ストアの使い方」を参照してください。唯一の例外は、JTA トランザクション ログ (TLOG) です。TLOG では、常にデフォルト ストアを使用します。これは、サーバの起動プロセスの初期に必ずトランザクション ログを使用するためです。TLOG の詳細については、『WebLogic JTA プログラマーズ ガイド』の「トランザクション ログ ファイル」を参照してください。
デフォルト ストアのデータは、ドメインのルート ディレクトリの servername サブディレクトリにある data\store\default ディレクトリに保持されます。
たとえば、デフォルト ファイル ストアのディレクトリ名が指定されていない場合、次のディレクトリがデフォルトになります。
bea_home\user_projects\domains\domain-name\servers\server-name\data\store\default
domainname はドメインのルート ディレクトリ (通常は c:\bea\user_projects\domains\domainname) です。これは、WebLogic Server プログラム ファイルが格納されるディレクトリ (通常は c:\bea\wlserver_10.0) に対応するディレクトリです。
ただし、DefaultFileStoreMBean パラメータを直接操作するか Administration Console を使用して、デフォルト ストアの格納場所を変更することもできます。詳細については、Administration Console オンライン ヘルプの「デフォルト ストアの設定の変更」を参照してください。
ドメインのコンフィグレーション ファイルでのデフォルト ファイル ストアの定義例を示します。この例では、デフォルトのディレクトリと同期書き込みポリシーの設定がオーバーライドされています。
<server>
<name>myserver</name>
<default-file-store>
<directory>C:/store</directory>
<synchronous-write-policy>Disabled</synchronous-write-policy>
</default-file-store>
</server>
デフォルトのファイル ストアを使用するだけでなく、特定のニーズに合わせてファイル ストアや JDBC ストアをコンフィグレーションすることもできます。デフォルト ファイル ストアと同様、カスタム ファイル ストアもディレクトリに格納された一連のファイルにデータを保持します。一方、カスタム ファイル ストアを作成して、特定のストレージ デバイスにデータを保持したり、ファイル ストアにアクセスする JMS サービスがクラスタ内の別のサーバ メンバーにストアを移行できるようにしたりすることも可能です。ファイル ストアのディレクトリをコンフィグレーションする場合は、そのファイル ストアが配置されているサーバ インスタンスにアクセスできるディレクトリを設定する必要があります。
JDBC ストアは、リレーショナル データベースをストレージとして使用している場合にコンフィグレーションできます。JDBC ストアを使用することで、指定の JDBC データ ストアを介してアクセスできる標準の JDBC 対応データベースに永続メッセージを格納できます。JDBC ストアのデータベース テーブルに格納されたデータには、WLStore という論理名が付けられます。データベースの高可用性とパフォーマンスをコンフィグレーションするかどうかは、データベース管理者の判断です。JDBC ストアでは、JMS サービスを自動または手動で移行する移行可能対象をサポートすることもできます。
永続ストアのコンフィグレーションの詳細については、「カスタム永続ストアを使用すべき状況」を参照してください。
WebLogic Server では、カスタム ファイル ストアや JDBC ストアを作成するためのコンフィグレーション オプションが用意されています。たとえば、次のような状況が考えられます。
カスタム永続ストアは、以下の方法でコンフィグレーションできます。
config.xml) を直接編集する。
以下の節では、カスタム ファイル ストアの例を示し、同期書き込みポリシーを選択する上でのコンフィグレーション ガイドラインについて説明します。
カスタム ファイル ストアを作成する場合は、デフォルトの FileStoreMBean パラメータを直接編集できます。Administration Console を使用してカスタム ファイル ストアを作成する方法については、Administration Console オンライン ヘルプの「ファイル ストアの作成」を参照してください。
カスタム ファイル ストアを作成するための主な手順は次のとおりです。
ドメインのコンフィグレーション ファイルでのデフォルト ファイル ストアの定義例を示します。この例では、ファイルが /disk1/jmslog ディレクトリに保持されるように定義されています。
<file-store>
<name>SampleFileStore</name>
<target>myserver</target>
<directory>/disk1/jmslog</directory>
</file-store>
表 6-2 に、ファイル ストアの変更可能なコンフィグレーション パラメータを示します。
|
||||
Administration Console を使用してカスタム ファイル ストアをコンフィグレーションする手順については、Administration Console オンライン ヘルプの「ファイル ストアの作成」を参照してください。
デフォルトの同期書き込みポリシーである [Direct-Write] では、ファイル ストアのデータが Solaris および Windows オペレーティング システムのディスクに直接書き込まれます。通常は、[Cache-Flush] を選んだ場合よりも速く書き込まれます。
通常、デフォルト ポリシーから [Disabled] に変更すると、ファイル ストアのパフォーマンスは大幅に向上します。その代わり、オペレーティング システムがクラッシュしたり、ハードウェアの障害が発生したりした場合には、メッセージがトランザクション対応であっても、送信したメッセージが失われたり、同じメッセージを重複して受信したりする可能性があります。これは、書き込みがメモリにキャッシュされると、ディスクに正常に格納されるまで待機せず、すぐにトランザクションが完了するためです。オペレーティング システムでは通常のシャットダウン時に未処理の書き込みをすべてフラッシュするので、OS をシャット ダウンするだけではこうしたエラーは発生しません。こうしたエラーは、ビジー状態のサーバの電源を突然遮断することでエミュレートできます。
以下の節では、JDBC ストアの例を示し、既存の DDL を使用した JDBC ストア用のデータベースの作成について説明します。また、DDL ファイルで Oracle blob レコード カラムを有効にする方法についても説明します。
JDBC ストアを作成する場合は、デフォルトの JDBCStoreMBean パラメータを直接編集できます。Administration Console を使用して JDBC ストアを作成する手順については、Administration Console オンライン ヘルプの「JDBC ストアの作成」を参照してください。
JDBC ストアでプレフィックスを使用する場合のコンフィグレーション ガイドライン、および JDBC データ ソースの推奨設定については、「JDBC ストアのコンフィグレーションのガイドライン」を参照してください。
ドメインのコンフィグレーション ファイルでの JDBC ストアの定義例を示します。この例では、JDBC データ ソース MyDataSource を使用しており、論理名が指定されています。
<jdbc-store>
<name>SampleJDBCStore</name>
<target>yourserver</target>
<data-source>MyDataSource</data-source>
<logical-name>Baz</logical-name>
</jdbc-store>
表 6-3 に、JDBC ストアの変更可能なコンフィグレーション パラメータを示します。
|
||||
WLStore) にアクセスするために、この JDBC ストアによって使用される JDBC データ ソースまたはマルチ データ ソース。このデータ ソースまたはマルチ データ ソースは、JDBC ストアと同じサーバ インスタンスを対象指定していなければならない。
|
||||
WLStore となり、データベースでは JDBC 接続の現在のユーザに基づいて暗黙的にスキーマが決定される。また、2 つの JDBC ストアで同じデータベース テーブルを共有することはできない。詳細については、「JDBC ストアでのプレフィックスの使い方」を参照。
|
||||
WLStore) を作成するために、必要に応じて、サポートされている DDL (データ定義言語) ファイルで使用する。このオプションは、JDBC ストアのデータベース テーブルがすでに存在する場合は無視される。詳細については、「デフォルトおよびカスタム DDL ファイルを使用した JDBC ストア テーブルの自動作成」を参照。
|
Administration Console を使用して JDBC ストアをコンフィグレーションする手順については、Administration Console オンライン ヘルプの「JDBC ストアの作成」を参照してください。
JDBC ストアを使用する場合、JDBC ドライバを介してアクセスできるデータベースであればバッキング データベースにできます。WebLogic Server では、サポートされるデータベース用の一部の JDBC ドライバが自動的に検出されます。
これらのデータベースごとに対応する DDL (データ定義言語) ファイルがあり、WL_HOME\server\lib\weblogic.jar ファイル内の weblogic/store/io/jdbc/ddl ディレクトリに格納されています。WL_HOME は、WebLogic Server の最上位のインストール ディレクトリです。
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 テンプレート ファイルをコピーし、使用するデータベースに合わせて編集できます。
/weblogic/store/io/jdbc/ddl ディレクトリに抽出できます。jar xf weblogic.jar /weblogic/store/io/jdbc/ddl| 注意 : | weblogic/store/io/jdbc/ddl パラメータを省略すると、jar ファイル全体が抽出されます。 |
mydatabase.ddl)。/mydatabase.ddl)。| 注意 : | Windows システムの場合、絶対パス名には必ずドライブ文字を含めます。 |
Oracle データベースの場合は、oracle_blob.ddl ファイルを使用すると、レコード カラムの型がデフォルトの LONG RAW 型ではなく BLOB 型の JDBC ストア テーブルを作成できます。oracle_blob.ddl ファイルは、「サポートされる JDBC ドライバ」に示すように、WebLogic CLASSPATH にあらかじめコンフィグレーションされています。
JDBC ストアで Oracle BLOB DDL を使用するには
oracle_blob.ddl ファイルの場所として /oracle_blob.ddl を指定します。
すでに Oracle の LONG RAW カラムに入っているデータを保持する必要がある場合は、この方法で BLOB に切り替えないようにしてください。このような場合は、SQL ALTER TABLE コマンドに関する Oracle ドキュメントを参照してください。
JDBC utils.Schema ユーティリティを使用すると、既存のバージョンを削除することで新しい JDBC ストア データベース テーブル (WLStore) を再生成できます。通常、このテーブルは自動的に作成されるため、このユーティリティを実行する必要はありません。しかし、既存の JDBC ストア データベース テーブルに障害が発生した場合は、utils.Schema ユーティリティを使用して削除できます。
utils.Schema ユーティリティは Java プログラムで、以下の項目を指定するコマンドライン引数をとります。
$ java utils.Schemaurl JDBC_driver[options]DDL_file
| 注意 : | utils.Schema を実行するには、CLASSPATH に weblogic.jar ファイルを指定する必要があります。 |
表 6-5 に、utils.Schema のコマンドライン引数を示します。
|
|
|
たとえば、次のコマンドでは、ユーザ名 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 ストアのバッキング データベース テーブルのプレフィックス名オプションを、コンフィグレーションした 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"ConnectionCreationRetryFrequencySeconds=
TestTableName="SYSTABLES""600"
JDBC のデフォルトのテスト テーブル名については、『WebLogic JDBC のコンフィグレーションと管理』の「データ ソースの接続テスト オプション」を参照してください。データベースの再接続の試行数の設定については、『WebLogic JDBC のコンフィグレーションと管理』の「接続作成の再試行の有効化」を参照してください。
JDBC ストアとして使用するデータ ソースで DB2 用の WebLogic Type 4 JDBC ドライバを使用する場合は、JMS の内部的なバッチ処理の要件を満たすため、BatchPerformanceWorkaround プロパティを「true」に設定する必要があります。
詳細については、『WebLogic Type 4 JDBC ドライバ ガイド』の「バッチ挿入およびバッチ更新に関するパフォーマンスの回避策」を参照してください。
JDBC ストアは、グローバル トランザクションをサポートするようにコンフィグレーションされた JDBC データ ソースを使用するようにコンフィグレーションすることはできません。JDBC ストアは、非 XA JDBC ドライバを使用する JDBC データ ソースを使用する必要があります。また、このデータ ソースで [ロギング ラスト リソース] または [2 フェーズ コミットのエミュレート] を有効にすることはできません。
JDBC ストアは、XAResource インタフェースを実装しているため、JDBC ストア自体のリソース マネージャとして動作し、JDBC ドライバ レベルより上位のトランザクションを処理します。つまり、ストア自体が XAResource を実装し、メッセージがデータベースに格納されている場合でもそのデータベースに依存せずにトランザクションを処理します。
このため、JDBC ストアとデータベース (JMS メッセージが格納されているデータベースと同じ場合でも) を使用する場合、それは常に 2 フェーズ コミット トランザクションになります。
JDBC ストアでの JMS トランザクションの使用については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS によるトランザクションの使い方」を参照してください。
LLR による最適化を使用すると、トランザクションは 2 フェーズ コミット プロトコルに従いますが、データベース操作は単一のローカル トランザクションで処理されるため、トランザクション全体のパフォーマンスは向上します。LLR による最適化の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「ロギング ラスト リソース トランザクション オプションについて」を参照してください。
既存の各永続ストアおよび開かれている各ストア接続の統計情報をモニタできます。
各永続ストアは、実行時には PersistentStoreRuntimeMBean インスタンスによって表現されます。以下のオプションが用意されています。
永続ストアは、開かれている各永続ストア接続についても PersistentStoreConnectionRuntimemMBean を登録します。以下のオプションが用意されています。
表 6-8 に、永続ストアへの接続を作成できる WebLogic サービスおよびサブシステムの実行時プレフィックス名のほとんどを示します。
WebLogic ストア管理ユーティリティを使用すると、WebLogic 永続ストアのトラブルシューティングを行うことができます。ストア ユーティリティで操作できるのは、実行中のサーバ インスタンスによって開かれていないストアのみです。このユーティリティは、Java コマンドラインまたは WLST (WebLogic Scripting Tool) から実行できます。詳細については、「Java コマンドラインを使用したストア管理」および「WLST を使用したストア管理」を参照してください。
ストア管理の最も一般的な使用例は、サイズを減らすためにファイル ストアを圧縮する場合や、トラブルシューティングを目的としてファイル ストアまたは JDBC ストアの内容を XML ファイルにダンプする場合です。これらの使用例については後ほど説明します。
表 6-9 に、Java および WLST で使用できるストア管理コマンドを示します。
|
||||
永続ストアは、ファイル システム (ファイル ストア) または 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 から永続ストア管理ユーティリティにアクセスするには、次のように入力します。
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 ディレクトリの下にユニークな名前の新しいディレクトリが作成され、圧縮前のストア ファイルが格納されます。
  
|
