JP2015057685A - 監視システム - Google Patents

Abstract

【課題】ジョブ実行サーバの異常発生時にプロセス単位の柔軟なリカバリ処理を可能とし、一括して異常発生として処理されていた状況を事前に回避する。
【解決手段】ジョブ実行サーバ１０は、ジョブを構成するプロセスを実行するプロセス実行部１０２と、プロセス実行部によって生成されプロセス実行部を監視するプロセス監視部１０３と、外部からジョブ実行コマンドを受信するコマンド受信部１０１と、プロセスの処理結果を外部に対して送信する処理結果送信部１０４とを有し、プロセス実行部は、プロセス毎にログファイル１０５にログを記録し、プロセス監視部は、ログファイルのログを所定の時間ごとに参照して、プロセス実行部のプロセスが所定の時間内に処理を終えていないと判断した場合には、処理中のプロセスを停止し、プロセス監視部の実行結果をプロセス実行部の処理結果として処理結果送信部を介して外部に送信する。
【選択図】図２

Description

本発明は、システムのプロセス管理に属し、より詳細には、ジョブ実行サーバにおけるプロセス監視システムに関する。

サーバ等で構成されるプロセスの実行システムでは、ジョブ実行サーバにジョブ実行コマンドを送信したジョブ管理サーバが、一定時間のタイムアウトを設定し、設定時間内にジョブ実行コマンドに対する応答がない場合に、ジョブ実行サーバに異常が発生したと判断する。無応答の原因としては、実行サーバがハングアップ状態に陥ったこと等に加え、一時的な実行サーバの負荷の増加や、一時的なネットワーク障害等がありうるので、タイムアウト値はジョブ実行コマンドに応じて数十分ないし数時間に設定されることが一般的である。

また、上記タイムアウトの設定に加え、あるいはタイムアウト設定とは別に、ジョブ管理サーバはジョブ実行サーバに対して一定間隔でｐｉｎｇコマンドを送信し、ｐｉｎｇコマンドに対するジョブ実行サーバからの応答が無い場合には、ジョブ実行サーバに異常が発生したと判断する方法がとられる場合もある。

特開２０１２−１３８０１５号公報

しかしながら、タイムアウト値は数十分ないし数時間という比較的長時間に設定されるため、タイムアウトが発生しジョブ実行サーバに異常が発生したと判断された場合に、ジョブ実行サーバのリカバリ処理の開始が、少なくともタイムアウト設定時間の分だけ遅くなる。

なお、仮にタイムアウト時間を短く設定した場合には、ジョブ実行サーバの処理の遅延や、ジョブ管理サーバとジョブ実行サーバ間の通信ネットワークに一時的で回復可能な障害等が発生した場合でも、異常発生と判断してしまうので、異常発生の頻度が増加するという問題がある。

また、ジョブ実行コマンドは通常複数のプロセスから構成されるが、タイムアウト処理の場合には、どのプロセスで障害が発生したのかを適時に検知することができない。すなわち、どのプロセスで障害が発生したかに関係なく、同じリカバリ処理を行うことしかできない。

また、障害発生の内容や発生箇所に応じたきめ細かなリカバリ処理を行おうとしても、どのプロセスで障害が発生したのかを検知することができないので、大部分のリカバリ処理を手動で行わなければならない。

また、ジョブ管理サーバが、ジョブ実行サーバにコマンドを送信した後に、一定間隔でｐｉｎｇコマンドをジョブ実行サーバに送信するという方法をとった場合も、やはりどのプロセスで障害が発生したのかを知ることができない。

そこで、本発明は、ハングアップ状態等の異常発生をより早く適時に検知することによって、異常発生時に迅速かつプロセス単位の柔軟なリカバリ処理を可能とし、従来技術では一括して異常発生として処理されていた状況を事前に回避することが可能なプロセス処理システムを提供することを目的とする。

本発明の一実施形態に係るジョブ実行サーバによって処理されるプロセスの監視システムは、ジョブを構成するプロセスを実行するプロセス実行部と、プロセス実行部によって生成されるプロセス監視部とを有し、プロセス実行部は、プロセス毎にログファイルにログを記録し、プロセス監視部は、プロセス実行部を監視する。

