JP2013196238A - バッチ処理システム - Google Patents

Abstract

【課題】バッチジョブの実行状態を記録する処理の性能が低下するとバッチジョブの処理時間が長期化すること。
【解決手段】制御コンピュータは、バッチジョブの実行状態を記憶装置に記録する処理の性能を検出し、検出した前記性能に応じて、複数の記録方法の中から、使用する記録方法を選択し、第１のコンピュータに通知する。第１のコンピュータは、第２のコンピュータから通知された記録方法を用いて、自コンピュータにおけるバッチジョブの実行状態を記憶装置に記録する。
【選択図】図１

Description

本発明は、バッチジョブを実行する機能を有するバッチ処理システムに関する。

バッチ処理は、コンピュータのデータ処理方法の一種であり、データを一定期間あるいは一定量をまとめてから、一つのジョブとして一括して処理を行う方式のことである。大量のデータを一括して処理するため、途中で異常終了した際、最初から再実行するとコストが高くなる傾向がある。このため、バッチジョブの実行状態を適宜に記憶装置に保存しておき、万が一に異常終了した際、バッチジョブの途中から再実行するシステムが提案ないし実用化されている（例えば特許文献１参照）。

また、バッチ処理は、単純な処理の繰り返しが比較的多い。このため、バッチ処理を複数のコンピュータを利用して、分散して実行することがある（例えば特許文献２参照）。このような処理を分散バッチ処理、それを実行するシステムを分散バッチ処理システムと言う。分散バッチ処理システムでは、複数のコンピュータにおけるバッチジョブの実行状態は、複数のコンピュータから共通にアクセスされる記憶装置に保存されることが多い。

特開平９−２８２１９２号公報 特開平１０−３２６２０１号公報

バッチジョブを実行するコンピュータにとって、バッチジョブの実行状態を記録する処理はオーバーヘッドになる。このため、バッチジョブの実行状態を記録する記憶装置の障害等によって実行状態を記録する処理の性能が低下すると、記録に必要な処理時間が当初予定した時間よりも長くかかり、その分だけバッチジョブの処理時間が長期化することになる。

一般にバッチ処理は、その後の業務への影響を避けるために、大量のデータを決められた期限までに完了しなければならない場合が多い。そのため、バッチジョブの実行状態を記録するのに要する時間が長くかかると、期限までにバッチ処理を完了することが困難になる。

本発明の目的は、上述した課題、すなわち、バッチジョブの実行状態を記録する処理の性能が低下するとバッチジョブの処理時間が長期化する、という課題を解決するバッチ処理システムを提供することにある。

本発明の一形態にかかるバッチ処理システムは、
バッチジョブを実行する第１のコンピュータと、前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置と、前記第１のコンピュータと前記記憶装置とに接続された第２のコンピュータとを有し、
前記第２のコンピュータは、
前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出する検出手段と、
前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択する選択手段と、
前記選択された記録方法を前記第１のコンピュータに通知する通知手段と
を有し、
前記第１のコンピュータは、
前記第２のコンピュータから通知された前記記録方法を用いて、自コンピュータにおける前記バッチジョブの実行状態を前記記憶装置に記録する実行状態記録手段
を有する
といった構成を採る。

また本発明の他の形態にかかるバッチ処理システム制御方法は、
バッチジョブを実行する第１のコンピュータと、前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置と、前記第１のコンピュータと前記記憶装置とに接続された第２のコンピュータとを有するバッチ処理システムが実行する制御方法であって、
前記第２のコンピュータが、前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出し、
前記第２のコンピュータが、前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択し、
前記第２のコンピュータが、前記選択した記録方法を前記第１のコンピュータに通知し、
前記第１のコンピュータが、前記第２のコンピュータから通知された前記記録方法を用いて、自コンピュータにおける前記バッチジョブの実行状態を前記記憶装置に記録する
といった構成を採る。

また本発明の他の形態にかかるコンピュータは、
バッチジョブを実行する第１のコンピュータと前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置とに接続され、
前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出する検出手段と、
前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択する選択手段と、
前記選択された記録方法を前記第１のコンピュータに通知する通知手段と
を有する
といった構成を採る。

本発明は上述したような構成を有するため、バッチジョブの実行状態を記録する処理の性能が低下しても、バッチジョブの処理時間が長期化するのを防止することができる。

本発明の第１の実施形態のブロック図である。 本発明の第１の実施形態におけるバッチジョブの実行状態の記録フォーマットの一例を示す図である。 本発明の第１の実施形態の処理の一例を示すフローチャートである。 本発明の第２の実施形態におけるジョブリポジトリの或る時点の内容例を示す図である。 本発明の第２の実施形態におけるジョブリポジトリの別の或る時点の内容例を示す図である。 本発明の第２の実施形態の前提となる分散バッチ処理の概略図である。 本発明の第２の実施形態のシステム全体の概要を示すブロック図である。 本発明の第２の実施形態のブロック図である。 本発明の第２の実施形態において、ジョブリポジトリ更新性能低下時のジョブリポジトリ更新方法変更の流れを示すフローチャートである。 本発明の第３の実施形態のブロック図である。 本発明の第３の実施形態におけるジョブリポジトリ更新ポリシーの一例を示す図である。 本発明の第３の実施形態において、ジョブリポジトリ更新性能低下時のジョブリポジトリ更新方法変更の流れを示すフローチャートである。 本発明の第３の実施形態におけるジョブリポジトリ更新ポリシーの別の例を示す図である。

次に本発明の実施の形態について図面を参照して詳細に説明する。
[第１の実施形態]
図１を参照すると、本発明の第１の実施形態にかかるバッチ処理システムは、バッチジョブを実行する１台または複数台の第１のコンピュータ１１０と、第１のコンピュータ１１０におけるバッチジョブの実行状態を記録する記憶装置１２０と、第１のコンピュータ１１０と記憶装置１２０とに接続された第２のコンピュータ１３０とを有する。

第２のコンピュータ１３０は、バッチ処理システム全体の制御を行う機能を有する。第２のコンピュータ１３０は、検出手段１３１と選択手段１３２と通知手段１３３とを有する。

検出手段１３１は、バッチジョブの実行状態を記憶装置１２０に記録する処理の性能を検出する機能を有する。以下、この性能を実行状態記録性能と記す。例えば記憶装置１２０がＲＡＩＤ５等による冗長構成を有する場合、ＲＡＩＤからディスクの一つを切り離して縮退運転している場合のＩ／Ｏ性能（スループットやレイテンシなど）は、ＲＡＩＤが正常に運用されている場合に比べて低下する。このため、記憶装置１２０が正常に稼働しているか、縮退運転しているかを検出することは、実行状態記録性能を検出することに相当する。但し、検出手段１３１は、記憶装置１２０のI/O性能を測定することで実行状態記録性能を検出するようにしてもよい。また、第１のコンピュータ１１０が記憶装置１２０とネットワーク等の通信路によって接続されている場合、通信路の性能（スループットやレイテンシなど）は上記記録する処理の時間に影響を及ぼす。従って、検出手段１３１は、例えば通信路が正常な状態か、輻輳状態かなどを検出することで、実行状態記録性能を検出してもよい。

