このスクリプトでは、e-docs マニュアルの検索に必要な Google 検索のパラメータを出力します。
eDocs ホーム > BEA WebLogic Integration 8.1 ドキュメント > 可用性の維持

可用性の維持

WebLogic Integration ソリューションの可用性の維持には、WebLogic Platform ツールと、使用するエンタープライズ情報システム (EIS) に最適なアプリケーションが必要です。クラスタ環境で WebLogic Server の高可用性を維持する方法の概要については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタでの通信」を参照してください。WebLogic Integration ソリューションの可用性を高めるコンフィグレーションについては、『WebLogic Integration ソリューションのデプロイメント』の「WebLogic Integration の高可用性について」を参照してください。


詳細については、以下のトピックを参照してください。



高可用性コンフィグレーション

WebLogic Integration には、機能分野固有のエラー処理機能および障害回復機能があります。高可用性ソリューションをコンフィグレーションするには、以下の点に注意する必要があります。

bullet arrow Trading Partner Integration の場合

『WebLogic Integration ソリューションのデプロイメント』の「WebLogic Integration の高可用性について」にある「Trading Partner Integration」の説明に従って WebLogic Integration Administration Console を使用します。

bullet arrow Application Integration の場合

『WebLogic Integration ソリューションのデプロイメント』の「WebLogic Integration の高可用性について」にある「Application Integration」の説明に従って WebLogic Integration Administration Console を使用します。

高可用性コンフィグレーションのデプロイメント前のチェックリストについては、『WebLogic Integration ソリューションのベスト プラクティスに関する FAQ』の「WebLogic Integration アプリケーションの回復処理」にある「回復処理のチェックリスト」を参照してください。


重要推奨事項

以下では、WebLogic Integration ソリューションの可用性に関する重要な推奨事項について説明します。

bullet arrow アプリケーション開発時

プロジェクト JMS キューの再試行回数および再試行の遅延をコンフィグレーションして、JPD のトランザクション再試行のカウント (再試行回数 * 再試行の遅延) が、管理対象サーバの回復に必要な時間よりも長くなるようにします (プロジェクト JMS キューの再試行回数および再試行の遅延パラメータをコンフィグレーションすると、JPD の再試行回数および再試行の遅延パラメータが上書きされます)。プロジェクト JMS キューのこれらのプロパティをコンフィグレーションすることで、再試行パラメータを持たない特定の非同期コールバック (タイマー コントロール、プロセス コントロール) に関連する回復処理中の問題を防ぐことができます。


JMS キューの再試行回数および再試行の遅延のコンフィグレーションについては、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」にある「ロールバック、回復、再配信、または期限切れメッセージの管理」を参照してください。

bullet arrow XA 対応エンタープライズ情報システムで障害が発生した場合

通常、WebLogic Server TransactionManager から EIS リソース マネージャにトランザクション完了の命令 (コミットまたはロールバック) を出せるようになるまで、トランザクションはアクティブなままになります。以下の手順に従うことで、WebLogic Server のコネクタ コンテナおよび TransactionManager で EIS との通信が正常に再確立され、アクティブなトランザクションが回復されます。


  • 使用不能な EIS のアダプタ インスタンスがサスペンドされていることを確認します。
  • 依存アプリケーション ビューがすべてサスペンドされていることを確認します。

EIS インスタンスが再び使用可能になった時点で、以下の手順に従います。


  • その EIS インスタンスのアダプタ インスタンスを再開して再デプロイします。
  • 依存アプリケーション ビューをすべて再開します。

WebLogic Integration Administration Console でこれらのタスクを実行する方法については、『WebLogic Integration ソリューションの管理』の「Application Integration」を参照してください。


これらの手順を正しく実行しないと、EIS インスタンスが使用可能になった後も、EIS インスタンスに対してトランザクションがアクティブなままになります。EIS がデータベースの場合、行ロックまたはテーブル ロックが残ることもあります。EIS のタイプにかかわらず、不明なトランザクションが原因で、以前にサスペンドされたアプリケーション ビュー サービスと今後使用するアプリケーション ビュー サービスの実行で障害が発生する可能性があります。


JMS キューの再試行回数および再試行の遅延のコンフィグレーションについては、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」にある「ロールバック、回復、再配信、または期限切れメッセージの管理」を参照してください。

以下のトピックも参照してください。



 Microsoft SQL Server についての注意