また、本発明の一実施形態に係るプロセスの監視システムでは、プロセス監視部がプロセス実行部を監視することは、プロセス監視部が所定の時間ごとにプロセス実行部が存在しているか否かを確認し、プロセス実行部が存在していない場合には所定の時間内に処理を終えたと判断し、プロセス実行部が存在している場合には所定の時間内に処理を終えていないと判断することを含んでもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、プロセス監視部が、ログファイルのログを所定の時間ごとに参照し、参照したログの内容から変化していない場合には、プロセスが処理中であると判断することを含んでもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、プロセス監視部が所定の時間内に処理を終えていないと判断した場合に、プロセス監視部は処理中のプロセスを停止してもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、プロセス監視部が所定の時間内に処理を終えたと判断した場合には、プロセス監視部が消滅してもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、ジョブ実行サーバが、外部からジョブに対応するジョブ実行コマンドを受信するコマンド受信部と、プロセスの処理結果を前記外部に対して送信する処理結果送信部とを有してもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、プロセス監視部が、所定の時間内に処理を終えていないと判断した場合に、プロセス監視部の実行結果をプロセスの処理結果として処理結果送信部を介して外部に送信してもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、プロセス実行部が、所定の時間内に処理を終えたとき、プロセスの処理結果を処理結果送信部を介して外部に送信してもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、プロセス実行部が、プロセスの起動に対応して生成されてもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、プロセス実行部が、ジョブの実行が終了すると消滅してもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、ジョブ管理サーバをさらに含み、ジョブ管理サーバは、ジョブ実行サーバにジョブ実行コマンドを送信し、ジョブ実行サーバからプロセスの処理結果を受信してもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、プロセス監視部が所定の時間内に処理を終えていないと判断した場合に、ジョブ管理サーバがジョブの進行状況に応じたリカバリ処理を行う実行コマンドをジョブ実行サーバに送信してもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、リカバリ処理がリトライ処理を行うことを含んでもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、ジョブ実行コマンドが、ジョブ実行サーバのサーバリブートを行うことをその内容としてもよい。

また、本発明の一実施形態に係るプロセスの監視システムは、ジョブ実行コマンドが、ジョブ実行サーバのデータベース再編を行うことをその内容としてもよい。

本発明により、プロセスのハングアップ状態等の異常発生をより早く適時に検知することができるとともに、異常発生時に迅速かつプロセス単位の柔軟なリカバリ処理を実行することが可能とし、従来技術では一括して異常発生として処理されていた状況を事前に回避することができる。

本発明の一実施形態に係るプロセスの実行システムの概要図である。 本発明の一実施形態に係るジョブ実行サーバの機能を説明するブロック図である。 本発明の一実施形態に係るジョブ実行サーバの正常処理時におけるシーケンス図である。 本発明の一実施形態に係るジョブ実行サーバの異常処理時におけるシーケンス図である。 本発明の一実施形態に係るサーバリブート処理の異常処理時における処理概要を示した図である。 本発明の一実施形態に係るサーバリブート処理の異常処理時における処理概要を示した図である。 本発明の一実施形態に係るデータベース再編処理の異常処理時における処理概要を示した図である。

以下、本発明の実施形態について図面等を参照しながら説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、以下に例示する実施形態の記載内容に限定して解釈されるものではない。

なお、以下に説明する発明の内容については、同一部分又は同様な機能を有する部分については同一の符号を異なる図面間で共通して用い、その場合において特段の事情がない限り繰り返しの説明は省略する。

＜プロセスの実行システムの全体構成について＞
図１は、本発明の一実施形態に係るプロセスの実行システムの概要図である。

図１を参照すると、本発明の一実施形態に係るプロセスの実行システムは、ジョブ実行サーバ１０と、ジョブ管理サーバ２０とを有する。ジョブ実行サーバとジョブ管理サーバとは、ＬＡＮ又はＷＡＮ等の通信ネットワーク４０を介して接続される。