選択手段１３２は、検出手段１３１によって検出された実行状態記録性能に応じて、バッチジョブの実行状態を記録する複数種類の記録方法の中から、第１のコンピュータ１１０で使用する記録方法を選択する機能を有する。

バッチジョブの実行状態を記録する複数種類の記録方法は、互いに記憶装置１２０へのアクセス頻度が相違していることが望ましい。例えば、複数種類の記録方法には、所定単位の処理を正常に完了する毎に記憶装置１２０へバッチジョブの実行状態を記録する記録方法と、この記録方法に比べてアクセス頻度が低下する、エラー発生時にのみ記憶装置１２０へバッチジョブの実行状態を記録する記録方法とが含まれていてよい。或いは、複数種類の記録方法には、所定単位の処理を正常に完了する毎に記憶装置１２０へバッチジョブの実行状態を記録する記録方法と、この記録方法に比べてアクセス頻度が低下する、上記所定単位に比べて大きな単位の処理を正常に完了する毎に記憶装置１２０へバッチジョブの実行状態を記録する記録方法とが含まれていてよい。

選択手段１３２は、実行状態記録性能に応じて複数種類の記録方法の中から記録方法を選択する際、実行状態記録性能がより低下しているならば、アクセス頻度がより少ない記録方法を選択することが望ましい。

通知手段１３３は、選択手段１３２によって選択された記録方法を第１のコンピュータ１１０に通知する機能を有する。

バッチジョブを実行する第１のコンピュータ１１０は、バッチジョブの実行機能に加えて、実行状態記録手段１１１を有する。

実行状態記録手段１１１は、第２のコンピュータ１３０の通知手段１３３から通知された記録方法を用いて、自コンピュータにおけるバッチジョブの実行状態を記憶装置１２０に記録する機能を有する。

図２はバッチジョブの実行状態の記録フォーマットの一例である。この例では、一つのバッチジョブに対応する実行状態の記録情報は、ジョブ識別子と記録種別と状態とから構成される。ジョブ識別子は、バッチジョブを一意に識別する文字列である。記録種別は、記録方法を一意に識別する文字列である。状態は、バッチジョブの実行状態を示しており、その内容は記録種別によって相違する。この状態の項目には、例えば、１０件のレコードの処理を正常に完了する毎にバッチジョブの実行状態を記録する記録方法では、例えば、「正常終了」あるいは「実行中」などの文字列から構成されるジョブステータスと、何番のレコードまで正常に処理を終えたかを示す「レコード番号」などの文字列とから構成される。他方、エラー発生時にのみバッチジョブの実行状態を記録する記録方法では、例えば、「異常終了」あるいは「実行中」などのジョブステータスと、異常終了したレコードを示す「レコード番号」などの文字列とから構成される。

第１のコンピュータ１１０と第２のコンピュータ１３０は、ＲＡＭやハードディスク等の記憶装置と、外部の装置との間でデータ通信を行うための通信インターフェースと、プログラムを記録するＣＤＲＯＭや磁気ディスク等で構成されたコンピュータ可読記録媒体と、これらに接続されたＣＰＵ等のプロセッサとを有するパーソナルコンピュータ等のコンピュータで構成することができる。コンピュータ可読記録媒体に記録されたプログラムは、コンピュータの立ち上げ時にコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータ上に、第１のコンピュータ１１０の場合には実行状態記録手段１１１を実現し、第２のコンピュータ１３０の場合には、検出手段１３１と選択手段１３２と通知手段１３３とを実現する。

図３は第１および第２のコンピュータの処理の一例を示すフローチャートである。以下、図３を参照して本実施形態にかかるジョブ処理システムの動作を説明する。

第２のコンピュータ１３０の検出手段１３１は、定期的に実行状態記録性能を検出する（ステップＳ１０１）。検出手段１３１は、今回検出した実行状態記録性能と前回検出した実行状態記録性能とを比較することにより、実行状態記録性能が変化したか否かを判定する（ステップＳ１０２）。実行状態記録性能が変化していなければ、ステップＳ１０１に戻って次回の周期の到来を待つ。他方、実行状態記録性能が変化していれば、検出手段１３１は、今回検出した実行状態記録性能を選択手段１３２に伝達する。

選択手段１３２は、検出手段１３１から受け取った実行状態記録性能に基づいて、複数の記録方法の中から第１のコンピュータ１１０に使用させる記録方法の種別を選択する（ステップＳ１０３）。そして、選択手段１３２は、その選択した記録方法の種別を通知手段１３３に伝達する。

通知手段１３３は、選択手段１３２から受け取った記録方法の種別をネットワーク等を通じて第１のコンピュータ１１０に通知する（ステップＳ１０４）。その後、制御は通知手段１３３から検出手段１３１に戻され、検出手段１３１は、次回の周期の到来を待つ。

第１のコンピュータ１１０は、投入されたバッチジョブを実行する（ステップＳ１１１）。そして、実行状態記録手段１１１は、第２のコンピュータ１３０から通知された種別の記録方法を使用して、バッチジョブの実行状態を記憶装置１２０に記録する処理を実行する（ステップＳ１１２）。

例えば、第１のコンピュータ１１０は、種別１の記録方法の通知を受けている状態で、或るバッチジョブの実行を開始した場合、種別１の記録方法を用いて当該バッチジョブの実行状態を記憶装置１２０に記録する処理を開始する。若し、当該バッチジョブの終了まで記録方法の変更がなければ、種別１の記録方法のみ使用してバッチジョブの実行状態が記憶装置１２０に記録される。他方、当該バッチジョブの実行途中で第２のコンピュータ１３０から種別２の記録方法が通知されると、第１のコンピュータ１１０は、バッチジョブの実行途中で記録方法を種別１から種別２へ変更する。

以上説明したように本実施形態によれば、バッチジョブの実行状態を記録する処理の性能が低下しても、バッチジョブの処理時間が長期化するのを防止することができる。その理由は、複数種類の記録方法の中から、実行状態記録性能に応じた記録方法で記録が行われるためである。より具体的には、実行状態記録性能がより低下した場合には、よりアクセス頻度の少ない種別の記録方法を用いて記録が行われるためである。

また本実施形態によれば、実行状態記録性能が回復すると、よりアクセス頻度の多い記録方法に戻すことが可能である。

本実施形態は以下のような付加変更が可能である。

例えば、第２のコンピュータ１３０は、図１に破線で示すように、第１のコンピュータ１１０で実行されるバッチジョブの属性を記憶する属性記憶手段１３４を有していてよい。バッチジョブの属性とは、例えば、１件のデータ量、後述するチャンクサイズなどを意味する。そして、属性記憶手段１３４を有する場合、選択手段１３２は、検出手段１３１で検出された実行状態記録性能と属性記憶手段１３４に記憶されているバッチジョブの属性とに応じて、第１のコンピュータ１１０毎に記録方法の種別を選択するようにしてよい。

