| Oracle® Fusion Middleware Oracle WebLogic Serverサーバー環境の構成 11gリリース1 (10.3.3) B60987-01 |
|
 前 |
次の項では、永続ストアを構成およびモニターする方法について説明します。永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。
永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能なストレージ・ソリューションを提供します。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。永続ストアは、ファイル・ベースのストアまたはJDBC対応データベースの永続性をサポートします。
表6-1に、永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムの多くを示します。永続ストアを使用する各サブシステムには、そのサブシステムを特定するための一意の接続IDが指定されます。
表6-1永続ストアのユーザー
| サブシステム/サービス | 格納対象 | 詳細についての参照先 |
|---|---|---|
|
診断サービス |
ログ・レコード、データ・イベント、収集されたメトリック |
『Oracle WebLogic Server診断フレームワークの構成と使い方』のWLDF構成について |
|
JMSメッセージ |
永続メッセージ、恒久サブスクライバ |
『Oracle WebLogic Server JMSプログラマ・ガイド』のメッセージング・モデルについて |
|
JMSページング・ストア |
各JMSサーバーに1つ。ページされた永続メッセージと非永続メッセージ。 |
『Oracle WebLogic Server JMSの構成と管理』の基本JMSシステム・リソースの構成の主な手順 |
|
JTAトランザクション・ログ(TLOG) |
サーバーによって調整された、完了していない可能性のあるコミット済みトランザクションに関する情報 |
『Oracle WebLogic Server JTAのプログラミング』のトランザクションの管理 |
|
パス・サービス |
メッセージのグループからメッセージング・リソースへのマッピング |
『Oracle WebLogic Server JMSの構成と管理』のWebLogicパス・サービスの使用 |
|
ストア・アンド・フォワード(SAF)サービス・エージェント |
SAF送信エージェントからSAF受信エージェントに再転送するメッセージ |
『Oracle WebLogic Serverストア・アンド・フォワードの構成と管理』のストア・アンド・フォワード・サービスについて |
|
Webサービス |
信頼性のあるWebLogic Webサービスの呼出しによるSOAPリクエスト・メッセージおよびレスポンス・メッセージ |
『Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング』の信頼性のあるSOAPメッセージングの使い方 |
|
EJBタイマー・サービス |
EJBタイマー・オブジェクト |
『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』のEnterprise JavaBeansを参照してください。 |
ストアの接続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 WebLogic Serverクラスタの使い方』のサーバー全体の移行を参照してください。ただし、ファイルベースのストアは、クラスタ内の移行可能な対象サーバーからアクセスできる共有ディスク上に構成する必要があります。
ファイルベースのストアおよびJDBC対応ストアも、ストアを使用してデータを維持するJMS関連サービス(ストア、JMSサーバー、SAFエージェント、パス・サービスなど)のサービス・レベル移行の一部として移行できます。サービス・レベルの移行は、JMS関連サービスをグループ化した移行可能なターゲットに制御されます。移行可能なターゲットは、クラスタ内の1つの物理サーバーのみでホストされます。このようにホストされたサービスは、ヘルス監視サブシステムを使用することで、現在の異常のあるホスト・サーバーから正常でアクティブなサーバーに自動的に移行できます。移行可能なターゲットによってホストされるJMSサービスは、サーバー障害への対処として、または定期的なサーバー・メンテナンスの一環として手動でも移行できます。移行可能なターゲットを移行すると、そのターゲットによってホストされているすべての固定サービスも移行されます。サービス・レベルの移行の詳細は、『Oracle WebLogic Serverクラスタの使い方』のサービスの移行を参照してください。
移行可能なJMS関連サービスで、デフォルトのファイル・ストアを使用することはできません。したがって、カスタムのファイル・ストアまたはJDBCストアを構成し、関連付けたJMSサーバー、SAFエージェント、またはパス・サービスと同じ移行可能対象にそのストアを対象指定する必要があります。
|
注意: パス・サービスの場合は、専用のカスタム・ストアと移行可能対象を使用するのがベスト・プラクティスです。 |
移行可能なファイル・ストアは、クラスタ内の移行可能なターゲットからアクセスできる共有ディスク上に構成するか、または移行前/移行後スクリプトを使用してファイル・ストアのデータをバックアップ・サーバーに移行できます。詳細は、『Oracle WebLogic Serverクラスタの使い方』のJMSサービスで使用できるカスタム・ストアを参照してください。
JMSサーバーまたはJTAトランザクション・ログの移行後に、リモート・マシンに存在する永続ストアにアクセスするアプリケーションがある場合は、以下の高可用性ストレージ・ソリューションのいずれかを実装する必要があります。
ファイル・ベース・ストア(デフォルトまたはカスタム) - デュアルポートSCSIディスクまたはストレージ領域ネットワーク(SAN)などのハードウェア・ソリューションを実装して、共有可能ディスクやリモート・マシンからもファイル・ストアを利用できるようにします。
|
注意: ファイル・ストアが切断されて再接続された場合、永続JMSメッセージの送受信を正常に続行するには、ホスト・サーバー・インスタンスを再起動する必要があります。たとえば、ファイル・ストアを含むファイル・システムがアンマウントされた後再びマウントされた場合、ホスト・サーバーを再起動せずに永続JMSメッセージを送信しようとするとJMS例外が生成されます。 |
JDBC対応ストア - JDBCストアを構成し、JDBCを使用してこのストアにアクセスします。このストアは、別のサーバーに存在する場合もあります。そのあと、アプリケーションでは、データベース・ベンダーによって提供されるあらゆる高可用性ソリューションまたはフェイルオーバー・ソリューションを利用できます。また、JDBCストアではマルチ・データ・ソースがサポートされるため、冗長なデータベースやOracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムのノード間でのフェイルオーバーが可能です。JDBCマルチ・データ・ソースの使用の詳細は、『Oracle WebLogic Server JDBCの構成と管理』のJDBCマルチ・データ・ソースの構成を参照してください。
すべての永続ストア - 可用性の高いVERITAS(tm) Cluster Serverなどのクラスタリング・ソフトウェアを使用します。このようなソフトウェアでは、WebLogic Serverベースのアプリケーション用のすぐに使用できる統合ソリューションを提供します。前述の他に、IBM HACMPなどもお薦めできる可用性の高いソフトウェア・ソリューションです。
管理サーバーを含め、すべてのサーバー・インスタンスには、構成が不要なデフォルトの永続ストアがあります。デフォルト・ストアはファイルベースのストアで、サーバー・インスタンスのdata\store\defaultディレクトリに格納された一連のファイルにデータを保持します。デフォルト・ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト・ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトの記憶域メカニズムを使用することで最適に動作するサブシステムから使用できます。たとえば、永続ストアが構成されていないJMSサーバーは、管理対象サーバー用のデフォルトのストアを使用して永続メッセージングをサポートします。
デフォルト・ストアは、DefaultFileStoreMBeanパラメータを直接操作して構成できます。このMBeanがドメインの構成ファイルで定義されていない場合は、DefaultFileStoreMBeanには、構成サブシステムによってデフォルト値が確保されます。
また、管理コンソールを使用してデフォルト・ストアのパラメータを変更することもできます。たとえば、デフォルトのディレクトリの場所や同期書込みポリシーを変更できます。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのデフォルト・ストアの設定の変更を参照してください。
デフォルトのファイル・ストアの使用に加えて、特定のニーズに合わせてカスタム・ファイル・ストアやJDBCストアを構成することもできます。詳細は、「カスタム・ファイル・ストアとJDBCストアの使い方」を参照してください。ただし、1つの例外として、常にデフォルト・ストアを使用するJTAトランザクション・ログ(TLOG)があります。これは、サーバーの起動プロセスの初期に、必ずトランザクション・ログが使用可能である必要があるためです。TLOGの詳細は、『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パラメータを直接操作するか、管理コンソールを使用してデフォルト・ストアの場所を変更できます。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのデフォルト・ストアの設定の変更を参照してください。
デフォルトのファイル・ストアを使用するだけでなく、特定のニーズに合わせてファイル・ストアやJDBCストアを構成することもできます。デフォルト・ファイル・ストアと同様、カスタム・ファイル・ストアもディレクトリに格納された一連のファイルにデータを保持します。一方、カスタム・ファイル・ストアを作成して、特定のストレージ・デバイスにデータを保持したり、ファイル・ストアにアクセスするJMSサービスがクラスタ内の別のサーバー・メンバーにストアを移行できるようにしたりすることも可能です。ファイル・ストアのディレクトリを構成する場合は、そのファイル・ストアが配置されているサーバー・インスタンスにアクセスできるディレクトリを設定する必要があります。
JDBCストアは、リレーショナル・データベースをストレージとして使用している場合に構成できます。JDBCストアを使用することで、指定のJDBCデータ・ストアを介してアクセスできる標準のJDBC対応データベースに永続メッセージを格納できます。JDBCストアのデータベース表に格納されたデータには、WLStoreという論理名が付けられます。データベースの高可用性とパフォーマンスを構成するかどうかは、データベース管理者の判断です。JDBCストアでは、JMSサービスを自動または手動で移行する移行可能対象をサポートすることもできます。
永続ストアの構成の詳細は、「カスタム永続ストアを使用すべき状況」を参照してください。
WebLogic Serverでは、カスタム・ファイル・ストアやJDBCストアを作成するための構成オプションが用意されています。たとえば、次のような状況が考えられます。
ファイル・ストアのファイルを特定のデバイスに配置します。
特定のサーバー・インスタンスで、ファイル・ストアの代わりにJDBCストアを使用します。
クラスタ内のすべての物理ストアで同じ論理名を共有します。
異なるサービスを論理的に分けて、別々のファイルや表を使用します。(これにより、パフォーマンスは下がりますが、管理や保守は容易になります。)
移行可能なJMS関連サービスでは、デフォルトの永続ストアは使用できません。したがって、カスタム・ストアを構成し、移行可能なJMSサービスと同じ移行可能なターゲットにターゲット指定する必要があります。詳細は、『Oracle WebLogic Serverクラスタの使い方』のサービスの移行を参照してください。
カスタム永続ストアは、次の方法で構成できます。
Oracle WebLogic Server管理コンソール・ヘルプの永続ストアの構成の説明に従って、管理コンソールを使用してカスタム・ファイル・ストアまたはJDBCストアを構成します。
デフォルト永続ストアをホストするサーバー・インスタンスの構成ファイル(config.xml)を直接編集します。
WebLogic Java Management Extensions(JMX)を使用して永続ストアを作成します。JMXは、ネットワーク上のリソースを監視および管理するためのJava EEソリューションです。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。
WebLogic Scripting Tool (WLST)を使用して永続ストアを作成します。WLSTは、WebLogic Serverインスタンスとドメインに対して、相互作用や構成のために使用するコマンド・ライン・スクリプト・インタフェースです。詳細は、『Oracle WebLogic Scripting Tool』を参照してください。
WebLogic構成ウィザードを使用して、デフォルト永続ストアのオプションを変更します。構成ウィザードを使用して永続ストアを構成する方法の詳細は、『構成ウィザードを使用したドメインの作成』のWebLogicドメインの作成を参照してください。
JDBCストアの接頭辞やファイル・ストアのディレクトリなど、特定のカスタム・ストアの構成オプションの変更において次を実行する場合、サーバーの再起動は必ずしも必要ではありません。
(カスタム・ストアを使用するJMSサーバーなど)依存するサービスの対象をnullに設定し、カスタム・ストアの対象をnullに設定します(サービスの対象をnullに設定すると、暗黙的にサービスが停止します)。
カスタム・ストアの対象を元の値に戻し、依存するリソースの対象を元の値に戻すことによってプロセスを元に戻します。
カスタム・ストアとJMSサーバーが移行可能対象を共有する場合、移行可能対象を管理的に再起動することができます。
次の項では、カスタム・ファイル・ストアの例を示し、同期書込みポリシーを選択する上での構成ガイドラインについて説明します。
カスタム・ファイル・ストアを作成する場合は、デフォルトのFileStoreMBeanパラメータを直接変更できます。管理コンソールを使用してカスタム・ファイル・ストアを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのファイル・ストアの作成を参照してください。
カスタム・ファイル・ストアを作成するための主な手順は次のとおりです。
ファイル・ストアのデータを格納するディレクトリを作成します。
カスタム・ファイル・ストアを作成し、作成したディレクトリの場所を指定します。
カスタム・ファイル・ストアにアクセスするサブシステムまたは移行可能対象に、以下の方法でカスタム・ファイル・ストアを関連付けます。
JMSサーバーの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。
ストア・アンド・フォワード・エージェントの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。
パス・サービスの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。
ドメインの構成ファイルでのデフォルト・ファイル・ストアの定義例を示します。この例では、ファイルが/disk1/jmslogディレクトリに保持されるように定義されています。
<file-store> <name>SampleFileStore</name> <target>myserver</target> <directory>/disk1/jmslog</directory> </file-store>
表6-2に、ファイル・ストアの変更可能な構成パラメータについて簡単にまとめます。
表6-2 カスタム・ファイル・ストアの構成オプション
| オプション | 必須 | 機能 |
|---|---|---|
|
名前 |
はい |
ファイル・ストアの名前。ドメイン内のすべてのストアの間で一意であることが必要です。 |
|
対象 |
はい |
ファイル・ストアを対象指定するサーバー・インスタンスまたは移行可能対象。複数のサブシステムが同じサーバー・インスタンスまたは移行可能対象を対象指定していれば、これらのサブシステムで同じファイル・ストアを共有できます。 注意: JMSサービスで移行可能なターゲットを使用する場合は、ファイル・ストアをJMSサービスで使用するのと同じターゲットにターゲット指定する必要があります。『Oracle WebLogic Serverクラスタの使い方』のサービスの移行を参照してください。 |
|
ディレクトリ |
はい |
ファイル・ストアを保持するディレクトリのファイル・システム上のパス名。 注意: ファイル・ストアに移行可能なターゲットを指定する場合、ストア・ディレクトリは移行可能なターゲットのすべての候補サーバー・メンバーからアクセスできる必要があります。最高レベルの可用性を実現するには、SAN(ストレージ領域ネットワーク)またはデュアルポートSCSIディスクのいずれかを使用してください。詳細は、『Oracle WebLogic Serverクラスタの使い方』のサービスの移行を参照してください。 既存のファイル・ストアのディレクトリを変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。 |
|
CacheDirectory |
いいえ |
この設定は、 |
|
論理名 |
いいえ |
必要に応じて、EJBなどのサブシステムでモジュールをクラスタ全体にデプロイする場合に使用します。ただし、クラスタ内のサーバー・インスタンスごとに別々の物理ストアが必要になります。このような構成では、各物理ストアに固有の名前を付けますが、すべての永続ストアで同じ論理名を共有します。 |
|
同期書込みポリシー |
いいえ |
個別の書込み操作の永続性を含む、ファイル・ストアのIO動作を定義します。指定できる値は、直接書込み(デフォルト)、直接書込み - キャッシュあり、キャッシュ・フラッシュ、および無効です。 詳細は、「同期書込みポリシーの構成のガイドライン」を参照してください。 |
管理コンソールを使用してカスタム・ファイル・ストアを構成する手順は、Oracle WebLogic Server管理コンソール・ヘルプのファイル・ストアの作成を参照してください。
ファイル・ストアで使用できる複数の同期書込みポリシーがあります。同期書込みポリシーでは、ファイル・ストアの書込み操作の動作が決まります。環境に最適で、実行時のパフォーマンスや万が一のクラッシュ発生後のデータ整合性のニーズを満たすポリシーを選択する必要があります。同期書込みポリシーのチューニングとパフォーマンスおよびファイル・ストアの他のオプションの詳細は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』のWebLogic永続ストアのチューニングを参照してください。
|
注意: 実行中のカスタム・ファイル・ストアまたはデフォルト・ファイル・ストアの同期書込みポリシーとドライバを表示するには、サーバー・ログのWL-280008およびWL-280009メッセージを確認してください。 |
ほとんどのシナリオでは、直接書込み - キャッシュありポリシーをご使用をお薦めします。このポリシーを選択すると、WebLogic Serverは、ネイティブなI/O wlfileioドライバを使用して、ファイル・ストアの構成のDirectory属性で定義された場所に格納される一連のプライマリ・ファイルに同期的に書き込みます。また、WebLogic Serverは、ファイル・ストアの構成のCacheDirectory属性で定義された場所にある、対応するキャッシュ・ファイルにも非同期に書き込みます。これは、OSメモリーにより、プライマリ・データ・ファイル用の出力バッファとしてキャッシュ・ファイル・ブロックをキャッシュすることで、暗示的に実行されます。キャッシュ・ファイルは、実行時と起動時のパフォーマンスの最適化、およびリカバリのために使用されます。ネイティブ・ファイル・ドライバによる直接的な書込みおよび対応するキャッシュ・ファイルの組合の使用により、ディスクへの書込みが最も安全に実施され、全体的に最良のパフォーマンスが実現されます。
このオプションでは、他のポリシーの約2倍のディスク領域が使用され、ファイルは2つの場所に格納されます。これらの場所のディスク領域の割当を考慮し、両方の場所を確保しておく必要が場合があります。
直接書込み - キャッシュありポリシーでファイルの場所を構成する場合は、高可用性(サーバー全体の移行またはサービスの自動移行)のために構成する場合であっても、CacheDirectory属性の場所はローカル・ディレクトリである必要があります。キャッシュ・ファイルはパフォーマンスの最適化のためにのみ使用されます。メッセージの実際の永続ストレージは、ファイル・ストアの構成のDirectory属性によって定義されます。移行されたWebLogic ServerインスタンスまたはJMSサービスは、移行後にこのディレクトリのみを使用できる必要があります。障害時リカバリの場合も同様ですが、Directory場所で定義されたファイルをバックアップ・サイトにレプリケートする必要があります。
|
注意: ファイル・ストアのネイティブwlfileioドライバがロードできない場合は、ストアは代替の特化された直接書込みポリシー・モードで自動的に実行されます。実行中のカスタム・ファイル・ストアまたはデフォルト・ファイル・ストアの構成済と実際の同期書込みポリシーとドライバを表示するには、サーバー・ログでWL-280008とWL-280009メッセージを確認してください。
以前のいくつかのバージョンのMicrosoft Windowsでは、Windowsのデフォルトの |
直接書込みポリシーを選択すると、WebLogic Serverでは、ネイティブのI/O wlfileioドライバを使用して、ファイル・ストアの構成のDirectory属性で定義された場所にあるプライマリ・ファイルのセットに同期に書き込まれます。このポリシーは直接書込み - キャッシュありポリシーより処理速度が遅いが、少ないディスク領域を使用し、管理する環境の考慮事項もより少ないです。通常は、直接書込みポリシーの処理速度はキャッシュ・フラッシュポリシーより速いです。
|
注意: 以前のいくつかのバージョンのMicrosoft Windowsでは、Windowsのデフォルトの直接書込み - キャッシュあり設定を使用すると、ストレージ・デバイスの同期書込みの完了が誤って報告される可能性があります。システム・クラッシュや停電の発生はレコード/メッセージの損失や重複につながる可能性があるため、これは、直接書込み(デフォルト)または直接書込み - キャッシュありポリシーで構成されたファイル・ストアを含む、(Oracle固有でない)トランザクション製品のトランザクション・セマンティクスに違反します。目に見える兆候の1つは、この問題がストレージ・デバイスの物理的な容量を超える高い永続メッセージ/トランザクション・スループットとして現れることです。この問題を解決するには、Microsoftから提供されるパッチを適用するか、WindowsのWrite Cache Enabled設定を無効にするか、または電源保護されたストレージ・デバイスを使用します。http://support.microsoft.com/kb/281672およびhttp://support.microsoft.com/kb/332023を参照してください。 |
キャッシュ・フラッシュポリシーを選択すると、WebLogic Serverでは、オペレーティング・システムとストレージ・デバイスのデフォルトのファイル書込み動作が有効になります。デフォルトのファイル書込み動作では、基本的にキャッシングとファイルの書込みのスケジューリングを行いますが、トランザクションが完了する前にキャッシュのディスクへのフラッシュを強制します。書込みがすべてディスクにフラッシュされるまで、トランザクションが完了できません。このポリシーは信頼性と拡張性があり、同時ユーザーの増加に対応できます。このポリシーは、トランザクションが安全ですが、通常のユース・ケースの場合は(同時プロデューサやコンシューマが多数の場合を除く)、実行時のパフォーマンスが直接書込みポリシーより低くなります。
無効ポリシーを選択すると、WebLogic Serverはオペレーティング・システムとストレージ・デバイスのデフォルト・ファイル書込み動作に依存します。ほとんどの場合は、ファイル書込みはメモリーにキャッシュされ、ディスクに直接書き込まれることはなく、書込みはスケジューリングされます。通常は、無効ポリシーは、ファイル・ストアのパフォーマンスを大幅に向上しますが、オペレーティング・システムのクラッシュまたはハードウェア障害に伴い、送信メッセージの紛失や受信メッセージの重複が生成する可能性があります。トランザクションは、ディスクへの書込みを待機することなく、書込みがメモリーにキャッシュされた時点で完了するためです。オペレーティング・システムの正常シャットダウンや、WebLogic Serverプロセスの中断でこのような障害が発生することはありません。オペレーティング・システムは、正常シャットダウンの際にすべての未処理の書込みをフラッシュするためです。ビジー・サーバーの電源を突然切断すると、このようなのエラーが発生します。
次の項では、JDBCストアの例を示し、既存のDDLを使用したJDBCストア用のデータベースの作成について説明します。また、DDLファイルでOracle blobレコード列を有効にする方法についても説明します。
デフォルトのJDBCStoreMBeanパラメータを直接変更してJDBCストアを作成できます。管理コンソールを使用してJDBCストアを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJDBCストアの作成を参照してください。
JDBCストアで接頭辞を使用する場合の構成ガイドライン、およびJDBCデータ・ソースの推奨設定については、「JDBCストアの構成のガイドライン」を参照してください。
JDBCストアを作成するための主な手順は次のとおりです。
JDBCストアへのインタフェースとなるJDBCデータ・ソースまたはマルチ・データ・ソースを作成します。
JDBCストアを作成し、これをJDBCデータ・ソースまたはマルチ・データ・ソースに関連付けます。
接頭辞オプションに、構成するJDBCストア表ごとに1つの一意の値を構成することを強くお勧めします。
JDBCストアを使用するサブシステムに、JDBCストアを関連付けます。
JMSサーバーの場合は、「構成:全般」ページでJDBCストアを選択します。
ストア・アンド・フォワード・エージェントの場合は、「構成:全般」ページでJDBCストアを選択します。
パス・サービスの場合は、「構成:全般」ページでカスタム・ファイル・ストアを選択します。
ドメインの構成ファイルでのJDBCストアの定義例を示します。この例では、JDBCデータ・ソースMyDataSourceを使用しており、論理名が指定されています。
<jdbc-store> <name>SampleJDBCStore</name> <target>yourserver</target> <data-source>MyDataSource</data-source> <logical-name>Baz</logical-name> </jdbc-store>
表6-3に、JDBCストアの変更可能な構成パラメータを示します。
表6-3 JDBCストアの構成オプション
| オプション | 必須 | 機能 |
|---|---|---|
|
名前 |
はい |
JDBCストアの名前。ドメイン内のすべてのストアの間で一意であることが必要です。 |
|
対象 |
はい |
JDBCストアを対象指定するサーバー・インスタンスまたは移行可能対象。複数のサブシステムが同じサーバー・インスタンスまたは移行可能な対象を対象指定していれば、これらのサブシステムで同じJDBCストアを共有できます。 注意: JMSサービスで移行可能なターゲットを使用する場合は、JDBCストアをJMSサービスで使用するのと同じ移行可能なターゲットにターゲット指定する必要があります。『Oracle WebLogic Serverクラスタの使い方』のサービスの移行を参照してください。 |
|
データ・ソース |
はい |
ストアのデータベース表( 注意:グローバル(XA)トランザクションをサポートするように構成されたJDBCデータ・ソースは指定できません。したがって、指定されたJDBCデータ・ソースは非XA JDBCドライバを使用する必要があります。また、このデータ・ソースで「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を有効にすることはできません。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。 |
|
接頭辞名 |
いいえ |
通常、JDBCストアの表の接頭辞は 複数のJDBCストアを使用する場合は、構成するJDBCストアごとに1つの一意の接頭辞を設定する必要があります。接頭辞を指定しないと、JDBCストアの表名は単に 既存のJDBCストアの接頭辞を変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。 |
|
論理名 |
いいえ |
必要に応じて、EJBなどのWebLogic Serverサブシステムでモジュールをクラスタ全体にデプロイする場合に使用します。ただし、クラスタ内のサーバー・インスタンスごとに別々の物理ストアが必要になります。このような構成では、各物理ストアに固有の名前を付けますが、すべての永続ストアで同じ論理名を共有します。 |
|
DDLファイルからの表の作成 |
いいえ |
JDBCストアのデータベース表( |
管理コンソールを使用してJDBCストアを構成する手順は、Oracle WebLogic Server管理コンソール・ヘルプの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 |
|
Sybase |
sysbase.ddl |
DDLファイルは、JDBCストアのデータベース表(WLStore)を作成するためのSQLコマンド(末尾がセミコロン)を含むテキスト・ファイルです。したがって、このリストに含まれていないデータベースを使用する場合は、そのデータベースに合わせて既存のDDLファイルを編集します。詳細は、「カスタムDDLファイルを使用したJDBCストア表の作成」を参照してください。
「JDBCストア構成」ページには「DDLファイルからの表の作成」オプションがあります。このオプションを使用してJDBCストアのバッキング表(WLStore)の作成に使用する構成済のDDLファイルにアクセスできます。JDBCストアのバッキング表がすでに存在する場合、このオプションは無視されます。このオプションを使用するのは、未サポートのデータベース用に作成したカスタムDDLファイルを指定する場合や、以前のリリースのJMS JDBCストア表を最新のJDBCストア表にアップグレードする場合などです。
「DDLファイルからの表の作成」フィールドにDDLファイル名が指定されておらず、バッキング表が存在しないことがJDBCストアによって検出されると、データベース・ベンダー固有の構成済DDLファイルが実行され、自動的に表が作成されます(「サポートされるJDBCドライバ」を参照してください)。
「DDLファイルからの表の作成」フィールドにDDLファイル名が指定されており、バッキング・テーブルが存在しないことがJDBCストアによって検出されると、まずファイル・パスに指定したDDLファイルが検索され、見つからない場合はCLASSPATH内のDDLファイルが検索されます。ファイルが見つかった時点で、DDLファイル内のSQLが実行され、JDBCストアのバッキング表が作成されます。構成済のファイルが見つからず、既存の表も存在しない場合、JDBCストアは起動に失敗します。
「サポートされるJDBCドライバ」のリストにないデータベースを使用する場合は、既存のDDLテンプレート・ファイルをコピーし、使用するデータベースに合わせて編集できます。
JDKで用意されているJARユーティリティを使用すると、次のコマンドでDDLファイルを/weblogic/store/io/jdbc/ddlディレクトリに抽出できます。
jar xf com.bea.core.store.jdbc_1.0.0.0.jar /weblogic/store/io/jdbc/ddl
|
注意: weblogic/store/io/jdbc/ddlパラメータを省略すると、jarファイル全体が抽出されます。 |
使用しているデータベースに合わせてDDLファイルを編集します。SQLコマンドは複数行にわたって指定できます。末尾にはセミコロン(;)を付けます。シャープ記号(#)で始まる行はコメントです。
変更を保存し、新しいDDLの名前を適切な名前に変更します(例: mydatabase.ddl)。
Oracle WebLogic Server管理コンソール・ヘルプのJDBCストアの作成の説明に従って、JDBCストアを作成します。
「構成」ページの「DDLファイルからの表の作成」オプションを使用して、カスタムDDLファイルを指定します(例: /mydatabase.ddl)。
|
注意: Windowsシステムの場合、フルパス名には必ずドライブ文字を含めます。 |
Oracleデータベースの場合は、oracle_blob.ddlファイルを使用してレコード列のタイプがデフォルトのLONG RAWタイプではなく、BLOBレコード列タイプのJDBCストア表を作成できます。oracle_blob.ddlファイルは、「サポートされるJDBCドライバ」に示すように、WebLogic CLASSPATHにあらかじめ構成されています。
JDBCストアでOracle BLOB DDLを使用するには
JDBCストアを使用するサーバー・インスタンスを停止します。
「JDBCストア表の管理」の説明に従って、現在のJDBC表を削除します。
サーバー・インスタンスを再起動します。
Oracle WebLogic Server管理コンソール・ヘルプのJDBCストアの作成の説明に従って、新しい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のデフォルトのテスト対象の表名の詳細は、『Oracle WebLogic Server JDBCの構成と管理』のデータソースの接続テスト・オプションを参照してください。データベースを再接続する試行回数の設定は、『Oracle WebLogic Server 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 WebLogic Server JMSのプログラミング』のWebLogic JMSでのトランザクションの使い方を参照してください。
パフォーマンスは、以下の方法で向上させることもできます。
データベース作業に使用するJDBCデータ・ソースを、JMS送り先と同じサーバー上に配置します。この場合、トランザクションは依然として2フェーズですが、より小さいネットワーク・オーバーヘッドで処理されます。
JDBCストアの代わりにファイル・ストアを使用します。
通常同じトランザクション内で呼び出されるサービスが複数あれば、これらのサービスが同じストアを共有するように構成します。
データベース操作を直接実行するアプリケーションで、同じトランザクション内のストア・サービス(JMSなど)が呼び出される場合は、データベース操作用にロギング・ラスト・リソース(LLR)を有効にしたJDBCデータ・ソースを使用することを検討します。
LLRによる最適化を使用すると、トランザクションは2フェーズ・コミット・プロトコルに従いますが、データベース操作は単一のローカル・トランザクションで処理されるため、トランザクション全体のパフォーマンスは向上します。LLRによる最適化の使用の詳細は、『Oracle WebLogic Server JDBCの構成と管理』のロギング・ラスト・リソース・トランザクション・オプションに関する項を参照してください。
既存の各永続ストアおよび開かれている各ストア接続の統計情報をモニターできます。
永続ストアは、開かれている各永続ストア接続についてもPersistentStoreConnectionRuntimemMBeanを登録します。以下のオプションが用意されています。
表6-7永続ストア接続の実行時オプション
| オプション | 機能 |
|---|---|
|
CreateCount |
この接続に対して発行された作成リクエストの数 |
|
ReadCount |
この接続に対して発行された読取りリクエストの数 |
|
UpdateCount |
この接続によって発行された更新リクエストの数 |
|
DeleteCount |
この接続によって発行された削除リクエストの数 |
|
ObjectCount |
この接続に含まれるオブジェクトの数 |
表6-8に、永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムのランタイム接頭辞名の大部分を示します。
表6-8 永続ストアのランタイム接頭辞名
| サブシステム/サービス | ランタイム接頭辞名 |
|---|---|
|
デプロイメント |
weblogic.deploy.
|
|
診断サービス |
weblogic.diagnostics.
|
|
EJBタイマー・サービス |
weblogic.ejb.timer.
|
|
JMSサービス |
JMSサーバー
weblogic.messaging.jmsServer.
JMS恒久サブスクライバ
weblogic.messaging.jmsServer.durablesubs.
|
|
JTAトランザクション・ログ(TLOG) |
weblogic.transaction.
|
|
パス・サービス |
weblogic.messaging.PathService.
|
|
SAFサービス |
SAFエージェント
weblogic.messaging.SAFAgent@server1.
SAF恒久サブスクライバ
weblogic.messaging.SAFAgent@server1.durablesubs.
|
|
Webサービス |
weblogic.wsee.server.store.
|
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 |
ストア名、開かれているストア、またはストア内の接続を一覧表示します。 |
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 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コマンド・ラインにはないメソッドがいくつか用意されています。たとえば、関連するJavaオブジェクトを戻し、WLSTのスクリプトで使用できるgetopenstoresおよびgetstoreconnsなどです。
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コマンドでストアを閉じる必要があります。
ここでは、compactstoreメソッド(dir,tempdir='null')を使用してmystoresディレクトリ内でファイル・ストアのファイルによって占有されるスペースを圧縮するWLSTスクリプトの例を示します。
> wls:/offline> compactstore('c:\mystores','c:\tmpmystore.dir')
compactstore()メソッドは、開かれていないファイル・ストアに対してのみ使用できます。「dir」ソース・ディレクトリ内のファイルを格納するストアはすべて閉じておく必要があります。また、「tempdir」一時ディレクトリには、少なくともソース・ディレクトリと同程度の余分なスペースが必要です。一時ディレクトリとして、ソース・ディレクトリ内のディレクトリを指定することはできません。圧縮が正常に完了すると、新たに圧縮されたストア・ファイルがmystoresディレクトリに格納されます。さらに、tmpmystoreディレクトリの下に一意の名前の新しいディレクトリが作成され、圧縮前のストア・ファイルが格納されます。
永続ストアには以下の制限があります。
永続ファイル・ストアは、2つのサーバー・インスタンスから同時に開くことはできません。同時に開くと、ファイル内のデータが破損するおそれがあります。永続ストアは、同時に開かれたことが検知できたときにはエラーを戻そうとしますが、この状態が必ず検知できるとは限りません。管理者の責任において、複数のサーバーが同じ永続ストアに同時にアクセスを試みない環境でのみ永続ストアを使用するようにしてください(名前とディレクトリが同じ2つのファイル・ストアは「同じストア」とみなされます)。
データが破損するので、2つのJDBCストアで同じデータベース表を共有することはできません。
永続ストアは、任意の破損に対応できない可能性があります。ディスク・ファイルが任意のデータで上書きされた場合の結果がどうなるかは不確定です。ストアから矛盾したデータが戻されたり、ストアをまったく回復できなくなったりするおそれがあります。
ディスクが一杯になると、ファイル・ストアから例外が戻されることがあります。しかし、ディスク・スペースが使用可能になると例外をスローされなくなり、通常の処理が再開します。また、これまでに説明したとおり、永続ストア内のデータはそのまま残されます。