また、本発明の一実施形態に係るプロセスの実行システムは、クライアント３０を含んでも良い。クライアントは、パーソナルコンピュータ、タブレットコンピュータ、携帯電話、スマートフォン、あるいはテレビ装置等の通信ネットワークに接続可能な電子機器によって構成される。クライアント３０とジョブ管理サーバ２０は通信ネットワーク４０を介して接続されており、クライアント３０はＨＴＴＰ等に基づいてジョブ管理サーバ２０と通信する機能を有する。

ジョブ管理サーバ２０は、クライアント３０等の指示に基づき、所定のプロセスを実行するためのジョブ実行コマンドをジョブ実行サーバ１０に送信する。ジョブ実行サーバ１０は、受信した実行コマンドに基づき処理を行い、処理結果をジョブ管理サーバ２０に送信する。ジョブ管理サーバ２０は、処理結果に基づいたメッセージ等をクライアント３０に送信する。

＜ジョブ実行サーバについて＞
図２は、本発明の一実施形態に係るジョブ管理サーバ１０の機能を説明するブロック図である。

図２を参照すると、本発明の一実施形態に係るジョブ管理サーバ１０は、コマンド受信部１０１、プロセス実行部１０２、プロセス監視部１０３及び処理結果送信部１０４で構成される。

コマンド受信部１０１は、ジョブ実行サーバ１０の外部から、ジョブ実行コマンドを受信する。典型的には、ジョブ管理サーバ２０が送信するジョブ実行コマンドを受信する。コマンド受信部１０１は、受信したジョブ実行コマンドに対応したプロセス実行部１０２を生成する。

プロセス実行部１０２は、ジョブ実行コマンドに対応したプロセス処理を実行する。通常、一つのジョブ実行コマンドには、複数のプロセス処理が対応しており、プロセス実行部１０２は対応するプロセス処理を順次実行し、それぞれのプロセス処理ごとに、ログファイル１０５にログを記録する。

ログファイル１０５は、プロセス実行部１０２及びプロセス監視部１０３がアクセス可能な記録領域又はファイルに設定される。ログファイル１０５には、例えば処理しようとするプロセス名、発行しようとするシェルコマンド、引数、コマンド送信時刻等を記録する。また、ログファイル１０５には、発行したコマンドに対する戻り値等を記録してもよい。ログファイル１０５は、プロセス実行部１０２が生成したプロセス監視部１０３が参照可能なように、ファイル保存位置、ファイル名、アクセス権限、プロセスＩＤとの関連付け等がなされる。

プロセス実行部１０２は、プロセス監視部１０３を生成する。プロセス監視部１０３の機能については、後述する。プロセス実行部１０２は、プロセス実行部１０２が生成されてから最初のプロセスを処理するまでの間に、プロセス監視部１０３を生成するが、プロセス監視部がプロセス実行部を適切に監視できるのであれば、生成時期はこれに限られない。

プロセス実行部１０２は、生成したプロセス監視部１０３がプロセス実行部１０２のプロセスＩＤを認識できるようにする。例えば、プロセス監視部１０３を生成する際の引数として自らのプロセスＩＤを含ませたり、プロセス監視部１０３を生成した後にメッセージを送信して、自らのプロセスＩＤを知らせたりする。

プロセス実行部１０２は、全てのプロセスが終了すると、処理結果を処理結果送信部１０４に送信する。この処理結果には、実行したプロセスが異常終了をリターンした場合等も含まれる。プロセス実行部１０２は、処理結果を送信し終わると、自らのプロセスを終了させ消滅する。

プロセス監視部１０３は、プロセス実行部１０２によって生成された後、所定の時間が経過すると、当該プロセス監視部１０３を生成したプロセス実行部１０２が存在するか否かを確認する。具体的には、例えばプロセス実行部のプロセスＩＤを取得するコマンドを用いて、プロセス実行部１０２が存在しているか否かを確認する。プロセス実行部１０２が存在しない場合は、プロセス実行部１０２が処理結果を処理結果送信部１０４に送信し、自らプロセスを終了したことを意味する。この場合は、プロセス監視部１０３は自らのプロセスを終了させ消滅する。