あるいは、第１のコンピュータ１１０は、図１に破線で示すように、自コンピュータにおけるバッチジョブの実行状況を第２のコンピュータ１３０に通知する実行状況通知手段１１２を有していてよい。バッチジョブの実行状況とは、ジョブ実行時間、単位時間当たりの記憶装置１２０へのアクセス回数などを意味する。そして、実行状況通知手段１１２を有する場合、第２のコンピュータ１３０は、図１に破線で示すように、第１のコンピュータ１１０から通知されるバッチジョブの実行状況を記憶する実行状況記憶手段１３５を有していてよい。そして、実行状況記憶手段１３５を有する場合、第２のコンピュータ１３０の選択手段１３２は、検出手段１３１で検出された実行状態記録性能と実行状況記憶手段１３５に記憶されているバッチジョブの実行状況とに応じて、第１のコンピュータ１１０毎に記録方法を選択するようにしてよい。

あるいは、属性記憶手段１３４、実行状況記憶手段１３５、および実行状況通知手段１１２を有し、選択手段１３２は、検出手段１３１で検出された実行状態記録性能と、属性記憶手段１３４に記憶されているバッチジョブの属性と、実行状況記憶手段１３５に記憶されているバッチジョブの実行状況とに応じて、第１のコンピュータ１１０毎に記録方法を選択するようにしてよい。

また、本実施形態のバッチ処理システムは、バッチジョブを実行する第１のコンピュータ１１０とは別に、実行状態記録性能の検出と記録方法の選択とを行う機能を有する第２のコンピュータ１３０を有しているが、バッチジョブを実行する第１のコンピュータ１１０に、第２のコンピュータ１３０の有する上記機能を持たせるようにしてもよい。

[第２の実施形態]
[本実施形態が解決しようとする課題]
バッチ処理実行において、その実行状況などの情報を保持することで、バッチ処理が失敗したときに失敗したところから再実行を行うことができる。ジョブの実行状態を保存したものを以降ジョブリポジトリと呼ぶ。例えば、データベースにジョブ実行状態の記録用テーブルを作成し、ジョブの実行とともに何件目のデータまで処理を行ったのかをテーブルに記録するといったものである。

本実施形態では、あるデータ群に対して連続して処理を実行するようなバッチ処理を想定する。そのバッチ処理は連続して実行する或るデータ件数をひとまとまりにしてトランザクション処理として実行するものとする。このデータのまとまりをチャンクと呼び、そこに含まれるデータ件数をチャンクサイズと呼ぶ。

トランザクション処理とは、相互依存のある複数の操作が全て完了するか、全てキャンセルされることを保証する処理のことである。本実施形態でのバッチ処理における動作の様子を説明すると、ひとつのチャンク内のデータすべての処理が成功した時点で始めてそのチャンク処理を成功とみなし、もしチャンク内のデータ処理のうちひとつでも失敗してしまった場合は、そのチャンク処理を失敗とみなし、対象チャンク処理実行前の状態に戻すという動作を行う。そして実行状態を保存する処理であるジョブリポジトリの更新は、チャンク処理の成功毎に実行するものとする。

図４および図５を用いてジョブリポジトリの更新について説明する。この例のジョブリポジトリは、バッチジョブ毎に、ジョブID、ジョブ名、開始時刻、終了時刻、実行状態、レコード番号、スキップ（Ｓｋｉｐ）回数、ジョブリポジトリ状態を記録する構成である。

図４はある時点のジョブリポジトリの例を示したものである。正常終了したＪｏｂ１と現在実行中のＪｏｂ２のバッチジョブ実行状態を示している。ここで、Ｊｏｂ２のチャンクサイズを１０とすると、図４から１チャンクの処理が終了した時のジョブリポジトリを示したものが図５である。レコード番号が５０から６０へと１０だけ進んでいるのがわかる。

このようにチャンク処理の成功毎にジョブリポジトリの更新を行うことで、バッチ途中で処理に失敗してしまった場合でも、常に、成功したチャンク以降の処理からチャンク
単位での再実行を行うことができる。チャンク処理の成功毎にジョブリポジトリの更新を行うという方法は、ジョブ実行に失敗して再実行を行う場合の処理量は少ない反面、ジョブリポジトリの更新頻度は高くなってしまうという側面を併せ持っている。

次に分散バッチ処理について述べる。分散バッチ処理とはバッチ処理を複数のコンピュータやプロセッサを利用して、分散して実行することである。バッチ処理は、単純な処理の繰り返しを行う処理が含まれている場合があるなど分散処理に向いており、分散処理によって効率的にバッチ処理を実行することが可能である。分散バッチ処理の処理モデルとして大きく以下の２つの形態が挙げられる。

○１つのバッチジョブを複数のサーバで分散処理する形態
ある膨大な件数の処理を行う１つのバッチジョブを、複数のサーバで分散処理する場合などに相当する。このとき、バッチジョブの実行自体は複数のサーバに分散すればするほど性能が上がるが、バッチジョブの実行状況はある程度まとめて管理することが望ましい。この理由は、ジョブ全体の状態を取得する場合や、ジョブの再実行を行う際は、各実行サーバでの実行結果を集める必要があり、これらは分散しているよりまとめて管理されているほうが高速に取得可能であるからである。したがってジョブの実行状態はまとめて管理されることが望ましい。

また、１つのバッチジョブを分割して同時に実行するので、ジョブリポジトリの更新タイミングが複数の実行サーバ間で合ってしまい、ジョブリポジトリ用リソースのアクセスに時間的に偏りが生じてしまうという側面もある。

○複数種類のバッチジョブを複数のサーバで分散処理する形態
異なるさまざまな種類のジョブが複数サーバで実行される場合である。また、同じジョブでも実行時に与えるパラメータ（例えばチャンクサイズ）が異なる場合などもこれに該当する。

図６に分散バッチ処理の概略図を示す。本実施形態ではジョブリポジトリにジョブの実行状態を保存するシステムを対象としているので、ジョブリポジトリを記述している。ジョブリポジトリは単体あるいは複数のリソースに分散して格納される。

ここで、分散バッチ処理においてジョブリポジトリの更新性能が低下した場合について考える。ジョブリポジトリの更新性能低下により、膨大な実行サーバのジョブリポジトリ更新処理がボトルネックとなりバッチジョブ全体の性能が低下してしまう恐れがある。したがって、何らかの対応を行う必要がある。しかし上記の１点目によりジョブの実行状態はまとめて管理されることが望ましいため、ジョブリポジトリの更新性能が低下したときに単純にジョブリポジトリ用のリソースを追加するという対応は好ましくない。

[本実施形態の概要]
上記のように、ジョブリポジトリの更新性能が低下したときに単純にジョブリポジトリ用のリソースを追加するという対応は好ましくない。したがって、本実施形態では、ジョブリポジトリの更新回数を減らす、または更新するデータ量を少なくするなど、ジョブリポジトリの性能低下時用に負荷を低減したジョブリポジトリ更新方法を導入する。

具体的には、通常はチャンク処理の成功毎にジョブリポジトリ更新を行うが、ジョブリポジトリの性能が低下した場合、処理の失敗時にのみ更新する方法に変更する。これによりジョブリポジトリの更新頻度を低下させることができ、ジョブリポジトリの性能低下による影響を低減することができる。

