WebLogic永続ストアのチューニングこの章では、永続ストアをチューニングする方法について説明します。Serverのサブシステムおよびサービスに高性能な組込みストレージ・ソリューションを提供します。永続ストア使用時のベスト・プラクティスJDBCストアのチューニングファイル・ストアのチューニングネットワーク・ファイル・システムの使用この章を読み込む前に、WebLogicストアの管理と監視についてよく知っておくことをお薦めします。Serverサーバー環境の構成』のWebLogic永続ストアの使い方を参照してください。次の項では、永続ストアの使い方について説明します。管理サーバーを含め、すべてのサーバー・インスタンスには、構成が不要なデフォルトの永続ストアがあります。デフォルト・ストアはファイルベースのストアで、サーバー・インスタンスのdata\store\defaultディレクトリに格納された一連のファイルにデータを保持します。デフォルト・ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト・ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができます。永続ストアが構成されていないJMSサーバーは、管理対象サーバー用のデフォルトのストアを使用して永続メッセージングをサポートします。Serverサーバー環境の構成』のWebLogic永続ストアの使い方に関する項。Server管理コンソール・ヘルプのデフォルト・ストアの設定の変更に関する項。カスタム・ファイル・ストアとJDBCストアの使い方デフォルトのファイル・ストアを使用するだけでなく、特定のニーズに合わせてファイル・ストアやJDBCストアを構成することもできます。デフォルト・ファイル・ストアと同様、カスタム・ファイル・ストアもディレクトリに格納された一連のファイルにデータを保持します。特定のストレージ・デバイスにデータを保持するカスタム・ファイル・ストアを作成することもできます。ファイル・ストアのディレクトリを構成する場合は、そのファイル・ストアが配置されているサーバー・インスタンスにアクセスできるディレクトリを設定する必要があります。JDBCストアは、リレーショナル・データベースをストレージとして使用している場合に構成できます。JDBCストアを使用することで、指定のJDBCデータ・ストアを介してアクセスできる標準のJDBC対応データベースに永続メッセージを格納できます。JDBCストアのデータベース表に格納されたデータには、WLStoreという論理名が付けられます。データベースの高可用性とパフォーマンスを構成するかどうかは、データベース管理者の判断です。Serverサーバー環境の構成』のカスタム永続ストアの使用タイミング。Serverサーバー環境の構成』のファイル・ストアとJDBCストアの比較。Serverサーバー環境の構成』のカスタム(ユーザー定義)ファイル・ストアの作成。Serverサーバー環境の構成』のJDBCストアの作成。TLOGストアを構成してトランザクション・ログがデータベースに永続化されるようにできます。これによって、ベースとなるデータベースのレプリケーションとHA特性を利用したり、障害時リカバリを簡易化したり、トランザクション・リカバリ・サービスの移行を改善できます。TLogストアの使用に関する項を参照してください。各JMSサーバーではファイルベースのページング・ストアが暗黙的に作成されます。JVMが低メモリー状態で動作しているときに、非永続性メッセージおよび永続メッセージのページングに使用されます。ページング・ストアを使用すると、アプリケーションによってはディスク・アクティビティが増大することがあります。オプションで、ページングが開始するしきい値設定およびディレクトリの場所を変更できます。可能な場合、一時ディレクトリなどローカルなファイル・システムにページング・ストア・ディレクトリの場所を指定すると、パフォーマンスを向上できます。ページング・ストア・ファイルはJMSサーバーを再起動するたびに自動的に再読込みされるので、どこからでもアクセスできる場所にバックアップ、レプリケートまたは配置する必要はありません。9.x以降でJMSサーバーの動作を参照してください。注意:ページングされた永続メッセージは、次の2つの場所に格納される可能性があります。通常は、デフォルト・ストアまたはカスタム・ストア。場合によっては、ページング・ディレクトリ。フラッシュ・ストレージを使用したJMSメッセージのページングローカルでマウントされたエンタープライズクラスのフラッシュ・ストレージ・デバイス上のディレクトリを参照するようJMSサーバーのページング・ディレクトリを構成すると、多くの場合、JMSメッセージ(永続または非永続)のページングのパフォーマンスを向上させることができます。これは、他のテクノロジよりも大幅に速い可能性があります。注意:ほとんどのフラッシュ・ストレージ・デバイスは単一障害点で、通常、ローカル・デバイスとしてのみアクセス可能です。障害の後にデータをリカバリしたり、必要に応じて自動的に再構築したりしないJMSサーバーのページング・ディレクトリとしては適しています。安全にリカバリできる必要のあるデータが通常含まれるカスタム・ストアやデフォルト・ストアとしては、ほとんどの場合、フラッシュ・ストレージ・デバイスは適していません。デフォルト・ストアまたはカスタム・ストアのDirectory属性の構成で、通常は単一障害点のデバイス上のディレクトリを参照しないようにします。フラッシュ・ストレージ・デバイスを使用してJMSメッセージをページングするには、次の手順を使用します。JMSサーバーのメッセージ・ページング・ディレクトリ属性をフラッシュ・ストレージ・デバイスのパスに設定します。「メッセージ・ページング・ディレクトリの指定」を参照してください。「メッセージ・バッファ・サイズ」属性(ページングのアクティブ化を制御)をチューニングします。高速のI/O処理によって負荷を吸収できる場合、より低いしきい値を使用できます。「「メッセージ・バッファ・サイズ」オプションのチューニング」を参照してください。JMSサーバーの割当てをチューニングし、フラッシュ・ストレージの領域の制限に対応します。これによって、JMSサーバーで、デバイスに格納できる以上のメッセージをページングしなくなります。場合によっては、実行時エラーや自動停止が発生することがあります。(16MB単位で切上げ)と想定します。「割当ての定義」を参照してください。診断ストアは、ファイル・ストアで、暗黙的に「無効化された」同期書込みポリシーを使用します。診断ストアは、WebLogicサーバーの診断情報を格納します。WebLogicサーバーのインスタンスごとに1つの診断ストアが構成されています。Server診断フレームワークの構成と使用』の診断アーカイブの構成を参照してください。永続ストア使用時のベスト・プラクティス同じサーバー・インスタンスを共有するサブシステムでは、サブシステムごとにストアを使用するのではなく複数のサブシステムで1つのストアを共有します。ストアを共有すると、次の理由から効率性が高まります。同時発生する複数のリクエストを1つのストアで1つのI/Oにまとめることで、全体のディスク使用率が減少します。参加するリソースが1つだけのトランザクションは軽量の1フェーズ・トランザクションです。逆に、複数のストアが関与するトランザクションは、より重い2フェーズ・トランザクションになります。同じサーバー・インスタンスで動作するすべてのSAFエージェントやJMSサーバーは、同じストアを共有するように構成します。古いストア(群)を拡張しなくなった場合にのみ、新しいストアを追加します。JDBCストアのチューニング次の項では、JDBCストアのチューニングについて説明します。JDBCストアのI/O負荷が高い場合、複数のJDBC接続を使用してI/O操作を同時に処理するようJDBCストアを構成すると、パフォーマンスが向上します。Serverサーバー環境の構成』のJDBCストアのI/Oマルチスレッドの有効化に関する項を参照してください。BLOBを使用する場合、ThreeStepThreshold値をチューニングすると、パフォーマンスが向上することがあります。BLOBレコード列の有効化に関する項を参照してください。空のストアを初期化するために使用されるJDBCストアDDLの場所は、構成できるようになっています。これにより、データベース表を作成するためのカスタムDDLを簡単に使用できるようになっています。このDDLはデータベースの特定のパフォーマンス・チューニングに使用されることもあります。Serverサーバー環境の構成』のWebLogic永続ストアの使い方に関する項を参照してください。ファイル・ストアのチューニング次の項では、ファイル・ストアのチューニングについて説明します。次の項では、ファイル・ストアのチューニングに関する一般的な情報を提供します。基本的な(非RAIDの)ディスク・ハードウェアの場合、ファイル・ストアごとに1つの専用のディスクを使用することを検討します。構成された各ストアや各JMSサーバー用のJMSページング・ストアの他に、デフォルト・ファイル・ストアがあることに留意してください。カスタムとデフォルトのファイル・ストアの場合は、同期書込みポリシーをチューニングします。キャッシュあり」、「直接書込み」および「キャッシュ・フラッシュ」の3つのトランザクションの安全な同期書込みポリシーがあります。キャッシュあり」は、これらのポリシーのうち最もパフォーマンスがよく、「キャッシュ・フラッシュ」は、最もパフォーマンスの悪いポリシーです。「直接書込み」は、デフォルトです。キャッシュあり」は、プライマリ・ファイルに加えてキャッシュ・ファイルを作成します。「無効化された」同期書込みポリシーは、トランザクションで安全ではありません。「無効化された」書込みポリシーを使用すると、特にクライアント負荷が低いときに、パフォーマンスを大幅に向上します。書込みポリシーは、システムの開始時および停電のときに非同期になって、データが失われる可能性があるので、安全ではありません。Serverサーバー環境の構成』の同期書込みポリシーの構成のガイドラインに関する項を参照してください。Enabled設定を使用すると、ストレージ・デバイスの同期書込みの完了は正しく報告されません。システム・クラッシュや停電が発生したときは、レコードやメッセージが失われたり、重複されたりするからです。キャッシュありポリシーで構成されたファイル・ストアを含む、トランザクション製品(Oracleに固有でない)のトランザクション・セマンティクスが違反されます。ストレージ・デバイスの物理的な機能を超える高い永続メッセージ/トランザクション・スループットの場合、この問題が現れます。Enabled設定を無効にするか、または電源保護のあるストレージ・デバイスを使用します。http://support.microsoft.com/kb/281672およびhttp://support.microsoft.com/kb/332023を参照してください。ベンダーを直接的に比較する場合、永続ストアの書込みポリシーをすべて同等のポリシーにします。WebLogic以外の一部のベンダーには、デフォルトで「無効」に相当する動作をするものがあります。同期書込みポリシーに応じて、カスタム・ストアとデフォルト・ストアには、複数の追加のチューニング可能な属性があります。これにより、パフォーマンスが向上する可能性があります。これには、CacheDirectory、MaxWindowBufferSize、IOBufferSize、BlockSize、InitialSizeおよびMaxFileSizeなどがあります。MBeanリファレンスのJMSFileStoreMBeanに関する項を参照してください。注意:JMSFileStoreMBeanは非推奨ですが、個別のbean属性が、カスタムとデフォルト・ファイル・ストアの非推奨ではないbeansに適用されます。ディスク・パフォーマンスがボトルネックの状況が続く場合、組込みのライトバック・キャッシュを備えたディスク・コントローラ・ハードウェアまたはRAIDコントローラ・ハードウェアの購入を検討します。これらのキャッシュで一時的に永続データを揮発性のメモリーへ保存すると、大幅にパフォーマンスが向上します。ライトバック・キャッシュでのトランザクションを確実に安全なものにするには、ライトバック・キャッシュを停電、ホスト・マシン障害、およびオペレーティング・システム障害から保護する必要があります。このような保護機能は通常、バッテリ・バックアップのあるライトバック・キャッシュで提供されます。キャッシュあり」同期書込みポリシーは、通常最もパフォーマンスのよいオプションで、トランザクション上安全なディスク書込みが行われます。みポリシーほどパフォーマンスはよくありませんが、「無効」ポリシーは、システム障害の発生時にバッファされた書込みが失われないようにする方法がない場合、本番システムに対して安全なオプションではありません。キャッシュありファイル・ストアは、ファイル・ストアの構成のDirectory属性で定義された場所に格納される一連のプライマリ・ファイルに同期して書込みます。ファイル・ストアは、ファイル・ストアの構成のCacheDirectory属性で定義された場所にある、対応するキャッシュ・ファイルにも非同期に書込みます。キャッシュ・ディレクトリとプライマリ・ファイルは、別々の目的に使用され、異なる場所に存在する必要があります。多くの場合は、プライマリ・ファイルは、高可用性のためにリモート記憶域に格納されている必要があります。キャッシュ・ファイルは、高可用性ではなく、厳密にパフォーマンスのために使用されるので、ローカルな場所に格納できます。キャッシュあり」同期書込みポリシーを選択すると、次の複数の追加のチューニング・オプションを考慮する必要があります。CacheDirectoryの設定。パフォーマンスのためにキャッシュ・ディレクトリがローカルなファイル・システムに存在する必要があります。デフォルトでは、オペレーティング・システムのtempディレクトリに存在しています。MaxWindowBufferSizeおよびIOBufferSize属性の増加。これらの属性は、ファイル・ストアのネイティブなメモリー使用量をチューニングします。InitialSizeおよびMaxFileSize属性の増加。これらの属性は、それぞれストアの初期サイズとストア内の特定のファイルの最大サイズをチューニングします。BlockSize属性のチューニング。「ファイル・ストアのブロック・サイズのチューニング」を参照してください。MBeanリファレンスのJMSFileStoreMBeanに関する項を参照してください。フラッシュ・ストレージを使用したパフォーマンスの向上エンタープライズクラスのフラッシュ・ドライブを使用すると、リアルタイム・アプリケーションでのデータのアクセスが回転式ディスクより大幅に速くなり、他のタスクの処理にメモリーを使用できるため、I/Oのパフォーマンスを向上させることができます。フラッシュ・ストレージ・デバイスのパスを使用してCacheDirectory属性を更新するのみです。ストアのプライマリ・ファイルの完全なコピーを格納するのに十分な空き領域が、デバイスにあることを確認します。MBeanリファレンスのCacheDirectory属性を参照してください。キャッシュありポリシーをチューニングする際には、次の項目を考慮する必要があります。キャッシュあり同期書込みポリシーを使用する場合は、さらにセキュリティおよびファイル・ロッキングの考慮事項がある場合があります。MBeanリファレンスの「JMSFileStoreMBean」のCacheDirectoryとLockingEnabled属性を参照してください。JMSFileStoreMBeanは非推奨ですが、個別のbean属性が、カスタムとデフォルト・ファイル・ストアの非推奨ではないbeansに適用されます。ストアが実行されていないときにキャッシュ・ディレクトリを削除すると安全ですが、次回ストアを起動するときに時間がかかる場合があります。-9の後でもOS/JVMのクラッシュの後でもなく)現在の起動の前に正常にシャットダウンされた場合かつプライマリ・ファイル(たとえば、ストアの管理圧縮ファイル)にオフライン変更がなかった場合は、キャッシュ・ファイルを再利用して、ファイル・ストアの起動とリカバリ・プロセスを迅速化することができます。既存のキャッシュ・ファイルを起動するときに安全に使用できない場合、それらは自動的に破棄されて新しいファイルが作成されます。「ログ280102」という警告が作成されます。移行またはフェイルオーバーのイベント後、同じ警告メッセージが作成されますが、無視できます。キャッシュありファイル・ストアを使用して、wlfileioのネイティブ・ドライバのロードに失敗した場合、同期書込みポリシーは自動的に同等の直接書込みに変更され、AvoidDirectIO=trueになります。実行中のカスタムまたはデフォルトのファイル・ストアの構成済および実際の同期書込みポリシーとドライバを表示する場合は、サーバーのログでWL-280008およびWL-280009のメッセージを参照してください。未使用のキャッシュ・ファイルがディスク領域を消費しないようにする場合、一時的に作成されたドメインに残されたキャッシュ・ファイルを定期的に削除するようにテスト環境と開発環境を変更する必要がある場合があります。本番環境では、ファイル・ストアによってキャッシュ・ファイルが自動的に管理されます。ファイル・ストアの直接書込みポリシーのチューニング非推奨の注意:この項に記載されているAvoidDirectIOのプロパティは、このリリースでもサポートされていますが、11gR1PS2以降は非推奨になります。キャッシュあり」同期書込みポリシーを使用してください。書込みの同期書込みポリシーによるファイル・ストアの場合は、Oracleサポートまたはリリース・ノートにおいて、weblogic.Serverのオプションをコマンド・ライン設定するか、またはストアを実行するJVMのスクリプトを起動するように指示されます。JVMで実行しているすべてのストアをグローバルに変更します。-Dweblogic.store.AvoidDirectIO=trueシングル・ストアの場合に使用します。ここでは、store-nameは、ストアの名前を示します。-Dweblogic.store.store-name.AvoidDirectIO=trueデフォルトのストアの場合に使用します。ここでは、server-nameは、ストアをホストするサーバーの名前を示します。-Dweblogic.store._WLS_server-name.AvoidDirectIO=trueAvoidDirectIOを個別のストアに設定すると、グローバルなオプションの-Dweblogic.store.AvoidDirectIOの設定がオーバーライドされます。AおよびBという2つのストアがあり、次のオプションを設定しているとします:-Dweblogic.store.AvoidDirectIO=true-Dweblogic.store.A.AvoidDirectIO=falseこの場合、ストアBの場合のみAvoidDirectIO=trueの設定があります。注意:AvoidDirectIOオプションを設定すると、パフォーマンスに影響を及ぼします。これは、「ファイル・ストアのブロック・サイズのチューニング」に記載されているように、通常、ブロックのサイズを設定すると軽減されます。キャッシュありまたはキャッシュ・フラッシュを使用して構成されたファイル・ストアのファイル・ストア・ブロック・サイズをチューニングしてください。次のケースについて検討します。JMSプロデューサは永続メッセージを1つずつ送信します。ネットワークのオーバーヘッドは、ごくわずかであることが分かっています。ディスク・ドライブはバッテリ・バックアップのあるライトバック・キャッシュを備えています。メッセージ・レートは1秒間に166メッセージと測定されています。rps)と同じ数値になります。ストアのブロック・サイズをファイル・システムのブロック・サイズと一致するようチューニングすることで、大幅な改善が可能です。以下のようなケースでは、ブロック・サイズをチューニングしても全く改善が見られなかったり、改善したとしても不十分であったりする可能性があります。キャッシュによって待機時間が小さくなっています(つまり、I/Oサブシステムは重大なボトルネックではありません)。ライトバック・キャッシングが使用されておらず、ディスク・ドライブの待機時間が大きいため、パフォーマンスが制限されています。使用しているブロック・サイズが大きい場合は、パフォーマンスとファイル・スペースの間にトレード・オフが存在する可能性があります。複数のアプリケーション・レコードは、同時に書き込まれた場合にのみ、単一のブロックにまとめられます。そのためブロック・サイズを大きくすると、サーバー・アクティビティが同時に実行されることがほとんどなく、小さいレコードしか生成されないアプリケーションの場合、ストア・ファイルのサイズが大幅に増大することになります。この場合、小さいレコードがブロックごとに1つずつ格納され、各ブロックの残りのスペースは使用されません。(WS-RM)アプリケーションが挙げられます。ここでは、ストアを使用するのはアプリケーションだけです。パフォーマンスを向上するために、ストアのブロック・サイズをファイル・ストアをホストするファイル・システムのブロック・サイズと一致するように、チューニングすることをお薦めします(一般的に、多くのファイル・システムの場合、4096)。ブロック・サイズをその他の値にチューニングしても(ページングおよびキャッシュ・ユニット)パフォーマンスを向上する場合があります。ブロック・サイズをチューニングして、パフォーマンスが向上されない場合、ブロック・サイズをデフォルトのままに設定しておくことをお薦めします。これにより、ファイル・システム・リソースの使用を最小化することができます。非推奨の注意:この項に記載されているBlockSizeコマンド・ライン・プロパティは、11gR1PS2でもサポートされていますが、非推奨です。かわりに、カスタムおよびデフォルトのファイル・ストアに構成可能なBlockSizeを使用することをお薦めします。ストアのブロック・サイズを設定するには、次のいずれかのプロパティをコマンド・ラインで使用するか、または、ストアを実行するJVMのスクリプトを起動してください。既存するファイルを持たないすべてのファイル・ストアのブロック・サイズをグローバルに設定します。-Dweblogic.store.BlockSize=block-size既存のファイルを持たない特定のファイル・ストアのブロック・サイズを設定します。-Dweblogic.store.store-name.BlockSize=block-sizeファイル・ストアに既存のファイルがない場合、デフォルトのファイル・ストアのブロック・サイズを設定します。BlockSize=block-sizeブロック・サイズは、512から8192の間の整数を設定します。近い2の倍数に自動的に切り捨てられます。BlockSizeを個別のストアに設定すると、グローバルなオプションの-Dweblogic.store.BlockSizeの設定がオーバーライドされます。AおよびBという2つのストアがあり、次のオプションを設定しているとします:-Dweblogic.store.BlockSize=8192-Dweblogic.store.A.BlockSize=512この場合、ストアBのブロック・サイズは、8192になり、ストアAのブロック・サイズが512になります。注意:コマンド・ライン・プロパティを使用したブロック・サイズの設定は、既存のファイルを持たないファイル・ストアでのみ可能です。ストアに既存のファイルが存在する場合は、ストアの最初の作成時に設定されたブロック・サイズがそのまま使用されます。ファイル・ストア・ブロック・サイズの確認ファイル・ストアの現在のブロック・サイズおよび同期書込みポリシーは、ストアをホストするサーバーのサーバー・ログで確認することができます。「280009」のストアがオープンされたというメッセージを検索してください。ファイル・システム・ブロック・サイズの確認ファイル・システムの現在のブロック・サイズを確認するには、使用しているオペレーティング・システムのドキュメントを参照してください。size」を検索します。Cluster」を検索します。Serverインスタンスを停止してファイルを削除すれば、ストアを再起動した際にブロック・サイズを変更できます。データを保持する必要がある場合は、新しいブロック・サイズを指定したファイル・ストアを作成して、既存のファイルが存在するストアのブロック・サイズを変換します。その際は、コマンド・ライン・ストア管理ユーティリティのcompactコマンドを使用します。weblogic.store.Adminhelpと入力して、使用可能なコマンドを確認します。Serverサーバー環境の構成』のJavaコマンド・ラインを使用したストア管理に関する項を参照してください。次の項では、ネットワーク・ファイル・システム(NFS)でのWebLogic永続ストアの使用について説明します。同期書込みポリシーの構成NFS記憶域は、同期書込みリクエストが揮発性メモリーに警告なしでバッファされるように構成されているので、トランザクション・データを完全に保護しない場合があります。ファイル・ストアのディレクトリがNFSマウントに存在して、ファイル・ストアの同期書込みポリシーが「無効化された」以外である場合、NFS実装と構成をチェックして、同期の書込みがサポートされるように構成されていることを確認します。「無効化された」の同期書込みポリシーを使用すると、同期書込みが行われていないので、一般的にはトランザクションで安全ではありません。記憶域デバイスの物理機能を超える最大数の永続メッセージまたはトランザクション・スループットを表示すると、同期書込みリクエストの不要なバッファリングが発生する可能性があります。NFSサーバーで、ファイル・ストアをホストするエクスポート済のNFSディレクトリの同期書込み設定をチェックします。SANベースのファイル・ストアまたはJDBCストアでは、安全な集中型の記憶域を提供する簡単な方法が用意されている場合があります。サーバーの再起動の動作のテストNFS搭載のディレクトリにJMSメッセージとトランザクション・ログが格納されている場合、マシンが不意に障害したら、サーバーの再起動の動作を検証することをお薦めします。NFS実装に応じて、フェイルオーバーまたは再起動後、様々な問題が発生する可能性があります。Logicサーバーをホストするノードを突然にシャットダウンして、動作を検証できます。サーバーの移行のためにサーバーが構成されている場合、対応するフェイルオーバー期間後、フェイルオーバー・ノード上でサーバーが自動的に起動する必要があります。起動しない場合は、同じホスト(ノードが完全に起動した後)上のWebLogicサーバーを手動で再起動します。v4ベースのネットワーク接続ストレージ(NAS)サーバーを構成できます。v4環境をチューニングしてテストする場合、この項の手順に従う必要はありません。ストレージ・デバイス上のNFSマウントされたディレクトリに格納されたファイルのロックに関する情報については、ストレージ・ベンダーのドキュメントを参照してください。WebLogicサーバーが再起動されないと、サーバーのログ・ファイルに次のエラーが表示されることがあります。errno=11NFSシステムがストア上のロックを解放しないために、このエラーが発生します。WebLogicサーバーでは、同じWebLogicサーバーの2つのインスタンスを誤って起動した場合、データが破損しないように、JMSデータとトランザクション・ログを格納するファイルでのロックが維持されます。NFSストレージ・デバイスは、マシンに障害が発生したことを適切なタイミングで認識しないので、ロックを解放しません。その結果、マシンに障害が発生しマシンの再起動後、WebLogicサーバーが前にロックされたファイルをロックしようとすると、失敗します。ストレージ・デバイス上のNFS搭載ディレクトリに格納されたファイルのロックに関する追加の情報については、ストレージ・ベンダーのドキュメントを参照してください。NFS環境でロック動作を適正にチューニングできない場合は、次の2つの方法で、ログ・ファイルおよびデータ・ファイルのロックを解除します。次の2つの方法のいずれかで、ログ・ファイルおよびデータ・ファイルのロックを解除します。データ・ファイルをコピーしてNFSロックの削除ログおよびJMSデータ・ファイルを手動でロック解除し、ロック済の永続ストア・ファイルのコピーを作成してサーバーを起動し、その後の操作のために以前に作成したコピーを使用します。ロック済の永続ストア・ファイルのコピーを作成するには、ファイルの名前を変更し、再度元の名前にコピーします。次のサンプルでは、トランザクション・ログが/shared/tlogsディレクトリおよびJMSデータが/shared/jmsディレクトリに格納されると仮定します。UMSJMSFILESTORE_AUTO_1000000.DATこの方法を使用すると、WebLogicのファイル・ロック・メカニズムは、同じサーバーの複数のインスタンスが誤って起動されたときにデータが障害されないように、データの保護を続行します。マシンが突然の障害で停止したときは、サーバーを手動で再起動する必要があります。ファイル・ストアでは、ファイル・ストアを使用して大量のデータを格納する場合、複数の連番の付けられた.DATファイルが作成されます。この場合は、すべてのファイルをコピーし、名前を変更する必要があります。Serverのロックが無効になっているので、自動サーバーを再起動して、フェイルオーバーに成功する必要があります。この方法を使用する場合は注意してください。WebLogicのファイル・ロック機能は、望ましくない同時実行性シナリオで発生するサーバー・ファイルの破損を避けるように設計されています。ファイル・ストアを使用するサーバーは、サーバーの移行のために構成されている場合、常に、データベースに基づくリース・オプションを構成します。Serverの複数のインスタンスが自動的に再起動するのを防ぎます。人為的なエラーが発生しないようにし、ある時点でサーバーのインスタンスが1つのみ手動で起動されたことを確認するために、さらに手続き上の注意を払う必要があります。同じように、同じディレクトリを参照する同じ名前のストアを持つ2つのドメインが存在しないことを確認するためにも、さらに注意を払う必要があります。Server管理コンソールによっても、デフォルトのファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストアおよび診断ファイル・ストアのWebLogicファイル・ロック・メカニズムを無効化できます。Server管理コンソールを使用してデフォルトのファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。必要に応じて、管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。2.「ドメイン構造」ツリーで、「環境」ノードを拡張し、「サーバー」を選択します。「サーバーのサマリー」リストで、変更するサーバーを選択します。「構成」>「サービス」タブを選択します。「デフォルト・ストア」のセクションへスクロール・ダウンし、「詳細」をクリックします。スクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。変更したサーバーを再起動して、変更を反映します。結果のconfig.xmlエントリは、次のようになります。Server管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。必要に応じて、管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。「ドメイン構造」ツリーで、「サービス」ノードを拡張し、「永続ストア」を選択します。「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックすると、ストアの詳細設定が表示されます。ページの下部にスクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。カスタム・ファイル・ストアが使用中であった場合、変更を反映するには、サーバーを再起動する必要があります。結果のconfig.xmlエントリは、次のようになります。Server管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。必要に応じて、管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。「ドメイン構造」ツリーで、「サービス」ノードを拡張し、「メッセージング」ノードを拡張して、「JMSサーバー」を選択します。「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。JMSサーバーの「構成」>「一般」タブで、スクロール・ダウンして、「ページング・ファイル・ロックの有効化」チェック・ボックスを選択解除します。「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。変更したサーバーを再起動して、変更を反映します。結果のconfig.xmlエントリは、次のようになります。Server管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。必要に応じて、管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。「ドメイン構造」ツリーで、「診断」ノードを拡張し、「アーカイブ」を選択します。「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。[server_name]の設定ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。変更したサーバーを再起動して、変更を反映します。結果のconfig.xmlエントリは、次のようになります。reserved.法律上の注意点ライブラリ。