プロセス実行部１０２が存在する場合は、プロセス監視部１０３はログファイル１０５を参照して、現在実行中のプロセスを確認する。例えば、ログファイル１０５へのログの記録方法が、プロセス実行部１０２が各プロセスを実行する直前に当該プロセス実行コマンド（シェル）をログファイル１０５へ記録する方法がとられている場合には、プロセス監視部１０３は、ログファイルを参照し、最後に記録されているプロセス実行コマンドに対応するプロセスが現在処理中のプロセス（無応答のプロセス）であると判断する。

プロセス監視部１０３は、プロセス実行部１０２を終了させ、処理結果を処理結果送信部１０４に送信して、自らのプロセスも終了させる。処理結果送信部１０４に送信する処理結果には、現在処理中のプロセスが認識可能なように、現在処理中のプロセスに関する情報を含ませてもよい。

プロセス監視部は、無応答のプロセスを検知した場合に、リカバリ処理を行ってもよい。具体的な処理の例は、後述する。

プロセス監視部が現在処理中のプロセスを判別する他の方法としては、プロセス監視部１０３が一定時間ごとにログファイル１０５を参照して、ログファイルに記録された最後のプロセスを確認し、前回確認した最後のプロセスから変化が無い場合に、当該プロセスが処理中であると判断することもできる。この場合、最初にログファイルを確認するときは、当該ログファイルに記録された最後のプロセスを確認し、プロセス監視部１０３の使用可能な記録領域又はファイルに記載し、二回目以降はログファイルに記録された最後のプロセスと、前回確認して使用可能な記録領域又はファイルに記載されたプロセスとを比較し、同じプロセスが処理中であるか否かを判断してもよい。

プロセス監視部１０３がログファイル１０５に記録された最後のプロセスを確認する間隔は、実行中のプロセスに応じて適宜変更してもよい。また、プロセスのグループ分けを行い、グループ単位で参照時間を設定してもよい。

一つの実施例としては、ジョブ管理サーバ２０から送信されるジョブ実行コマンドに、各プロセスの参照時間等の情報を含ませておき、プロセス監視部１０３が参照時間等の情報に基づき参照時間を設定することができる。

また、他の実施例としては、あらかじめ各プロセスの参照時間情報のテーブルをジョブ実行サーバ１０が保持しておき、プロセス監視部１０３は実行中のプロセスに対応する参照時間を、参照時間情報のテーブルに基づいて設定してもよい。

このように、上記二つの実施例によると、プロセス又はプロセスのグループ毎の、標準的な処理時間やエラー発生の頻度等の性質に対応させて、プロセス監視部１０３がエラーログ１０５を参照する間隔を設定することができる。

処理結果送信部１０４は、プロセス実行部１０２又はプロセス監視部１０３から処理結果を受信し、ジョブ実行コマンドを発行したジョブ管理サーバ２０等に対して、処理結果を送信する。

＜正常時の処理について＞
図３は、本発明の一実施形態に係るジョブ実行サーバの正常処理時における処理の流れを示したものである。

図３を参照すると、まず、コマンド受信部１０１が、ジョブ実行サーバ１０の外部から、ジョブ実行コマンドを受信する（Ｓ１）。

ジョブ実行コマンドを受信したコマンド受信部１０１は、当該ジョブ実行コマンドに対応したプロセス実行部１０２を生成する（Ｓ２）。

プロセス実行部１０２は、プロセス監視部１０３を生成する（Ｓ３）。その後、プロセス実行部１０２は、必要なプロセスをログファイル１０５にログを記録しながら実行する。プロセスが終了したら、処理結果を処理結果送信部１０４に送信し（Ｓ４）、自らのプロセスを終了させる。

処理結果送信部１０４は、プロセス実行部１０２から処理結果を受信すると、ジョブ実行コマンドを送信した外部に対して、処理結果を送信する（Ｓ５）。

プロセス監視部１０３は、一定時間経過後、プロセス実行部１０２が存在しているか否かを確認する（Ｓ６）。図３では、プロセス実行部１０２が消滅しているので、自らのプロセスを終了させる。

以上まとめると、正常時の処理においては、ジョブ実行コマンドに対応してプロセス実行部１０２及びプロセス監視部１０３が生成され、プロセス実行部１０２はプロセス処理を実行した後に自ら消滅し、プロセス監視部１０２はプロセス実行部１０２の監視を終えると、自らのプロセスを終了させ消滅する。

