| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > 管理者ガイド > トランザクションの管理 |
|
管理者ガイド
|
以下の節では、トランザクション管理について説明するとともに、Administration Console でトランザクションをコンフィグレーションおよび管理する際のガイドラインを紹介します。
JDBC 接続プールをコンフィグレーションして JDBC ドライバを分散トランザクションに参加できるようにする方法については、JDBC 接続の管理を参照してください。
Administration Console を使用すると、Java Transaction API (JTA) などの WebLogic Server 機能をコンフィグレーションするためのツールを利用できます。Administration Console を起動するには、../adminguide/overview.html#start_admin_console にある『管理者ガイド』の「Administration Console の起動と使い方」で説明されている手順を参照してください。トランザクションのコンフィグレーション プロセスでは、属性の値を指定する必要があります。指定した属性によって、以下のような、トランザクション環境のさまざまな側面を定義できます。
Administration Console で行う設定は、JTA のコンフィグレーション設定も含め、そのドメインの config.xml ファイルに保持されます。このファイル内のエントリについては、『コンフィグレーション リファレンス』の以下の節を参照してください。
トランザクション環境をコンフィグレーションする前に、EJB、JDBC、JMS など、トランザクションに参加可能な J2EE コンポーネントについてよく理解しておく必要があります。
J2EE コンポーネントのコンフィグレーションの詳細については、このマニュアルの対応する章、および Administration Console オンライン ヘルプを参照してください。
JTA のコンフィグレーション設定は、ドメイン レベルで適用できます。つまり、コンフィグレーション属性の設定はドメイン内のすべてのサーバに適用されることになります。JTA のモニタ タスクおよびロギング タスクは、サーバ レベルで実行されます。
サーバを起動する前にトランザクション属性をコンフィグレーションすることも (静的コンフィグレーション)、サーバの実行中にトランザクション属性をコンフィグレーションすることもできます (動的コンフィグレーション)。ただし、後者の場合、例外が 1 つあります。TransactionLogFilePrefix 属性は、サーバの起動前に設定する必要があります。
WebLogic Server で使用できる、有効な値およびデフォルト値などのトランザクション属性の詳細については、Administration Console オンライン ヘルプの「ドメイン」を参照してください。
デフォルトでは、グローバル トランザクションに参加している XA リソースが、WebLogic Server トランザクション マネージャからの XA 呼び出しへの応答に失敗すると、WebLogic Server はそのリソースを不健全で使用できないものとしてフラグを付け、リソース スレッドを保持するために、そのリソースへの以降の呼び出しをブロックします。 この障害は、不健全なトランザクションまたは不健全なリソースが原因で発生します (2 つの原因に違いはありません)。 どちらの場合でも、リソースは不健全なものとしてマークされます。
この制限を緩和するために、WebLogic Server では 表 7-1 に示すコンフィグレーション属性を用意しています。
これらの属性は、ドメインがアクティブでないときに、config.xml ファイルで直接設定します。 これらの属性は Administration Console には表示されません。 以下の例では、これらの属性を含むコンフィグレーション ファイルの抜粋を示します。
...
<JTA
MaxUniqueNameStatistics="5"
TimeoutSeconds="300"
RecoveryThresholdMillis="150000"
MaxResourceUnavailableMillis="900000"
MaxResourceRequestOnServer="60"
MaxXACallMillis="180000"
/>
<JDBCConnectionPool
Name="XAPool"
Targets="myserver"
DriverName="weblogic.qa.tests.transaction.
testsupport.jdbc.XADataSource"
InitialCapacity="1"
MaxCapacity="10"
CapacityIncrement="2"
RefreshMinutes="5"
TestTableName="dual"
EnableResourceHealthMonitoring="true"
Properties="user=scott;password=tiger;server=dbserver1"
/>
<JDBCTxDataSource
Name="XADataSource"
Targets="myserver"
JNDIName="weblogic.jdbc.XADS"
PoolName="XAPool"
/>
...
ドメイン間トランザクションに対するドメインのコンフィグレーション
トランザクション マネージャで分散トランザクションを管理する場合、トランザクションを準備し、その後コミットまたはロールバックするために、トランザクション マネージャはすべての参加サーバと通信できる必要があります。これは、WebLogic ドメインが、分散トランザクションにおいて、トランザクション マネージャまたはトランザクション参加コンポーネント (リソース) として機能する場合に当てはまります。以下の節では、ドメイン間トランザクションが可能なようにドメインをコンフィグレーションする方法を説明します。WebLogic ドメイン間での相互運用性の詳細については、Administration Console オンライン ヘルプの「WebLogic ドメイン間の信頼関係の有効化」を参照してください。
WebLogic Server 7.0 ドメインのドメイン間トランザクション
複数の WebLogic Server 7.0 ドメインにまたがる (つまり、すべての参加ドメインが WebLogic Server 7.0 で実行される) トランザクションを管理する、またはそのようなトランザクションに参加するには、すべてのドメインのセキュリティ資格を同じ値に設定する必要があります。資格の値を設定するには、各参加ドメインについて、次の手順に従います。
WebLogic Server 7.0 および WebLogic Server 6.x ドメインのドメイン間トランザクション
WebLogic Server 7.0 および WebLogic Server 6.x の双方のドメインのサーバを使用するトランザクションを管理するには、次の操作が必要です。
参加するすべての WebLogic Server 6.x ドメインにおいて、次の操作を実行します。
参加するすべての WebLogic Server 7.0 ドメインにおいて、次の操作を実行します。
Administration Console を使用すると、トランザクションをモニタしたり、トランザクション ログ ファイルのプレフィックスを指定したりできます。モニタ タスクおよびロギング タスクは、サーバ レベルで実行されます。トランザクション統計は特定のサーバに表示され、トランザクション ログ ファイルは各サーバに格納されます。
トランザクション統計を表示し、トランザクション ログ ファイルのプレフィックスを設定するには、以下の手順に従います。
値と属性のモニタとログの詳細については、Administration Console オンライン ヘルプの以下の節を参照してください。
WebLogic Console を使用して、進行中のトランザクションをモニタできます。『WebLogic JTA プログラマーズ ガイド』の「トランザクションの統計」で説明されている統計に加えて、以下の情報を表示できます。
各サーバでは、そのサーバで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション ログを備えています。WebLogic Server では、システムのクラッシュやネットワーク障害からの回復時にトランザクション ログを使用します。トランザクション ログを直接表示することはできません。このファイルはバイナリ フォーマットです。
トランザクション ログは、複数のファイルで構成されています。各ファイルは、ガベージ コレクションの対象となります。つまり、トランザクション ログ ファイル内に必要な記録がなければ、ファイルは削除され、そのディスク領域はファイル システムに戻されます。加えて、以前のログ ファイルが大きくなり過ぎたり、チェックポイントが発生したりした場合には、新しいトランザクション ログ ファイルが作成されます。
警告: 手動でトランザクション ログ ファイルを削除しないでください。トランザクション ログ ファイルを削除すると、データに矛盾が発生する可能性があります。
トランザクション ログ ファイルには、パス名プレフィックス、サーバ名、4 桁の数値サフィックス、およびファイル拡張子で構成されたユニークな名前が付けられます。パス名プレフィックスで、ファイルの格納場所が決まります。WebLogic Administration Console を使用して、TransactionLogFilePrefix サーバ属性の値を指定できます。TransactionLogFilePrefix のデフォルトは、サーバの作業ディレクトリです。
トランザクション ログ ファイルが RAID デバイスなどの高可用性ファイル システム上に作成されるように TransactionLogFilePrefix を設定する必要があります。クラスタ内のサーバでトランザクション回復サービスの移行機能を利用するには、トランザクション ログをサーバとそのバックアップ サーバからアクセス可能な場所、できればデュアル ポート SCSI ディスクまたはストレージ エリア ネットワーク (SAN) 上に格納する必要があります。詳細については、トランザクション回復サービスの移行準備を参照してください。
サーバ名が websvr で TransactionLogFilePrefix が /usr7/applog1/ に設定された UNIX システムでは、次のようなログ ファイルが作成されます。
/usr7/applog1/websvr0000.tlog
/usr7/applog1/websvr0001.tlog
/usr7/applog1/websvr0002.tlog
同様に、TransactionLogFilePrefix が C:¥weblogic¥logA¥ に設定された Windows システムでは、以下のような名前でログ ファイルが作成されます。
C:¥weblogic¥logA¥websvr0000.tlog
C:¥weblogic¥logA¥websvr0001.tlog
C:¥weblogic¥logA¥websvr0002.tlog
システムで大量のトランザクション ログ ファイルが作成されている場合は、完了していない長時間のトランザクションが複数存在している可能性があります。その原因としては、リソース マネージャの障害や、トランザクションのタイムアウト値が著しく大きいことが考えられます。
トランザクション ログ ファイルが含まれたファイル システムで領域が不足したり、アクセス不能になったりすると、commit() が SystemException を送出し、トランザクション マネージャによってシステム エラー ログにメッセージが書き込まれます。使用できる領域が増やされるまで、トランザクションはコミットされません。
サーバを別のマシンに移行する場合は、トランザクション ログ ファイルも一緒に移動し、1 つのサーバに関するすべてのログ ファイルをまとめておきます。詳細については、別のマシンへのサーバの移動を参照してください。
トランザクション ログ ファイル書き込みポリシーを選択することで、トランザクション ログ ファイルにエントリを書き込む方法を変更できます。選択できるオプションは以下のとおりです。
警告: Windows で Direct-Write トランザクション ログ ファイル書き込みポリシーを選択すると、トランザクション データはオンディスク キャッシュに残され、すぐにはディスクに書き込まれません。この場合、停電によってオンディスク キャッシュのデータが消失するおそれがあり、トランザクションとしては安全とはいえません。Windows で Direct-Write トランザクション ログ ファイル書き込みポリシーを使用する場合にキャッシュ データが消失するのを防ぐには、ディスクの書き込みキャッシュをすべて無効にする (デフォルトでは有効) か、システムのバッテリー バックアップを使用します。
警告: トランザクション ログ ファイル書き込みポリシーは、トランザクションのパフォーマンスに影響します。使用しているシステムでこれらのオプションをテストし、どちらのパフォーマンスがよいかを確認してください。オペレーティング システムおよびそのパラメータ設定にもよりますが、通常は「Direct-Write」の方が「Cache-Flush」よりもパフォーマンスが良く、Windows、HP-UX、および Solaris で利用できます。Windows システムでは、ディスクへの連続的な書き込みが最適化され、ファイルへの最初の書き込みよりも後続の書き込みのほうが速くなります。
トランザクション ログ ファイル エントリは連続的に書き込まれるため、パフォーマンスが向上する可能性があります。一部の UNIX システムで Cache-Flush オプションを選択すると、トランザクション ログ ファイルへの書き込みだけでなく、キャッシュされたすべてのディスク書き込みがフラッシュされるため、トランザクションのパフォーマンスが低下するおそれがあります。
トランザクション ログ ファイル書き込みポリシーを設定するには、次の手順に従います。
外部のトランザクション マネージャから WebLogic Server にトランザクションをインポートする場合、WebLogic Server トランザクション マネージャはその外部トランザクション マネージャによって調整される XA リソースとして機能します。トランザクションを保持する最長時間の経過後、または WebLogic Server にインポートされたトランザクションに参加している XA リソースがヒューリスティック例外を送出した場合など、滅多にないが破壊力の大きい状況下では、WebLogic Server トランザクション マネージャはヒューリスティックな決定を行います。つまり、WebLogic Server トランザクション マネージャは、外部トランザクション マネージャからの入力がない状態で、トランザクションをコミットするかロールバックするかを決定します。WebLogic Server トランザクション マネージャは、ヒューリスティックな決定を行うと、外部トランザクション マネージャからそのトランザクションの記録を破棄する指示があるまで、その決定の情報をヒューリスティック ログ ファイルに格納します。
ヒューリスティック ログ ファイルはトランザクション ログ ファイルと共に格納されます。.tlog 拡張子の前に .heur が付く、トランザクション ログ ファイルと似たファイル名になります。これらのファイルでは次のフォーマットを使用します。
<TLOG_file_prefix>¥<server_name><4-digit number>.heur.tlog
サーバ名 websvr の UNIX システムでは、次のような名前のヒューリスティック ログ ファイルになります。
/usr7/applog1/websvr0000.heur.tlog
/usr7/applog1/websvr0001.heur.tlog
/usr7/applog1/websvr0002.heur.tlog
同様に、Windows システムでは以下のような名前でヒューリスティック ログ ファイルが作成されます。
C:¥weblogic¥logA¥websvr0000.heur.tlog
C:¥weblogic¥logA¥websvr0001.heur.tlog
C:¥weblogic¥logA¥websvr0002.heur.tlog
ヒューリスティックな終了 (ヒューリスティックな決定) は、更新をコミットまたはロールバックする分散トランザクションの終了段階で、リソースが一方だけの決定を行ったときに発生します。これにより、分散されたデータは不確定な状態のままになります。ヒューリスティックな終了の原因としては、ネットワークの障害またはリソースのタイムアウトが考えられます。ヒューリスティックな終了が発生すると、以下のヒューリスティックな結果例外のいずれかが送出されます。
ヒューリスティックな終了が発生すると、サーバ ログにメッセージが書き込まれます。ヒューリスティックな終了を解決する方法については、データベース ベンダが提供するドキュメントを参照してください。
一部のリソース マネージャでは、ヒューリスティックな終了のコンテキスト情報が保存されます。この情報は、リソース マネージャのデータの矛盾を解決するときに便利です。WebLogic Console の JTA パネルで ForgetHeuristics 属性 ([ヒューリスティックを無視]) が true に設定されている場合、この情報はヒューリスティックな終了の後で削除されます。コンテキスト情報を保存するリソース マネージャを使用するときには、ForgetHeuristics 属性を false に設定することをお勧めします。
指定した時間の経過後に未完了のトランザクションを破棄することもできます。分散トランザクションの 2 フェーズ コミット プロセスでは、トランザクション マネージャはトランザクションに参加するすべてのリソース マネージャを調整します。すべてのリソース マネージャがコミットまたはロールバックを支持すると、トランザクション マネージャはリソース マネージャに、変更に対してコミットまたはロールバックのいずれかの動作を行うよう通知します。2 フェーズ コミット プロセスにおける、この第 2 フェーズでは、トランザクション マネージャはすべてのリソース マネージャでトランザクションの終了が示されるまで、トランザクションを終了しようとし続けます。AbandonTimeoutSeconds 属性を使用すると、トランザクション マネージャがコミット プロトコルの第 2 フェーズでトランザクションの終了を試み続ける最長時間を秒単位で設定できます。デフォルト値は 86400 秒 (24 時間) です。この時間を過ぎると、利用できないリソースや、トランザクションの結果を承認できないリソースが関わるトランザクションでそれ以上の解決は行われません。破棄される前にトランザクションの準備が完了していた場合、トランザクション マネージャは破棄されるトランザクションに代わってトランザクションをロールバックし、ロックを解放してから、サーバ ログにヒューリスティック エラーを書き込みます。
AbandonTimeoutSeconds 属性 ([トランザクションを保持する最長時間]) の設定方法については、Administration Console オンライン ヘルプの「JTA のコンフィグレーション」を参照してください。2 フェーズ コミット プロセスの詳細については、『WebLogic JTA プログラマーズ ガイド』の「分散トランザクションと 2 フェーズ コミット プロトコル」を参照してください。
アプリケーション サーバが別のマシンに移動された場合、サーバは新しいディスクにあるトランザクション ログ ファイルを見つけられなければなりません。このため、トランザクション ログ ファイルを新しいマシンに移動してから、そのマシン上でサーバを起動することをお勧めします。そうすることによって、確実に適切な回復処理を実行できます。新しいシステム上で WebLogic Server を起動すると、サーバはトランザクション ログ ファイルを読み取り、保留中のトランザクションがあれば、それを回復します。新しいマシンでパス名が異なる場合は、TransactionLogFilePrefix 属性を新しいパス名で更新してからサーバを起動します。TransactionLogFilePrefix の変更方法については、Administration Console オンライン ヘルプの「トランザクション ログ ファイルの場所 (プレフィックス) の指定」を参照してください。
WebLogic Server のトランザクション マネージャは、ユーザによる最低限の介入でシステムのクラッシュから回復するように設計されています。トランザクション マネージャは、クラッシュが何度も発生した後や、クラッシュの回復中であっても、リソース マネージャによって準備されたトランザクション ブランチをコミットまたはロールバックによって解決するために、あらゆる努力を払います。
クラッシュ後の回復を容易にするため、WebLogic Server ではトランザクション回復サービスを提供しています。このサービスでは、システムの起動時にトランザクションの回復が自動的に行われます。トランザクション回復サービスは、サーバのトランザクション ログを所有しています。クラッシュ後のトランザクション回復サービスのアクションで説明するように、トランザクション回復サービスは、起動時にすべてのログ ファイルを解析して未完了のトランザクションを見つけ、そのトランザクションを終了させます。
トランザクション回復サービスは、クラッシュ後にトランザクションの回復を正常に処理するよう設計されているため、サーバがクラッシュした場合は再起動し、トランザクション回復サービスによって未完了のトランザクションを処理することをお勧めします。
サーバがクラッシュして、適切な時間内に再起動できそうにない場合は、ユーザによる処理が必要になることがあります。サーバの障害発生後にトランザクションを回復する手順は、WebLogic Server の環境によって異なります。クラスタ化されていないサーバの場合は、手動でサーバ (およびトランザクション ログ ファイル) を別のシステム (マシン) に移動することでトランザクションを回復できます。詳細については、クラスタ化されていないサーバで障害が発生した場合のトランザクションの回復を参照してください。クラスタ内のサーバの場合は、同じクラスタ内の別のサーバに、トランザクション回復サービスを手動で移行できます。トランザクション回復サービスの移行には、トランザクションを回復するためのトランザクション ログにアクセスできるサーバを選択し、次に Administration Console または WebLogic コマンドライン インタフェースを使用してサービスを移行することが必要です。
注意: クラスタ化されていないサーバの場合は、サーバ全体を新しいシステムに移動することしかできません。クラスタ化されたサーバでは、トランザクション回復サービスを一時的に移行できます。
トランザクション回復サービスの移行の詳細については、クラスタ化されたサーバで障害が発生した場合のトランザクションの回復を参照してください。クラスタの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
クラッシュ後にサーバを再起動したり、トランザクション回復サービスを別の (バックアップ) サーバに移行したりすると、トランザクション回復サービスは以下の処理を行います。
リソース マネージャによってヒューリスティックな例外が報告されると、トランザクション回復サービスはそのヒューリスティックな例外をサーバ ログに記録し、[ヒューリスティックを無視] コンフィグレーション属性が有効になっている場合は、forget() を呼び出します。[ヒューリスティックを無視] コンフィグレーション属性が有効になっていない場合は、データベース ベンダのマニュアルでヒューリスティックな終了の解決に関する情報を参照してください。詳細については、ヒューリスティックな終了の処理を参照してください。
トランザクション回復サービスには、次のような利点があります。
トランザクション回復サービスは、一貫した予測しやすい方法でトランザクション回復処理を行います。クラッシュ前にコミットが決定されたものの、コミットがまだ行われておらず、XAResource.recover() からトランザクション ID が返されるトランザクションの場合、トランザクション回復サービスは一貫して XAResource.commit() を呼び出します。クラッシュ前にコミットが決定しておらず、XAResource.recover() からトランザクション ID が返されるトランザクションの場合、トランザクション回復サービスは一貫して XAResource.rollback() を呼び出します。トランザクションの回復が一貫性のある予測しやすいものであるため、トランザクション マネージャがクラッシュしても、一部のブランチがコミットされ一部がロールバックされるという混合ヒューリスティックの終了は発生しません。
リソース マネージャがクラッシュすると、トランザクション回復サービスでは準備されている各トランザクションについて commit() または rollback() を呼び出さなければなりません。commit() または rollback() の呼び出しは成功するまで続けられます。トランザクション解決の試行は、AbandonTimeoutSeconds コンフィグレーション属性を設定することで制限できます。詳細については、トランザクションの破棄を参照してください。
クラスタ化されていないサーバで障害が発生した場合のトランザクションの回復
障害が発生したサーバでトランザクションを回復するには、次の手順に従います。
サーバに障害が発生した後でトランザクション ログを移動する場合は、すべてのトランザクション ログ ファイルを新しいマシンで使用可能にしてから、マシンでサーバを起動します。このような移行は、両方のマシンで使用可能なデュアル ポート ディスクにトランザクション ログ ファイルを格納することで実行できます。計画的な移行の場合は、新しいマシンでパス名が異なるときに、TransactionLogFilePrefix 属性を新しいパス名で更新してからサーバを起動します。必ず、新しいマシンですべてのトランザクション ログ ファイルが使用可能になっていることを確認してから、サーバを起動してください。そうしないと、クラッシュ時にコミット中だったトランザクションが適切に解決できず、その結果、アプリケーション データに矛盾が発生する場合があります。
注意: トランザクション回復サービスは、クラッシュ後にトランザクションの回復を正常に処理するように設計されています。サーバがクラッシュした場合は、新しいマシンにサーバを移動するよりも、サーバを再起動し、トランザクション回復サービスによって未完了のトランザクションを処理することをお勧めします。
クラスタ化されたサーバで障害が発生した場合のトランザクションの回復
クラスタ化されたサーバがクラッシュした場合は、Administration Console またはコマンドライン インタフェースを使用して、同じクラスタ内でクラッシュしたサーバから別のサーバへ、トランザクション回復サービスを手動で移行できます。次のイベントが発生します。
Administration Console を使用してトランザクション回復サービスを移行する手順については、Administration Console オンライン ヘルプの「トランザクション回復サービスの同一クラスタ内サーバへの移行」を参照してください。コマンドライン インタフェースを使用してトランザクション回復サービスを移行する手順については、WebLogic Server コマンドライン インタフェース リファレンス.の「MIGRATE」を参照してください。
サーバでは、障害が発生した複数のサーバに対してトランザクション回復を行うことができます。他のサーバのトランザクションを回復している間に、バックアップ サーバは自身のトランザクションの処理および回復を続けます。回復中にバックアップ サーバで障害が発生した場合は、さらに別のサーバにトランザクション回復サービスを移行できます。この別のサーバで、トランザクション回復は続行されます。また、Administration Console またはコマンドライン インタフェースを使用して、トランザクション回復サービスを元の障害が発生したサーバに手動で移行して戻すこともできます。詳細については、Administration Console オンライン ヘルプの「トランザクション回復サービスの元のサーバへの手動による返還移行」を参照してください。
サーバのトランザクション回復がバックアップ サーバで完了すると、バックアップ サーバはトランザクション回復サービス (およびトランザクション ログ) の所有権を、障害が発生したサーバに解放します。障害が発生したサーバを再起動すると、このサーバはトランザクション回復サービスの所有権を再び要求しようとします。障害が発生したサーバを再起動したときに、バックアップ サーバがトランザクション回復処理中だった場合、バックアップ サーバはトランザクションの回復を中止し、内部クリーンアップを行い、トランザクション回復サービスの所有権を解放して、障害が発生したサーバがそれを再び要求して正しく起動できるようにします。その後、障害が発生したサーバでは、自身のトランザクション回復を完了します。
障害が発生したサーバのトランザクション回復サービスがまだバックアップ サーバで所有されており、障害が発生したサーバを再起動しようとしたときにバックアップ サーバが非アクティブだった場合、バックアップ サーバがトランザクション回復サービスの所有権を解放できないため、障害が発生したサーバは起動しません。これは、フェイルバック メカニズムが失敗した場合や、バックアップ サーバが管理サーバと通信できない場合にも当てはまります。トランザクション回復の移行は、Administration Console またはコマンドライン インタフェースを使用して手動で行えます。
トランザクション回復サービスを移行する場合は、以下の制限があります。
クラスタ内の障害が発生したサーバから同じクラスタ内の別のサーバ (バックアップ サーバ) へトランザクション回復サービスを移行するには、バックアップ サーバに、障害が発生したサーバのトランザクション ログ ファイルへのアクセス権が必要です。したがってトランザクション ログ ファイルは、双方の (またはさらに他の) サーバで使用できる永続ストレージに格納する必要があります。ストレージ エリア ネットワーク (SAN) デバイスまたはデュアル ポート ディスクに、トランザクション ログ ファイルを格納することをお勧めします。NFS ファイル システムを使ってトランザクション ログ ファイルを保存しないでください。NFS のキャッシング方式により、ディスク上のトランザクション ログ ファイルは常に現在のものとは限りません。NFS デバイスに保存されたトランザクション ログ ファイルを使用して回復を行うと、データが破損するおそれがあります。
トランザクション回復サービスをサーバから移行するときには、実際に移行を行う前に障害が発生している、または障害が発生したサーバを停止する必要があります。元のサーバがまだ実行中の場合は、そこからトランザクション回復サービスを移行することはできません。
トランザクション回復サービスを移行する手順の詳細については、Administration Console オンライン ヘルプの「トランザクション回復サービスの同一クラスタ内サーバへの移行」を参照してください。
コマンドラインを使用しても、トランザクション回復サービスを移行することができます。WebLogic Server コマンドライン インタフェース リファレンス.のMIGRATEを参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