コンフィグレーションに Microsoft SQL Server が含まれている場合 :

  • DBMS 障害が発生したときに、DBMS インスタンスが実行中の管理対象サーバの任意の XA トランザクションから使用されていた場合、そのサーバには保留中の XA トランザクションが残されることがあります。管理対象サーバに保留中のトランザクションが存在する場合、完了待ちのトランザクションがあるため正常にシャットダウンできません。Microsoft SQL Server ドライバの回復処理の問題が原因で、これらのトランザクションが正常に完了 (コミットまたはロールバック) されない場合があり、正常にシャットダウンできなくなります。

    通常の処理に回復する場合は、「XA 対応エンタープライズ情報システムで障害が発生した場合」で説明されている推奨手順に従うようにしてください。

  • プロセスにコンフィグレーションされている再試行回数が少なすぎる場合に、複数の非同期要求を単一のステートフル プロセスに送信すると、要求がロールバックされることがあります。ロールバックが発生すると、次のような SQL デッドロック メッセージがログに記録されます。

    Exception in ejbRemote java.sql.SQLException: [BEA][SQLServer JDBC Driver][SQLServer]Transaction (Process ID 67) was deadlocked on lock resources with another process and has been chosen as the deadlock victim.Rerun the transaction.

    再試行の設定の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」にある「ロールバック、回復、再配信、または期限切れメッセージの管理」を参照してください。


 Oracle についての注意

コンフィグレーションに Oracle が含まれている場合 :

  • DBMS 障害が発生したときに、DBMS インスタンスが実行中の管理対象サーバの任意の XA トランザクションから使用されていた場合、そのサーバには保留中の XA トランザクションが残されることがあります。管理対象サーバに保留中のトランザクションが存在する場合、完了待ちのトランザクションがあるため正常にシャットダウンできません。Oracle Thin ドライバの回復処理の問題が原因で、これらのトランザクションが正常に完了 (コミットまたはロールバック) されない場合があり、正常にシャットダウンできなくなります。

    通常の処理に回復する場合は、「XA 対応エンタープライズ情報システムで障害が発生した場合」で説明されている推奨手順に従うようにしてください。

  • 管理対象サーバで障害が発生し、Oracle に不明なトランザクションが残された場合、次の問題が発生することがあります。

    • [プロセス インスタンス統計] ページまたは [プロセス インスタンス概要] ページにアクセスしようとすると例外が生成されます。管理対象サーバが回復するまでは、プロセス インスタンス情報の要求に対する WebLogic Integration Administration Console の処理能力が制限されます。
    • 次の Oracle 例外が送出される場合があります。
    • ORA-01591: lock held by in-doubt distributed transaction global_tran_id

    • 別のレコードを挿入すると、不明なトランザクションが原因でテーブルにエラーが発生することがあります。そのため、新しい Java プロセスを開始できない場合があります。このような場合、障害が発生した JTA サービスを再起動するか、移行します。移行にかかる時間を考慮し、実行中のプロセスに十分な再試行回数が設定されていることを確認します。

      JTA サービスの再起動および移行については、『WebLogic Server Administration Console オンライン ヘルプ』の「[サーバ] --> [制御] --> [起動/停止]」および「[サーバ] --> [制御] --> [JTA 移行]」を参照してください。

      再試行の設定の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」にある「ロールバック、回復、再配信、または期限切れメッセージの管理」を参照してください。

    • Oracle から回復サービスにトランザクションが返されるまで数分かかる場合があります。数分待機してから回復を開始します。Oracle の準備が整う前に JTA 回復を開始すると、回復に失敗することがあります。回復に失敗した場合は、再度回復を開始します。

    COMMIT または ROLLBACK のいずれかのコマンドを実行して、Oracle の不明なトランザクション (transaction_id) を管理面から解決することも可能です。次に例を示します。

    COMMIT FORCE 'local_tran_id'

    ROLLBACK WORK FORCE 'local_tran_id'

    これを解決する別の管理的手法として、Oracle 認定システム管理者に依頼して、データベースの解析、不明なトランザクションが発生するテーブルの特定、およびそのテーブルのブロックごとの行数の削減を行うこともできます。このようなチューニングは慎重に行う必要があります。それらのブロックでトランザクションの重複が発生する可能性は低くなりますが、データベースのパフォーマンスに影響があるためです。



関連トピック

WebLogic Server クラスタ ユーザーズ ガイド

WebLogic Integration の高可用性機能の基本となる WebLogic Server クラスタ機能について説明しています。