＜異常時の処理について＞
次に、異常処理時の処理について図４を参照して説明する。図４のＳ１、Ｓ２及びＳ３は、上述の正常処理時の処理と同様である。

プロセス監視部１０３は、プロセス実行部１０２が存在するか否かを確認する（Ｓ７）。図４では、プロセス実行部１０２が存在しているので、プロセス監視部１０３は、ログファイル１０５（図示せず）を参照して、処理中のプロセスを確認する（Ｓ８）。そして、プロセス監視部１０３は、プロセス実行部１０２を終了させ（Ｓ９）、処理結果送信部１０４に処理結果を送信し（Ｓ１０）、自らのプロセスを終了させる。

処理結果送信部１０４は、プロセス監視部１０３から受信した処理結果を、ジョブ実行コマンドを送信した外部に対して送信する（Ｓ１１）。

以上まとめると、異常時の処理においては、ジョブ実行コマンドに対応してプロセス実行部１０２及びプロセス監視部１０３が生成され、プロセス監視部１０３は無応答のプロセスを検知し、プロセス実行部を終了させ、自らのプロセスを終了させ消滅する。

＜サーバリブート処理の異常処理時における処理フロー＞
（第１実施形態）
図５は、本発明の一実施形態に係る、サーバリブート処理の異常処理時における処理概要を示したものである。

サーバリブート処理では、まず、サーバのミドルウェアの通常停止処理を行う（Ｓ２１）。ここではミドルウェアＡ、Ｂ、Ｃがあるものとし、ミドルウェアの通常停止処理とは、ミドルウェアＡ、Ｂ、Ｃに対して、順次停止処理を実行することを意味する。全てのミドルウェアの停止処理が正常終了すると、ＯＳを停止しサーバを再起動する（Ｓ２２）。

ミドルウェアの通常停止処理を実行した場合、ミドルウェアを停止するコマンドに対して比較的短時間で異常終了がリターンされる場合がある。この場合は、ミドルウェアを強制終了させ（Ｓ２３）、ＯＳを停止しサーバを再起動する（Ｓ２４）。

このように、ミドルウェアの停止処理が正常終了するか、又は異常終了がリターンされた場合には、直ちに通常処理（Ｓ２２）又は異常終了時の処理（Ｓ２３、Ｓ２４）が行われる。

これに対し、ミドルウェアの停止処理を実行しても、無応答状態になる場合がある。ここでは、ミドルウェアＢの停止処理中に、無応答状態になったものとする。

本発明の実施形態によると、上述したように、無応答状態になったミドルウェアＢを検知することが可能である。すなわち、ジョブ実行サーバのプロセス監視部が無応答状態のミドルウェアＢを検知し、リカバリ処理を行うことが可能である。

リカバリ処理は、プロセス監視部で行わず、外部からの指示に基づいて実施することもできる。例えば、プロセス監視部は処理結果送信部を介して、処理結果をジョブ管理サーバに送信する。処理結果には、ミドルウェアＢの停止処理時に無応答となったこと等の情報が含まれる。ジョブ管理サーバは、ジョブ実行サーバから受信した処理結果に基づき、リカバリ処理を実行するためのジョブ実行コマンドをジョブ実行サーバに送信する。

プロセス監視部は、リカバリ処理として、ミドルウェアＢの強制停止処理を実行し（Ｓ２５）、ミドルウェアＣの通常停止処理を実行し（Ｓ２６）、ＯＳを停止しサーバを再起動する（Ｓ２７）。リカバリ処理をジョブ実行サーバの外部からの指示に基づいて実行する場合は、ジョブ実行サーバは受信したジョブ実行コマンドに基づき、上記リカバリ処理が行われる。

本発明の実施形態によると、無応答となった処理中のプロセス（本例ではミドルウェアＢの停止処理）を検知し判別することができる。これによって、図５の点線で囲んだ部分の処理のように、正常に処理が終了したミドルウェアＡの停止処理に関しては何も行わず、無応答となったミドルウェアＢの停止処理に対しては強制終了を行い、処理が行われていないミドルウェアＣに対しては通常の停止処理を行うという、処理結果に応じたきめ細かいリカバリ処理を実行することが可能となる。

