| Oracle® Fusion Middleware Oracle WebLogic Serverサーバー環境の構成 11g リリース1 (10.3.6) B60987-04 |
|
 前 |
この章では、WebLogic Server永続ストアを構成およびモニターする方法について説明します。永続ストアは、永続性を必要とする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) |
サーバーによって調整された、完了していない可能性のあるコミット済みトランザクションに関する情報TLOGは、デフォルトの永続ストアまたはJDBC TLOGストアに保存できます。 |
|
|
パス・サービス |
メッセージのグループからメッセージング・リソースへのマッピング |
『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の詳細は、「ストア接続のモニター」を参照してください。
永続ストアの主な特徴は以下のとおりです。
各サーバー・インスタンスのデフォルト・ファイル・ストアは構成不要です。
すべてのサブシステムが同じサーバー・インスタンスまたは移行可能ターゲットをターゲット指定している場合のみ、デフォルト・ストアおよびカスタム・ストアを複数のサブシステムで共有できます。
構成すると、JDBC TLOGストアには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報が格納されます。アプリケーションのニーズに応じて、TLOG情報をデフォルト・ストアまたはJDBC TLOGストアのどちらに保持するかを選択できます。「JDBC TLogストアの使用」を参照してください。
高パフォーマンスのスループットとトランザクション・サポート
パラメータを修正してカスタム・ファイル・ストアやJDBCストアを作成できる
永続ストアの統計情報と開いているストア接続をモニターできる
クラスタリング環境では、サーバー全体レベルまたはサービス・レベルで、JDBC TLOGストアおよびカスタマイズしたストアを異常のあるサーバーからバックアップ・サーバーに移行できます。
永続ストアのパフォーマンス上の主な目標はスループットの向上です。複数のサブシステムが同じサーバー・インスタンスまたは移行可能ターゲットをターゲット指定していれば、これらのサブシステムで同じデフォルトまたはカスタム・ストアを共有できます。
|
注意: JDBC TLOGストアは、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を保持する場合にのみ使用されます。他のサブシステムによって共有できません。 |
この点が、永続ストアを使用するパフォーマンス上の利点です。なぜなら、同じストアを使用する複数のサービスに関係するトランザクションであっても、そのトランザクションのトランザクション・マネージャによって永続ストアが単一のリソースとして扱われるためです。たとえば、TLOG、JMSとEJBのタイマーが1つのファイル・ストアを共有し、JMSメッセージとEJBタイマーが単一のトランザクションで作成された場合、そのトランザクションは1フェーズとなり、リソースの書込みは1回しか発生しません。一方、2フェーズの場合であれば、リソースごとに2回ずつで合計4回のリソース書込みが発生し、加えてトランザクション・ログでのトランザクション・エントリの書込みが1回発生することになります。
ファイル・ストアおよびJDBCストアは、プロセスのクラッシュやハードウェアの電源障害が発生しても、コミットされた更新を失うことなく存続できます。コミットされていない更新は保持されるとは限りませんが、クラッシュ後にトランザクションが部分的に完了した状態で残されることはありません。
次に、ファイル・ストアとJDBC対応ストアの類似点と相違点を挙げます。
デフォルトの永続ストアはファイル・ストアにしかできません。したがって、JDBCストアはデフォルトの永続ストアとしては使用できません。
どちらもトランザクションのセマンティクスと保証を備えています。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 TLOGストアを構成し、JDBCを使用してこのストアにアクセスします。このストアは、別のサーバーに存在する場合もあります。そのあと、アプリケーションでは、データベース・ベンダーによって提供されるあらゆる高可用性ソリューションまたはフェイルオーバー・ソリューションを利用できます。また、JDBCストアではGridLinkデータ・ソースおよびマルチ・データ・ソースがサポートされるため、Oracle Real Application Clusters (Oracle RAC)など、可用性の高いデータベース・システムのノード間でのフェイルオーバーが可能です。詳細については、以下を参照。
『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のJDBCマルチ・データ・ソースの構成
『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のGridLinkデータ・ソースの使用
任意の永続ストア - WebLogic Serverベースのアプリケーション用のすぐに使用できる統合ソリューションを提供する、高可用性クラスタリング・ソフトウェアを使用します。
管理サーバーを含め、すべてのサーバー・インスタンスには、構成が不要なデフォルトの永続ストアがあります。デフォルト・ストアはファイルベースのストアで、サーバー・インスタンスのdata\store\defaultディレクトリに格納された一連のファイルにデータを保持します。デフォルト・ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト・ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトの記憶域メカニズムを使用することで最適に動作するサブシステムから使用できます。たとえば、永続ストアが構成されていないJMSサーバーは、管理対象サーバー用のデフォルトのストアを使用して永続メッセージングをサポートします。
デフォルト・ストアは、DefaultFileStoreMBeanパラメータを直接操作して構成できます。このMBeanがドメインの構成ファイルで定義されていない場合は、DefaultFileStoreMBeanには、構成サブシステムによってデフォルト値が確保されます。
また、管理コンソールを使用してデフォルト・ストアのパラメータを変更することもできます。たとえば、デフォルトのディレクトリの場所や同期書込みポリシーを変更できます。詳細は、Oracle WebLogic Server管理コンソール・ヘルプのデフォルト・ストアの設定の変更を参照してください。
デフォルト・ストアのデータは、ドメインのルート・ディレクトリの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ストアを使用します。トランザクション・ログを保持する場合は、JDBC TLOGストアを使用します。「JDBC TLogストアの使用」を参照してください。
クラスタ内のすべての物理ストアで同じ論理名を共有します。
異なるサービスを論理的に分けて、別々のファイルや表を使用します。(これにより、パフォーマンスは下がりますが、管理や保守は容易になります。)
移行可能なJMS関連サービスでは、デフォルトの永続ストアは使用できません。したがって、カスタム・ストアを構成し、移行可能なJMSサービスと同じ移行可能なターゲットにターゲット指定する必要があります。詳細は、『Oracle WebLogic Serverクラスタの使用』のサービスの移行を参照してください。
カスタム永続ストアは、次の方法で構成できます。
管理コンソールを使用する。カスタム・ファイル・ストアまたはJDBCストアの構成については、『Oracle WebLogic Server管理コンソール・ヘルプ』の永続ストアの構成に関する項を参照してください。JDBC TLOGストアの構成については、『Oracle WebLogic Server管理コンソール・ヘルプ』のトランザクション・ログ・ストアの構成に関する項を参照してください。
永続ストアをホストするサーバー・インスタンスの構成ファイル(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のデフォルトのWrite Cache Enabled設定を使用すると、ストレージ・デバイスの同期書込みの完了が誤って報告される可能性があります。システム・クラッシュや停電の発生はレコード/メッセージの失敗や重複につながる可能性があるため、これは、直接書込み(デフォルト)または直接書込み - キャッシュありポリシーで構成されたファイル・ストアを含む、(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対応ストアを構成および使用する方法について説明します。
JDBC TLogストア: トランザクション・ログ(TLOGs)をデータベースに保持します。「JDBC TLogストアの使用」を参照してください。
JDBCストア: WebLogic Serverインスタンス・サービスとサブシステム情報をデータベースに保持します(ただし、TLOGは除きます)。「JDBCストアの使用」を参照してください。
JDBC TLOGストアを構成すると、トランザクション・ログをデータベースに保持できます。これには次の利点があります。
基本データベースのレプリケーションとHA特性を活用できます。
データベースの状態とTLOGを簡単に同期できるため、災害からのリカバリを簡素化できます。
実行するトランザクション・ログを新しい場所に移行(コピー)する必要がないため、トランザクション・リカバリ・サービスの移行が向上します。
JDBC TLOGストアを作成するための主な手順は次のとおりです。
JDBCストアへのインタフェースとなるJDBCデータ・ソース、GridLinkデータ・ソースまたはマルチ・データ・ソースを作成します。「データ・ソースの選択」を参照してください。
JDBC TLOGストアを作成し、これを手順1で作成したJDBCデータ・ソース、GridLinkデータ・ソースまたはマルチ・データ・ソースに関連付けます。『Oracle WebLogic Server管理コンソール・ヘルプ』のトランザクション・ログ・ストアの構成に関する項を参照してください。
オプション。接頭辞オプションに、構成するJDBC TLOGストア表ごとに1つの一意の値を構成することを強くお薦めします。
高可用性のため、データ・ソースをバックアップ・サーバーで利用できるようにします。第6章「JDBC TLOGストア使用時のサーバー移行」を参照してください。
ご使用のWebLogic Serverライセンスとアプリケーションのニーズに応じて、次のデータ・ソース・タイプのいずれかを選択できます。
汎用データ・ソース - 『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のJDBCデータ・ソースの作成に関する項およびOracle RACでの接続時間フェイルオーバーの使用に関する項を参照してください。
GridLinkデータ・ソース - 『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のGridLinkデータ・ソースの使用に関する項を参照してください。
マルチ・データ・ソース - 完全にレプリケーションされたゼロ・レイテンシ・データベース(Oracle RACなど)によってバックアップされます。『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のJDBCマルチ・データ・ソースの構成に関する項およびOracle RACでマルチ・データ・ソースの使用に関する項を参照してください。
ドメインの構成ファイルでのJDBC TLOGストアの定義例を示します。この例では、JDBCデータ・ソースMyDataSourceを使用しており、論理名が指定されています。
<server>
<transaction-log-jdbc-store>
<data-source>MyDataSource</data-source>
<prefix-name>TLOG_MS1</prefix-name>
<create-table-ddl-file>myDDL/myCreateTable.sql</create-table-ddl-file>
<max-retry-seconds-before-tlog-fail>120</max-retry-seconds-before-tlog-fail>
</transaction-log-jdbc-store>
</server>
表6-4に、JDBCストアの変更可能な構成パラメータを示します。
表6-3 JDBC TLOGストアの構成オプション
| オプション | 必須 | 機能 |
|---|---|---|
|
はい |
ストアのデータベース表( 注意:グローバル(XA)トランザクションをサポートするように構成されたJDBCデータ・ソースは指定できません。したがって、指定されたJDBCデータ・ソースは非XA JDBCドライバを使用する必要があります。また、このデータ・ソースで「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を有効にすることはできません。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。 |
|
|
いいえ |
通常、JDBCストアの表の接頭辞は 複数のJDBCストアを使用する場合は、構成するJDBCストアごとに1つの一意の接頭辞を設定する必要があります。接頭辞を指定しないと、JDBCストアの表名は単に 既存のJDBCストアの接頭辞を変更した場合、サーバーの再起動は必ずしも必要ではありません(「カスタム永続ストアのパラメータの変更」を参照)。 |
|
|
いいえ |
JDBCストアのデータベース表( |
|
|
デフォルトは20です。 |
データベースを呼び出すごとに削除される最大表行数。 |
|
|
バッチごとに挿入(最大) |
デフォルトは20です。 |
データベースを呼び出すごとに挿入される最大表行数。 |
|
デフォルトは20です。 |
データベースを呼び出すごとに削除される最大表行数。 |
|
|
デフォルトは300です。 |
WebLogic ServerがJDBC TLogストア障害からのリカバリを試行する最大時間(秒単位)。この期間後でもストアを使用できない場合は、WebLogic Serverによって正常性状態がHEALTH_FAILEDに設定されます。値が0の場合は、WebLogic Serverによって再試行は実行されず、ただちに正常性状態がHEALTH_FAILEDに設定されます。 |
|
|
デフォルトは60です。 |
トランザクションの処理中にWebLogic ServerがJDBC TLogストア障害からのリカバリを試行するまでの最大待機時間(秒単位)。この期間後でもストアを使用できない場合は、影響を受けるトランザクションはWebLogic Serverによってロールバックされます。値が0の場合は、WebLogic Serverによって再試行は実行されず、ただちにトランザクションはロールバックされます。実際の最大値は、 |
|
|
デフォルトは5です。 |
ストア障害発生後に、WebLogic ServerがTLOGストアの正常性を検証する試行を実行するまでの最大待機時間(秒単位)。 |
管理コンソールを使用してJDBC TLOGストアを構成する手順は、『Oracle WebLogic Server管理コンソール・ヘルプ』のトランザクション・ログ・ストアの構成に関する項を参照してください。
次の項では、JDBC TLOGストアの構成に関するガイドラインを示します。
JDBC TLOGストアをターゲットにできるのは、グローバル・スコープ(アプリケーション・スコープではありません)のデータ・ソースのみです。
1台のWebLogic Serverごとに構成できるJDBC TLOGストアの数は1つのみです。逆に、複数のWebLogic Serverで1つのJDBC TLOGストアを共有できません。
JDBC TLOGストアを構成する必要があります。デフォルトでは、TLOG情報をサーバーのデフォルト永続ストアに保持するよう設定されています。
XA JDBCドライバを使用するよう構成されたデータ・ソースや、グローバル・トランザクションをサポートするよう構成されたデータ・ソースは使用できません。非XAデータ・ソースを使用します。
JDBC対応ストアに関する一般ルールについては、「JDBCストアの構成のガイドライン」を参照してください。
次の項では、JDBC TLOGストアの動作と制約に関する追加の考慮事項について説明します。
TLOG情報の保存に使用されるデータベースは、サーバー起動時に使用可能な状態である必要があります。データベースが使用できない場合は、WebLogic Serverインスタンスの起動が失敗します。
JDBC TLOGストアを使用し、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を保持できるのは、JTAサブシステムのみです。それ以外のシステムはJDBC TLOGストアにアクセスできません。
JDBC TLOGストアを使用してもLLR動作は変更されません。JDBC TLOGストアはLLRの有無に関係なく使用できます。LLRトランザクションと連動して使用すると、情報をコミットするトランザクションはLLR表に保存されますが、チェックポイント・レコードとヒューリスティック・ログはJDBC TLOGストアに保存されます。
TLOGストアのタイプが別のタイプに変更されたり、場所が別の場所に変更される場合、変更内容は再起動後にのみ有効となり、古いストア内に保留中のすべてのトランザクションは新しいストアにコピーされません。TLOGストアのストア・タイプまたは場所を変更する前に、保留中のトランザクションがないことを確認する必要があります。
JDBC TLOGストアが使用できない場合、JTAの正常性状態はFAILEDに遷移し、あらゆるグローバル・トランザクションは失敗します。同様に、サーバーのライフサイクルもFAILEDに変更されます。JTAトランザクション・リカバリ・システムは、可能な場合は一時的なランタイム・エラーからの復旧を試行し、インダウト・トランザクションを解決します。「JDBC TLOGストア使用時のサーバー移行」を参照してください。
TLOGの保存に使用されるデータベースが破損しているため復旧できない場合、保留中のトランザクション情報はすべて失われます。
JDBC TLOGストアによって使用されるデータベースの表または行がなんらかの理由でデータベース内でロックされている場合、データベース管理者が手動でこのロック状態を解除する必要があります。これを行わないと、JTAサブシステムはブロックされ、ロックを解除するまで一時停止状態となります。また、ロックによる例外が発生します。JTAサブシステムは、ロックを解除するか、またはMaxRetrySecondsBeforeTLOGFailの値が超過するまで、正常に実行されません。
|
注意: ロックされたローカル・トランザクションに関する機能は、データベースの種類によって異なります。一部のデータベースでは、データベースのロック状態をただちに解決することが難しい場合があります。アプリケーション環境で基本的な行ロックの問題が発生する場合は、詳細情報についてデータベース管理者に連絡する必要があります。 |
WebLogic Serverでは、JDBC TLOGストアの使用時にトランザクション・リカバリ・サービスの移行について、手動および自動の両方で実行する機能をサポートしています。JDBC TLOGストアによって使用されるデータ・ストアは、プライマリ・サーバー・インスタンスとバックアップ・サーバー・インスタンスの両方でターゲットにする必要があります。クラスタ内のすべてのサーバー・インスタンスをデータ・ソースのターゲットに指定することをお勧めします。詳細は、『Oracle WebLogic Server JTAのプログラミング』のサーバーに障害が発生した後のトランザクションのリカバリに関する項を参照してください。
トランザクション・ログ・ストアの統計および開かれている各ストア接続の統計情報をモニターできます。永続ストアを監視する方法の詳細については、「永続ストアのモニター」を参照してください。
WebLogic ServerでJDBC TLOGストアを使用するように構成すると、次の形式の名前を使用して重要ではないサブシステムとしてストアは正常性管理システムに登録されます。
PersistentStore.TLOG_servername
ここで、servernameは、プライマリTLOGストアをホストしているWebLogic Server インスタンスの名前を示します。
管理コンソールでJDBC TLOGストアの正常性状態を監視できます(『Oracle WebLogic Server管理コンソールのヘルプ』のサーバーの正常性の監視に関する項を参照してください)。
管理コンソールでトランザクション・ログ・ストア統計情報を監視できます(『Oracle WebLogic Server管理コンソールのヘルプ』のサーバーのトランザクション・ログ統計情報の表示に関する項を参照してください)。
管理コンソールでトランザクション・ログ・ストア接続を監視できます(『Oracle WebLogic Server管理コンソールのヘルプ』のTLOGストア接続の統計情報の表示に関する項を参照してください)。
JDBC TLOGストア表をはじめ、アプリケーション環境は適切に保護します。これを怠ると、次の現象が発生する可能性があります。
悪意を持って、あるいは意図せずに情報を削除します。このような削除によって、トランザクション情報が損失し、影響を受けるグローバル・トランザクションがヒューリスティックに完了されます。
悪意を持って、あるいは意図せずに情報を改変します。このような改変によって、予期しない動作が発生する可能性があります。
トランザクションの開始時や関与するリソース情報などの機密トランザクション情報を読み取ります。
データベース・インスタンスやデータベース・マシンにアクセスします。
JTAとデータベース間のネットワークにアクセスし、データの妨害、閲覧、または改変などが行われる可能性があります。
第6章「セキュリティの考慮事項」を参照してください。
次の項では、JDBCストアの例を示し、既存のDDL、カスタム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-4に、JDBCストアの変更可能な構成パラメータを示します。
表6-4 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では、サポートされるデータベース用の一部のドライバが自動的に検出されます。
これらのデータベースごとに対応するDDL (データ定義言語)ファイルがあり、MW_HOME\modules\com.bea.core.store.jdbc_1.0.0.0.jarファイル内のweblogic/store/io/jdbc/ddlディレクトリに格納されています。MW_HOMEは、WebLogic Serverの最上位のインストール・ディレクトリです。
表6-5 サポートされるJDBCドライバと対応するDDLファイル
| データベース | DDLファイル |
|---|---|
|
IBM DB2 |
db2.ddl db2v6.ddl |
|
Informix |
informix.ddl |
|
Microsoft SQL (MSSQL) Server |
mssql.ddl |
|
MySQL |
mysql.ddl |
|
Oracle |
oracle.ddl oracle_blob.ddl oracle_blob_securefile.ddl |
|
Sybase |
sysbase.ddl |
DDLファイルは、JDBCストアのデータベース表(WLStore)を作成するためのSQLコマンド(末尾がセミコロン)を含むテキスト・ファイルです。したがって、このリストに含まれていないデータベースを使用する場合は、そのデータベースに合わせて既存のDDLファイルを編集します。詳細は、「カスタムDDLファイルを使用したJDBCストア表の作成」を参照してください。
「JDBCストア構成」ページには「DDLファイルからの表の作成」オプションがあります。このオプションを使用してJDBCストアのバッキング表(WLStore)の作成に使用する構成済のDDLファイルにアクセスできます。JDBCストアのバッキング表がすでに存在する場合、このオプションは無視されます。このオプションを使用するのは、未サポートのデータベース用に作成したカスタムDDLファイルを指定する場合や、以前のリリースのJMS JDBCストア表を最新のJDBCストア表にアップグレードする場合などです。
「DDLファイルからの表の作成」フィールドにDDLファイル名が指定されておらず、バッキング表が存在しないことがJDBCストアによって検出されると、データベース・ベンダー固有の構成済DDLファイルが実行され、自動的に表が作成されます(「サポートされるJDBCドライバ」を参照してください)。
「DDLファイルからの表の作成」フィールドにDDLファイル名が指定されており、バッキング表が存在しないことがJDBCストアによって検出されると、まずファイル・パスに指定したDDLファイルが検索され、見つからない場合はCLASSPATH内のDDLファイルが検索されます。ファイルが見つかった時点で、DDLファイル内のSQLが実行され、JDBCストアのバッキング表が作成されます。構成済のファイルが見つからず、既存の表も存在しない場合、JDBCストアは起動に失敗します。
「サポートされるJDBCドライバ」のリストにないデータベースを使用する場合は、既存のDDLテンプレート・ファイルをコピーし、使用するデータベースに合わせて編集できます。
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ファイルまたはoracle_blob_securefile.ddlファイルを使用してレコード列のタイプがデフォルトのLONG RAWタイプではなく、BLOBレコード列タイプのJDBCストア表を作成できます。oracle_blob.ddlは、Oracleベーシック・ファイルのBLOBの作成に使用され、oracle_blob_securefile.ddlファイルはOracleセキュア・ファイルのBLOBの作成に使用されます。両方のファイル・タイプは、「サポートされるJDBCドライバ」に示すように、WebLogic CLASSPATHにあらかじめ構成されています。
Oracle Database 11gリリース2には、セキュア・ファイル用のゼロ・コピーI/Oパフォーマンス機能改善およびBLOB用の論理キャッシュが含まれます。これらの機能改善を使用すると、メッセージ・サイズが大きい場合やデータベースへのネットワーク接続速度が遅い場合に、JDBCストアによるスループットを向上できます。Oracle LONG RAWデータ型は、データベースへの接続速度が速い場合に、BLOBSよりも通常はパフォーマンスが高くなります。
|
注意: すでにOracleのLONG RAW列に入っているデータを保持する必要がある場合は、この方法でBLOBに切り替えないようにしてください。このような場合は、SQL ALTER TABLEコマンドに関するOracleドキュメントを参照してください。 |
JDBCストアでOracle BLOB DDLを使用するには
JDBCストアを使用するサーバー・インスタンスを停止します。
「JDBCストア表の管理」の説明に従って、現在のJDBC表を削除します。
サーバー・インスタンスを再起動します。
Oracle WebLogic Server管理コンソール・ヘルプのJDBCストアの作成の説明に従って、新しいJDBCストアを作成します。
「全般的な構成」ページの「DDLファイルからの表の作成」フィールドで、次の場所を入力します。
oracle_blob.ddlファイルは、/oracle_blob.ddl
oracle_blob_securefile.ddlファイルは、/oracle_blob_securefile.ddl
「完了」をクリックすると、JDBCストアのバッキング表が作成されます。
Oracle BLOBSの使用時に、ThreeStepThresholdの値を調整するとパフォーマンスを向上できる場合があります。
JDBCストア・スキーマには、Oracle BLOB列(ベーシック・ファイルまたはセキュア・ファイル)が含まれ、JDBCストアによって、BLOBデータのサイズに基づいて次の実装のいずれかを使用してBLOBデータが自動的に設定されます。
JDBCストアによって、1回の手順でBLOBデータを含む行がストア表に直接挿入されます。関与するのが1回の手順のみであるため、JDBC一括挿入も採用されており、データ・サイズが小さい場合はこの方法が最高のパフォーマンスを発揮します。この実装は、挿入するBLOBデータがThreeStepThresholdの値以下の場合に使用されます。
JDBCストアによって、Oracle LOB APIを使用して、3段階でBLOBデータを含む行がストア表に直接挿入されます。この実装は、データ・サイズが大きい場合に良好なパフォーマンスを発揮します。この実装は、挿入するBLOBデータがThreeStepThresholdの値より大きい場合に使用されます。
ThreeStepThresholdのデフォルト値は200Kです。
JDBC utils.Schemaユーティリティを使用すると、既存のバージョンを削除することで新しいJDBCストア・データベース表(WLStore)を再生成できます。通常、この表は自動的に作成されるため、このユーティリティを実行する必要はありません。しかし、既存のJDBCストア・データベース表に障害が発生した場合は、utils.Schemaユーティリティを使用して削除できます。
utils.SchemaユーティリティはJavaプログラムで、以下の項目を指定するコマンド・ライン引数をとります。
JDBCドライバ
データベース接続情報
データベース表を作成するSQLデータ定義言語(DDL)コマンドを含むファイルの名前
utils.Schemaコマンドを次のように入力します。
$ java utils.Schema url JDBC_driver [options] DDL_file
|
注意: utils.Schemaを実行するには、CLASSPATHにweblogic.jarファイルを指定する必要があります。 |
表6-6にutils.Schemaのコマンド・ライン引数を示します。
表6-6 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スキーマによって本番カタログ内に作成され、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の構成と管理』のロギング・ラスト・リソース・トランザクション・オプションに関する項を参照してください。
JDBCストアのI/O負荷が重い環境の場合、複数のJDBC接続を使用して同時にI/O処理を実行するようにJDBCストアを構成すると、パフォーマンスを向上できます。
|
注意: 付加が軽い環境でI/Oマルチスレッド処理を有効化すると、実際にはパフォーマンスが低下する場合があります。アプリケーションを適切に調整することをお勧めします。 |
I/Oマルチスレッド処理を有効化するには、Worker Count属性を1より大きい整数値に設定します。構成プロパティのデフォルト値は1で、この状態ではオプションは無効になっています。Worker Count属性によって、JDBCストアがI/Oの処理に使用するワーカー・スレッド数が指定されます。各ワーカー・スレッドによって、ストアの開放時に構成済のデータ・ソース・プールからJDBC接続が1つ取得されます。多くの場合、マルチスレッド処理の利点は同時実行スレッド数が4つを超えると減少する傾向にあります。データベースへの接続速度が遅い場合、マルチスレッド処理によってパフォーマンスが向上しない場合があります。
|
注意: Worker Countを接続プールで使用可能な接続数が足りない値に設定すると、JDBCストアの開放に失敗します。 |
Worker Preferred Batch Size属性の値を変更すると、各ワーカー・スレッドの作業負荷を調整できます。この属性値を増加すると、各ワーカー・スレッドに割り当てられる作業負荷が徐々に増加します。作業負荷はストアのI/Oリクエストから構成されます。これらのリクエストはグループ化され、処理のために各JDBCワーカー・スレッドにプッシュされます。各I/Oリクエストのサイズが共通して非常に大きい場合(1 MBのJMSメッセージを保存するリクエストなど)、Worker Preferred Batch Sizeの値を小さく調整してパフォーマンスを向上させます。
I/Oマルチスレッド処理を有効にすると、ストアI/O処理を同時に実行するために複数のJDBC接続が使用されます。この結果、データベース・リソースの競合が発生する可能性があります。Oracle Database上の競合を低減するには、I/Oマルチスレッド処理の使用時に主キー索引をリバース・キー索引に再構築することをお勧めします。I/Oマルチスレッド処理を使用してから無効にする場合、主キー索引を非リバース・キー索引に再構築することをお勧めします。リバース・キー索引に関する詳細については、『Oracle Databaseの概念』の索引および索引が整理された表に関する項を参照してください。
次の基本手順を実行し、Oracle Database用ストア表索引を再構築します。
ストア・スキーマ名の下にあるOracle Databaseにログインします。ストア・スキーマ名は、データ・ソース・ユーザー名と同じでも異なっていても有効です。
『Oracle Database用リバース索引の構築』または「Oracle Database用非リバース索引の構築」に記載したPL/SQLスクリプトを使用し、必要に応じてストア表索引を再構築します。「JDBCストアでの接頭辞の使い方」で説明したように、各スクリプトの<Store Table Name>をストア表名に置き換えます。PL/SQLの詳細については、Oracle DatabaseコンセプトのPL/SQLサブプログラムの実行に関する項を参照してください。
|
注意: リバース索引はI/Oマルチスレッド処理に使用し、非リバース索引はシングル・スレッドI/Oに使用することをお勧めします。 |
ストア表索引をOracle Database用リバース索引として再構築するには、次のPL/SQLブロックをストア・データベース・ユーザーとして実行します。
declare
idx user_ind_columns.index_name%TYPE;
alter_stmt VARCHAR2(200);
begin
select index_name into idx from user_ind_columns where table_name =
<Store Table Name> and column_name = 'ID';
alter_stmt := 'alter index ' || idx || ' rebuild reverse';
dbms_output.put_line(alter_stmt);
execute immediate alter_stmt;
end;
/
ストア表索引をOracle Database用非リバース索引として再構築するには、次のPL/SQLブロックをストア・データベース・ユーザーとして実行します。
declare
idx user_ind_columns.index_name%TYPE;
alter_stmt VARCHAR2(200);
begin
select index_name into idx from user_ind_columns where table_name =
<Store Table Name> and column_name = 'ID';
alter_stmt := 'alter index ' || idx || ' rebuild noreverse';
dbms_output.put_line(alter_stmt);
execute immediate alter_stmt;
end;
/
既存の各永続ストアおよび開かれている各ストア接続の統計情報をモニターできます。
永続ストアは、開かれている各永続ストア接続についてもPersistentStoreConnectionRuntimemMBeanを登録します。以下のオプションが用意されています。
表6-8 永続ストア接続の実行時オプション
| オプション | 機能 |
|---|---|
|
CreateCount |
この接続に対して発行された作成リクエストの数 |
|
ReadCount |
この接続に対して発行された読取りリクエストの数 |
|
UpdateCount |
この接続によって発行された更新リクエストの数 |
|
DeleteCount |
この接続によって発行された削除リクエストの数 |
|
ObjectCount |
この接続に含まれるオブジェクトの数 |
表6-9に、永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムのランタイム接頭辞名の大部分を示します。
表6-9 永続ストアのランタイム接頭辞名
| サブシステム/サービス | ランタイム接頭辞名 |
|---|---|
|
デプロイメント |
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-10に、JavaおよびWLSTで使用できるストア管理コマンドを示します。
表6-10 永続ストアの管理オプション
| 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などです。
|
注意: このリリースでは、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のデフォルト値を使用することもできます。省略可能なパラメータのデフォルト値は、コマンド固有のヘルプに一覧表示されます。
ここでは、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ストアで同じデータベース表を共有することはできません。
永続ストアは、任意の破損に対応できない可能性があります。ディスク・ファイルが任意のデータで上書きされた場合の結果がどうなるかは不確定です。ストアから矛盾したデータが戻されたり、ストアをまったく回復できなくなったりするおそれがあります。
ディスクが一杯になると、ファイル・ストアから例外が戻されることがあります。しかし、ディスク・スペースが使用可能になると例外をスローされなくなり、通常の処理が再開します。また、これまでに説明したとおり、永続ストア内のデータはそのまま残されます。