初めに、本実施形態のシステム全体の構成を簡略化して示す図７を用いて、分散バッチ処理において、ジョブリポジトリ更新性能低下時に、ジョブリポジトリ更新方法を変更することによって、ジョブリポジトリ更新性能の低下の影響を低減する構成の概要について説明する。

制御サーバ２１０はバッチジョブを各実行サーバ２２０に振り分ける。各実行サーバ２２０は与えられたバッチジョブを実行する。通常は、図４および図５に示したように、チャンク単位の処理が正常終了した時点でジョブ実行状態の保存、つまりジョブリポジトリの更新を行う。

ここで、ジョブリポジトリ更新処理の性能が低下した場合を考える。上で説明したとおり、通常の状態では、上で述べたようにチャンク単位の処理が正常終了するたびにジョブリポジトリの更新を行っている。これを、ジョブリポジトリ更新性能の低下時には、チャンク処理にエラーが起きたときのみにジョブリポジトリを更新するように変更する。例えば、３つのチャンクの処理を正常に実行し、４つ目のチャンクの処理中にエラーが起きた場合、通常時の方法では、ジョブリポジトリへのアクセスが３回発生するのに対して、エラーが発生したときのみジョブリポジトリを更新する方法では、１回しかアクセスが発生しない。

エラーが発生したときのみジョブリポジトリを更新する方法では、ジョブリポジトリの内容は、図４および図５中、ジョブリポジトリ状態が「正常」でなく「異常」あるいは「縮退運転」に変わり、レコード番号は処理が失敗したレコード番号を示す。記録フォーマット自体は、記録方法の変更前後で同じである。このように、処理が失敗したデータ位置を保持しつつ、ジョブリポジトリ用のＤＢへのアクセスを減らすことができる。これによって、ジョブリポジトリ更新性能の低下による影響を低減することができる。

[本実施形態の構成]
本実施形態の構成を図８を参照して詳細に説明する。

図８を参照すると、本実施形態は、分散バッチ処理を制御する制御サーバ２１０と、制御サーバ２１０により制御されて各バッチ処理を実行する複数の実行サーバ２２０（実行サーバ群）と、ジョブリポジトリ２３０とから構成される。

制御サーバ２１０は、処理実行制御部２１１と、ジョブリポジトリ管理部２１２と、ジョブリポジトリ更新制御部２１３とから構成される。処理実行制御部２１１は、処理を行う必要があるバッチ処理群を、各実行サーバ２２０に振り分け、実行を制御する。ジョブリポジトリ管理部２１２は、ジョブリポジトリ用のリソースが正常に動作しているかどうかの監視と、ジョブリポジトリの内容を管理する。ジョブリポジトリ更新制御部２１３は、実行サーバ２２０のジョブリポジトリ更新部２２２に対してジョブリポジトリ更新方法（記録方法）の変更を指示する。

各実行サーバ２２０は、処理実行部２２１と、ジョブリポジトリ更新部２２２とから構成される。処理実行部２２１はバッチジョブの実行を行う。ここでは例として入力用のＤＢ２４０と、結果出力用のＤＢ２５０とを記述している。ジョブリポジトリ更新部２２２は、バッチジョブ実行に合わせて、ジョブリポジトリ２３０の更新を行う。こちらも例として複数のＤＢ２３１から構成されるジョブリポジトリを記述している。すなわち、ジョブリポジトリ２３１は、ジョブリポジトリ用リソース群で構成される。

[本実施形態の動作]
本実施形態の動作について、図９のフローチャートを参照して説明する。

まず、制御サーバ２１０の処理実行制御部２１１が、各実行サーバ２２０にジョブを振り分け、実行を指示する（ステップＳ２０１）。

次に、上記の指示を受けて、各実行サーバ２２０の処理実行部２２１にてジョブ実行が開始される（ステップＳ２０２）。各実行サーバ２２０はジョブの実行に合わせてジョブリポジトリ更新を行い、ジョブの実行状況の保存を行う。

ジョブの開始とともに、制御サーバ２１０のジョブリポジトリ管理部２１２は、ジョブリポジトリ用リソースの状態を監視する（ステップＳ２０３）。そして、ジョブリポジトリ管理部２１２は、ジョブリポジトリ更新性能の低下を検知した場合、ジョブリポジトリ更新方法変更処理に入るようにジョブリポジトリ更新制御部２１３に指令する（ステップＳ２０４）。

制御サーバ２１０のジョブリポジトリ更新制御部２１３は、まず、更新方法の変更を行う一つの実行サーバ２２０の選択を行う（ステップＳ２０５）。次にジョブリポジトリ更新制御部２１３は、上記選択した実行サーバ２２０に対して、ジョブリポジトリ更新方法の変更を通知する（ステップＳ２０６）。ジョブリポジトリ更新制御部２１３は、すべての実行サーバ２２０に対してジョブリポジトリ更新方法の変更指示を行うまで、ステップＳ２０５、Ｓ２０６の処理を繰り返す。

各実行サーバ２２０のジョブリポジトリ更新部２２２は、ジョブリポジトリ更新制御部２１３からの上記通知を受けて、ジョブリポジトリ更新方法を変更する（ステップＳ２０７）。以降のジョブ実行についてのジョブリポジトリ更新処理は、ここで変更した方法を用いて行う。

[本実施形態の効果]
第1の効果は、分散バッチ処理実行基盤において、ジョブリポジトリ用リソースの更新処理性能が低下した場合に、各実行サーバのジョブリポジトリ更新方法を変更することにより、性能低下の影響を低減できる点である。

以下に、本実施形態のジョブリポジトリ更新方法の変更を用いることによる効果を、例を挙げて説明する。

具体例の前提を以下に述べる。１つの制御サーバ２１０に対して、１００台の実行サーバ２２０があるシステムとする。１つのジョブのデータを１００分割し、各実行サーバ２２０にて実行する。すべてのサーバ２２０でチャンクサイズを同じとする。１チャンクの実行にかかる時間を５秒、実行サーバ２２０はそれぞれ１００００チャンクの処理を行うこととする。

想定するケースは、以下の２通りとする。
・ケースＡ：
全ての実行サーバが、ジョブの開始から終了まで、チャンク単位の処理が正常終了するごとに更新を実行する方法でジョブリポジトリを更新する。
・ケースＢ：
全ての実行サーバが、ジョブの開始から終了まで、チャンク単位の処理が失敗した場合のみに更新を実行する方法でジョブリポジトリを更新する。但し、ジョブが正常終了した時点では、その旨を記録するためにジョブリポジトリを更新する。

また、１台の実行サーバ２２０がジョブリポジトリ２３０の更新を１回行うのに0.1秒かかるものとする。各実行サーバ２２０上で行われるジョブ処理自体ではエラーは一切発生しないものとする。このとき、Ａ、Ｂそれぞれのケースの場合について、処理完了までのサーバ１台あたりの平均処理時間を計算すると、おおよそ以下のようになる。