また、上記リカバリ処理では、無応答となったミドルウェアＢの停止処理に対しては強制終了を行ったが、ミドルウェアＢに対して通常の停止処理を行うこと、すなわち無応答となった処理中のプロセスを再び実行すること（リトライ）を、リカバリ処理の内容としてもよい。

さらに、リカバリ処理の内容としては、本来予定していたジョブの処理（上述のミドルウェアＢに対する通常の停止処理）や、これに準じる処理（上述のミドルウェアＢに対する強制終了）を含まなくてもよく、リカバリ処理として、本来予定していたジョブに対応する別のジョブを実行してもよい。

このように、本発明の実施形態によると、ジョブを構成するプロセス毎に対応する各リカバリ処理を事前に準備することができる。さらに、各リカバリ処理の内容も、状況に応じた複数の処理を準備することができる。処理結果に応じた複数のリカバリ処理を事前に準備することによって、自動リカバリ処理を実現することも可能となる。

さらに、本発明の実施形態によると、通常数十分ないし数時間に設定されるタイムアウトよりも早く異常（ミドルウェアＢの停止処理の無応答）を検知することが可能となるので、上記リカバリ処理を短時間で実行することができる。

（第２実施形態）
第２実施形態は、第１実施形態と同様に、サーバリブート処理では、サーバのミドルウェアＡ、Ｂ、Ｃに対して順次停止処理を実行し、ＯＳを停止してサーバを再起動するものとする。第１実施形態では、リカバリ処理をするためのジョブ実行コマンドをジョブ実行サーバが受信してリカバリ処理が行われたが、第２実施形態では、ジョブ実行サーバがリターンコードを受信してリカバリ処理を行う点に特徴がある。以下、図６を参照しながら詳述する。

ミドルウェアＡの停止処理時に無応答となった場合、リカバリ処理としてＳ４１、Ｓ４２、Ｓ４３及びＳ４４の処理（図６枠線内の一番上のルートＡ）が実行される。ここで、Ｓ４１はミドルウェアＡの強制停止処理、Ｓ４２はミドルウェアＢの通常停止処理、Ｓ４３はミドルウェアＣの通常停止処理、Ｓ４４はＯＳ停止とサーバ再起動の処理である。

ミドルウェアＢの停止処理時に無応答となった場合、リカバリ処理としてＳ４５、Ｓ４３及びＳ４４の処理（図６枠線内の中央のルートＢ）が実行される。ここで、Ｓ４５はミドルウェアＢの強制停止処理である。なお、ルートＢにおける処理は、図５の枠線内に示した処理に対応しており、Ｓ２５とＳ４５、Ｓ２６とＳ４３、Ｓ２７とＳ４４が、それぞれ対応する。

ミドルウェアＣの停止処理時に無応答となった場合、リカバリ処理としてＳ４６及びＳ４４の処理（図６枠線内の一番下のルートＣ）が実行される。ここで、Ｓ４６はミドルウェアＣの強制停止処理である。

ルートＡ、Ｂ、Ｃの各処理内容をみると、ＯＳ停止とサーバ再起動の処理Ｓ４４はルートＡ、Ｂ及びＣに含まれ、ミドルウェアＣの通常終了Ｓ４３はルートＡ及びＢに含まれる。このように、サーバリカバリ処理における各ルートの処理は、個々の処理内容が重複している場合がある。

実施例２では、ジョブ管理サーバは、リカバリ処理を実行するためのリターンコードを、ジョブ実行サーバに送信する。ジョブ実行サーバは、受信したリターンコードに応じたリカバリ処理を実行する。例えば、リターンコード１はルートＡの処理に対応し、Ｓ４１、Ｓ４２、Ｓ４３、Ｓ４４の各処理を順次実行する。また、リターンコード２はルートＢの処理に対応し、Ｓ４５、Ｓ４３、Ｓ４４の各処理を順次実行する。この場合、ジョブ実行サーバは、リターンコードとそれに対応する処理内容及が記載されたテーブルを持ってもよい。

