リカバリー・モードでのアプリケーション・サーバーの再始動

処理中のアクティブなトランザクションを持つアプリケーション ・サーバー・インスタンスが、失敗後に再始動する場合、トランザクション・ サービスはリカバリー・ログを使用してリカバリー処理を完了します。 これらのログはそれぞれのトランザクション・リソースによって維持され、 未確定のトランザクションを再実行し、自己整合性のある状態にシステム全体を 戻すために使用されます。

[z/OS]

始める前に

製品の前のバージョンからマイグレーションを行う場合は、コントローラーの JCL プロシージャー・ステートメントで REC パラメーターが REC=N または REC=Y に指定されていることを確認してください。JCL プロシージャーに REC=N または REC=Y が指定されていない場合、-recovery オプションを指定しても、サーバーはリカバリー・モードで再始動しません。

JCL プロシージャーに REC=N が組み込まれている場合、サーバーの再始動時に -recovery を指定すると、 この設定は自動的に REC=Y 変更されます。 製品の前のバージョンからマイグレーションを行わなかった場合は、REC=N が JCL プロシージャーに自動的に組み込まれます。 更新された PROC ステートメントは、以下の例のようになります。

//BBO6ACR  PROC PARMS=' ',REC=N,Z=BBO6ACRZ       

このタスクについて

リカバリー・モードでアプリケーション・サーバーを再始動するには、次のようにします。
  • トランザクション・リソースにリカバリー・ログのアクションを完了させ、シャットダウンします。 このアクションは、アプリケーション・サーバーの障害が発生する前に保持していたリソースのロックを解放します。
  • リカバリー期間中、処理するトランザクション・リカバリーに必要なアプリケーション・サーバー機能のサブセットのみが使用可能です。
  • アプリケーション・サーバーは、リカバリー処理中に新規作業を受け入れません。
  • アプリケーション・サーバーは、リカバリーが完了するとシャットダウンします。

このリカバリー処理は、アプリケーション・サーバー内のすべての必要なサブシステムが使用可能になればすぐに開始されます。 アプリケーション・サーバーがリカバリー・モードで再始動しない場合は、サーバーの準備が整い次第、アプリケーション・サーバーは新規作業を受け入れ始めることができます。これは、リカバリー作業が完了する前に行われる場合があります。

通常、この処理は問題ではありません。ただし、操作手順には、リカバリー作業と新規作業を同時にサポートする互換性がない場合があります。 例えば、処理していた作業が、アプリケーション・サーバーの失敗後直ちに別のアプリケーション・サーバーに移動される HA 環境がある場合があります。 このバックアップ・アプリケーション・サーバーは、障害が発生したアプリケーション・サーバーでリカバリーが完了し、2 つのアプリケーション・サーバーが再同期化されるまで、障害が発生したアプリケーション・サーバーからの作業を排他的に処理します。 この状態では、障害のあるアプリケーション・サーバーにそのトランザクション・リカバリー処理のみを実行させ、シャットダウンしたいというときがあります。 リカバリー処理が行われている間に、このアプリケーション・サーバーに新規作業の受け入れを開始してほしくない場合もあります。

トランザクション・リカバリー処理を行っているアプリケーション・サーバーに新規作業を割り当てないようにするには、 リカバリー・モードでアプリケーション・サーバーを再始動します。

障害が発生したアプリケーション・サーバーを再始動すると、 障害が発生したアプリケーション・サーバーがあるノードのノード・エージェントは、そのアプリケーション・サーバーを再始動する前に稼働している必要があります。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): アプリケーション・サーバーが通常のシャットダウン処理の一部として停止すると、メッセージ「WSVR0024I: Server xxxxxxxx PROCESS xxxxxxxx stopped」がシステム・ログ・ファイルに送信されます。 サーバーのユーザー ID に、機能クラスの該当する MVSADMIN.* プロファイルへの ALTER 権限が含まれている場合、アプリケーション・サーバーのこのインスタンスに関してアプリケーション・サーバーに関連付けられているリソース・マネージャー登録項目は、RRS ログから削除されます。 ただし、サーバーのユーザー ID に、機能クラスの適切な MVSADMIN.* プロファイルに対する ALTER アクセス権限がない場合は、アプリケーション・サーバーのこのインスタンスに対するアプリケーション・サーバーに関連付けられたリソース・マネージャーの登録エントリーは、RRS ログから削除されません。

このリソース・マネージャー登録項目が RRS ログから削除されると、それ以降のアプリケーション・サーバーの開始では、コールド・スタートが実行されます。 ただし、アプリケーション・サーバーをリカバリー・モードで始動している場合は、RRS でコールド・スタートを実行することはできません。

[z/OS]このサービス・リリースを使用すると、サーバーを構成済みのシステムでのみ、リカバリー・モードでサーバーのコールド・スタートを実行することができます。

gotcha

リカバリー・モードでアプリケーション・サーバーを再始動 できるようにするには、障害が発生する前に、以下のステップを実行して、 アプリケーション・サーバーを再始動し、構成変更を有効にする必要があります。

手順

タスクの結果

アプリケーション・サーバーがリカバリー・モードで再始動し、トランザクションのリカバリーを実行し、シャットダウンします。 アプリケーション・サーバーの障害が発生する前に保持していたリソースのロックを解放します。
[z/OS]

次のタスク

トランザクションのピア・リカバリーには、トランザクション・サービス・サブコンポーネント のための統合高可用性サポートを構成します。


トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_svr_recoverymode
ファイル名:trun_svr_recoverymode.html