・ケースＡ
チャンク処理とジョブリポジトリの更新処理を１００００回繰り返す。下の式では１台当たりの平均処理時間を計算しているので、１００[台]で割っている。
((5[s] + 0.1[s]) * 10000[チャンク]) * 100[台] / 100[台]＝ 51000 [sec]

・ケースＢ
この場合、ジョブ処理自体ではエラーは発生しないので、ジョブリポジトリ更新処理は、処理終了時の一度のみとなる。したがって、各実行サーバはチャンク処理１００００回と、ジョブ終了時の１回のジョブリポジトリ更新を行う。
(5[s] * 10000[チャンク] + 0.1[s]) * 100[台] / 100[台] ≒ 50000 [sec]

今回の例においては、サーバ１台あたりの平均処理時間に関して、ケースＡの結果と比べた時、ケースＢの方法では１０００秒だけ処理時間が短いという結果になっている。つまり、ジョブリポジトリ更新性能の低下時に、チャンク単位の処理が正常終了するごとに更新を実行する方法から、チャンク単位の処理が失敗した場合のみに更新を実行する方法に変更することで、ジョブリポジトリ更新性能低下の影響を低減できることがわかる。

[第３の実施形態]
本実施形態では、ジョブリポジトリ更新性能が低下した場合、第２の実施形態のように、単純にすべての実行サーバ２２０のジョブリポジトリ更新方法を、エラー時のみに更新するという方法に変更するのではなく、各実行サーバ２２０毎に、実行しているジョブの属性に基づくジョブリポジトリ更新方法決定ポリシーによってジョブリポジトリ更新方法を決定する。これにより各実行ジョブ毎に適切なジョブリポジトリ更新方法を適用することを可能とする。

このため、本実施形態では、図１０に示すように、第２の実施形態の構成に変更を加えている。まず制御サーバ２１０には、ジョブリポジトリ更新方法変更ポリシー２１４と、ジョブデータ２１５とを追加し、各実行サーバ２２０には、ジョブリポジトリ更新方法を決定するために使用する動的な情報を取得するためのジョブ実行状況取得部２２３を追加する。以下で本実施形態についての詳細な説明を行う。

第２の実施形態では、バッチジョブの実行時にエラーが生じたときのみにジョブリポジトリの更新を行うように変更した。しかしながら、バッチジョブの実行時にエラーが生じたときのみにジョブリポジトリの更新を行うという方法を取る場合、バッチジョブ実行プロセスが落ちてしまった場合など、エラーが生じたにもかかわらずジョブリポジトリへの更新が行われないという状況が発生しうる。この時、その実行サーバ２２０でエラーが起こらずにすべてのデータが正常に処理されていた場合、どこまでバッチジョブが実行されたのかという情報が記録されておらず、バッチジョブを再実行する際には、一番初めのデータから処理をやり直す必要がある。

つまり、ジョブリポジトリ更新の性能低下による影響を低減するということと、ジョブ再実行時にかかるコストを抑えるということは、トレードオフの関係にあると言える。

以下に挙げるいくつかのジョブは、ジョブの再実行時にかかるコストが大きいなどの理由から、エラー時のみにジョブリポジトリの更新を行うという方法を採用するのが不適切なケースである。
(1)割り当てられたバッチジョブを初めから再実行するコストが大きいバッチジョブ
実行サーバ２２０に割り当てられたバッチジョブを初めから再実行する必要があるが、扱うデータが非常に大きいなど、再実行時のコストが非常に大きいバッチジョブである。
(2)高い信頼性が求められるバッチジョブ
実行サーバ２２０に割り当てられたバッチジョブを初めから再実行することになるが、２回以上実行できないバッチジョブが存在する場合など、高い信頼性を持った状態管理が必要なバッチジョブである。
(3)実行時間が大きいバッチジョブ
実行サーバ２２０がダウンするなどしてしまった場合、実行サーバ２２０に割り当てられたバッチジョブを初めから再実行する必要があるが、大きな実行時間がかかっているバッチジョブは、再度その大きな実行時間をかける必要がある。したがって、ジョブリポジトリ更新性能の低下が発生した時点で実行時間の大きなバッチジョブについては、障害発生後も、各チャンクの処理成功毎にジョブリポジトリを更新するなどして、再度ジョブを最初から行うということを避ける、といった運用を行うのが望ましい。
(4)単位時間当たりのジョブリポジトリ更新処理回数が少ないバッチジョブ
単位時間当たりのジョブリポジトリ更新処理の回数が少ないバッチジョブの場合、もともとジョブリポジトリ用ＤＢに与える負荷が少ないので、ＤＢの障害時もその更新方法を変える必要がない可能性がある。
(5)異常終了する可能性が高いバッチジョブ
「スキップ回数」が多いなど、異常終了する可能性が高いジョブがその例である。ジョブリポジトリはエラーの再実行に備えるために更新するという側面が強いため、異常終了する可能性が高いバッチジョブについてはジョブリポジトリの更新を確実に行うことが望ましい。

このように、性能の低下を防ぐためにジョブリポジトリ更新の頻度を落とすべきジョブがある一方で、再実行時にかかるコストを抑えるべきジョブも存在する。したがって、本実施形態では、ジョブリポジトリ更新方法を複数用意し、また、それぞれの更新方法の適用ポリシーを定義する。以下にジョブリポジトリ更新方法を例として挙げる。
(a)１回のチャンク処理終了毎に更新（第２実施形態における通常時の更新方法）
(b)一定回数（２以上）のチャンク処理終了毎に更新
(c)一定件数の処理終了毎に更新
(d)一連の処理（サブジョブＡ→サブジョブＢ→サブジョブＣというような一連の処理終了など)毎に更新
(e)エラー発生時のみに更新（第２実施形態におけるジョブリポジトリ更新性能低下時に採用する更新方法）

また、ジョブリポジトリ更新方法決定ポリシーに使用するジョブの属性の例を以下に列挙する。括弧内に、当該ジョブの属性がジョブ実行以前に定められるか（静的）、ジョブの実行過程で定められるか（動的）を付記する。

（ア）１件のデータ容量（静的データ）
（イ）チャンクサイズ（静的データ）
（ウ）ジョブが一連の処理を持つかどうか（静的データ）
（エ）サーバダウンの可能性（静的データ）
（オ）ジョブ実行時間（動的データ）
（カ）単位時間当たりのジョブリポジトリ更新回数（動的データ）

ジョブリポジトリ更新方法変更ポリシー２１４は、ジョブリポジトリの更新方法の変更についての指標を定めるものである。図１１はジョブリポジトリ更新ポリシー２１４の一例である。この例のジョブリポジトリ更新ポリシー２１４は、５つのエントリを有する。各々のエントリは、更新方法とその適用条件とを有する。更新方法には、上記ａ〜ｅの５種類の更新方法の何れかが記述される。適用条件には、対応する更新方法を採用する条件が記述される。上側のエントリから順に適用の可否が判断され、最初に適用条件のマッチした更新方法が使用される。