以上のように、実施例２では、ある処理に不具合が発見され修正を要する場合には、当該処理のみを修正すればよく、当該処理を含む各ルートの処理を個別に修正する必要が無いので、メンテナンス性に優れる。例えば、ＯＳ停止とサーバ再起動の処理Ｓ４４に不具合が発見された場合には、当該Ｓ４４のみを修正すればよい。

また、実施例２においては、個々の処理の組み合わせを変更したり、新たな処理を追加したりする等の設計変更に、柔軟に対応することができる。

＜データベース再編処理の異常処理時における処理フロー＞
（実施例３）
図７は、本発明の一実施形態に係る、データベース再編処理の異常処理時における処理概要を示したものである。なお、データベース再編処理とは、データベースへのデータの追加、削除、更新が繰り返されることによって、データベースの格納効率が低下したときに行われるものであり、データベースの配置の乱れを修正し適切に配置する処理をいう。

データベース再編処理では、まず、再編処理の対象となる各テーブルのエクスポート処理を行う（Ｓ３１）。エクスポート処理は、後に実行されるデータベース再編処理で何らかのエラーが発生した場合に備えて、バックアップをとることに相当する。

エクスポート処理が完了すると、データベース再編処理を行う（Ｓ３２）。データベース再編処理は例えばテーブル単位で行われ、複数のテーブルが再編処理の対象となり、処理はテーブル毎に順次行われることが一般的である。ここでは簡単のため、テーブルＤ、Ｅ、Ｆの再編処理を行うこととする。

テーブルＤ、Ｅ、Ｆの再編処理が正常終了すると、データ件数の確認処理が行われる（Ｓ３３）。データベース再編処理を開始した後に、データベースを再編する処理を実行するコマンドに対して、比較的短時間で異常終了がリターンされる場合がある。この場合は、エクスポートしたテーブルに対しテーブルインポート処理を行い（Ｓ３４）、インポートしたデータの件数を確認する（Ｓ３５）。

以上のように、データベース再編処理が正常終了するか、又は異常終了がリターンされた場合には、直ちに通常処理（Ｓ３３）又は異常終了時の処理（Ｓ３４、Ｓ３５）が行われる。

これに対し、データベースの停止処理を実行しても、無応答になる場合がある。ここでは、テーブルＥの再編処理中に、無応答状態になったものとする。

上述のように、本発明の実施形態によると、プロセス監視部によって無応答状態になったテーブルＥを検知し、リカバリ処理を行うことが可能である。

なお、上述のサーバリブート処理の異常処理時における処理フローで説明したのと同様の方法によって、リカバリ処理をジョブ実行サーバの外部からの指示に基づいて実行することも可能である。この場合、ジョブ実行サーバは、処理結果（テーブルＥの再編処理時に無応答）をジョブ管理サーバに送信する。

プロセス監視部は、リカバリ処理として、テーブルＥの再編処理プロセスを停止し（Ｓ３６）、テーブルＥ及びＦのインポート処理（Ｓ３７）を行った後に、データ件数を確認する（Ｓ３８）。リカバリ処理をジョブ実行サーバの外部からの指示に基づいて実行する場合は、ジョブ実行サーバは受信したジョブ実行コマンドに基づき、上記リカバリ処理が行われる。

このように、本発明の実施形態によると、無応答となった処理中のプロセス（本例ではテーブルＥの再編処理）を検知し判別することができるので、図７の点線で囲んだ部分の処理のように、正常に処理が終了したテーブルＤの停止処理に関しては何も行わず、無応答になったテーブルＥ及び停止処理を行っていないテーブルＦのみインポート処理を行うという、処理結果に応じたきめ細かいリカバリ処理を短時間で実行することが可能となる。

また、本発明の実施形態によると、通常数十分ないし数時間に設定されるタイムアウトよりも早く異常（テーブルＥの再編処理の無応答）を検知することが可能となるので、上記リカバリ処理を短時間で実行することができる。

（実施例４）
実施例４においても、実施例２と同様に、ジョブ実行サーバはジョブ管理サーバから受信したリターンコード基づいて、リカバリ処理を行う点に特徴がある。

１０ ジョブ実行サーバ
２０ ジョブ管理サーバ
３０ クライアント
４０ 通信ネットワーク
１０１ コマンド受信部
１０２ プロセス実行部
１０３ プロセス監視部
１０４ 処理結果送信部
１０５ ログファイル

Claims (16)

1. ジョブを構成するプロセスを実行するプロセス実行部と、前記プロセス実行部によって生成されるプロセス監視部とを有し、
   前記プロセス実行部は、前記プロセス毎にログファイルにログを記録し、
   前記プロセス監視部は、前記プロセス実行部を監視する、
   ジョブ実行サーバによって処理されるプロセスの監視システム。
2. 前記プロセス監視部が前記プロセス実行部を監視することは、
   前記プロセス監視部が所定の時間ごとに前記プロセス実行部が存在しているか否かを確認し、前記プロセス実行部が存在していない場合には所定の時間内に処理を終えたと判断し、前記プロセス実行部が存在している場合には所定の時間内に処理を終えていないと判断することを含む、
   請求項１に記載の監視システム。
3. 前記プロセス監視部は、前記ログファイルのログを所定の時間ごとに参照し、前回参照したログの内容から変化していない場合には、前記プロセスが処理中であると判断すること
   を特徴とする請求項２に記載の監視システム。
4. 前記プロセス監視部が前記所定の時間内に処理を終えていないと判断した場合に、前記プロセス監視部は前記処理中のプロセスを停止する、
   請求項２に記載の監視システム。
5. 前記プロセス監視部が前記所定の時間内に処理を終えたと判断した場合には、前記プロセス監視部が消滅する、
   請求項２に記載の監視システム。
6. 前記ジョブ実行サーバは、
   外部から前記ジョブに対応するジョブ実行コマンドを受信するコマンド受信部と、
   前記プロセスの処理結果を前記外部に対して送信する処理結果送信部とを有する、
   請求項１に記載の監視システム。
7. 前記プロセス監視部は、前記所定の時間内に処理を終えていないと判断した場合に、前記プロセス監視部の実行結果を前記プロセスの処理結果として前記処理結果送信部を介して前記外部に送信する、
   請求項２に記載の監視システム。
8. 前記プロセス実行部は、前記所定の時間内に処理を終えたとき、前記プロセスの処理結果を前記処理結果送信部を介して前記外部に送信する、
   請求項７に記載の監視システム。
9. 前記プロセス実行部は、プロセスの起動に対応して生成される、
   請求項８に記載の監視システム。
10. 前記プロセス実行部は、前記ジョブの実行が終了すると消滅する、
    請求項１に記載の監視システム。
11. 前記監視システムは、ジョブ管理サーバをさらに含み、
    前記ジョブ管理サーバは、前記ジョブ実行サーバに前記ジョブ実行コマンドを送信し、前記ジョブ実行サーバから前記プロセスの処理結果を受信する
    請求項１０に記載の監視システム。
12. 前記プロセス監視部が前記所定の時間内に処理を終えていないと判断した場合に、前記ジョブ管理サーバが前記ジョブの進行状況に応じたリカバリ処理を行う実行コマンドを前記ジョブ実行サーバに送信する、
    請求項１１に記載の監視システム。
13. 前記プロセス監視部が前記所定の時間内に処理を終えていないと判断した場合に、前記ジョブ管理サーバが前記ジョブの進行状況に応じたリターンコードを前記ジョブ実行サーバに送信し、前記ジョブ実行サーバは前記リターンコードに対応したリカバリ処理を行う、
    請求項１１に記載の監視システム。
14. 前記リカバリ処理は、リトライ処理を行うことを含む、請求項１２又は１３に記載の監視システム。
15. 前記ジョブ実行コマンドは、前記ジョブ実行サーバのサーバリブートを行うことをその内容とする、請求項１２乃至１４のいずれか一つに記載の監視システム。
16. 前記ジョブ実行コマンドは、前記ジョブ実行サーバのデータベース再編を行うことをその内容とする、請求項１２乃至１４のいずれか一つに記載の監視システム。