例えば、ジョブリポジトリ２３０のＤＢ状態が通常であれば、ａの更新方法が使用される。また、ジョブリポジトリ２３０のＤＢ状態が縮退運転で、然もＤＢ障害発生時点のジョブ実行時間がｍ以上またはジョブリポジトリ更新処理がｍ[回／ｍｉｎ]以上であれば、同じくａの更新方法が使用される。しかし、縮退運転であっても、ＤＢ障害発生時点のジョブ実行時間がｍ以上またはジョブリポジトリ更新処理がｍ[回／ｍｉｎ]以上でなければ、次に、チャンクサイズがｍ以下か否かが判断され、そうであればｂの更新方法が使用される。チャンクサイズがｍ以下でなければ、さらに１件のデータ容量がｍ[ＭＢ]以上か否かが判断され、そうであればｃの更新方法が使用される。また、１件のデータ容量がｍ[ＭＢ]以上でなければ、ジョブが一連の処理単位を持つならばｄの更新方法が使用され、そうでなければｅの更新方法が使用される。

[本実施形態の構成]
図１０を参照すると、本実施形態は、図８に示される第1の実施形態の構成と比較して、制御サーバ２１０にジョブリポジトリ更新方法変更ポリシー２１４と、ジョブデータ２１５とを有し、各実行サーバ２２０にジョブリポジトリ更新方法を決定するために使用する動的な情報を取得するためのジョブ実行状況取得部２２３を有する点で相違する。

実行サーバ２２０のジョブ実行状況取得部２２３は、ジョブ実行時にジョブリポジトリ更新方法変更ポリシー２１４で使用する動的なジョブデータを定期的に制御サーバ２１０に送信する機能を有する。なお、静的なデータは事前にジョブデータ２１５に存在する。

ジョブリポジトリの更新性能が低下した場合は、制御サーバ２１０のジョブリポジトリ更新制御部２１３は、格納されているジョブデータ２１５を参照して、ジョブリポジトリ更新方法変更ポリシー２１４に基づいたジョブリポジトリ更新方法の決定を行う。

[本実施形態の動作]
本実施形態の動作について、図１２のフローチャートを参照して説明する。

まず、制御サーバ２１０の処理実行制御部２１１が、各実行サーバ２２０にジョブを振り分け、実行を指示する（ステップＳ３０１）。

次に、上記の指示を受けて、各実行サーバ２２０の処理実行部２２１にてジョブ実行が開始される（ステップＳ３０２）。各実行サーバ２２０はジョブの実行に合わせてジョブリポジトリ更新を行い、ジョブの実行状況の保存を行う。また、各実行サーバ２２０は、ジョブリポジトリ更新方法を決定するために使用する動的なジョブデータの取得を行い、制御サーバ２１０に送信する。

ジョブの開始とともに、制御サーバ２１０のジョブリポジトリ管理部２１２は、ジョブリポジトリ用リソースの状態を監視する（ステップＳ３０３）。そして、ジョブリポジトリ管理部２１２は、ジョブリポジトリ更新性能の低下を検知した場合、ジョブリポジトリ更新方法変更処理に入るようにジョブリポジトリ更新制御部２１３に指令する（ステップＳ３０４）。

制御サーバ２１０のジョブリポジトリ更新制御部２１３は、まず、更新方法の変更を行う一つの実行サーバ２２０の選択を行う（ステップＳ３０５）。次にジョブリポジトリ更新制御部２１３は、ジョブデータ２１５から、当該実行サーバ２２０のジョブにかかる静的および動的なジョブデータを取得する（ステップＳ３０６）。次にジョブリポジトリ更新制御部２１３は、取得したジョブデータを元に、当該実行サーバ２２０にて実行されているバッチジョブが、ジョブリポジトリ更新ポリシーのどの更新方法の適用条件に当てはまるかの検査を行い、更新方法を決定する（ステップＳ３０７）。そして、ジョブリポジトリ更新制御部２１３は、上記選択した実行サーバ２２０に対して、ジョブリポジトリ更新方法の変更を通知する。ジョブリポジトリ更新制御部２１３は、すべての実行サーバ２２０に対してジョブリポジトリ更新方法の変更指示を行うまで、ステップＳ３０５〜Ｓ３０７の処理を繰り返す。

各実行サーバ２２０のジョブリポジトリ更新部２２２は、ジョブリポジトリ更新制御部２１３からの上記通知を受けて、ジョブリポジトリ更新方法を通知された方法に変更する（ステップＳ３０８）。

[本実施形態の効果]
本実施形態によれば、第２の実施形態と同様の効果が得られると共に、以下のような効果が得られる。

各実行サーバ２２０毎に、実行中のバッチジョブの情報をジョブリポジト更新方法決定の判断材料として使用することで、ジョブリポジトリ更新の性能低下による影響の低減と、ジョブ再実行時にかかるコストのバランスを取った柔軟な運用が可能になる。

また、各実行サーバ２２０毎に、実行中のバッチの処理結果から動的に得られるバッチジョブ実行に関する情報を、ジョブリポジト更新方法決定の判断材料として使用することで、さらに柔軟な運用が可能である。具体的に説明すると、ある実行サーバ２２０について、思ったような速度が出ないなどの予想外のジョブ実行時間の増大や、入力データの事前チェックを行わないでジョブを実行した結果、実行してみたら入力データに不備が多かったなど、実行して初めてわかるジョブの情報もある。本実施形態では、このような動的な情報を使用して、より柔軟性の高い運用を可能としている。

以下では、本実施形態を用いることによる効果を、例を挙げて説明する。具体例の前提を以下に述べる。

１つの制御サーバ２１０に対して、１００台の実行サーバ２２０があるシステムとする。１つのジョブのデータを１００分割し、各実行サーバ２２０にて実行する。すべてのサーバ２２０でチャンクサイズを同じとする。１つのチャンクの実行にかかる時間を５秒、実行サーバ２２０はそれぞれ１００００チャンクの処理を行うこととする。

想定するケースは、以下の３通りとする。
・ケースＡ：
全ての実行サーバが、ジョブの開始から終了まで、チャンク単位の処理が正常終了するごとに更新を実行する方法でジョブリポジトリを更新する。
・ケースＢ：
全ての実行サーバが、ジョブの開始から終了まで、チャンク単位の処理が失敗した場合のみに更新を実行する方法でジョブリポジトリを更新する。
ケースＣ：
全ての実行サーバが、ジョブの開始から終了まで、実行サーバ毎に適した更新方法によってジョブリポジトリを更新する（つまり、本実施形態による方法）

なお、ここではケースＣにおける実行サーバ毎に適した更新方法を、図１３に示す単純化したものとして説明する。すなわち、ジョブリポジトリ２３０のＤＢ状態が通常であるか、または、縮退運転であって、且つ実行サーバに割り当てられた処理をすべて実行するまでにサーバダウンが発生する可能性が統計的に見て１０パーセント以上ならば、図１１中のａの更新方法を用い、それ以外はｅの更新方法を用いるものとする。

また、１台の実行サーバ２２０がジョブリポジトリ２３０の更新を１回行うのに0.1秒かかるものとする。また、１００台のサーバのうち、５０台のサーバが１００００チャンク目の処理終了直前に１００パーセントの確率でダウンし、ジョブ実行プロセスが落ちるものとする。ダウンしたサーバ、ジョブ実行プロセスは即座に復旧するものとし、復旧にかかる時間は０[ｓｅｃ]とする。また、各実行サーバ２２０上で行われるジョブ処理自体ではエラーは一切発生しないものとする。このとき、Ａ、Ｂ、Ｃのケースそれぞれについて、処理完了までのサーバ１台あたりの平均処理時間を計算するとおおよそ以下のようになる。

・ケースＡ
チャンク処理とジョブリポジトリの更新処理を１００００回繰り返す。５０台のサーバについては１００００チャンク目の処理途中にサーバがダウンするが、瞬時に復旧し１０００００チャンク目から処理を再開する。
((5[s] + 0.1[s]) * 10000[チャンク] * 50[台]) + (5[s] + 0.1[s]) * 10001[チャンク] * 50[台])) / 100[台] ≒ 51002[sec]

・ケースＢ
この場合、ジョブ処理自体ではエラーは発生しないので、ジョブリポジトリ更新処理は、処理終了時の一度のみとなる。ダウンしないサーバに関しては、チャンク処理１００００回と、ジョブ終了時の１回のジョブリポジトリ更新となる。また、ダウンするサーバに関しては、１００００チャンク目の処理の直前にダウンした時点で、ジョブリポジトリに実行情報は残されていないので、再度１００００チャンクの実行が必要となるため、合計２００００チャンクを実行することになる。
((5[s] * 10000[チャンク] + 0.1[s]) * 50[台] + (5[s] * 20000[チャンク] + 0.1[s]) * 50[台])) / 100[台] ≒ 75000[sec]

・ケースＣ
ダウンしないサーバに関しては、チャンク処理１００００回と、１回のジョブリポジトリ更新となる。また、ダウンするサーバに関してであるが、１００００チャンク目の処理終了直前に１００パーセントの確率でダウンするということは、失敗確率１０パーセント以上であるため、ａの更新方法を用いるということになる。復旧後には１００００チャンク目から処理を再開することができるので、チャンク処理とジョブリポジトリの更新処理を１０００１回繰り返すことになる。
((5[s] * 10000[チャンク] + 0.1[s]) * 50[台] + (5[s] + 0.1[s]) * 10001[チャンク] * 50[台])) / 100[台] ≒50500 [sec]

今回の例においては、サーバ１台あたりの平均処理時間に関して、ケースＡの結果と比べた時、ケースＢでは約２５０００秒の増加、ケースＣは約５００秒の減少という結果となった。通常、ケースＡと比べて、ケースＢはジョブリポジトリ更新回数が減るので、処理時間が減るはずだが、今回のようにサーバがダウンしてしまう場合は、処理をデータの一番初めから再実行する必要があるので、処理時間が増大してしまうこともある。

これに対し、ケースＣの場合は、実行サーバに応じた更新方法を用いていることから、処理時間を減らすことに成功している。つまり、ジョブリポジトリ更新性能の低下時に、本実施形態を用いることによって、ジョブリポジトリ更新の性能低下による影響の低減と、ジョブ再実行時にかかるコストのバランスを取った運用を行うことができる。

このように本実施形態によれば、バッチ処理分散実行基盤において、バッチジョブの実行状態保存処理の性能低下を考慮した制御装置及び制御システムを提供することができる。

また本実施形態によれば、バッチ処理分散実行基盤において各ジョブの実行状態の保存を行う時に、実行状態保存処理の性能低下時には、実行状態の保存方法を保存用リソースへのアクセスを減らすような方法に変更する。これによって、実行状態保存処理の性能低下が及ぼすバッチ処理全体への影響を低減するシステムを提供することができる。

また本実施形態によれば、性能低下時の実行状態保存方法の変更に関して、ジョブの特徴及びジョブ実行によって得られる情報から、どのような変更を適用するかどうかの判断を行う部分を有し、それによりバッチ処理実行の性能と信頼性のバランスを制御することを可能とするシステムを提供することができる。

本発明は、バッチジョブを実行する機能を有するバッチ処理システム、特に分散バッチ処理システムに好適である。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
（付記１）
バッチジョブを実行する第１のコンピュータと、前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置と、前記第１のコンピュータと前記記憶装置とに接続された第２のコンピュータとを有し、
前記第２のコンピュータは、
前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出する検出手段と、
前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択する選択手段と、
前記選択された記録方法を前記第１のコンピュータに通知する通知手段と
を有し、
前記第１のコンピュータは、
前記第２のコンピュータから通知された前記記録方法を用いて、自コンピュータにおける前記バッチジョブの実行状態を前記記憶装置に記録する実行状態記録手段
を有する
バッチ処理システム。
（付記２）
前記複数の記録方法は、互いに前記記憶装置へのアクセス頻度が相違する
付記１に記載のバッチ処理システム。
（付記３）
前記第２のコンピュータは、さらに、
前記第１のコンピュータで実行される前記バッチジョブの属性を記憶する属性記憶手段を有し、
前記選択手段は、前記検出した前記性能と前記属性記憶手段に記憶されている前記バッチジョブの属性とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記１または２に記載のバッチ処理システム。
（付記４）
前記第１のコンピュータは、さらに、
自コンピュータにおける前記バッチジョブの実行状況を前記第２のコンピュータに通知する実行状況通知手段
を有し、
前記第２のコンピュータは、さらに、
前記第１のコンピュータから通知される前記バッチジョブの実行状況を記憶する実行状況記憶手段を有し、
前記選択手段は、前記検出した前記性能と前記実行状況記憶手段に記憶されている前記バッチジョブの実行状況とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記１または２に記載のバッチ処理システム。
（付記５）
前記第１のコンピュータは、さらに、
自コンピュータにおける前記バッチジョブの実行状況を前記第２のコンピュータに通知する実行状況通知手段
を有し、
前記第２のコンピュータは、さらに、
前記第１のコンピュータで実行される前記バッチジョブの属性と前記第１のコンピュータから通知される前記バッチジョブの実行状況とを記憶する属性・実行状況記憶手段を有し、
前記選択手段は、前記検出した前記性能と前記属性・実行状況記憶手段に記憶されている前記バッチジョブの属性および前記バッチジョブの実行状況とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記１または２に記載のバッチ処理システム。
（付記６）
前記第１のコンピュータが複数存在する
付記１乃至５の何れかに記載のバッチ処理システム。
（付記７）
バッチジョブを実行する第１のコンピュータと、前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置と、前記第１のコンピュータと前記記憶装置とに接続された第２のコンピュータとを有するバッチ処理システムが実行する制御方法であって、
前記第２のコンピュータが、前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出し、
前記第２のコンピュータが、前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択し、
前記第２のコンピュータが、前記選択した記録方法を前記第１のコンピュータに通知し、
前記第１のコンピュータが、前記第２のコンピュータから通知された前記記録方法を用いて、自コンピュータにおける前記バッチジョブの実行状態を前記記憶装置に記録する
バッチ処理システム制御方法。
（付記８）
前記複数の記録方法は、互いに前記記憶装置へのアクセス頻度が相違する
付記７に記載のバッチ処理システム制御方法。
（付記９）
前記第２のコンピュータにおける前記記録方法の選択では、前記検出した前記性能と前記第１のコンピュータで実行される前記バッチジョブの属性とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記７または８に記載のバッチ処理システム制御方法。
（付記１０）
前記第１のコンピュータが、自コンピュータにおける前記バッチジョブの実行状況を前記第２のコンピュータに通知し、
前記第２のコンピュータにおける前記記録方法を選択では、前記検出した前記性能と前記通知された前記バッチジョブの実行状況とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記７または８に記載のバッチ処理システム制御方法。
（付記１１）
前記第１のコンピュータが、自コンピュータにおける前記バッチジョブの実行状況を前記第２のコンピュータに通知し、
前記第２のコンピュータにおける前記記録方法を選択では、前記検出した前記性能と前記第１のコンピュータで実行される前記バッチジョブの属性と前記第１のコンピュータから通知される前記バッチジョブの実行状況とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記７または８に記載のバッチ処理システム制御方法。
（付記１２）
バッチジョブを実行する第１のコンピュータと前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置とに接続され、
前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出する検出手段と、
前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択する選択手段と、
前記選択された記録方法を前記第１のコンピュータに通知する通知手段と
を有するコンピュータ。
（付記１３）
前記複数の記録方法は、互いに前記記憶装置へのアクセス頻度が相違する
付記１２に記載のコンピュータ。
（付記１４）
さらに、前記第１のコンピュータで実行される前記バッチジョブの属性を記憶する属性記憶手段を有し、
前記選択手段は、前記検出した前記性能と前記属性記憶手段に記憶されている前記バッチジョブの属性とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記１２または１３に記載のコンピュータ。
（付記１５）
さらに、前記第１のコンピュータから通知される前記バッチジョブの実行状況を記憶する実行状況記憶手段を有し、
前記選択手段は、前記検出した前記性能と前記実行状況記憶手段に記憶されている前記バッチジョブの実行状況とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記１２または１３に記載のコンピュータ。
（付記１６）
さらに、前記第１のコンピュータで実行される前記バッチジョブの属性と前記第１のコンピュータから通知される前記バッチジョブの実行状況とを記憶する属性・実行状況記憶手段を有し、
前記選択手段は、前記検出した前記性能と前記属性・実行状況記憶手段に記憶されている前記バッチジョブの属性および前記バッチジョブの実行状況とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記１２または１３に記載のコンピュータ。
（付記１７）
バッチジョブを実行する第１のコンピュータと前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置とに接続されたコンピュータを、
前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出する検出手段と、
前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択する選択手段と、
前記選択された記録方法を前記第１のコンピュータに通知する通知手段と
して機能させるためのプログラム。
（付記１８）
前記複数の記録方法は、互いに前記記憶装置へのアクセス頻度が相違する
付記１７に記載のプログラム。
（付記１９）
前記選択手段は、前記検出した前記性能と前記第１のコンピュータで実行される前記バッチジョブの属性とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記１７または１８に記載のプログラム。
（付記２０）
さらに、前記第１のコンピュータから通知される前記バッチジョブの実行状況を記憶する実行状況記憶手段を有し、
前記選択手段は、前記検出した前記性能と前記第１のコンピュータから通知される前記バッチジョブの実行状況とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記１７または１８に記載のプログラム。
（付記２１）
さらに、前記第１のコンピュータで実行される前記バッチジョブの属性と前記第１のコンピュータから通知される前記バッチジョブの実行状況とを記憶する属性・実行状況記憶手段を有し、
前記選択手段は、前記検出した前記性能と前記第１のコンピュータで実行される前記バッチジョブの属性と前記第１のコンピュータから通知される前記バッチジョブの実行状況とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
付記１７または１８に記載のプログラム。

１１０…第１のコンピュータ
１１１…実行状態記録手段
１１２…実行状況通知手段
１２０…記憶装置
１３０…第２のコンピュータ
１３１…検出手段
１３２…選択手段
１３３…通知手段
１３４…属性記憶手段
１３５…実行状況記憶手段

Claims (9)

1. バッチジョブを実行する第１のコンピュータと、前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置と、前記第１のコンピュータと前記記憶装置とに接続された第２のコンピュータとを有し、
   前記第２のコンピュータは、
   前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出する検出手段と、
   前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択する選択手段と、
   前記選択された記録方法を前記第１のコンピュータに通知する通知手段と
   を有し、
   前記第１のコンピュータは、
   前記第２のコンピュータから通知された前記記録方法を用いて、自コンピュータにおける前記バッチジョブの実行状態を前記記憶装置に記録する実行状態記録手段
   を有する
   バッチ処理システム。
2. 前記複数の記録方法は、互いに前記記憶装置へのアクセス頻度が相違する
   請求項１に記載のバッチ処理システム。
3. バッチジョブを実行する第１のコンピュータと、前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置と、前記第１のコンピュータと前記記憶装置とに接続された第２のコンピュータとを有するバッチ処理システムが実行する制御方法であって、
   前記第２のコンピュータが、前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出し、
   前記第２のコンピュータが、前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択し、
   前記第２のコンピュータが、前記選択した記録方法を前記第１のコンピュータに通知し、
   前記第１のコンピュータが、前記第２のコンピュータから通知された前記記録方法を用いて、自コンピュータにおける前記バッチジョブの実行状態を前記記憶装置に記録する
   バッチ処理システム制御方法。
4. 前記複数の記録方法は、互いに前記記憶装置へのアクセス頻度が相違する
   請求項３に記載のバッチ処理システム制御方法。
5. バッチジョブを実行する第１のコンピュータと前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置とに接続され、
   前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出する検出手段と、
   前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択する選択手段と、
   前記選択された記録方法を前記第１のコンピュータに通知する通知手段と
   を有するコンピュータ。
6. 前記複数の記録方法は、互いに前記記憶装置へのアクセス頻度が相違する
   請求項５に記載のコンピュータ。
7. さらに、前記第１のコンピュータで実行される前記バッチジョブの属性を記憶する属性記憶手段を有し、
   前記選択手段は、前記検出した前記性能と前記属性記憶手段に記憶されている前記バッチジョブの属性とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
   請求項５または６に記載のコンピュータ。
8. さらに、前記第１のコンピュータから通知される前記バッチジョブの実行状況を記憶する実行状況記憶手段を有し、
   前記選択手段は、前記検出した前記性能と前記実行状況記憶手段に記憶されている前記バッチジョブの実行状況とに応じて、前記第１のコンピュータ毎に前記記録方法を選択する
   請求項５または６に記載のコンピュータ。
9. バッチジョブを実行する第１のコンピュータと前記第１のコンピュータにおける前記バッチジョブの実行状態を記録する記憶装置とに接続されたコンピュータを、
   前記バッチジョブの実行状態を前記記憶装置に記録する処理の性能を検出する検出手段と、
   前記検出した前記性能に応じて、前記記憶装置への前記バッチジョブの実行状態を記録する複数種類の記録方法の中から、前記第１のコンピュータで使用する記録方法を選択する選択手段と、
   前記選択された記録方法を前記第１のコンピュータに通知する通知手段と
   して機能させるためのプログラム。

Images