JPH07302242A - 負荷分散方式 - Google Patents

Abstract

(57)【要約】 【目的】 ネットワ−ク上に接続されたクライアントと
サ−バの間でトランザクション処理を行うオンライント
ランザクション処理システムにおいて，負荷情報やその
通信量を減らし，トランザクションの処理を効率化，高
速化し，システム全体としての処理効率を向上させる負
荷分散を行うことを目的とする． 【構成】 従来のクライアントサ−バ−モデルのクライ
アントまたはサ−バに付加機能を加えたものから構成さ
れるシステムまたはそのシステムと負荷分散のためのマ
ネ−ジャから構成されるシステム．

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、ネットワーク上に接
続された業務クライアントと業務サーバの間でトランザ
クション処理を行うオンライントランザクション処理シ
ステムにおける、負荷分散方式に関するものである。

【０００２】

【従来の技術】本発明の第１，第２の発明に最も近い公
知例として、特開昭６２−２７９４３３公報記載の「動
的タスク変更方式」がある。

【０００３】従来のオンライントランザクション処理シ
ステムにおいて、負荷の変化を監視し、その変化に計算
機資源の状態を追従させて性能向上を図る方法として
は、図５３に示すような方式が提案されている。この図
は特開昭６２−２７９４３３公報記載の発明の実施例の
ブロック図であり、図において４５０１はトランザクシ
ョン処理システム、４５０２は端末、４５０３はデータ
ベース、４５１１はトランザクション監視手段、４５１
２はタスク数変更判定手段、４５１３はタスク数変更手
段、４５１４はトランザクション負荷情報格納領域、４
５１５はタスク数判定テーブル、４５１６ａ，４５１６
ｂ，４５１６ｃは例としてのタスクである。トランザク
ション処理管理部４５１０は、トランザクション監視手
段４５１１、タスク数変更判定手段４５１２、タスク数
変更手段４５１３、トランザクション負荷情報格納領域
４５１４、タスク数判定テーブル４５１５から構成され
る。

【０００４】従来の負荷分散方式は、上記のように構成
されているので、トランザクション監視手段４５１１が
トランザクションの負荷を監視してトランザクション負
荷情報格納領域４５１４に格納し、タスク数変更判定手
段４５１２は、その格納された負荷に基づき、必要なタ
スク数をタスク数判定テーブル４５１５の内容を参照し
て取得し、この取得したタスク数と現在のタスク数との
比較によりタスク数を変更する必要の有無を判定して、
タスク４５１６ａ，４５１６ｂ，４５１６ｃの数を増減
する。端末４５０２から要求のあったトランザクション
を処理する場合には、トランザクション処理管理部４５
１０が、タスク４５１６ａ〜４５１６ｃに空きがあるか
どうかを判断し、空きがなければそのトランザクション
を待ち状態とし、空きがあれば空いているタスクにその
トランザクション処理を行うよう指示する。

【０００５】本発明の第１，第２の発明に対する従来の
負荷分散方式は、上記のように処理を行うので、入力と
なるトランザクションが増大した場合には、その要求を
複数のタスク、すなわち業務サーバプロセスで処理する
ための振り分け処理が必要となり、その振り分け処理に
よるオーバーヘッドがシステム全体としての処理効率を
低下させるという問題点があった。

【０００６】入力となるトランザクションの処理が多い
ときにも、その要求を複数の業務サーバプロセスで処理
するための振り分け処理を不要にするための改良された
負荷分散方式が必要である。

【０００７】本発明の第３，４，５の発明に最も近い公
知例として、日経エレクトロニクス１９９３．１２．２
０、ｐ．１４３〜１５４記載の「タスクブローカ」があ
る。

【０００８】従来の負荷分散方式としては、図５４に示
すような方式が提案されている。この図は日経エレクト
ロニクス１９９３．１２．２０、ｐ．１４３〜１５４記
載の「タスクブローカ」記載の実施例を示す図であり、
図において１はクライアント計算機、２はサーバ計算
機、４６０５はクライアント計算機１内で、サーバプロ
グラムに処理を要求するクライアントプログラム、４６
０６はクライアント内で、最適なサーバプログラムを探
索するための手段を提供するタスクブローカ・クライア
ントデーモン、４６０７〜４６０９は各サーバ計算機内
でクライアントが要求する処理を提供可能なサーバプロ
グラム、４６１０〜４６１２は各サーバ計算機内でサー
バプログラムの負荷などを監視してクライアントプログ
ラムからの要求を受諾できる度合いを評価する処理受諾
度評価部である。

【０００９】従来の負荷分散方式は、上記のように構成
されているので、クライアントプログラム４６０５が処
理要求を行う際に、その要求内容をタスクブローカ・ク
ライアントデーモン４６０６に提出し、タスクブローカ
・クライアントデーモン４６０６は各サーバ２ａ〜２ｃ
に対してその要求内容に対する処理受諾度を評価するよ
う要求する。各サーバ内の処理受諾度評価部４６１０〜
４６１２は、計算機の負荷、サーバプログラムに滞留し
ている他のクライアントプログラムからの要求数などに
応じて、要求された処理を受諾できる度合い、すなわち
処理受諾度を評価して、タスクブローカ・クライアント
デーモン４６０６にその処理受諾度とサーバ計算機のア
ドレスを返す。タスクブローカ・クライアントデーモン
４６０６は、最も高い処理受諾度を返したサーバを選択
して、そのサーバのアドレスにクライアントプログラム
４６０５からの処理要求を転送する。

【００１０】本発明の第３，４の発明に対する従来の負
荷分散方式は、上記のように処理を行うので、負荷情報
を収集したり、サーバに処理受諾度を問い合わせるため
の処理のオーバーヘッドがかえってシステム全体として
の処理効率を低下させるという問題点があった。さら
に、サーバの負荷情報はわかるものの、ネットワークの
負荷情報を得る手段がなかったため、結果として最適な
サーバを選択することにつながらないことがあった。

【００１１】負荷情報を収集したり、負荷情報を問い合
わせるための処理に関する無駄を抑制するための改良さ
れた負荷分散方式が必要である。

【００１２】本発明の第５の発明に対する従来の負荷分
散方式は、上記のように処理を行うので、同じ処理を依
頼するクライアントが多数存在した場合にも、それぞれ
のクライアントが同じような問い合わせをサーバに行う
という無駄があった。

【００１３】同じ処理を依頼するクライアントが多数存
在した場合にも、それぞれのクライアントが同じような
問い合わせをサーバに行うという無駄を抑制するための
改良された負荷分散方式が必要である。

【００１４】本発明の第６および７の発明に関する従来
例として、オンライントランザクション処理システムに
おける従来の負荷分散処理技術では、特開昭５８−１９
９６０のような負荷分散システムにおける縮退運転方式
が提案されている。図５５はこの方式におけるシステム
構成を示し、図において，４７０１ａ，４７０１ｂは演
算装置、４７０２ａ，４７０２ｂは記憶装置である。演
算装置１ ４７０１ａには機能Ａが、演算装置２ ４７
０１ｂには機能Ｂが配置され、更に演算装置１４７０１
ａには機能Ｂの一部機能を有する簡易サーバ機能Ｂ’
が、演算装置２４７０１ｂには機能Ａの一部機能を有す
る簡易サーバ機能Ａ’が配置されている。なお，図５５
は本発明に係わる部分のみを表示している．

【００１５】この様な構成で，平常運転時は，演算装置
１ ４７０１ａでは機能Ａと簡易サ−バ機能Ｂ’が動作
する．同様に，演算装置２ ４７０１ｂでは機能Ｂ，サ
−バ機能Ａ’が動作する．何れの場合も，平常運転時は
機能Ａ，Ｂが処理をするので，簡易サ−バ機能Ａ’，
Ｂ’は記憶装置へのアクセスはしない．いま，演算装置
１ ４７０１ａがダウンすればシステムは自動的に縮退
運転に入り，演算装置２４７０１ｂの簡易サ−バ機能
Ａ’がバックアップに入り，記憶装置へのアクセスも行
う．演算装置１ ４７０１ａ が復旧したら機能Ａがそ
の上で動作し平常運転に戻る．逆に，演算装置２ ４７
０１ｂがダウンした場合は，同じ様に，演算装置１の簡
易サ−バ機能Ｂ’がバックアップする縮退運転に入り，
記憶装置へのアクセスも行う．演算装置２ ４７０１ｂ
が復旧したら平常運転に戻る．

【００１６】本発明に対する従来の負荷分散方式は、多
くのマネージメント・サービスから構成され、実行時に
は非常に多くのメモリ領域を必要とする。サーバは、マ
ルチ・クライアント対応で、かつシステム障害時の代替
作業を行うことを考慮し、同機能サーバもしくは簡易サ
ーバを用意している。しかし、これはサーバの過負荷状
態時には、メモリ中のスワップ領域が不足してしまいシ
ステム障害を起こすという問題があった。

【００１７】システム上のサーバ稼働状況を管理するこ
とにより、ハードウェア・ネックによるシステム障害の
防止と、システムの安定した負荷管理を図る負荷分散方
式が必要である。

【００１８】従来のシステムは、クライアントからの処
理を受け付ける簡易サーバを他のサーバ上に用意するこ
とによって、演算処理装置のいずれかに障害が生じた場
合、障害の起こらない演算装置に配置されている簡易サ
ーバが、障害から復旧するまで処理を代行するという手
段をとっている。しかし、この方法では、障害を未然に
防止するための技術については考慮されていないという
問題がある。

【００１９】処理作業を分担している分散型オンライン
・トランザクション処理システムにおいて、前記のよう
に，ある演算処理装置に障害が発生した場合は、その装
置上で動作していたサーバの簡易サーバを別の装置上に
用意することによって、復旧するまでの一時的な救済処
置は行える。しかし、障害原因によっては復旧に長時間
を要する場合もあり、簡易サーバの処理では業務を継続
して遂行するには問題となる。

【００２０】サーバの一部機能を有する代行サーバの使
用によって、システム障害の防止とサーバの負荷の軽減
を行い、かつ処理効率を向上することを図る負荷分散方
式が必要である。

【００２１】本発明の第８の発明に関する従来の負荷分
散方式としては、「特開昭６３−７５８６８」や「特開
平２−９３８３６」にあるような方式が提案されてい
る。

【００２２】図５６は、従来のこの種の負荷分散方式の
構成を示すもので、業務クライアント１と業務サーバ２
ａ，２ｂ、負荷監視マネージャ４８０３が伝送路４８０
４によって接続されている。業務サーバ２ａ，２ｂは、
トランザクション要求と応答を送受信するトランザクシ
ョン要求送受信部４８０５と、トランザクション要求を
処理するトランザクション処理部４８０６と、業務サー
バの負荷を検出する負荷検出部４８０７と、負荷監視マ
ネージャに業務サーバの負荷を報告する負荷報告部４８
０８を備え、負荷監視マネージャ４８０３は、業務サー
バ２ａ，２ｂから業務サーバの負荷を収集するサーバ負
荷検出部４８０９と、サーバの負荷情報を基に業務サー
バ２からのトランザクション要求を負荷の少ない業務サ
ーバ２に割り振るトランザクション要求分配部４８１０
を備えている。

【００２３】負荷監視マネージャ４８０３は、業務クラ
イアント１からのトランザクション要求が特定の業務サ
ーバ２に集中しないように、業務サーバの負荷を監視
し、業務クライアント１からのトランザクション要求を
適切な業務サーバ２に割り振っている。

【００２４】しかし、従来の方式では、一箇所の負荷監
視マネージャ４８０３にクライアントのトランザクショ
ン要求が集中した場合、負荷監視マネージャ４８０３の
処理が分散処理システムのボトルネックになるという問
題がある。また、負荷監視マネージャ４８０３の為に、
ポーリングやイベントによる監視のための通信が必要で
あり、監視トラフィックが増大するという問題点があ
る。

【００２５】業務クライアントが、トランザクションを
処理するサーバ候補をトランザクション要求に添付し、
サーバ候補間でトランザクションを一回り回覧し、回覧
リストの最後のサーバが最も負荷の低いサーバにトラン
ザクションの処理を依頼することによって、負荷監視マ
ネージャ４８０３および負荷監視の為の通信を不要にし
て通信トラフィックの減少を計ることが必要である。

【００２６】本発明の第９の発明に関する従来の負荷分
散方式としては、「特開平１−２６７７６５」にある方
式が提案されている。

【００２７】図５７は、従来のこの種の負荷分散方式を
示すもので、伝送路上４９０１に接続される一つのネッ
トワーク管理計算機，負荷監視マネ−ジャ４９０２と複
数の分散処理計算機，業務サ−バ２ａ，２ｂ，・・・か
ら構成される。

【００２８】各分散処理計算機，業務サ−バ２ａ，２
ｂ，・・・により自己の処理負荷率をモニタリングしつ
つ負荷が設定値，閾値以上となった時にネットワーク管
理計算機，負荷監視マネ−ジャ４９０２に対して分散処
理要求を発するようにし、これを受ける上記ネットワー
ク管理計算機，負荷監視マネ−ジャ４９０２はネットワ
ークを介して接続されている負荷の低い他の分散処理計
算機，業務サ−バ２を選択して分散処理命令を発してい
た。

【００２９】しかし、従来の方法では、分散処理計算
機，業務サ−バ２がその処理負荷の閾値を越えてからネ
ットワーク管理計算機，負荷監視マネ−ジャ４９０２に
高負荷を報告し処理を他の分散処理計算機，業務サ−バ
２に依頼するため、高負荷になってから処理を他の分散
処理計算機，業務サ−バ２に依頼するまでの間、高負荷
の状態が持続するという問題点がある。

【００３０】単位時間当たりの処理負荷の増減傾向を用
い、処理負荷の増加傾向から、一定時間後に閾値を越え
ると予測される場合は、当該分散処理計算機，業務サ−
バ２の負荷が高いと判断し、逆に処理負荷の減少傾向か
ら、一定時間後に閾値内に入ると予想される場合は、当
該分散処理計算機，業務サ−バ２の負荷が通常と判断す
ることによって、複数の分散処理計算機，業務サ−バ２
の処理効率を高めることが必要である。

【００３１】本発明の第１０，１１の発明に関する従来
の負荷分散方式としては、「特開平１−２６７７６５」
にある方式が提案されている。

【００３２】図５８は、従来のこの種の負荷分散方式の
構成を示すもので、伝送路５００１上に接続される一つ
の負荷マネージャ５００２と複数の業務サーバ２ａ，２
ｂ，・・・から構成される。

【００３３】負荷監視マネージャ５００２は、各業務サ
ーバ２ａ，２ｂ，・・・に対して一定の時間間隔でポー
リングを行うことによって、或いは業務サーバ２ａ，２
ｂ，・・・から負荷監視マネージャ５００２に負荷増大
の警報を通知することによって、業務サーバ２ａ，２
ｂ，・・・の負荷を検出していた。

【００３４】しかし、従来の方法では、負荷監視マネー
ジャから各業務サーバ２ａ，２ｂ，に対する最適なポー
リング間隔を設定することが難しい上に、管理される業
務サーバが増大した時やポーリング間隔が短い時には、
管理オーバヘッドが増大するという問題点があった。ま
た，この様な技術において発生する問題点に対して，業
務クライアント（図示なし）は負荷監視マネージャ５０
０２に監視機能を委ね，専ら処理の依頼をするのみであ
り，問題解決に働かなかった．

【００３５】サーバに対しては、マネージャからポーリ
ングベースでサーバの負荷状況を監視し、クライアント
からマネージャに対して、サーバの処理速度劣化をイベ
ントベースで報告させ、負荷監視をサーバとクライアン
トの両面から行うことによって、レスポンス性能向上な
どサービスの品質を向上し、さらにクライアントとサー
バ間のネットワークの障害も検出することが必要であ
る。

【００３６】本発明の第１２，１３の発明に関する従来
の負荷分散方式としては、特開平４−３４６４０号公報
の方法が提案されている。その構成を図５９に示す。５
１０１はマネージャ、２は業務サーバ、１は業務クライ
アントで構成される。業務クライアント１と業務サーバ
２は複数存在することができるが、マネージャ５１０１
は１つのみ存在する。

【００３７】次に動作について説明する。マネージャ５
１０１は常時、業務サーバ２の負荷情報を収集してい
る。業務クライアント１はどの業務サーバ２に処理を要
求するか決定するためにマネージャ５１０１にアクセス
する。マネージャ５１０１は、収集した負荷情報を用い
て業務クライアント１がどの業務サーバ２にアクセスさ
せるかを決定し業務クライアント１に通知する。業務ク
ライアント１は決定した業務サーバ２に処理を要求す
る。業務サ−バ２は処理を行う。

【００３８】本発明の従来の負荷分散方式は、上記のよ
うに処理を行うので、常に負荷情報を収集しなければな
らないので、マネージャ５１０１や業務サーバ２に負荷
がかかり、またトラフィック量も大きくなってしまう問
題があった。

【００３９】常に負荷情報を収集しなければならないの
で、マネージャや業務サーバに負荷がかかり、またトラ
フィック量も大きくなってしまう問題があったことは前
記の通りであるが，これに加えて，マネージャは必ずど
れかの業務サーバ名を業務クライアントに返すので、す
べての業務サーバが負荷が高いときも業務サーバを割り
振ってしまう。そのため、すべての業務サーバが高負荷
のためダウンする可能性があるという問題点があった。

【００４０】従来のものよりマネージャや業務サーバに
負荷とトラフィック量も減らし、負荷を分散することが
必要である。

【００４１】換言すれば，従来のものよりマネージャや
業務サーバに負荷とトラフィック量も減らすことと、業
務サーバの負荷が高い時業務クライアントの業務サーバ
へのアクセスを減らし負荷分散を行うことが必要であ
る。

【００４２】本発明の第１４の発明に関する従来の負荷
分散方式としては、株式会社ソフト・リサーチ・センタ
ー発行の「ＴＣＰ／ＩＰ〜ネットワーク・プロトコルと
インプリメント〜」の１２９ページに記載されているよ
うに、ＴＣＰの帯域外通信が上げられる。この方法は緊
急なデータを通常のソケットの送信待ち行列に入れない
で即座に送信するものである。即ち，送信側ユ−ザが受
信側に緊急に処理して貰いたいデ−タがある場合にＴＣ
Ｐに対して送信要求を行う際に緊急デ−タであることを
知らせる．送信側ＴＣＰはそれを受け取ると，ユ−ザが
指定した緊急デ−タのセグメント内での終了位置を示す
ポインタ（Ｕｒｇｅｎｔポインタ）と，緊急情報である
ことを示すＵｒｇｅｎｔ ｆｌａｇをヘッダ内につけて
送信する．受信側ＴＣＰはそのセグメントを受信する
と，Ｕｒｇｅｎｔポインタで指定されているデ−タを即
座に受信ユ−ザに知らせる．

【００４３】本発明の第１４の発明に関する従来の負荷
分散方式は、上記のように処理を行うので、緊急データ
に複数のランクづけがなされていないため緊急度の度合
いによる送信量の調節ができないという問題点があっ
た。

【００４４】緊急度に応じてデータを選択でき、緊急度
の高いデータが少ない場合は、より緊急度の低いデータ
さえも出力できることが必要である。

【００４５】本発明の第１５，１６，１７の発明に関す
る従来の負荷分散方式としては，日経オ−プンシステム
１９９２年１０月創刊前特別１号の６４ページから６５
ページに掲載されている方法がある。その構成を図６０
に示す。１は業務クライアント、２ａ，２ｂは業務サー
バ、５２０３はデータベースである。ただし業務クライ
アント１と業務サーバ２は複数存在することができるが
データベースは一つである。次に動作について説明す
る。業務クライアント１は業務サーバ（２ａまたは２
ｂ）にアクセスする。業務サーバ（２ａまたは２ｂ）は
データベース５２０３のデータを使用し業務クライアン
ト１に要求された処理を行う。

【００４６】本発明の第１５，１６，１７の発明に関す
る従来の負荷分散方式は、上記のように処理を行うの
で、記憶場所であるたった一つのデータベース５２０３
にすべての業務サーバ２がアクセスする。そのためデー
タベース５２０３への通信が集中する問題点があった。
また、データベース５２０３の性能が悪いと業務サーバ
２の動作が止まってしまい業務サーバ２を有効に負荷分
散できなくなる問題点があった。 このため，従来の
ものより業務サーバの負荷を分散し、トラフィック量も
減らすことが必要である。

【００４７】

【発明が解決しようとする課題】従来の技術は以上の様
に構成されているので，トランザクションが多くなると
負荷分散制御，処理の過負荷により，負荷分散システム
に障害が発生するという問題があった．

【００４８】本発明はこのような課題を解決するための
ものであり，トランザクションが増大し，負荷分散制
御，処理等の負荷が増大しても負荷分散システムに障害
を及ぼさない負荷分散方式を提供することを目的とす
る．

【００４９】

【課題を解決するための手段】この発明の第１の発明に
係わる負荷分散方式では，トランザクションの負荷を監
視する負荷監視手段と、該負荷監視手段が監視した結果
を基にして業務サーバプロセスの数を決める業務サーバ
プロセス数変更手段と、該業務サ−バプロセス数変更手
段の該制御に基いて各業務サーバプロセスが処理要求を
受け付けるべき業務クライアントを決定する業務クライ
アント決定手段と、各業務サーバプロセスが処理要求を
受け付ける業務クライアントを管理する業務クライアン
ト管理テーブルとを設けたものである。

【００５０】この発明の第２の発明に係わる負荷分散方
式では，トランザクションの負荷を監視する負荷監視手
段と、該負荷監視手段が監視した結果を基にして業務サ
ーバプロセスの数を決める業務サーバプロセス数変更手
段と、該業務サ−バプロセス数変更手段の該制御に基い
て各業務サーバプロセスが処理をするデ−タを決定する
管理デ−タ決定手段と、各業務サーバプロセスが処理の
対象とするデ−タを管理するデ−タ管理テーブルとを設
けたものである。

【００５１】この発明の第３の発明に係わる負荷分散方
式では，業務クライアントの処理依頼の送信から処理結
果の受信までの間の任意の処理の任意の時点の時刻を刻
印する時刻刻印手段と，該時刻刻印手段が打刻した該任
意の処理の内，指定した処理の指定した時点の時刻から
指定した処理の指定時点間の所要時間を算出する所要時
間算出手段と，を備えたものである．

【００５２】この発明の第４の発明に係わる負荷分散方
式では，業務クライアントからの依頼データを業務サ−
バが受信したデータ受信時刻を刻印するデータ受信時刻
刻印手段と、業務サーバプロセスにおいてトランザクシ
ョン処理の開始時刻と該処理終了時刻とを刻印するトラ
ンザクション処理開始終了時刻刻印手段と，該処理結果
を返信した時刻を刻印する返信時刻刻印手段と，業務ク
ライアントが該処理結果を受信した時刻を刻印する処理
結果刻印手段と，これらの任意の時刻から所要時間を算
出する所要時間算出手段を備えたものである。

【００５３】この発明の第５の発明に係わる負荷分散方
式では，各業務サーバの処理内容とそのネットワーク上
のアドレスの対応表を保持している名前サーバと、名前
サーバにおいて問い合わせのあった処理を提供している
業務サーバのアドレスを応答として返信するサーバアド
レス応答データ送信手段と、該サーバアドレス応答デ−
タ送信手段において該返信する業務サ−バのアドレスを
複数の業務クライアントに対して放送通信する放送通信
手段と，を備えたものである。

【００５４】この発明の第６の発明に係わる負荷分散方
式では，業務サ−バは，使用メモリ容量の閾値を保持
し，プロセスのメモリ占有量が閾値を超過したらプロセ
スを退避させて縮退運転に移り，プロセスがメモリを開
放してメモリの占有量が該閾値を下回ったら退避した該
プロセスを復旧させて平常運転に移る制御を行う制御部
を備えるものである。

【００５５】この発明の第７の発明に係わる負荷分散方
式では，業務サ−バは，負荷の閾値を保持し，トランザ
クションの処理負荷が該閾値を超過したらトランザクシ
ョンを処理していた業務サーバプロセスを退避し，その
処理機能を代行する代行業務サーバプロセスを生成して
縮退運転に移り，業務サ−バプロセスが処理を終了して
実行待ちになり，負荷が該閾値を下回れば，該代行業務
サ−バプロセスを消去して前記の退避した業務サ−バプ
ロセスを復旧する制御を行う制御部を備えるものであ
る．

【００５６】この発明の第８の発明に係わる負荷分散方
式では，トランザクションの処理要求をできる業務サー
バに回覧し要求を処理する業務サ−バを決めるためのト
ランザクション回覧を作成するトランザクション回覧発
生部とトランザクション処理要求にそのトランザクショ
ン回覧を添付して送信するトランザクション要求送受信
部を設けた業務クライアントと、それらのトランザクシ
ョン要求とトランザクション回覧を送受信する送受信部
と自業務サ−バの処理負荷を検出するサーバ負荷検出部
と回覧リストを解析し負荷検出部の処理負荷を回覧リス
トに記入し該送受信部により最も処理負荷の低い業務サ
ーバにトランザクション処理要求を回覧する処理負荷ト
ランザクション回覧手段を設けた業務サ−バと，を備え
るものである。

【００５７】この発明の第９の発明に係わる負荷分散方
式では，業務サ−バは業務サーバの処理負荷閾値を記憶
する負荷閾値記憶手段と、業務サーバの処理負荷を検出
する処理負荷検出手段と、業務サーバの時系列的な処理
負荷履歴を記憶する負荷履歴記憶手段と、業務サーバの
処理負荷履歴から処理負荷を予測する負荷傾向検出手段
と、負荷傾向検出手段が算出した処理負荷の予測値と負
荷閾値記憶手段に格納された負荷閾値からトランザクシ
ョン要求を当該業務サーバで行うかどうかを判定する業
務判定手段を備えるものである。

【００５８】この発明の第１０の発明に係わる負荷分散
方式では，業務クライアントはトランザクション処理要
求を発行してから処理結果を受信するまでの最大待ち時
間の閾値を記憶するトランザクション処理閾時間記憶手
段と，トランザクション処理要求を発行して処理結果を
受信するまでの経過時間を計測して前記の閾値と比較
し，経過時間が閾値を超過したら任意の指定処理をする
トランザクション処理時間検出手段と，を備えたもので
ある．

【００５９】この発明の第１１の発明に係わる負荷分散
方式では，業務クライアントはトランザクション要求を
発行してから処理結果を受信するまでの最大待ち時間を
閾値として記憶するトランザクション処理閾時間記憶手
段と、トランザクション毎の処理要求発行の時点から処
理結果を受信するまでの経過時間を計測し該経過時間と
前記の閾値との比較を行い、該経過時間が前記の閾値よ
りも大きいときには負荷監視マネージャに警報を発行す
るトランザクション処理時間検出手段とを備えている．
業務サーバは負荷監視マネージャからの負荷の照会を受
信しそれに応答する管理要求送受信手段を備えている．
そして，負荷監視マネージャは、業務クライアントから
の前記の警報または業務サ−バに対して同業務サ−バの
負荷に応じて加減された間隔でなされる前記の負荷の照
会に対する回答などによりトランザクション処理システ
ムの異常部分を検出するクライアント・サーバ統括管理
手段を備えるものである。

【００６０】この発明の第１２の発明に係わる負荷分散
方式では，業務サ−バプロセスは業務サ−バプロセスの
負荷を把握し高負荷になれば該業務サ−バプロセスの作
成をマネ−ジャに要求する負荷監視部と、マネ−ジャか
ら受けた業務サ−バプロセスの条件を満たせば該業務サ
ーバプロセスの自己消去を行う自己消去部とを備えてい
る．マネ−ジャは業務サ−バプロセスを起動するサ−バ
起動部と，業務サ−バプロセスの条件を保存し，業務ク
ライアントまたは該負荷監視部からの要求に基いて業務
サ−バプロセスの条件を付し，サ−バ起動部を介して該
業務サ−バプロセスを起動するサーバ振り分け処理部と
を備えるものである。

【００６１】この発明の第１３の発明に係わる負荷分散
方式では，業務サ−バは業務サーバの負荷状態を知る負
荷監視部と、業務クライアントのアクセス優先順位を制
御する情報と該負荷監視部の情報により業務クライアン
トへアクセス権を付与するアクセス権付与決定部とを備
えるものである。

【００６２】この発明の第１４の発明に係わる負荷分散
方式では，データ量制御装置は，データを入力する入力
手段、処理条件の設定変更削除の情報を入出力する管理
情報入出力手段，該管理情報入出力手段の設定した条件
により該入力手段からの入力データの重要度を識別し絶
対出力デ−タと任意出力デ−タに分類する重要度識別手
段、前記の絶対出力デ−タの時間あたりの数をカウント
するカウント手段、前記カウント手段の時間当りの絶対
出力デ−タの数と該管理情報入出力手段の設定条件に基
き前記任意出力データを取捨選択する取捨選択手段、出
力データを出力する出力手段、とを備える。

【００６３】この発明の第１５の発明に係わる負荷分散
方式では，時刻を取得する時刻取得部と、データを記憶
する記憶部と、他の業務サ−バからのデ−タを該記憶部
に格納し，該時刻取得部の時刻が所定のデ−タ移動時刻
になれば該記憶部のデータを他の業務サ−バに移動する
データ移動処理部と、業務クライアントの要求の処理を
行うクライアント要求処理部とを設けた業務サ−バを備
えるものである。

【００６４】この発明の第１６の発明に係わる負荷分散
方式では，業務サ−バは上位業務サ−バと下位業務サ−
バよりなっている．下位業務サ−バは時刻を取得する時
刻取得部と、データを記憶する下位記憶部と、上位業務
サ−バからのデ−タを該下位記憶部に格納し，該時刻取
得部の時刻が上位業務サ−バの指定のデ−タ移動時刻に
なれば該下位記憶部のデータを上部業務サ−バに移動す
るデータ移動処理部と、業務クライアントのデ−タに係
わる要求の処理を行うクライアント要求処理部とを備え
ている．そして，上位業務サ−バはデータを記憶する上
位記憶部、データの移動時刻を指定して該上位記憶部か
ら該下位記憶部への移動処理及び該指定移動時刻になれ
ば該下位記憶部からのデ−タを上位記憶部に保存するデ
ータ移動処理部と、業務クライアントの要求の処理を行
う上部クライアント要求処理部とを備える。

【００６５】この発明の第１７の発明に係わる負荷分散
方式では，業務サ−バは，業務クライアントのデ−タに
係わる処理要求に対して自記憶部のデ−タで対応出来な
いときは，他の業務サ−バのデ−タを使用して該業務ク
ライアントの要求を処理する分散トランザクション処理
を行うクライアント要求処理部を備えるものである．

【００６６】

【作用】この発明の第１の発明における負荷分散方式で
は，負荷監視手段はトランザクション負荷を監視し、負
荷の大小により業務サーバプロセス数変更手段は業務サ
ーバプロセスの数を決める．該業務サ−バプロセス数変
更手段の決めたプロセスの数に基いて，業務クライアン
ト決定手段は各業務サーバプロセスが処理要求を受け付
けるべき業務クライアントを決定し，それらを管理する
業務クライアント管理テーブルに保存する。

【００６７】この発明の第２の発明における負荷分散方
式では，負荷監視手段はトランザクション負荷を監視
し、負荷の大小により業務サーバプロセス数変更手段は
業務サーバプロセスの数を決める．該業務サ−バプロセ
ス数変更手段の決めたプロセスの数に基いて，管理デ−
タ決定手段は各業務サーバプロセスが処理の対象とする
デ−タを決定し，それらを管理するデ−タ管理テーブル
に保存する。

【００６８】本発明の第３の発明においては、時刻刻印
手段は業務クライアントの処理依頼の送信から処理結果
の受信までの間の任意の処理の任意の時点の時刻を刻印
し，所要時間算出手段は該時刻刻印手段が打刻した該任
意の処理の内，指定した処理の指定した時点から指定し
た処理の指定時点間の所要時間を算出する．

【００６９】本発明の第４の発明においては、データ受
信時刻刻印手段は業務クライアントからの依頼データを
業務サ−バが受信したデータ受信時刻を刻印し、トラン
ザクション処理開始終了時刻刻印手段は業務サーバプロ
セスのトランザクション処理の開始時刻と該処理終了時
刻とを刻印し，返信時刻刻印手段は該処理結果を返信し
た時刻を刻印し，処理結果刻印手段は業務クライアント
が該処理結果を受信した時刻を刻印し，所要時間算出手
段はこれらの任意の時刻から指定の所要時間を算出す
る。

【００７０】本発明の第５の発明において、名前サーバ
は各業務サーバの処理内容とそのネットワーク上のアド
レスの対応表を保持している．名前サーバにおいて問い
合わせのあった処理を提供している業務サーバのアドレ
スをサーバアドレス応答データ送信手段は応答として返
信するが、放送通信手段はこのとき，その返信する業務
サ−バのアドレスを複数の業務クライアントに対して放
送通信する．

【００７１】この発明の第６の発明において，業務サ−
バの制御部は，使用メモリ容量の閾値を保持し，プロセ
スのメモリ占有量が閾値を超過したらプロセスを退避さ
せて縮退運転に移り，プロセスがメモリを開放してメモ
リの占有量が該閾値を下回ったら退避した該プロセスを
復旧させて平常運転に移る制御を行う。

【００７２】本発明の第７の発明においては、業務サ−
バの制御部は，負荷の閾値を保持し，トランザクション
の処理負荷が該閾値を超過したらトランザクションを処
理していた業務サーバプロセスを退避し，その処理機能
を代行する代行業務サーバプロセスを生成して縮退運転
に移り，業務サ−バプロセスが処理を終了して実行待ち
になり，負荷が該閾値を下回れば，該代行業務サ−バプ
ロセスを消去して前記の退避した業務サ−バプロセスを
復旧する制御を行う．

【００７３】本発明の第８の発明においては、業務クラ
イアントでは，トランザクション回覧発生部はトランザ
クションの処理要求をできる業務サーバに回覧し要求を
処理する業務サ−バを決めるためのトランザクション回
覧を作成し，トランザクション要求送受信部はトランザ
クション処理要求にそのトランザクション回覧を添付し
て送信する．一方，業務サ−バでは，送受信部はそれら
のトランザクション要求とトランザクション回覧を送受
信し，負荷検出部は自業務サーバの処理負荷を検出し，
処理負荷トランザクション回覧手段は回覧リストを解析
し自業務サーバの負荷検出部の処理負荷を回覧リストに
記入し該送受信部により最も処理負荷の低い業務サーバ
にトランザクション処理要求を回覧する。

【００７４】本発明の第９の発明においては、業務サ−
バでは，負荷閾値記憶手段は業務サーバの処理負荷閾値
を記憶し，処理負荷検出手段は業務サ−バの処理負荷を
検出し、負荷履歴記憶手段は処理負荷検出手段から負荷
を得て時系列的な同処理負荷履歴を記憶し、負荷傾向検
出手段は業務サーバの処理負荷履歴から処理負荷傾向を
検出し予測値を算出する．そして，業務判定手段は負荷
傾向検出手段が算出した処理負荷の予測値と負荷閾値記
憶手段に格納された負荷閾値との比較により発生したト
ランザクション要求を当該業務サーバで行うかどうかを
判定する。

【００７５】本発明の第１０の発明においては，業務ク
ライアントでは，トランザクション処理閾時間記憶手段
はトランザクション処理要求を発行してから処理結果を
受信するまでの最大待ち時間の閾値を記憶し，トランザ
クション処理時間検出手段はトランザクション処理要求
を発行して処理結果を受信するまでの経過時間を計測し
て前記の閾値と比較し，閾値を超過したら任意の指定処
理をする．

【００７６】本発明の第１１の発明においては、業務ク
ライアントでは，トランザクション処理閾時間記憶手段
はトランザクション要求を発行してから処理結果を受信
するまでの最大待ち時間を閾値として記憶る．そして，
トランザクション処理時間検出手段はトランザクション
毎の処理要求発行の時点から処理結果を受信するまでの
経過時間を計測しており，その経過時間と前記の閾値と
の比較を行い、該経過時間が前記の閾値を超過したとき
には負荷監視マネージャに警報を発行する．一方，業務
サーバでは，管理要求送受信手段は負荷監視マネージャ
からの負荷の照会を受信しそれに応答する．そして，負
荷監視マネージャでは、クライアント・サーバ統括管理
手段は業務サ−バに対して同業務サ−バの負荷に応じて
加減した間隔でなされる前記の負荷の照会に対する回答
あるいは業務クライアントからの前記の警報などにより
トランザクション処理システムの異常部分を検出する．

【００７７】この発明の第１２の発明においては，業務
サ−バプロセスでは負荷監視部は業務サ−バプロセスの
負荷を把握し高負荷になれば該業務サ−バプロセスの作
成をマネ−ジャに要求し、自己消去部はマネ−ジャから
受けた業務サ−バプロセスの条件を満たせば該業務サー
バプロセスの自己消去を行う．マネ−ジャではサ−バ起
動部は業務サ−バプロセスを起動し，サーバ振り分け処
理部は業務サ−バプロセスの条件を保存し，業務クライ
アントまたは該負荷監視部からの要求に基いて業務サ−
バプロセスの条件を付し，サ−バ起動部を介して該業務
サ−バプロセスを起動する。

【００７８】この発明の第１３の発明においては，業務
サ−バでは負荷監視部は業務サーバの負荷状態を知り、
アクセス権付与決定部は業務クライアントのアクセス優
先順位を制御する情報と該負荷監視部の情報により業務
クライアントへアクセス権を付与する。

【００７９】この発明の第１４の発明においては，デー
タ量制御装置は次ぎの各手段を備える．即ち，入力手段
はデータを入力し、重要度識別手段は管理情報入出力手
段の設定した条件により該入力手段からの入力データの
重要度を識別し絶対出力デ−タと任意出力デ−タに分類
し、カウント手段は前記の絶対出力デ−タの時間あたり
の数をカウントする．そして，取捨選択手段は前記カウ
ント手段の時間当りの絶対出力デ−タの数と該管理情報
入出力手段の設定条件に基き前記の重要度識別手段の出
力した任意出力データを取捨選択し、出力手段は取捨選
択手段が選択した出力データを出力する。

【００８０】この発明の第１５の発明においては，業務
サ−バでは，時刻取得部は時刻を取得し、記憶部はデー
タを記憶し、データ移動処理部は他の業務サ−バからの
デ−タを該記憶部に格納し，該時刻取得部の時刻が所定
のデ−タ移動時刻になれば該記憶部のデータを他の業務
サ−バに移動し、クライアント要求処理部は業務クライ
アントの要求の処理を行う。

【００８１】この発明の第１６の発明においては，業務
サ−バは上位業務サ−バと下位業務サ−バよりなってい
る．下位業務サ−バでは，時刻取得部は時刻を取得し、
下位記憶部はデータを記憶し、データ移動処理部は上位
業務サ−バからのデ−タを下位記憶部に格納し，該時刻
取得部の時刻が上位業務サ−バの指定のデ−タ移動時刻
になれば該下位記憶部のデータを上部業務サ−バに移動
し、クライアント要求処理部は業務クライアントの要求
の処理を行う．そして，上位業務サ−バでは，上位記憶
部はデータを記憶し、データ移動処理部は該データ移動
時刻を指定して該上位記憶部から該下位記憶部への移動
処理及び該指定移動時刻になれば該下位記憶部からのデ
−タを上位記憶部に保存し、クライアント要求処理部は
業務クライアントの要求の処理を行う．

【００８２】この発明の第１７の発明においては，業務
サ−バでは，クライアント要求処理部は業務クライアン
トのデ−タに係わる処理要求に対して自記憶部のデ−タ
で対応出来ないときは，他の業務サ−バの記憶部のデ−
タを使用して該業務クライアントの要求を処理する分散
トランザクション処理を行うものである．

【００８３】

【実施例】

実施例１．本発明の第１の発明の１実施例である実施例
１について図１〜４を参照して説明する．図１は本発明
の第１の発明により、各業務サーバプロセスが、処理要
求を受け付ける業務クライアントを分担することによ
り、システム全体としての処理効率を向上させることが
できることを示す実施例のブロック図を示したものであ
る。図１において、１はトランザクション処理を要求す
る計算機としての業務クライアント，２〜３は業務クラ
イアントから要求された処理を行う計算機としての業務
サーバ、９〜１０は各業務サーバ２，３上で同じ内容の
トランザクション処理を実行する業務サーバプロセス、
１１は業務サーバプロセス９と業務サーバプロセス１０
の負荷を監視する負荷監視手段、１２は負荷監視手段１
１による監視結果に基づいて業務サーバプロセス数の設
定，変更等を制御する業務サーバプロセス数変更手段、
１３は各業務サーバプロセスが要求を受け付けるべき業
務クライアント１を決定する業務クライアント決定手
段、１４〜１５は各業務サーバプロセスが要求を受け付
けるべき業務クライアント１を管理する業務クライアン
ト管理テーブル、１６は負荷監視手段１１と業務サーバ
プロセス数変更手段１２と業務クライアント決定手段１
３を実現するトランザクション処理管理部である。

【００８４】図２、図３および図４は本発明の第１の発
明の同実施例の動作を説明するための図であり、図２は
負荷増大前の状態を表す図、図３は負荷増大後の状態を
表す図である．図１と同一符号は同一または相当の部分
である．なお，業務クライアント管理テ−ブル１４，１
５内にアドレス表示の業務クライアント１〜６は業務ク
ライアント１ａ〜１ｆに対応している．図４はトランザ
クション処理管理部の処理例を示す流れ図である。

【００８５】なお，本実施例のトランザクション処理と
はネットワーク上に接続された単数または複数の業務ク
ライアントと単数または複数の業務サーバの間でトラン
ザクション処理を行うオンライントランザクション処理
システムを指す．このことは他の実施例でも同様であ
る．

【００８６】次に動作を図２，３，４を用いて説明す
る。図２は負荷増大前の状態を示した図である。業務サ
ーバ７は、業務クライアント１ａ〜１ｆからの処理要求
を受け付け、業務サーバプロセス９にて要求されたトラ
ンザクションを実行する。業務サーバプロセス９の業務
クライアント管理テーブル１４には、業務クライアント
１ａ〜１ｆの計算機アドレスが格納されている。

【００８７】図４は負荷増大時或は減少時のトランザク
ション処理管理部１６の処理の流れの例を示した図であ
る。負荷監視手段１１は、定期的に業務クライアント１
でのトランザクション発生比率情報を収集するなどし
て、トランザクションの負荷情報を収集する（ステップ
４０１）。負荷が高まり、負荷監視手段１１にて負荷が
一定以上になったと検知すると（ステップ４０２）、業
務サ−バ数変更手段１２はその負荷より必要な業務サー
バプロセス数を判定する（ステップ４０３）。その数
が、存在する業務サーバプロセス数より多い場合は、業
務サーバプロセス数変更手段１２が、新たな業務サーバ
プロセス１０を起動する（ステップ４０４）。同時に業
務クライアント決定手段１３が、各業務サーバプロセス
が処理を受け付けるべき業務クライアントを決定する
（ステップ４０５）。例えば、業務サーバプロセス９が
業務クライアント１ａ〜１ｃからの処理要求を、業務サ
ーバプロセス１０が業務クライアント１ｄ〜１ｆからの
処理要求を受け付けるとすると、業務サーバプロセス９
の業務クライアント管理テーブル１４には、業務クライ
アント１ａ〜１ｃの計算機アドレスが、業務サーバプロ
セス１０の業務クライアントテーブル１５には、業務ク
ライアント１ｄ〜１ｆの計算機アドレスが、格納される
ことになる。図３は、負荷増大に伴い，これらの制御結
果の状態を示す図である。

【００８８】負荷が増大して、業務サーバプロセス間で
業務クライアント１の再分担を行ったとしても業務クラ
イアント１ｄ〜１ｆはそれを知らないので、再分担後こ
れらの業務クライアント１ｄ〜１ｆからの最初のアクセ
スは、前に分担の業務サーバプロセス９に処理を要求す
ることがある。そのような場合には、業務サーバプロセ
ス９からの応答として、業務サーバプロセス１０が処理
を要求すべき新たな業務サーバプロセスであることを業
務クライアント管理テ−ブル１４から判断・指示し、以
降業務サーバプロセス１０に処理要求を発行させること
になる。

【００８９】次ぎに、負荷監視手段１１にて負荷が一定
以下になったと検知されると、業務サーバプロセス数変
更手段１２が業務サーバプロセス１０を消去し（ステッ
プ４０６）、同時に業務クライアント決定手段１３が、
各業務サーバプロセスが処理を受け付けるべき業務クラ
イアント１を再決定する（ステップ４０７）。例えば、
業務サーバプロセス９が業務クライアント１ａ〜１ｆか
らの処理要求を受け付けるとすると、業務クライアント
決定手段１３により業務サーバプロセス９の業務クライ
アント管理テーブル１４には、図２に示す様に業務クラ
イアント１ａ〜１ｆの計算機アドレスが格納されること
になる。

【００９０】このように、業務サーバプロセス間で、処
理要求を受け付ける業務クライアント１を分担すること
が可能となる．これらの制御は各トランザクション処理
要求毎に割り振りをするのではなく，トランザクション
の負荷が所定の範囲外になった時にのみ業務サ−バプロ
ッセスの生成／消去，クライアンの分担調整を行うの
で，負荷に比例してオ−バヘッド増が発生することもな
く，結果として全体の処理効率が向上し，負荷の増加に
よるトランザクション処理システムへの障害も抑制され
る．

【００９１】上記の業務クライアント１の分担処理にお
いて、業務クライアント管理テーブルに格納されていた
のは、業務クライアント１の計算機アドレスであった
が、業務を実行する利用者名を格納してもよい。

【００９２】また，上記のトランザクション分担におい
て、業務サーバプロセス毎に負荷監視手段１１と業務プ
ロセス数変更手段１２と業務クライアント決定手段１３
を持ち、業務サーバプロセス９，１０のレベルで負荷に
応じて、さらに子としての業務サーバプロセス１０を生
成して、それまでその業務プロセス９，１０のそれぞれ
業務クライアント管理テーブル１４，１５に格納されて
いた業務クライアント１の一部を子の業務サーバプロセ
スの業務クライアント管理テーブルに格納させて、それ
らの業務クライアント１からの処理要求を受け付けさせ
てもよい。

【００９３】以上のように第１の発明によれば、オンラ
イントランザクション処理における業務サーバプロセス
を、絶えず変化するトランザクションの付加に応じて変
化させ、さらに処理依頼を受け付ける業務クライアント
１をそれらの間で分担・統合するので、業務サーバプロ
セス間でのトランザクションの振り分け処理を行うこと
なく、トランザクションの応答性を保証し、トランザク
ション処理負荷の増大に伴うシステムへの障害を回避出
来，かつ，システム資源の有効性を図ることができる効
果がある。また，本発明の第１の発明は，これから説明
する第２以後の発明と組み合せて実施出来るものはそう
して，更なる効果を実現させてもよい．このことは，第
２以後の発明につても同様であることはいうまでもな
い．

【００９４】実施例２．前記の実施例１は、各業務サー
バプロセスで要求を受け付ける業務クライアント１を分
担する本発明の第１の発明の実施例であったが、実施例
２は本発明の第２の発明により、各業務サーバプロセス
が扱うデータを分担することにより、システム全体とし
ての処理効率を向上させることができる実施例である．

【００９５】以下，本発明の第２の発明の１実施例であ
る実施例２を図５〜８を参照して説明する．図５は本実
施例の構成を示すブロック図である。図５において、図
１〜３と同一又は相当の部分は同一符号を付し，説明を
したのでこれらの説明は省略する．図６、図７および図
８は第２の発明による同実施例の動作を説明するための
図であり、図６は負荷増大前の状態を表す図、図７は負
荷増大後の状態を表す図である．図６のデ−タ管理テ−
ブル１４内に示すデ−タ（Ａｌａｎ〜Ｍａｒｋ）は業務
クライアント１ａ〜１ｆからアクセスされる可能性のあ
るデ−タである．図７でも同様である．図８はトランザ
クション処理管理部の処理例を示す流れ図である。

【００９６】次に上記実施例２の動作を図６〜７を用い
て説明する。図６は負荷増大前の状態を示した図であ
る。業務サーバ２は、業務クライアント１ａ〜１ｆから
の処理要求を受け付け、業務サーバプロセス９にて要求
されたトランザクションを実行する。業務サーバプロセ
ス２は、業務クライアント１ａ〜１ｆからの処理要求を
受け付け、扱うデータとしてＡで始まるデータからＭで
始まるデータまでを管理しており、そのデータ管理テー
ブル１４には、扱うデータの一覧が格納されている。

【００９７】図８は負荷増大時のトランザクション処理
管理部１６の処理の流れの例を示した図である。負荷監
視手段１１は、定期的に業務クライアント１でのトラン
ザクション発生比率情報を収集するなどして、トランザ
クションの負荷情報を収集する（ステップ８０１）。負
荷が高まり、負荷監視手段１１にて負荷が一定以上にな
ったと検知すると（ステップ８０２）、業務サ−バプロ
セス数変更手段１２はその負荷より必要な業務サーバプ
ロセス数を判定する（ステップ８０３）。その数が、存
在する業務サーバプロセス数より多い場合は、業務サー
バプロセス変更手段１２が、新たな業務サーバプロセス
１０を起動する（ステップ８０４）。同時に管理テーブ
ル決定手段１３が、各業務サーバプロセスが扱うべきデ
ータを決定する（ステップ８０５）。例えば、業務サー
バプロセス９がＡで始まるデータからＨで始まるデータ
までを、業務サーバプロセス１０がＩで始まるデータか
らＭで始まるデータまでを扱うとすると、業務サーバプ
ロセス９のデータ管理テーブル１４にはＡで始まるデー
タからＨで始まるデータの一覧が、業務サーバプロセス
１０のデータ管理テーブル１５にはＩで始まるデータか
らＭで始まるデータまでの一覧が、格納されることにな
る。図７は、負荷増大に伴うこれらの処理結果の状態を
示す図である。

【００９８】負荷が増大して、業務サーバプロセス間で
扱うデータの再分担を行ったとしても業務クライアント
１はそれを知らないので、業務クライアント１からＭで
始まるデータに関する処理に関する１回目の要求は、業
務サーバプロセス９に要求されることになる。そのよう
な場合には、業務サーバプロセス９からの応答として、
業務サーバプロセス１０が処理を要求すべき新たな業務
サーバプロセスであることを業務クライアント管理テ−
ブル１４から判断・指示し、以降業務サーバプロセス１
０に処理要求を発行させることになる。

【００９９】負荷監視手段１１にて負荷が一定以下にな
ったと検知されると、業務サーバプロセス数変更手段１
２が業務サーバプロセス１０を消去し（ステップ８０
６）、同時に管理データ決定手段１３が、各業務サーバ
プロセスが扱うべきデータを再決定する（ステップ８０
７）。例えば、業務サーバプロセス９がＡで始まるデー
タからＭで始まるデータまでを管理するとすると、図６
に示すように業務サーバプロセス９のデータ管理テーブ
ル１４には、Ａで始まるデータからＭで始まるデータの
一覧が格納されることになる。

【０１００】このように、業務サーバプロセス間で、処
理要求を受け付ける扱うデータを分担することが可能と
なる．これらの制御は個々のトランザクション要求毎に
するのではなく，トランザクションの負荷が所定の範囲
外になった時にのみ業務サ−バプロセスの生成／消去，
扱うデ−タの分担調整を行うので，不要なオ−バヘッド
が発生することもなく，結果として全体の処理効率が向
上し，負荷の増加によるトランザクション処理システム
の障害も抑制される．

【０１０１】本実施例２において、業務サーバプロセス
毎に負荷監視手段と業務サ−バプロセス数変更手段１２
と管理データ決定手段１３を持ち、業務サーバプロセス
のレベルで負荷に応じて、さらに子としての業務サーバ
プロセスを生成して、それまでその業務プロセスのデー
タ管理テーブルに格納されていたデータの一覧の一部を
子の業務サーバプロセスのデータ管理テーブルに格納さ
せて、それらのデータに関する処理要求を受け付けさせ
てもよい。

【０１０２】以上のように第２の発明によれば、オンラ
イントランザクション処理における業務サーバプロセス
を、絶えず変化するトランザクションの付加に応じて変
化させ、さらに処理の対象となるデータをそれらの間で
分担・統合するので、業務サーバプロセス間でのトラン
ザクションの振り分け処理を行うことなく、トランザク
ションの応答性を保証し、かつ、システム資源の有効利
用を図ることができる効果がある。

【０１０３】実施例３．実施例２は、各業務サーバプロ
セスで扱うデータを分担する第２の発明の実施例であっ
たが、本実施例３は第３，４の発明により、業務クライ
アントが業務サーバおよびネットワークの負荷を予測
し，負荷分散する例である．以下，図９〜１０を用いて
実施例３を説明する．

【０１０４】図９は実施例３の構成を示すブロック図で
ある。図９において、１はトランザクション処理の要求
を発行する計算機としての業務クライアントである．な
お，業務クライアント１は図示していないが，後記の時
刻管理手段９０３と同様の手段をもっている．２は業務
クライアント１から要求されたトランザクションを実行
する計算機としての業務サーバ、９０３は現在の時刻を
保持する時刻管理手段、９０４は業務クライアントから
依頼されたデータを受信する処理依頼データ受信手段、
９０５は処理依頼データ受信手段９０４においてデータ
にデータ受信時刻情報を付加することにより、データ受
信時刻を刻印するデータ受信時刻刻印手段、９０６は実
際にクライアントから要求されたトランザクションを実
行する業務サーバプロセス、９０７は業務サーバプロセ
ス９０６においてトランザクション処理の開始時刻と終
了時刻に関する情報を付加することにより、トランザク
ション処理の開始時刻と終了時刻とを刻印するトランザ
クション処理開始／終了時刻刻印手段、９０８はデータ
ベースにアクセスするなどして実際のトランザクション
処理を行うトランザクション処理実行部、９０９は処理
結果を業務クライアント１に返信する処理結果データ送
信手段である。９１０は業務サ−バ−２の記憶装置であ
る．図１０は本発明の動作を説明するための図である。

【０１０５】次に動作を図１０により説明する。処理依
頼データ受信手段９０４が業務クライアント１からの処
理要求データを受信すると、データ受信時刻刻印手段９
０５がその時点での時刻ｔ１を時刻管理手段９０３から
取得し、処理要求データにデータ受信時刻ｔ１を含む情
報を付加する。処理を実行すべき業務サーバプロセス９
０６が決定され、処理要求データに関するトランザクシ
ョン処理を開始する時点で、トランザクション処理開始
／終了時刻刻印手段９０７が、その時点での時刻ｔ２を
時刻管理手段９０３から取得し、処理要求データにトラ
ンザクション処理開始時刻ｔ２を含む情報を付加する。
処理を実行した業務サーバプロセス９０６において、処
理要求データに関するトランザクション処理が完了した
時点で、再びトランザクション処理開始／終了時刻刻印
手段９０７が、その時点での時刻ｔ３を時刻管理手段９
０３から取得し、データ受信時刻ｔ１、トランザクショ
ン処理開始時刻ｔ２および処理結果を含む応答データ
に、トランザクション処理終了時刻ｔ３を含む情報を付
加する。結果として、データ受信時刻ｔ１を含む情報と
トランザクション処理開始時刻ｔ２を含む情報とトラン
ザクション処理終了時刻ｔ３を含む情報が付加された応
答データが、処理結果データ送信手段９０９から、業務
クライアント１に送信されることになる。

【０１０６】処理の結果を受信した業務クライアント１
は、処理結果を受信した時刻と、業務サーバでのトラン
ザクション処理終了時刻ｔ３の差分から、処理結果の転
送時間９１１を知ることができ、ネットワーク負荷を予
測することができる。また、データ受信時刻ｔ１とトラ
ンザクション処理開始時刻ｔ２の差分から、業務サーバ
２における処理受け付けから処理開始までの時間９１２
を知ることができ、この時間９１２は業務サーバ２の負
荷に比例するので，その負荷予測に利用することができ
る。

【０１０７】業務クライアント１においては、このよう
な負荷の予測を各業務サーバ２に対して行っておくこと
により、同じ要求を実行可能な業務サーバ２の中から実
際に要求を行う業務サーバ２を選択する際に最も負荷の
軽い業務サーバ２を選択することが可能となる。また、
予測したネットワークの負荷から、ネットワーク経由で
他の業務サーバ２に処理を依頼するか、業務クライアン
ト１と同じ計算機内の業務サーバプロセスに処理を依頼
するか（デ−タへの時刻刻印に業務サ−バプロセス名を
併記）の選択の際の参考情報とすることができる。この
ようにして，トランザクションの負荷が増大し，トラン
ザクション処理システムの障害発生を抑制することが出
来る．

【０１０８】本実施例において、処理結果を返信するす
べてのデータにデータ受信時刻ｔ１、トランザクション
処理開始時刻ｔ２、トランザクション処理終了時刻ｔ３
という時刻情報を含めていたが、それをいくつかの処理
結果返信データのうちの一つに入れるという方法を採っ
てもよい。また、業務クライアント１から送られた処理
要求データにデータ受信時刻ｔ１、トランザクション処
理開始時刻ｔ２を付加するのではなく、それらをテーブ
ルに蓄積しておいて、応答データ作成の時にそのテーブ
ルを参照することにより付加してもよい。

【０１０９】本実施例の刻印する処理の時刻例として，
処理要求受信ｔ１，要求トランザクション処理開始ｔ
２，要求トランザクション処理終了ｔ３について説明し
たが，これらに限定されることはない．これ以外に任意
に選んだ処理（例えば，デ−タベ−スへのアクセス要求
時刻，アクセス結果の取得時刻など）の時刻デ−タを収
集し，処理或は待ちなどの時間を計算して必要な時間情
報を得，業務サ−バ２，ネットワ−クなどの処理，待ち
時間などを多角的，詳細に，分析，予測できることはい
うまでもない．例えば，処理待ち，処理時間などについ
てトランザクション処理負荷の大小，処理内容，ネット
ワ−ク構成，ピ−ク時期等の相関分析などが容易にな
り，システムの分析評価も容易になる．

【０１１０】以上のように第３，４の発明によれば、負
荷収集のための処理，或は通信トラフイックなどのオ−
バヘッドによる処理効率低下を招くことなく、しかも業
務クライアント１がネットワークの負荷と業務サーバプ
ロセスの負荷を知ることができるため、業務クライアン
ト１が最適な業務プロセスを選択することが可能とな
り、システム資源の有効性を図りつつ、システム全体の
処理効率向上を図る。

【０１１１】実施例４．実施例３は、業務サーバ２と業
務クライアント１間で交換されるデータに様々な時刻情
報を含ませることにより、最適なサーバ選択を可能にす
ることを示す第３，４の発明の実施例であったが、本実
施例４は第５の発明により、サーバからの応答を全クラ
イアントで共有することを示す例である．以下，実施例
４を図１１〜１２を参照して説明する．

【０１１２】図１１は本発明の構成例を示すブロック図
である。 図１１において、１はトランザクション処理
の要求を行う業務クライアント、２は業務クライアント
から要求にしたがってトランザクション処理を行う業務
サーバ、４は各業務サーバの処理内容とそのネットワー
ク上のアドレスの対応表を保持してその対応を業務クラ
イアント１に教える名前サーバ、１１０４は名前サーバ
４において保持されている各業務サーバの処理内容とそ
のネットワーク上のアドレスの対応表、１１０５は名前
サーバ４において問い合わせのあった処理を提供してい
る業務サーバ２のアドレスを応答として返信するサーバ
アドレス応答データ送信手段、１１０６はサーバアドレ
ス応答送信手段１１０５において送信すべきデータを業
務クライアント１ａを含む複数の業務クライアント１に
対して放送通信する放送通信手段である。図１２は本発
明による実施例の動作を説明するための図である。

【０１１３】次に本実施例の動作を図１２，図１１に基
づいて説明する。業務サーバ２は、業務サーバプロセス
Ａ１２０１にて在庫データ更新処理という処理を提供し
ており、名前サーバ４がその処理内容と業務サーバ２の
ネットワーク上のアドレスの対応表１１０４を保持して
いる。名前サーバ４は、業務クライアント１ａからの在
庫データ更新処理という処理を提供しているサーバアド
レスの問い合わせ１２０２を受けると、業務サーバ２の
アドレスを応答データ１２０３として、サーバアドレス
応答データ送信手段１１０５にその送信を要求する。そ
の際、サーバアドレス応答送信手段１１０５は、放送通
信手段１１０６を利用して応答データ１２０３を送信す
る。

【０１１４】このため、サーバアドレス問い合わせを行
った業務クライアント１ａ以外の例えば業務クライアン
ト１ｆもサーバアドレス応答データ１２０３を受信する
ことが可能となる。その業務クライアント１ｆが在庫デ
ータ更新処理という処理を業務サーバに依頼したい場
合、名前サーバ４に対して同じ問い合わせを行う必要が
なく、直接業務サーバ２に処理を依頼すればよい様にな
る。また、一般に放送通信はネットワークの負荷を高め
るものであるが、ある処理を提供している業務サーバ２
のアドレスに関する問い合わせはいずれかの業務クライ
アント１がやれば他の業務クライアントはそれを行う必
要がないので、この放送通信の行われる頻度は少なく、
ネットワークへの負荷はあまり高くない。特に，対象と
なる業務クライアント１が多くしかも，それぞれのトラ
ンザクション処理要求が多いときには本発明の効果は大
きい．

【０１１５】なお，業務サ−バ２の業務サ−バプロセス
の内容によってサ−ビスをする業務クライアント１が限
定されているときは，アドレスの対応表１１０４に各業
務サ−バの処理内容，業務サ−バプロセスのアドレスに
加えて，対象の業務クライアント１の情報を付加し，問
い合わせに対して該当の各業務クライアント１に限定し
て放送通信する様にしてもよい．

【０１１６】以上のように第５の発明によれば、ある業
務クライアント１が名前サーバ４に対して問い合わせた
業務サーバ２に関する情報を、他の業務クライアント１
も共有することができるため、それらの業務クライアン
ト１が名前４サーバに対して同じサーバに関する問い合
わせを行う無駄を抑制することができるため、システム
の処理効率向上を図ることができるという効果がある。

【０１１７】実施例５．本発明の第６の発明に係わる本
実施例５は高負荷時にメモリ容量の制約によりシステム
のオ−バフロ−等の障害を未然に防止し負荷分散する事
例であり，以下図１３〜図１９を用いて説明する。

【０１１８】図１３は、当発明の一実施例である実施例
５の全体構成図である。図１３において、２ａ、２ｂは
業務サーバ、１ａ、１ｂ、１ｃは業務クライアント、１
３０３ａ、１３０３ｂは業務サーバ２ａ、２ｂの記憶装
置である。

【０１１９】図１４は図１３の業務サーバ２ａ、２ｂの
構成図である。図１４で２は業務サーバ、１４１１ａ〜
ｂは業務クライアント１ａ〜ｃの要求を処理する手段を
持つ業務サーバプロセス、１４２１は業務サーバ２のメ
モリ領域を管理する手段を持つメモリ管理部、１４２２
はプロセスの実行等を制御する手段を持つプロセス制御
部、１４２３はプロセスの実行、或いは実行待ちなどの
状態を管理する手段をもつプロセス管理部、１４２４は
プロセス管理部１４２３のための記憶部、１４２５はメ
モリ管理部１４２１のための記憶部である。

【０１２０】図１５はプロセス管理部１４２３が備え、
起動中の業務サーバプロセス１４１１の状態を管理する
起動プロセス管理テーブル１４６０の構成を示す。同図
中、１４６１は業務サーバプロセス名、１４６２はプロ
セスＩＤ、１４６３は複製プロセス数、１４６４は業務
サ−バプロセス１４１１の処理回数を示すアクセス回
数，１４６５は業務サ−バプロセス１４１１の優先順
位，１４６６は業務サ−バプロセス１４１１が縮退対象
か否かを示す縮退対象，である。図１６はメモリ管理部
１４２１の、図１７はプロセス制御部１４２２の、それ
ぞれフロ−チャ−トである．図１８はプロセス管理部１
４２３の動作を示すフローチャートである。図１９はプ
ロセス管理部１４２３内でプロセス制御部１４２２に対
応する動作を示すフロ−チャ−トである．

【０１２１】つぎに上記実施例の動作を図１５〜１９を
参照しながら説明する。メモリ管理部１４２１の動作、
プロセス制御部１４２２の動作、プロセス管理部１４２
３の動作の順に説明する。

【０１２２】まず、メモリ管理部１４２１の動作につい
て図１６により説明する。はじめに、残メモリサイズの
閾値を設定する（ステップ１５０１）。最大メモリサイ
ズ、使用メモリサイズを入力し（ステップ１５０２）、
残メモリサイズを測定後、閾値と比較しメモリの負荷状
況を判断する（ステップ１５０３）。その結果、閾値以
上の場合、プロセス制御部１４２２に対して縮退運転要
求を送信しステップ１５０２に戻り、結果が閾値以下の
場合（ステップ１５０３）は、処理を行なわずステップ
１５０２に戻る。

【０１２３】次にプロセス制御部１４２２の動作につい
て図１７により説明する。プロセス制御部１４２２は常
にメモリ管理部１４２１からのメモリ負荷状況の入力待
ち状態にある（ステップ１６０１）。メモリ管理部１４
２１から負荷状況が通知された場合、負荷状況を判断し
（ステッブ１６０２）、その結果が閾値以上の場合は、
プロセス管理部１４２３に対して、縮退運転命令を通知
し、優先順位が付けられた処理待ち状態である業務サー
バプロセス１４１１（以下、処理待ち状態である業務サ
ーバプロセスを不活性プロセスと呼ぶ）の情報を受信す
る（ステップ１６０３）。この詳細は後に図１９で説明
する．そして、当該の消去プロセスを記憶部１４２５に
記録し（ステップ１６０４）、優先順位の低い順に不活
性プロセスである業務サーバプロセス１４１１をメモリ
から消去する（ステップ１６０５）。また、メモリ負荷
が閾値以下と判断された場合は、先にステップ１６０５
で消去された業務サーバプロセス１４１１が存在するか
をプロセス管理部１４２３に照会し，存在しなければス
テップ１６０１に移る．存在すれば，後述の図１９のス
テップ１４５５〜１４５６の処理を経て，復旧する消去
プロセスの情報を得，復旧運転命令を実行する（ステッ
プ１６０６〜１６０８）．

【０１２４】次にプロセス管理部１４２３の動作につい
て図１４、図１５、図１８、図１９を用いて説明する。
図１４，図１５，図１８において，初めに、業務サーバ
プロセス１４１１ａ，ｂが起動された時、業務サーバプ
ロセス名１４６１、業務サーバプロセスのプロセスＩＤ
１４６２、複製プロセスの数１４６３、各複製プロセス
のプロセスＩＤ１４６２を起動プロセス管理テ−ブル１
４６０に通知する（ステップ１７０１）。複製プロセス
の数とはメモリ上に複製され、同一内容のプロセスが別
タスクとして実行されるプロセスの数である。

【０１２５】プロセス管理部１４２３内では、図１５に
示す起動プロセス管理テーブル１４６０を用いて起動中
の業務サーバプロセス情報を管理する。この手続きは、
業務サーバプロセス１４１１が起動される時に必ず行な
われる。続いて、業務サーバプロセス１４１１ａ〜ｂか
らの処理要求待ち状態に入る（ステップ１７０２）。業
務サーバプロセス１４１１ａ〜ｂからその機能の開始通
知が来た場合は、同時に業務サ−バプロセス名１４６
１，プロセスＩＤ１４６２を受信し（ステップ１７０
３）、起動プロセス管理テーブル１４６０の業務サーバ
プロセスのアクセス回数１４６４を加算する（ステップ
１７０４）。このアクセス回数１４６４の集計結果か
ら、各業務サーバプロセス１４１１ａ〜ｂの優先順位１
４６５を決定する。優先順位１４６５は、アクセス回数
１４６４の値の多い業務サ−バプロセス１４１１ほど負
荷も大きいので，高い（ステップ１７０５）。

【０１２６】また、ステップ１７０２の結果、業務サー
バから機能の終了通知が来た場合は、ステップ１７０３
と同様に，業務サ−バプロセス名１４６１，プロセスＩ
Ｄ１４６２を受信し（ステップ１７０６）、起動プロセ
ス管理テーブル１４６０のアクセス回数１４６４を減算
する（ステップ１７０７）。続いて、業務サーバプロセ
ス１４１１の優先順位１４６３を再設定し（ステップ１
７０８），ステップ１７０２に戻る．

【０１２７】次に，プロセス管理部１４２３内で，プロ
セス制御部１４２２に対応する動作を図１９，図１７を
用いて説明する．図１７において，ステップ１６０２の
メモリ負荷の判断に続く閾値以上のときのステップ１６
０３と閾値以下のステップ１６０６の実行が図１９のス
テップ１４５１に繋がる．プロセス管理部１４２３で
は，プロセス制御部１４２２より縮退運転命令が実行さ
れる旨通知されると（ステップ１４５１），起動プロセ
ス管理テ−ブル１４６０において，優先順位１４６５が
最も低く，且つ縮退対象１４６６に縮退のマ−クが付い
ていない業務サ−バプロセス名１４６１等を検索する
（ステップ１４５２）．そして，当該の業務サ−バプロ
セス名１４６１の縮退対象１４６６に縮退のマ−クを付
け（ステップ１４５３），業務サ−バプロセス名１４６
１及びプロセスＩＤ１４６２をプロセス制御部１４２２
に通知し（ステップ１４５４），図１７に示すプロセス
制御部１４２２の処理のステップ１６０３に繋がる．一
方，ステップ１４５１のプロセス制御部１４２２からの
受信が，縮退した業務サ−バプロセス１４１１の復旧運
転命令を実行する旨の場合は，起動プロセス管理テ−ブ
ル１４６０を検索し，縮退対象１４６６にマ−クがなさ
れ，且つ優先順位１４６５の高いプロセスの業務サ−バ
プロセス名１４６１，プロセスＩＤ１４６２を得る（ス
テップ１４５５）．そして，当該業務サ−バプロセス名
１４６１の縮退対象１４６６の縮退マ−クを削除し（ス
テップ１４５６），ステップ１４５４に移って，検索し
た業務サ−バプロセス名１４６１，プロセスＩＤ１４６
２をプロセス制御部１４２２に通知し，図１７のステッ
プ１６０６に繋げる．

【０１２８】このように、不活性プロセスの強制消滅に
よる空きメモリ領域の一時的確保やプロセス数の減少な
どにより、メモリのオーバ・フロー，システム・ダウン
などの障害も未然に防ぐことが出来，障害回復に時間を
要することもない。また、各種サーバも必要なメモリ領
域を確保することが出来る。更に、システム障害を予測
し、それに備えて予め用意する複製サーバプロセスの数
を制限し、通常のシステムのパフォーマンスを低下させ
ることもなくなり，トランザクション負荷の増大に伴う
システムの障害が回避される。

【０１２９】第６の発明によれば、高負荷時にあっても
各種業務サーバの縮退運転機能によって、自動的に空き
メモリ領域が確保される。そのため、ハードウェアの制
限からくるシステム・ダウン等の障害も未然に防止する
ことができる。また、システム障害を予測して、予め用
意する同一機能サーバの数を制限し消極的に見積もる必
要がなく一定化でき、資源の利用効率を向上させる。

【０１３０】実施例６．本実施例６は本発明の第７の発
明に係わる実施例で，過負荷時においても負荷分散す
る。以下，本実施例６を図２０〜図２５を用いて説明す
る．

【０１３１】図２０は、本実施例６の構成図で，図１３
の業務サーバ２ａもしくは２ｂと同じ業務サ−バ２の内
部構成を表す。図２０において、１は業務クライアン
ト、１８１１は業務サーバプロセス、１８１２は業務サ
ーバプロセス１８１１の機能群を構成する機能、１８２
１は、過負荷時に発生させる代行業務サーバプロセス
（後記）を制御するサーバ管理部である．業務サーバプ
ロセス１８１１はサーバ管理部１８２１によって管理さ
れる。業務サーバプロセス１８１１は、上記のように１
つ以上の機能から構成される機能群の集合体であり、生
成および消滅はサーバ管理部１８２１によって実施され
る。１８２２は、プロセスの状態を管理するプロセス管
理部であり、１８２４はサーバ管理部１８２１の記憶部
であり、１８２３はプロセス管理部１８２２の記憶部で
ある。

【０１３２】また図２１は，図２０の平常負荷状態か
ら、業務サーバプロセスの過負荷時に、業務サーバプロ
セスの１機能群の業務を遂行するための代行業務サーバ
プロセス（業務サ−バプロセスの内，必要機能に絞った
構成）が発生した状態の構成を示す図である。図におい
て，１９１１は代行業務サーバプロセスである。１９１
２は代行業務サーバプロセス１９１１の構成を示すもの
で、実体は代行業務サーバプロセス１９１１である。な
お，図２２はサーバ管理部１８２１が持つ業務サーバプ
ロセスのアドレス情報を保持しているアドレス管理テー
ブル１８５０で，業務サーバプロセス名１８５１、機能
群名１８５２、アドレス情報１８５３などにより構成さ
れる。図２３はプロセス管理部１８２２が持つ業務サー
バ管理テーブル１８６０で、業務サーバプロセス名１８
６１、機能群名１８６２、閾値１８６３、機能名１８６
４，アクセス回数１８６５，縮退運転１８６６により構
成される．これらの内，アクセス回数１８６５は業務サ
−バプロセス１８１１の実行タスク数を意味する．図２
４はプロセス管理部１８２２の、図２５はサーバ管理部
１８２１の何れも内部動作を示すフローチャートであ
る。

【０１３３】次に上記実施例の動作を図２０，図２２，
図２４、２５を用いて説明する。業務クライアント１か
ら処理の要求があつた時の動作、プロセス管理部１８２
２の動作、業務サーバ管理部１８２１の動作を順に説明
する。

【０１３４】全体動作の前提になる処理を主に図２０，
図２２により説明する．まず，任意の業務クライアント
１ａ〜ｃより、業務サーバプロセス１８１１に対して処
理要求，アクセス要求が生じた場合は、まずサーバ管理
部１８２１に対して業務サーバプロセス１８１１と通信
を行なうためのアドレス情報の獲得要求をする。サーバ
管理部１８２１は、図２２に示すアドレス管理テーブル
１８５０を持ち、各機能群毎のアドレス情報１８５３を
管理している。サーバ管理部１８２１は、業務サーバプ
ロセス１８１１のアドレス管理テーブル１８５０を検索
し、要求した業務クライアント１に対して検索結果を返
送し，業務クライアント１は業務サ−バプロセス１８１
１へのアクセスが可能になる。

【０１３５】次にプロセス管理部１８２２の動作につい
て図２４を用いて説明する。初めに、プロセス管理部１
８２２の業務サーバ管理テーブル１８６０には予め業務
サーバプロセス名１８６１と、その業務サーバプロセス
が保有する機能群１８６２、機能名１８６４、及び機能
群の閾値１８６３の設定を行なう（ステップ２００
１）。機能群の閾値１８６３とは、ある機能群に対する
処理要求，アクセス要求が集中した場合、その業務サー
バプロセス１８１１がボトルネック状態となり、他の機
能群への処理要求を妨げる状態となることを未然に防ぐ
ために予め設定するアクセス回数の限度数である。この
閾値１８６３の設定値を越えた場合は、代行業務サーバ
１９１１が起動される。

【０１３６】次いで、業務サーバプロセス１８１１が起
動された時、業務サーバプロセス名、業務サーバプロセ
スのプロセスＩＤ、複製プロセスの数、各複製プロセス
のプロセスＩＤを既述の図１５の起動プロセス管理テー
ブル１４６０と同様のテーブルに登録する（ステップ２
００２）。なお，このテ−ブルは処理が終了したら登録
プロセスを削除する．プロセス管理部１８２２内では、
図２３に示す業務サーバ管理テーブル１８６０を用いて
各業務サーバ１８１１の情報を管理する。続いて、業務
サーバプロセス１８１１は処理要求，アクセス要求待ち
状態に入る（ステップ２００３）。

【０１３７】業務サーバプロセス１８１１から機能の開
始通知が来た場合は、同時に機能群名１８６２および機
能名１８６４を受信し（ステップ２００４）、その機能
群へのアクセス回数１８６５を増加させる（ステップ２
００５）。続いて、業務サーバプロセス１８１１内の機
能群の負荷状況を、アクセス回数，その時の全体の使用
可能なメモリ領域，タスク数などを考慮して計算する
（ステップ２００６）。その結果から、負荷状況を判断
し（ステップ２００７）、全体のメモリ領域，タスク数
などを考慮した機能群へのアクセス回数１８６５が閾値
１８６３以上となった場合は、業務サ−バ管理テ−ブル
１８６０で縮退運転マ−クがなく，且つアクセス回数１
８６５が最大の業務サ−バプロセス名１８６１を検索
し，サーバ管理部１８２１に対して対応業務サ−バプロ
セス１８１１の縮退運転命令を送る．また，同時に縮退
対象の業務サ−バプロセス１８１１の縮退運転１８６６
に縮退のマ−クをする．（ステップ２００８）。機能群
へのアクセス回数１８６５が閾値１８６３以下の場合は
（ステップ２００３）に戻る。

【０１３８】また、ステップ２００３の結果、業務サー
バプロセス１８１１から機能の終了通知が来た場合は、
機能群および機能名を受信し（ステップ２００９）、そ
の機能群のアクセス回数１８６５を減少させる（ステッ
プ２０１０）。続いて、業務サーバプロセス内の機能群
の負荷状況を計算する（ステップ２０１１）。その結果
から、負荷状況を判断し（ステップ２０１２）、機能群
へのアクセス回数１８６５が閾値１８６３以下に下がっ
た場合は、サーバ管理部１８２１に対してステップ２０
０８でおこなった業務サーバプロセスの縮退運転を解消
するため復旧運転命令を送り，縮退運転１８６６の縮退
のマ−クを削除する（ステップ２０１３）。機能群への
アクセス回数１８６５が閾値１８６３以上の場合はステ
ップ２００３に戻る。

【０１３９】次にサーバ管理部１８２１の動作を図２５
を用いて説明する。サーバ管理部１８２１は、常にプロ
セス管理部１８２２からの処理要求，アクセス要求を受
け入れる機能を用意しているが（ステップ２１０１），
これは図２４のプロセス管理部１８２２の処理であるス
テップ２００８，ステップ２０１３から繋がる。プロセ
ス管理部１８２２からの命令が、縮退運転命令である
か、もしくは復旧運転命令であるかを判断し（ステップ
２１０２）、縮退運転命令の場合は、代行業務サーバプ
ロセス１９１１の生成、及び代行業務サーバプロセス１
９１１のアドレス情報の獲得を行ない（ステップ２１０
３）、過負荷な機能群の代行業務サーバプロセス１９１
１への移行を行なう（ステップ２１０４）。そして、機
能群を移行した業務サーバプロセス１８１１に対して、
移行した機能群にサスペンド命令を出して当該の業務サ
−バプロセス１８１１を記憶部１８２４に退避させる．
また、ステップ２１０３によって得られたアドレス情報
を基に、図２２のアドレス管理テーブル１８５０中の機
能群のアドレス情報１８５３の変更を行ない（ステップ
２１０５）、ステップ２１０１に戻る。それ以降の業務
クライアント１ａ〜ｃからの移行した機能群への処理要
求に対しては、代行業務サーバプロセス１９１１のアド
レス情報１８５３を通知し，以後，それがアクセスされ
る。

【０１４０】また、ステップ２１０２の結果が復旧運転
命令の場合は、機能群を移行した業務サーバプロセス１
８１１に対してサスペンド状態の解除命令（ステップ２
１０６）を出し、代行業務サーバプロセス１９１１を強
制消去し，ステップ２１０５で退避した業務サ−バプロ
セス１８１１を記憶部１８２４から復帰させる（ステッ
プ２１０７）。そして、アドレス管理テーブル１８５０
中の機能群のアドレス情報１８５３を復帰する業務サ−
バプロセス１８１１のアドレスに修正をし機能群の復旧
運転を終了する（ステップ２１０８）。 サーバ管理部
１８２１は、それ以降の業務クライアント１ａ〜ｃの処
理要求に対しては、通常の業務サーバプロセス１８１１
のアドレス情報１８５３を返送する。

【０１４１】このように、第７の発明によれば、過負荷
時においても代行業務サーバへの処理の移行によって、
ボトルネック現象を防止し、業務サーバプロセスの円滑
な処理を継続することが出来る。また、業務サーバ資源
に対する処理の応答性や利用効率を向上させることが出
来、従来システム障害によって行なってきた復旧作業に
要する時間および作業が発生しなくなり、メンテナンス
時間も短縮することが出来る。従って，過負荷により発
生するトランザクションシステムの障害が未然に抑制さ
れる．

【０１４２】実施例７．本実施例７は本発明の第８の発
明に係る一実施例で以下図２６〜図２８を参照して説明
する．

【０１４３】この実施例の目的は、負荷を制御するマネ
ージャと、それにともなう負荷監視のための通信を不要
にして通信トラフィックの減少を計り，また，マネ−ジ
ャの監視負荷を軽減し，更には，負荷の増大に対してシ
ステムの障害発生を防止することである。

【０１４４】図２６は本実施例の構成を示す。図におい
て、２２０１は伝送路、１はトランザクション要求をす
る業務クライアントである．２は業務クライアント１の
要求を処理する業務サ−バである．業務クライアント１
と業務サーバ１（２ａ）、業務サーバ２（２ｂ）は、伝
送路２２０１を介して通信を行う。２２０４はトランザ
クション要求の送受信処理を行なうトランザクション要
求送受信部、２２０４ａと２２０４ｂはトランザクショ
ン要求の送受信処理を行なう業務サーバ２のトランザク
ション要求送受信部、２２０５はトランザクション要求
の種類によって回覧リストを発生するトランザクション
回覧発生部、２２０６ａと２２０６ｂは回覧リストを解
析する業務サーバのトランザクション回覧部、２２０７
ａと２２０７ｂは業務サーバ２の負荷を検出するサーバ
負荷検出部、２２０８ａと２２０８ｂはトランザクショ
ン要求を処理する業務サーバ２のトランザクション処理
部である。

【０１４５】図２７は業務サーバ回覧リストの構成を示
す。図において、２２０９はトランザクション要求時に
トランザクション回覧発生部２２０５が発行し、トラン
ザクション要求を処理する業務サーバ２の候補をリスト
アップした業務サーバ回覧リストであり，ここでは、業
務サーバ１（２ａ）と業務サーバ２（２ｂ）が記載され
ているものとする。業務サーバ回覧リスト２２０９に
は、システム起動時には予め業務サーバ候補の欄と処理
負荷の欄に既定値が設定されている．図２８は、業務サ
ーバ２の動作を示すフローチャートを示す。

【０１４６】次ぎに，図２８を用いて動作を説明する．
業務クライアント１がトランザクション回覧発生部２２
０５において、トランザクション要求を処理することの
できる業務サーバ２のリスト，業務サ−バ回覧リスト２
２０９を生成し、業務サ−バ回覧リスト２２０９とトラ
ンザクション要求をトランザクション要求送受信部２２
０４を介して業務サーバ１（２ａ）に送信する。

【０１４７】業務サーバ１（２ａ）では、トランザクシ
ョン要求送受信部２２０４ａにて業務クライアント１か
ら業務回覧リスト２２０９とトランザクション要求を受
信する（ステップ２４０１）。

【０１４８】業務サ−バ回覧リスト２２０９を受け取っ
た業務サーバ１（２ａ）は、それが既に該当の業務サ−
バ２（２ｂ）の回覧を終了していたら，トランザクショ
ン処理部２２０８ａにてトランザクションを処理し、ト
ランザクション要求送受信部２２０４ａを介して業務ク
ライアント１に応答を返す（ステップ２４０２，２４０
３）。

【０１４９】回覧リスト２２０９に記載されている業務
サーバ２への回覧後に他の業務サーバ２への回覧がすべ
て終了していない場合、サーバ負荷検出部２２０７ａが
検出した業務サーバ１（２ａ）の処理負荷を回覧リスト
２２０９に書き込んだ後、回覧リスト２２０９の中で最
も処理負荷の低い業務サーバ２にトランザクション要求
と回覧リストを送信する（ステップ２４０４，２４０
５）。もし、回覧リスト２２０９を受信した業務サーバ
２の負荷がすべて同じならば、最後に受信した業務サー
バで処理を行なう。

【０１５０】トランザクション回覧部２２０６ａで、業
務サ−バ回覧リスト２２０９に記載されている業務サー
バ２への回覧が終了していなければ、サーバ負荷検出部
２２０７ａが検出した業務サーバ１（２ａ）の処理負荷
を業務サ−バ回覧リスト２２０９の処理負荷欄に書き込
んだ後、それに記載された順番通り（この実施例では次
ぎの業務サーバ２ （２ｂ））にトランザクション要求
送受信部２２０４ａからトランザクション要求と業務サ
−バ回覧リスト２２０９を送信する（ステップ２４０
４，２４０６，２４０７）。

【０１５１】以上のように第８の発明によれば、回覧リ
スト２２０９に記載された業務サーバ２間でトランザク
ションの回覧を行い、最も負荷の低い業務サーバ２でト
ランザクションを処理するので、負荷を制御するマネー
ジャと、それにともなう負荷監視のための通信を不要に
して通信トラフィックの減少を計ることができる。この
ため，トランザクション処理負荷が増大しても制御負
荷，制御用の通信トラフイック増によるシステム障害を
回避出来る．

【０１５２】実施例８．本実施例８は本発明の第９の発
明に係わる実施例で，以下図２９，図３０を用いて説明
する．

【０１５３】この実施例の目的は、急激にトランザクシ
ョン処理の負荷が変動するトランザクション処理システ
ムにおいて、すべての業務サーバの負荷を均一化し、ト
ランザクション処理システムの処理を効率化を図り，負
荷増に伴うシステムの障害を回避することにある。

【０１５４】図２９は本実施例の構成を示す．図におい
て，２５０１は伝送路、１はトランザクション要求を発
行する業務クライアント、２はトランザクション要求を
処理する業務サーバ、２５０４はトランザクション要求
の送受信処理を行うトランザクション要求送受信部、２
５０５はトランザクション要求を処理するトランザクシ
ョン処理部、２５０６は業務サーバの処理負荷を検出す
る処理負荷検出部、２５０７は業務サーバの処理負荷の
履歴を記憶する負荷履歴記憶部、２５０８は業務サーバ
の処理負荷の傾向を計算する負荷傾向検出部、２５０９
は業務サーバの処理負荷の上限値を記憶する負荷閾値記
憶部、２５１０はトランザクション要求を処理するかど
うかを判別する業務判定部である。図３０は業務サーバ
２の動作を示すフローチャートを示す。

【０１５５】業務クライアント１と業務サーバ２は、伝
送路２５０１を介して通信を行う。

【０１５６】業務サーバ２の動作を図３０を参照して説
明する．業務開始時に負荷閾値記憶部２５０９に処理負
荷の上限値（閾値）Ｗｔが記憶されている（ステップ２
６０１）。業務クライアント１は、トランザクション要
求送受信部２５０４から業務サーバ２にトランザクショ
ン要求を発行する。

【０１５７】業務サーバ２では、処理負荷検出部２５０
６がトランザクション処理部２５０５の処理負荷を定期
的に検出しており（ステップ２６０２）、検出した処理
負荷を時系列順に負荷履歴記憶部２５０７に記憶してい
る（ステップ２６０３）。さらに負荷傾向検出部２５０
８が、負荷履歴記憶部２５０７に記憶されている時刻と
処理負荷の関係から負荷傾向Ｔｒを以下の式によって計
算する（ステップ２６０４）。 Ｔｒ＝（Ｗ２−Ｗ１）／（Ｔ２−Ｔ１）
なお、この式において、時刻Ｔ１における処理負荷
をＷ１、時刻Ｔ２における処理負荷をＷ２とし、Ｔ２＞
Ｔ１である。また、処理負荷検出部２５０６は、予めシ
ステム起動時に負荷を検出する時間間隔が決められてい
るが、負荷傾向を分析することによって負荷を検出する
時間間隔を学習的に最適化してもよい。すなわち、Ｔｒ
が大きい時はＴ２−Ｔ１を小さくし、Ｔｒが小さい時は
Ｔ２−Ｔ１を大きくすることによって、負荷を検出する
時間間隔を最適化する。

【０１５８】業務サーバ２は、トランザクション要求送
受信部２５０４にてトランザクション要求を受け取る
（ステップ２６０５）。業務判定部２５１０では、負荷
傾向検出部２５０８から得られる負荷傾向Ｔｒと、負荷
閾値記憶部２５０９から得られる処理負荷の閾値Ｗｔか
ら、一定時間Ｔｉ後に処理負荷予測値が閾値を越えない
と判断した場合、すなわち以下の式が成り立つ場合は、 Ｔｒ・Ｔｉ≦Ｗｔ 業務判定部２５１０はトランザクション要求部２５０４
が受け取ったトランザクション要求をトランザクション
処理部２５０５に渡し、トランザクション要求を処理
し、トランザクション要求送受信部２５０４から業務ク
ライアント２５０２にトランザクション応答を返す（ス
テップ２６０７）。

【０１５９】逆に、業務判定部２５１０にて負荷予測値
が閾値を越えると予測される場合、すなわち以下の式が
成り立つ場合は、 Ｔｒ・Ｔｉ＞Ｗｔ
当該業務サーバ２でのトランザクション処理
を拒否し、トランザクション要求送受信部２５０４から
業務クライアント１にトランザクション処理の拒否を伝
える（ステップ２６０６）。なお、これに代えて、実施
例７に記載した方法によって（回覧リストの内容を各業
務サーバが記憶しておく）、自業務サーバ２よりも負荷
の低い他の業務サーバ２にトランザクション処理を依頼
するようにしてもよい。

【０１６０】このように時刻Ｔ１，Ｔ２における処理負
荷ではなく、時間Ｔｉ後の処理負荷を予測して負荷を分
散するので、急激にトランザクション処理の負荷が変動
するトランザクション処理システムにおいて、処理負荷
の集中を回避し、すべての業務サーバの負荷を均一化
し、トランザクション処理システムの処理を効率化し，
負荷の増大に伴うシステムの障害を防ぐ。

【０１６１】以上のように第９の発明によれば、急激に
トランザクション処理の負荷が変動するトランザクショ
ン処理システムにおいて、すべての業務サーバの負荷を
均一化し、トランザクション処理システムの処理を効率
化するという効果がある。

【０１６２】実施例９．図３１は、本発明の第１０，１
１の発明の一実施例である実施例９を図３１〜図３４に
より説明する．

【０１６３】本実施例の目的は、業務サーバにポーリン
グをかけて管理情報を収集すると共に、業務クライアン
トから最大待ち時間の経過を報告させることによって、
負荷増大の原因が業務サーバにあるのか、業務クライア
ントにあるのか、中継する伝送路にあるのかを判別する
ことが可能となり、速やかに負荷増大への対処を可能に
し，システムの障害を回避することにある。

【０１６４】図３１は本実施例の主要構成を示すブロッ
ク図である．図において，２７０１は伝送路、１はトラ
ンザクション要求を発行する業務クライアント、２７０
３はトランザクション要求の処理を行うトランザクショ
ン要求送受信部、２７０４は業務クライアント１におけ
るトランザクション処理経過時間を計測するトランザク
ション処理時間検出部、２７０５は業務クライアント１
においてトランザクション要求から応答までの最大待ち
時間を記憶するトランザクション処理閾時間記憶部、２
７０６は管理通信を処理する管理要求送受信部である．
なお，トランザクション要求送受信部２７０３は業務ク
ライアント１と後記の業務サ−バ２に設けられている．

【０１６５】２はトランザクション要求を処理する業務
サーバ、２７０６は管理情報を送受信する管理要求送受
信部，２７０８はトランザクション要求を処理するトラ
ンザクション処理部、２７０９は業務サーバ２の管理情
報を収集する管理情報収集部である．２７１０は業務サ
ーバと業務クライアントを監視する負荷監視マネージャ
であり，その中の２７１１は業務クライアントを管理す
るクライアント管理部、２７１２は業務サーバを管理す
るサーバ管理部、２７１３はクライアント管理部２７１
１の管理情報とサーバ管理部２７１２の管理情報を統括
するクライアント・サーバ統括管理部である。

【０１６６】図３２は業務サーバ２における動作を示す
フローチャートを示す。図３３は、業務クライアント１
における動作を示すフローチャートを示す。図３４は、
負荷監視マネージャ２７１０における動作を示すフロー
チャートを示す。

【０１６７】業務クライアント１と業務サーバ２、負荷
監視マネージャ２７１０は、伝送路２７０１を介して通
信を行う。

【０１６８】図３３において，業務クライアント１は、
予めトランザクション処理閾時間記憶部２７０５にトラ
ンザクション要求を発行してから応答が返ってくるまで
の最大待ち時間を記憶している（ステップ２９０１）。

【０１６９】業務クライアント１は、トランザクション
要求送受信部２７０３からトランザクション要求を業務
サーバ２に発行すると同時に、トランザクション処理時
間検出部２７０４がトランザクション要求発行時刻から
の経過時間の測定を開始する（ステップ２９０２）。

【０１７０】トランザクション処理閾時間記憶部２７０
５に記憶された最大待ち時間以内に応答が返ってこなか
った場合は、管理要求送受信部２７０３を介して負荷監
視マネージャ２７１０に処理遅延を報告する（ステップ
２９０３，２９０４）。なお，処理遅延の場合監視マネ
−ジャ２７１０への報告以外に，例えばユ−ザの指示待
ち，中断など任意の処理，制御をするように出来ること
はいう迄もない．

【０１７１】次ぎに図３２において，業務サーバ２は、
業務クライアント１からのトランザクション要求をトラ
ンザクション要求送受信部２７０３にて受信し、トラン
ザクション処理部２７０８がトランザクション要求を処
理する。

【０１７２】また、業務サーバ２は、定期的に管理情報
収集部２７０９がトランザクション処理部２７０８とト
ランザクション要求送受信部２７０３から要求処理負荷
の発生と処理状況などに関する管理情報を収集しており
（ステップ２８０１）、負荷監視マネージャ２７１０か
ら管理情報収集要求を受信すると（ステップ２８０
２）、管理要求送受信部２７０６を介して管理情報を応
答する（ステップ２８０３）。

【０１７３】負荷監視マネージャ２７１０は、ポーリン
グによって業務サーバ２を管理し、図３３のステップ２
９０４のようなイベントによって業務クライアント１を
管理する。

【０１７４】図３４において，サーバ管理部２７１２
は、管理要求送受信部２７０６を介して業務サーバ２に
管理情報収集要求（ポーリング）を行なう．（ステップ
３００１）。ポーリングの時間間隔はクライアント・サ
−バ統轄管理部２７１３がポーリングによって得られた
業務サーバの負荷傾向を分析することによってポーリン
グの時間間隔を学習的に最適化する。すなわち、ポーリ
ングによって得られた負荷の変動が小さい場合にはポー
リングの時間間隔を大きくし、逆に変動が大きい場合に
は時間間隔を小さくして負荷状況を頻繁に監視すること
により、ポーリングの時間間隔を最適化する。なお、ポ
ーリングの時間間隔には、システム起動時に予め規定値
を設定してもよい．

【０１７５】クライアント管理部２７１１は、業務クラ
イアント１から非同期に送信される管理報告を管理要求
送受信部２７０６を介して受信する。

【０１７６】ポーリングの結果、業務サーバ１に異常が
発見され、クライアント管理部２７１１において管理報
告を受信した時は、クライアント・サーバ統括管理部２
７１３は、業務サーバ２に障害が発生したと判断する
（ステップ３００２，３００３，３００４）。

【０１７７】ポーリングの結果、業務サーバ２に異常が
発見され、クライアント管理部２７１１において管理報
告を受信していないときは、クライアント・サーバ統括
管理部２７１３は、業務サーバ２７０７および伝送路２
７０１に障害が発生したと判別する（ステップ３００
２，３００３，３００５）。

【０１７８】ポーリングの結果、業務サーバ２に異常が
発見されず、クライアント管理部２７１１において管理
報告を受信した時は、クライアント・サーバ統括管理部
２７１３は、伝送路２７０１に障害が発生したと判別す
る（ステップ３００２，３００６，３００７）。

【０１７９】上記以外の場合は、クライアント・サーバ
統括管理部２７１３は、システムが正常であると判断す
る。このように、業務クライアント１からマネージャへ
高負荷検出のイベントを送信して業務サーバ２の負荷状
況を監視することができるので、業務サーバ２に対する
ポーリング間隔を短くしなくても業務サーバ２の負荷を
迅速に検出することが可能になり、さらに業務クライア
ント１と業務サーバ２間のネットワークの障害も検出す
ることもできる。この様にして，負荷増に伴うトランザ
クション処理の障害を未然に防止対策をとることができ
る．

【０１８０】以上のように第１０，１１の発明によれ
ば、業務サーバにポーリングをかけて管理情報収集する
と共に、業務クライアントから最大待ち時間の経過を報
告させることによって、負荷増大の原因が業務サーバに
あるのか、業務クライアントにあるのか、中継する伝送
路にあるかを判別することが可能となり、速やかに負荷
増大への対処を施すことができるという効果がある。

【０１８１】実施例１０．本実施例１０は本発明の第１
２の実施例である．以下，図３５〜４０を参照して説明
する．

【０１８２】本実施例は，従来の技術と異なり，業務サ
ーバプロセスを増減するのに負荷情報を常時収集しない
で負荷分散するものである。

【０１８３】図３５は本発明の第１２の発明における一
実施例の構成を示したものである。図において、３１０
１はマネージャである。その内部の３１０２はマネージ
ャ３１０１の管理情報を入出力する手段を持つマネージ
ャ管理情報入出力処理部、３１０３は業務サーバプロセ
スを起動する手段を持つサーバ起動部、３１０４は業務
クライアントからの要求を業務サーバプロセスに振り分
ける手段を持つサーバ振り分け処理部、３１０５は通信
を行う手段を持つ通信処理部である。

【０１８４】２は業務サーバである。３１１６は業務サ
−バプロセスで，それは次ぎにより構成される．即ち，
３１１２はサーバの負荷状態を知り，高負荷判定基準を
持つ負荷監視部、３１１３は業務クライアントの要求の
処理を行う手段を持つクライアント要求処理部、３１１
４はサーバの自己消去を行う手段を持つ自己消去部、３
１１５は通信する手段を持つ通信処理部である。なお，
業務サ−バ２は図３５では１台であるが，複数でもよ
い．

【０１８５】１は業務クライアントである。その内部の
３１２２はクライアント処理を行う手段を持つクライア
ント処理部、３１２３は通信する手段を持つ通信処理部
である。図３５では１台であるが，複数でもよい．図３
６はマネ−ジャ３１０１のサ−バ振り分け処理部３１０
４内のサ−バプロセス管理テ−ブルｃの構成を示し，そ
れを構成するものがプロセス名３１５１，作成条件３１
５２（例えば，１度に作成のプロセス数他），高負荷を
決定する条件３１５３（例えば，トランザクションのキ
ュ−の数，高負荷と判定する基準ロ−ドなど他），自己
消去する条件３１５４（例えば，作成後消去する時間
他），登録されたサ−バプロセスのアドレス３１５５な
どである．なお，登録されたサ−バプロセスのアドレス
３１５５には生成されている業務サ−バプロセス３１１
６のアドレスが書き込まれる．図３７はマネ−ジャ３１
０１の振り分けテ−ブル３１６０の構成でプロセス名３
１６１，振り分けを再開する時刻３１６２よりなる．な
お，時刻を測定する手段は構成図に図示していないが，
業務サ−バプロセス３１１６，マネ−ジャ３１０１は共
にこれをもっている．

【０１８６】次に上記実施例の動作を図３６，３７，３
８，３９，４０を参照しながら説明する。図３８はマネ
ージャ３１０１の、図３９は業務サーバプロセス３１１
６の、図４０は業務クライアント１のフローチャートで
ある。マネージャ３１０１の動作、業務サーバプロセス
３１１６の動作、業務クライアント１の動作の順に説明
する。

【０１８７】マネージャ３１０１の動作について説明す
る。初期化、業務サーバプロセス３１１６から受信した
時の動作、業務クライアント１から受信したときの動作
の順に説明する。

【０１８８】図３８において，マネージャ３１０１の初
期化の動作について説明する（ステップ３２０２）。マ
ネージャ３１０１は起動時に、マネージャ管理情報入出
力処理部３１０２より、新たに業務サーバプロセス３１
１６を作成し実行可能状態にするよう要求があった場
合，それを作る条件（例えば作成する個数）、サーバが
高負荷と判定する条件（例えばＣＰＵのロードアベレー
ジ、トランザクションの発生数）、新たに発生する業務
サーバプロセス３１１６が自己消去する条件（例えば決
められた一定の時間が経過したら自己消去する）を入力
し，図３６のプロセス管理テーブルｃ ３１５０をサ−
バ振り分け処理部３１０４に設定する。これらの条件は
マネージャ管理情報入出力部３１０２により変更でき
る。なおマネージャ管理情報入出力部３１０２によりこ
れらの条件や各部状況を出力できる（ステップ３２０
２）。

【０１８９】マネージャ３１０１が業務クライアント１
から受信した時の動作について説明する。マネージャ３
１０１の通信処理部３１０５が業務クライアント１から
受信したら（ステップ３２０３）、その内容をサーバ振
り分け処理部３１０４に渡す。振り分け処理部３１０４
はプロセス管理テ−ブルｃ ３１５０のプロセス名３１
５１によりアクセスできる業務サーバプロセス３１１６
が登録されているか確認する（ステップ３２０４）。

【０１９０】登録されていれば、登録されている業務サ
ーバプロセス３１１６からランダムに選択し業務クライ
アント１に通知する（ステップ３２０６）。

【０１９１】登録されていない場合（ステップ３２０
４）は、サーバ起動部３１０３に業務サーバプロセス３
１１６を起動することを要求する。サーバ起動部３１０
３は業務サーバプロセス３１１６に存在できる時間，自
己消去する条件３１５４と高負荷を決定する条件３１５
４を与えて起動を業務サ−バ２に対して起動をかける．
起動をかけた業務サ−バプロセス３１１６のアドレスを
受信し，マネ−ジャ管理情報入出力処理部３１０２，振
り分け処理部３１０４はそのアドレスをプロセス管理テ
−ブルｃ ３１５０の登録されたサ−バプロセスのアド
レス３１５５に登録する（ステップ３２０５）。そして
業務クライアント１に通信処理部３１０５を用いて通知
する（ステップ３２０６）。

【０１９２】次ぎに，マネージャ３１０１が業務サーバ
プロセス３１１６から受信したときの動作について説明
する（ステップ３２０３）。マネージャ３１０１の通信
処理部３１０５は業務サ−バプロセス３１１６の要求を
受信するとサーバ振り分け処理部３１０４に渡す。

【０１９３】もし処理依頼が消去であれば（ステップ３
２０７）、サーバ振り分け処理部３１０４はその業務サ
ーバプロセス３１１６の登録をプロセス管理テ−ブルｃ
３１５０から解除し、解除したことを通信処理部３１
０５を使用し業務サーバプロセス３１１６に通知する
（ステップ３２０８）。

【０１９４】もし依頼内容が起動であれば（ステップ３
２０７）、サーバ振り分け処理部３１０４はサーバ起動
部３１０３を使用し、新たな業務サーバプロセス３１１
６を存在する時間の条件即ち，自己消去する条件と高負
荷を判断する条件を与え起動する。起動された業務サ−
バプロセス３１１６のアドレスを受信し，サーバ振り分
け処理部３１０４はそのアドレスを登録されたサ−バプ
ロセスのアドレス３１５５に登録する（ステップ３２０
９）。

【０１９５】次に業務サーバプロセス３１１６の動作に
ついて説明する。初期化、業務クライアント１の処理要
求を受信した時の動作、負荷が高いときの動作、自己消
去条件を満たしたときの動作の順に説明する。

【０１９６】図３９において，初期化ではマネージャ３
１０１に自己消去する条件と高負荷を判断する条件をサ
−バ振り分け処理部３１０４から与えられ起動される
（ステップ３３０２）。

【０１９７】業務クライアント１の処理要求を受信した
ときの動作について説明する（ステップ３３０３）。業
務クライアント１より処理要求を受信すると業務サーバ
プロセス３１１６は、クライアント要求処理部３１１３
に渡し要求を処理する（ステップ３３０４）。業務クラ
イアント１へ処理結果を返信する（ステップ３３０
５）。

【０１９８】業務サーバプロセス３１１６が高負荷にな
った時の動作を説明する。業務サーバプロセス３１１６
は負荷監視部３１１２から得た負荷が高負荷の判定条件
を満たしたら（ステップ３３０６）、通信処理部３１１
５を使用してマネージャ３１０１に新たな業務サーバプ
ロセス３１１６の作成を要求し，図３８のステップ３２
０９の処理がなされる（ステップ３３０７）。

【０１９９】業務サーバプロセス３１１６が自己消去す
る時の動作について説明する。業務サーバプロセス３１
１６は自己消去する条件３１５４を満たすと（ステップ
３３０８）、マネージャ３１０１に自己消去することを
通知し返信を得る（ステップ３３０９）。なお，この時
マネ−ジャ３１０１は図３８のステップ３２０８の処理
をする．そして業務サーバプロセス３１１６は自己消去
部３１１４を使用し自己消去する（ステップ３３１
０）。

【０２００】なおフローチャート図３９では、業務クラ
イアント１の処理要求を受信した時の動作、負荷が高い
時の動作、自己消去条件を満たした時の動作の順に説明
しているが、この順番は変更してもよい。

【０２０１】次に業務クライアント１の動作について図
４０により説明する。業務クライアント１はマネージャ
３１０１のアドレス情報を得るなどの初期化を行う（ス
テップ３４０２）。クライアント処理部３１２２は業務
サーバプロセス３１１６に処理を要求する場合、通信処
理部３１２３を用い、どの業務サーバプロセス３１１６
にアクセスするか情報を得るため、まずマネージャ３１
０１にアクセスし情報を得る（ステップ３４０３）。こ
の時，マネ−ジャ３１０１は図３８のステップ３２０４
〜３２０６の処理をする．業務クライアント１はその業
務サーバプロセス３１１６に通信処理部３１２３を用い
てアクセスする（ステップ３４０４）。

【０２０２】このようにすることにより、従来のように
業務サーバプロセス３１１１を増減するのに負荷情報を
常時、収集することがないのでマネージャ３１０１や業
務サーバプロセス２に負荷を軽くし、また通信トラフィ
ック量も小さくでき、負荷分散ができる。

【０２０３】上記実施例ではランダムに業務サーバプロ
セス３１１６を振り分けた。しかし、新しい業務サーバ
プロセス３１１６ほどキューに溜っているトランザクシ
ョンの数が少ないと考えられるので、負荷の低い新しい
業務サーバプロセス３１１６ほど振り分ける確率を高く
すると，より良い負荷分散ができる。

【０２０４】上記実施例ではランダムに業務サーバプロ
セス３１１６を振り分けたが、新しい業務サーバプロセ
ス３１１６ｂを作ることを要求した業務サーバプロセス
３１１６ａには指定された時間の間、業務クライアント
１の要求を振り分けない方法をとることにより、きめ細
かく実効を上げより良い負荷分散ができる。即ち，業務
サ−バプロセスプロセス３１１６ａは通常高負荷である
ため，新しい業務サ−バプロセス３１１６ｂの作成を要
求する．このため，指定時間内は業務サ−バプロセス３
１１６ａへの業務クライアント１の要求振り分けを保留
し，負荷の増大を抑える．具体的にはマネージャ３１０
１のサ−バ振分処理部３１０４が図３７の振り分けテー
ブル３１６０を持つ。業務サーバプロセス３１１６ａか
ら新たな業務サーバプロセス３１１６ｂを作るように要
求があったらマネージャ３１０１は現在時刻にあらかじ
め決められた一定の時間を加えてテーブルに書き込みそ
れを振り分け再開時刻とする。振り分ける時、そのプロ
セス３１１６ａが振り分け再開時刻を経過していなけれ
ばそれに振り分けずに他の業務サーバプロセス３１１６
ｂに振り分ける。このようにすることにより、新しく作
成し，未だ負荷の低い業務サーバプロセス３１１６ｂに
負荷を分散できる。

【０２０５】上記実施例の新たな業務サーバプロセス３
１１６が消去する条件としては、ある一定時間後に自己
消去、トランザクションをある回数だけ実行後に自己消
去する、トランザクション処理を受け付けなくなってか
ら一定時間後に自己消去するなどの条件がある。

【０２０６】上記実施例では業務サーバプロセス３１１
６はある条件で自己消滅してしまうが、業務サーバプロ
セス３１１６がマネージャ３１０１に消去することを通
知する時に負荷監視部３１１２から得た負荷が高いとき
はそれも併せて通知し，マネージャ３１０１のサーバ振
り分け処理部３１０４が業務サーバプロセス３１１６の
存在時間を延長することを通信処理部３１１５を用いて
業務サーバプロセス３１１６に通知するようにしてもよ
い。この方法をとると負荷が高い状態が続くとき、業務
サーバプロセス３１１６が自動的に消去され再立ち上げ
をするための無駄な時間を減らすことができる。

【０２０７】以上のように第１２の発明によれば、従来
と違い負荷情報を常に収集しなくても、サーバプロセス
の数を増減し、適度に負荷を分散できるので負荷が増大
してもシステムの障害を抑制する効果がある。

【０２０８】実施例１１．本発明の第１３の発明の１実
施例である実施例１１を図４１〜４５を用いて説明す
る．本実施例のポイントは負荷情報を収集するためのマ
ネージャやサーバの負荷とトラフィック量も減らすこと
と、サーバの負荷が高い時業務クライアントのサーバへ
のアクセスを減らし負荷分散を行うことにある。

【０２０９】図４１は第１３の発明における一実施例を
示したものである。図において、３５０１はアクセス制
御装置である。その内部の３５０２はアクセス制御装置
の管理情報を入出力する手段を持つアクセス制御管理情
報入出力処理部、３５０３はアクセス制御を行う手段を
持つアクセス制御処理部、３５０４は通信を行う手段を
持つ通信処理部である。

【０２１０】２は業務サーバである。その内部の３５１
２は業務サーバの管理情報を入出力する手段を持つサー
バ管理情報入出力処理部、３５１３は業務サーバの負荷
状態を知る手段を持つ負荷監視部、３５１４は業務クラ
イアントへアクセス権の付与を決定する手段を持つアク
セス権付与決定部、３５１５は業務クライアントの要求
の処理を行う手段を持つクライアント要求処理部、３５
１６は通信する手段を持つ通信処理部である。１は業務
クライアントである。その内部は３５２２は業務クライ
アント処理を行う手段を持つクライアント処理部、３５
２３は通信する手段を持つ通信処理部である。図４２は
業務サ−バ２のサ−バ管理情報入出力処理部３５１２の
アクセス制御テ−ブル３５５０の構成を示す．

【０２１１】次に上記実施例の動作を図４３，４４，４
５を参照しながら説明する。図４３はアクセス制御装置
３５０１の、図４４は業務サーバ２の、図４５ は業務
クライアント１のフローチャートである。アクセス制御
装置３５０１の動作、業務サーバ２の動作、業務クライ
アント１の動作の順に説明する。

【０２１２】まず、図４３によりアクセス制御装置３５
０１の動作について説明する。アクセス制御装置３５０
１の通信処理部３５０４が業務クライアント１から受信
したら（ステップ３６０２）、その内容をアクセス制御
処理部３５０３に渡す。アクセス制御処理部３５０３は
業務クライアント１がどの業務サーバ２にアクセスでき
るかを調べる。その結果、アクセスできる業務サーバ２
があれば（ステップ３６０３）、当該業務サ−バ２にア
クセスできることを証明する証明チケットを業務クライ
アント１に通信処理部３５０４を用いて送信する（ステ
ップ３６０４）。アクセスできる業務サーバ２がなけれ
ば（ステップ３６０３）、アクセスできる業務サ−バ２
はないことを業務クライアント１に送信しる（ステップ
３６０５）。

【０２１３】もし業務サーバ２から受信したら（ステッ
プ３６０２）、アクセス制御装置３５０１の通信処理部
３５０４はアクセス制御処理部３５０３にその情報を渡
す。アクセス制御処理部３５０３はその業務サーバ２に
アクセスできる業務クライアント１を変更する（ステッ
プ３６０６）。この変更処理は次ぎに詳述する．

【０２１４】次に業務サーバ２の動作について図４４，
４２を用いて説明する。初期化、業務クライアント１の
処理要求を受信したときの動作、アクセスできる業務ク
ライアント１の範囲を変更するときの動作の順に説明す
る。

【０２１５】業務サーバ２の初期化（ステップ３７０
２）について，業務サーバ２はサーバ管理情報入出力処
理部３５１２内で、図４２に示すアクセス制御テーブル
３５５０の業務クライアント１のアクセスの優先順位が
入力設定される。即ち，図のサ−バ名３５５１毎にクラ
イアントのアクセス優先順位３５５２と，負荷の程度に
応じてアクセス出来る業務クライアント１の範囲を示す
負荷３５５３が入力される．その情報をアクセス権付与
決定部３５１４におくる。なお，サーバ管理情報入出力
部３５１２によりこれらの条件や各部状況を出力でき
る。

【０２１６】業務サーバ２は通信処理部３５１６が業務
クライアント１からの要求を受け取ったら（ステップ３
７０３）、クライアント要求処理部３５１５に渡す。ク
ライアント処理部３５１５では証明チケットが正しいか
を確認し、正しければ（ステップ３７０４）業務クライ
アント１の要求を処理し（ステップ３７０５）、クライ
アントへ処理結果を返信する（ステップ３７０６）。証
明チケットが正しくなければ（ステップ３７０４）業務
クライアント１の要求処理を行わない。

【０２１７】次に業務サーバ２が業務クライアント１に
アクセス権を付与する時の動作を説明する。業務サーバ
２のアクセス権付与決定部３５１４は負荷監視部３５１
３から負荷情報をもらう。その負荷情報とプロセス制御
テ−ブル３５５０が設定している負荷に応じてアクセス
できる業務クライアント１の条件により、アクセス権付
与決定部３５１４はアクセスできる業務クライアント１
を決定し（ステップ３７０７）、負荷の増減により業務
クライアント１のアクセス範囲に変更があれば（ステッ
プ３７０８）その情報を通信処理部３５１６を用いて、
アクセス制御装置３５０１に送る（ステップ３７０
９）。これは，図４３のアクセス制御装置３５０１の動
作のステップ３６０６に繋がる．これにより，アクセス
制御装置３５０１が業務スライアント１からの要求に対
して正確に前記の証明チケットを発行する．

【０２１８】なおフローチャート図４４では、業務クラ
イアント１の処理要求を受信した時の動作、アクセスで
きる業務クライアント１の範囲を変更する時の動作の順
であるがこの順番は変更してもよい。

【０２１９】次に業務クライアント１の動作を図４５に
より説明する。業務クライアント１はアクセス制御装置
３５０１のアドレスを得るなどの初期化作業を行う（ス
テップ３８０２）。クライアント処理部３５２２は業務
サーバ２に処理を要求する場合、通信処理部３５２１を
用いどの業務サーバ２にアクセスするかの情報を得るた
めまずアクセス制御装置３５０１にアクセスする（ステ
ップ３８０３）。そして業務クライアント１は証明チケ
ットを渡されたら、その業務サーバ２に通信処理部３５
１６を用いてアクセスする（ステップ３８０４）。

【０２２０】このようにすることにより、業務サーバ２
は負荷が高い時は狭い範囲の業務クライアント１のみの
要求を受け付け、負荷が低いときは広い範囲の業務クラ
イアント１の要求を受け付ける。このため業務サーバ２
の負荷が高い時業務クライアント１の業務サーバ２への
アクセスを減らし負荷の低い業務サーバ２に負荷を分散
できる。また従来のように負荷情報を常に収集しないの
でアクセス制御装置３５０１や業務サーバ２の負荷とト
ラフィック量も減らすことができる。また、すべての業
務サーバ２の負荷が高い場合にも、業務クライアント１
からの要求を受け付けてしまうこともあったが、業務サ
ーバ２にアクセスする前にアクセス制御装置３５０１に
より割り当てられないため、業務サーバ２が業務クライ
アント１の要求を拒絶する作業の負荷がなくなった。こ
のようにして，トランザクション処理負荷が増大して
も，システムへの障害が未然に防げる．

【０２２１】上記実施例では、業務サーバ２と業務クラ
イアン１は各々１つの場合を考えたがそれぞれ複数あっ
ても構わない。

【０２２２】以上のように第１３の発明によれば、従来
のものよりマネージャやサーバの負荷とトラフィック量
も減らして負荷分散ができる効果がある。

【０２２３】実施例１２．本発明の第１４の発明の実施
例１２を図４６〜４７を用いて説明する．本実施例１２
のポイントはユーザデータの少ない時間を使用して、軽
度な障害の情報、負荷分散を行うための負荷情報，管理
情報の詳細等を得ることにある。

【０２２４】図４６は本実施例の構成を示したものであ
る。図において、３９０１はデータ量制御装置である。
その内部の３９０２は各部の初期条件の設定や条件の変
更の情報を入出力する手段を持つ管理情報入出力部、３
９０３はデータを入力する手段を持つデータ入力部、３
９０４は入力されたデータの重要度を識別する手段を持
つ重要度識別部、３９０５はデータの時間あたりの数を
カウントする手段とデータカウント部、３９０６はデー
タを取捨選択する手段を持つデータ取捨選択部、３９０
７はデータを出力する手段を持つデータ出力部、３９０
８はデータ取捨選択部により捨てられたデータを廃棄す
る手段を持つデータ廃棄部である。

【０２２５】次に上記実施例の動作を図４７を参照しな
がら説明する。まず初期化について説明し、次に通常の
動作について説明する。

【０２２６】初期化の動作について説明する（ステップ
４００２）。データ量制御装置３９０１は、管理情報入
出力部３９０２を使用することにより、重要度識別部３
９０４が重要度を識別する条件、データ取捨選択部３９
０６が、データを取捨する条件を入力する。これらの条
件は管理情報入出力部３９０２により随時変更できる。
なお管理情報入出力装置３９０２によりこれらの条件や
各部状況を出力できる。

【０２２７】次に通常の動作を説明する。データはデー
タ入力部３９０３より入力され（ステップ４００３）、
重要度識別部３９０４に送られる。そのデータは重要度
識別部３９０４により、重要度のランクづけをされる
（ステップ４００４）。絶対に出力しなければならない
データは（ステップ４００５）、データカウント部３９
０５に送られる。それ以外のデータはデータ取捨選択部
３９０６に送られる。データカウント部３９０５は送ら
れてくるデータの単位時間当たりの数を測定し、データ
をデータ出力部３９０７に送る。測定した単位時間当た
りの数をデータ取捨選択部３９０６に送る（ステップ４
００６）。データ取捨選択部３９０６は送られてきた単
位時間当たりの数というデータとデータを取捨する条件
によりデータを取捨し廃棄するか決めるが，単位時間当
りのデ−タ数が多いと重要度の高いデ−タが出力されて
それが低いデ−タは廃棄され，デ−タ数が少ないと需要
度の低いデ−タも出力される（ステップ４００７）。廃
棄されたデータはデータ廃棄部３９０８に送られ廃棄さ
れる（ステップ４００９）。廃棄されなかったデータは
データ出力部３９０７に送られる。データ出力部３９０
７では送られてきたデータを出力する（ステップ４００
８）。

【０２２８】この発明を業務サーバまたは業務クライア
ントに取り付けることにより、トランザクション処理の
ユーザデータと負荷情報・障害情報・管理情報・診断情
報等のデータを扱うことが考えられる。上記の実施例で
いうと絶対出力しなければならないデータはユーザデー
タとユーザデータ以外の非常に重要な情報のみである。
データ取捨選択部３９０６に送られるデータは重要度の
ランクを付けられる。データカウント部３９０５の送ら
れたデータの単位時間の数により、その数が多いときは
データ取捨選択部３９０６に送られたデータのうち重要
度の高いデータのみを出力し、少ないときは重要度の低
いデータも出力する。このように、ユーザデータが単位
時間当たりの多いときはユーザデータを多く出力でき、
少ないときは他の情報も送ることができる。このため、
ユーザデータの少ない時間を使用して、軽度な障害の情
報、負荷情報の詳細等を送ることができる。

【０２２９】以上のように請求項１４の発明によれば、
重要なデータの単位時間の発生具合により、データを重
要度に応じて取捨選択し出力でき，トランザクション負
荷が増大してもその処理が阻害されない。

【０２３０】実施例１３．本発明の第１５，１６，１７
の発明の１実施例である実施例１３を図４８〜５２を用
いて説明する．本実施例１３のポイントは従来のように
一つのデータベースにアクセスが集中するのを防ぎ、従
来のものより業務サーバの負荷を分散し、トラフィック
量も減らすことにある。

【０２３１】一般に，デ−タの精度，整合性等の維持の
ためには集中管理が便利である．一方，デ−タへのアク
セスは例えば，混雑時期の乗物の指定券の発売当初，或
は企業内デ−タの昼間と夜間の様に，アクセス負荷のピ
−クが発生するが，ある時期を過ぎればアクセス負荷は
減少して平常或は低負荷に戻る場合が多い．本発明は，
この様に時間的要因の下で，デ−タの集中管理をしなが
らピ−ク時には一時的にデ−タを分散し，アクセス負荷
を分散して，レスポンス性能の維持を図る．このよう
に，集中と分散という実際には多くの場面で発生し相反
する要求を満たすものである．

【０２３２】図４８は第１５，１６，１７の発明の構成
例を示したものである。図において、２は上位業務サー
バである。その内部の４１０２はデータ情報を入出力す
る手段を持つデータ情報入出力部、４１０３は時刻を取
得する手段を持つ時刻取得部、４１０４はデータの移動
処理を行う手段を持つデータ移動処理部、４１０５はデ
ータを記憶する手段を持つ記憶部、４１０６は業務クラ
イアントの要求の処理を行う手段を持つクライアント要
求処理部、４１０７は通信する手段を持つ通信処理部で
ある。

【０２３３】３ａ，ｂは下位業務サーバである。その内
部の４１１２ａ，４１１２ｂは時刻を取得する手段を持
つ時刻取得部、４１１３ａ，４１１３ｂはデータの移動
処理を行う手段を持つデータ移動処理部、４１１４ａ，
４１１４ｂはデータを記憶する手段を持つ記憶部、４１
１５ａ，４１１５ｂは業務クライアントの要求の処理を
行う手段を持つクライアント要求処理部、４１１６ａ，
４１１６ｂは通信する手段を持つ通信処理部である。

【０２３４】１ａ，１ｂ，１ｃは業務クライアントであ
る。その内部の４１２２ａ，４１２２ｂ，４１２２ｃは
業務クライアント処理を行う手段を持つクライアント処
理部、４１２３ａ，４１２３ｂ，４１２３ｃは通信する
手段を持つ通信処理部である。図４９はチケットデ−タ
情報４２５０の構成を示し，例えば，乗物の座席予約な
ら，品名は便名，等級区分などからなり，在庫は座席番
号と予約のフラッグ等のセットの一覧等，上位サ−バに
デ−タを移動する時刻は上位業務サ−バ２にデ−タを移
動する設定時刻で通常アクセス負荷が減少する時刻等か
らなる．

【０２３５】次に上記実施例の動作を図５０、図５１、
図５２を参照しながら説明する。図５０は上位業務サー
バ２の、図５１は下位業務サーバの３ａ〜ｂの、図５２
は業務クライアント１ａ〜ｃのフローチャートである。
本発明が適用されるデータは限定されないが，ここでは
例えば座席予約のチケットの例を説明する。動作の概略
はまず上位サーバ２が下位サーバ３ａ〜ｂにチケットデ
ータを配布する。決められた時間を経過すると下位サー
バ３ａ〜ｂが上位サーバ２にチケットデータを移動し，
在庫を引き渡す。また、全業務サーバ２，３ａ〜ｂは業
務クライアント１ａ〜ｃの要求を処理する。

【０２３６】詳細な動作を上位業務サーバ２の動作、下
位業務サーバの３ａ〜ｂの動作、業務クライアント１ａ
〜ｃの動作の順に説明する。

【０２３７】まず上位業務サーバ２の動作について図５
０により説明する。初期化、下位業務サーバ３ａ〜ｂへ
データを配布するときの動作、業務クライアント１ａ〜
ｃ処理の要求を受けた時の動作の順に説明する。

【０２３８】上位業務サーバ２が下位業務サーバ３ａ〜
ｂに図４９に示すチケットデータ情報４２５０を配布す
る初期化動作について説明する（ステップ４２０２）。
上位業務サーバ２にはデータ情報入出力部４１０２から
チケットデータ情報（品名、どの下位業務サーバ３ａ〜
ｂに何枚配布するかの在庫（ここでは予約可能座席
数）、下位業務サーバ３ａ〜ｂから上位業務サーバ２に
データの在庫を移動する時刻等）を入力する。データ移
動処理部４１０４はチケットデータ情報４２５０を通信
処理部４１０７を使用して下位業務サーバ３ａ〜ｂに与
え，その分は上位業務サ−バ２の在庫から差し引く（ス
テップ４２０３）。

【０２３９】次に上位業務サーバ２が業務クライアント
１ａ〜ｃから座席予約のチケット発行処理を要求された
時の上位業務サーバ２の動作を説明する。以下では業務
クライアント１ａに上位業務サーバ２が処理を要求され
た例について述べる（ステップ４２０４）。上位業務サ
ーバ２の通信処理部４１０７はクライアント要求処理部
４１０６に業務クライアント１の要求をわたす。

【０２４０】クライアント要求処理部４１０６は記憶部
４１０５を利用して上位業務サーバ４１０１の在庫で足
りれば，即ち，空席があれば（ステップ４２０５）、業
務クライアント１ａの要求を処理する（ステップ４２０
９）。

【０２４１】もし上位業務サーバ２の在庫で必要な予約
可能座席が不足し（ステップ４２０５），かつ時刻取得
部４１０３の時刻と記憶部４１０５に保持するチケット
デ−タ情報４２５０の上位業務サ−バにデ−タを移動す
る時刻との比較により，在庫移動時刻を経過していると
判定すれば（ステップ４２０６）、全下位業務サーバ３
ａ〜ｂにも在庫がないので在庫不足であると業務クライ
アント１ａに通知する（ステップ４２１０）。なぜなら
ば、在庫移動時刻を経過すると全下位業務サーバ３ａ〜
ｂから上位業務サーバ２に在庫が移動する。そのためチ
ケットの在庫が存在するとすれば上位業務サーバ２のみ
である。その上位業務サーバ２にも在庫がなければ全サ
ーバにも在庫がないためである。

【０２４２】上位業務サーバ２の在庫で不足し（ステッ
プ４２０５）、かつ在庫移動時刻を経過していない場合
（ステップ４２０６）、他の全下位業務サーバ３ａ〜ｂ
に在庫引当を確保するため分散トランザクションを行う
（ステップ４２０７）。分散トランザクションを行った
結果、在庫が足りれば（ステップ４２０８）業務クライ
アント１ａの要求を処理し（ステップ４２０９）し、在
庫が足りなければ（ステップ４２０８）在庫不足である
と業務クライアント１ａに送信する（ステップ４２１
０）。

【０２４３】以上、業務クライアント１ａにから処理要
求があった場合について述べたが、業務クライアント１
ｂ〜ｃについても同様である。

【０２４４】次に下位業務サーバ３ａ〜ｂの動作につい
て図５１により説明する。ここでは、下位業務サーバ３
ａを例にとり説明する。下位業務サーバ３ａの動作は大
きく分けると業務クライアント１ａ〜ｂから処理を要求
された時の動作、在庫移動時刻を経過した時の動作、他
の業務サーバ２，３ｂから処理の要求があった時の動作
の順に説明する。

【０２４５】下位業務サーバ３ａが業務クライアント１
ａ〜ｃから座席予約のチケット発行処理を要求された時
の動作を説明する。ここでは業務クライアント１ａから
処理を要求された時の例を述べる。下位業務サーバ３ａ
の通信処理部４１１６ａはクライアント要求処理部４１
１５ａに処理要求をわたす（ステップ４３０２）。

【０２４６】クライアント要求処理部４１１５ａは記憶
部４１１４ａを利用して自己の在庫で足りれば（ステッ
プ４３０３）、業務クライアント１ａの要求を処理する
（ステップ４３０９）。

【０２４７】下位業務サーバ３ａの在庫で足りなく（ス
テップ４３０３）、かつ時刻取得部４１１２ａの時刻と
記憶部４１１４ａに保持するチケットデ−タ情報４２５
０の上位サ−バにデ−タを移動する時刻との比較によ
り，在庫移動時刻を経過していないと判断した場合（ス
テップ４３０４）、全サーバ２，３ｂに在庫を確保する
ため分散トランザクションを行う（ステップ４３０
５）。下位業務サーバ３ａの在庫で足りなく（ステップ
４３０３）かつ在庫移動時刻を経過している場合（ステ
ップ４３０４）、他の全ての下位業務サーバ３ａ〜ｂに
は在庫がないので、上位業務サーバ２のみに在庫を確保
するため分散トランザクションを行う（ステップ４３０
６）。

【０２４８】分散トランザクションをした結果、在庫を
確保できれば（ステップ４３０７）業務クライアント１
ａの要求を処理し（ステップ４３０９）、在庫が確保で
きなければ在庫不足であると要求があった業務クライア
ントａに送信する（ステップ４３０８）。

【０２４９】以上業務クライアント１ａから処理を要求
された下位業務サーバ３ａの例について述べたが業務ク
ライアント１ｂ〜ｃについても同様である。

【０２５０】次ぎに，下位業務サーバ３ａが上位業務サ
ーバ２に在庫データを移動する動作について説明する。
デ−タ移動処理部４１１３ａは時刻取得部４１１２ａか
ら時刻を入手し、記憶部４１１４ａに保存のチケットデ
−タ情報４２５０を上位業務サ−バにデ−タを移動する
時刻との比較で在庫移動時刻になったと判定すれば（ス
テップ４３１１）、在庫を上位業務サーバ２に移動する
（ステップ４３１２）。つまり、移動後の下位業務サー
バ３ａのチケットデータ情報４２５０の在庫フィールド
は０となり、上位業務サーバ２のチケットデータ情報４
２５０の在庫のフィールドは下位業務サーバ３ａの持っ
ていた枚数分増加する。

【０２５１】下位業務サーバ３ｂが他の業務サーバ２，
３ｂから処理要求があった時（ステップ４３０２）の動
作について説明する。処理要求が上位業務サーバ２から
のデータの配布であれば（ステップ４３２１）、そのデ
ータを記憶する（ステップ４３２２）。処理要求が他の
業務サーバ２，３ｂから分散トランザクション処理の要
求であれば（ステップ４３２１）、分散トランザクショ
ン処理を実行させられる（ステップ４３２３）。これ
は，図５０の上位業務サ−バ２のフロ−でステップ４２
０７の処理に繋がっている．

【０２５２】以上下位業務サーバ３ａについて説明した
が、下位業務サーバ３ｂについても同様である。また，
在庫移動時刻は必要により，年月日或は指定の時点から
の経過時間（単位は任意）を組み合せた時刻でもよい．
また，在庫移動時刻はチケットデ−タ情報４２５０によ
り通知しているが，他の方法によって指定，通知しても
よい．例えば，上位業務サ−バ２からチケットデ−タと
は別に通知，或はネットワ−クに接続の任意の計算機か
ら通知，特定の計算機が移動された各サ−バの在庫の残
数を把握して一定の残数以下になれば在庫を移動させえ
る，更に，時間指定ではなく直接移動を指示する等の方
法でもよい．

【０２５３】次に業務クライアント１ａ〜ｃの動作につ
いて図５２により説明する。業務クライアント１ａは業
務サーバ２，３ａ〜ｂのアドレスを得るなどの初期化を
行う（ステップ４４０２）。この詳細は本発明に直接関
係ないので省略する．クライアント処理部４１２２ａが
通信処理部４１２３ａを使用しサーバに処理を依頼する
（ステップ４４０３）。以上業務クライアント１ａにつ
いて述べたが、業務クライアントｂ，ｃについても同様
である。

【０２５４】このように各サーバが記憶部４１０５，４
１１４を持つので従来のように一つのデータベースのよ
うな記憶部にアクセスが集中するのを防ぎ、従来のもの
より業務サーバの負荷を分散できる。またチケットの在
庫データのような時間が経過するにつれて減少するデー
タを扱うと在庫が分散されているので在庫がどこに存在
するかわからなくなる可能性がある。しかし本方法では
時間が経過すると一箇所のサーバに在庫が集中するため
在庫管理も容易である．また，下位業務サ−バ３を任意
の群に区分し，群ごとに在庫移動時刻を設定すれば，時
間により各サーバが分散トランザクションを行う通信相
手も限られてきて通信量が減り、サーバの負荷も減少で
きる。この場合，図５０のステップ４２０６，図５１の
ステップ４３０４，４３１１等における在庫移動時刻の
判定では，下位業務サ−バ群毎に判定する．また，図５
０のステップ４２０７，図５１のステップ４３０５，４
３２３等の分散トランザクション処理でも下位業務サ−
バ群を基に処理をする．

【０２５５】上記実施例での下位業務サーバ３ａ〜ｂの
下にさらに下位業務サーバのある階層化でもよい。階層
化することによりさらに分散することができる。また，
これとは逆に業務サ−バを上位，下位の構成ではなく，
各業務サ−バを対等にする構成でもよい．

【０２５６】上記実施例では、座席予約のチケットデー
タを扱ったが、物流在庫などの流通で使用されるデータ
などを扱うことができることはいうまでもない。

【０２５７】以上のように第１５，１６，１７の発明に
よれば、従来のものよりサーバの負荷を分散し、トラフ
ィック量も減らす効果がある。

【０２５８】

【発明の効果】以上の様にこの発明によりトランザクシ
ョンの処理要求が多くなっても負荷分散システムに対す
る障害が回避出来るという効果がある．

【図面の簡単な説明】

【図１】図１はこの発明の第１の発明による一実施例の
ブロック図である。

【図２】図２はこの発明の第１の発明による一実施例の
動作を説明する図である。

【図３】図３はこの発明の第１の発明による一実施例の
動作を説明する図である。

【図４】図４はこの発明の第１の発明による一実施例に
おける処理例を示す流れ図である。

【図５】図５はこの発明の第２の発明による一実施例の
ブロック図である。

【図６】図６はこの発明の第２の発明による一実施例の
動作を説明する図である。

【図７】図７はこの発明の第２の発明による一実施例の
動作を説明する図である。

【図８】図８はこの発明の第２の発明による一実施例に
おける処理例を示す流れ図である。

【図９】図９はこの発明の第３，４の発明による一実施
例のブロック図である。

【図１０】図１０はこの発明の第３，４の発明による一
実施例の動作を説明する図である。

【図１１】図１１はこの発明の第５の発明による一実施
例のブロック図である。

【図１２】図１２はこの発明の第５の発明による一実施
例の動作を説明する図である。

【図１３】図１３はこの発明の第６の発明による一実施
例のブロック図である。

【図１４】図１４はこの発明の第６の発明による一実施
例のブロック図である。

【図１５】図１５はこの発明の第６の発明による一実施
例の構成を示す図である．

【図１６】図１６はこの発明の第６の発明による一実施
例の動作を示す図である．

【図１７】図１７はこの発明の第６の発明による一実施
例の動作を説明する図である。

【図１８】図１８はこの発明の第６の発明による一実施
例の動作を説明する図である。

【図１９】図１９はこの発明の第６の発明による一実施
例の動作を説明する図である。

【図２０】図２０はこの発明の第７の発明による一実施
例のブロック図である。

【図２１】図２１はこの発明の第７の発明による一実施
例のブロック図である。

【図２２】図２２はこの発明の第７の発明による一実施
例の構成を示す図である．

【図２３】図２３はこの発明の第７の発明による一実施
例の構成を示す図である．

【図２４】図２４はこの発明の第７の発明による一実施
例の動作を説明する図である。

【図２５】図２５はこの発明の７の発明による一実施例
の動作を説明する図である。

【図２６】図２６はこの発明の第８の発明による一実施
例のブロック図である。

【図２７】図２７はこの発明の第８の一実施例の内、回
覧リストを示す図である。

【図２８】図２８はこの発明の第８の発明による一実施
例の動作を説明する図である。

【図２９】図２９はこの発明の第９の発明による一実施
例のブロック図である。

【図３０】図３０はこの発明の第９の発明による一実施
例の動作を説明する図である。

【図３１】図３１はこの発明の第１０，１１の発明によ
る一実施例のブロック図である。

【図３２】図３２はこの発明の第１０，１１の発明によ
る一実施例の動作を説明する図である。

【図３３】図３３はこの発明の第１０，１１の発明によ
る一実施例の動作を説明する図である。

【図３４】図３４はこの発明の第１０，１１の発明によ
る一実施例の動作を説明する図である。

【図３５】図３５はこの発明の第１２の発明による一実
施例のブロック図である。

【図３６】図３６はこの発明の第１２の発明による一実
施例のプロセス管理テ−ブルｃの内容を示す図である．

【図３７】図３７はこの発明の第１２の発明による一実
施例の振り分けテ−ブルの内容を示す図である．

【図３８】図３８はこの発明の第１２の発明による一実
施例の動作を説明する図である。

【図３９】図３９はこの発明の第１２の発明による一実
施例の動作を説明する図である。

【図４０】図４０はこの発明の第１２の発明による一実
施例の動作を説明する図である。

【図４１】図４１はこの発明の第１３の発明による一実
施例のブロック図である。

【図４２】図４２はこの発明の第１３の発明の一実施例
のアクセス制御テ−ブルの内容を示す図である．

【図４３】図４３はこの発明の第１３の発明による一実
施例の動作を説明する図である。

【図４４】図４４はこの発明の第１３の発明による一実
施例の動作を説明する図である。

【図４５】図４５はこの発明の第１３の発明による一実
施例の動作を説明する図である。

【図４６】図４６はこの発明の第１４の発明による一実
施例のブロック図である。

【図４７】図４７はこの発明の第１４の発明による一実
施例の動作を説明する図である。

【図４８】図４８はこの発明の第１５，１６，１７の発
明による一実施例のブロック図である。

【図４９】図４９はこの発明の第１５，１６，１７の発
明による一実施例のチケットデ−タ情報の内容を示す図
である．

【図５０】図５０はこの発明の第１５，１６，１７の発
明による一実施例の動作を説明する図である。

【図５１】図５１はこの発明の第１５，１６，１７の発
明による一実施例の動作を説明する図である。

【図５２】図５２はこの発明の第１５，１６，１７の発
明による一実施例の動作を説明する図である。

【図５３】図５３はこの発明の第１の発明と第２の発明
の従来図である。

【図５４】図５４は第３と第４と第５の発明の従来図で
ある。

【図５５】図５５はこの発明の第６，７の発明の従来図
である。

【図５６】図５６はこの発明の第８の発明の従来図であ
る。

【図５７】図５７はこの発明の第９の発明の従来図であ
る。

【図５８】図５８はこの発明の第１０，１１の発明の従
来図である。

【図５９】図５９はこの発明の第１２と第１３の発明の
従来図である。

【図６０】図６０はこの発明の第１５，１６，１７の発
明の従来図である。

【符号の説明】

１ 業務クライアント ２〜３ 業務サーバ ４ 名前サ−バ ９〜１０ 業務サーバプロセス １１ 負荷監視手段 １２ 業務サーバプロセス数変更手段 １３ 業務クライアント決定手段 １４〜１５ 業務クライアント管理テーブル １６ トランザクション処理管理部 ５０９〜５１０ 業務サーバプロセス ５１１ 負荷監視手段 ５１２ 業務サーバプロセス数変更手段 ５１３ 管理データ決定手段 ５１４〜５１５ データ管理テーブル ５１６ トランザクション処理管理部 ９０３ 時刻管理手段 ９０４ 処理依頼データ受信手段 ９０５ データ受信時刻刻印手段 ９０６ 業務サーバプロセス ９０７ トランザクション処理開始／終了時刻刻印手段 ９０８ トランザクション処理実行部 ９０９ 処理結果データ送信手段 ９１０ 処理結果の転送時間 ９１１ 処理受け付けから処理開始までの時間 １１０３ 名前サーバ １１０４ 各業務サーバの処理内容とそのネットワーク
上のアドレスの対応表 １１０５ サーバアドレス応答データ送信手段 １１０６ 放送通信手段 １２０１ 業務サーバプロセス １２０２ ある処理を提供しているサーバアドレスの問
い合わせ １２０３ 名前サーバからの応答データ １３０３ａ，１３０３ｂ 記憶装置 １４１１ａ，１４１１ｂ 業務サーバプロセス １４２１ メモリ管理部 １４２２ プロセス制御部 １４２３ プロセス管理部 １４２４，１４２５ 記憶部 １８１１ 業務サーバプロセス １８２１ サーバ管理部 １８２２ プロセス管理部 １８２３，１８２４ 記憶部 １９１１ 代行サーバプロセス ２２０１ 伝送路 ２２０４ トランザクション要求送受信部 ２２０４ａ 業務サーバ１のトランザクション要求送受
信部 ２２０４ｂ 業務サーバ２のトランザクション要求送受
信部 ２２０５ トランザクション回覧発生部 ２２０６ａ 業務サーバ１のトランザクション回覧部 ２２０６ｂ 業務サーバ２のトランザクション回覧部 ２２０７ａ 業務サーバ１の負荷を検出するサーバ負荷
検出部 ２２０７ｂ 業務サーバ２の負荷を検出するサーバ負荷
検出部 ２２０８ａ 業務サーバ１のトランザクション処理部 ２２０８ｂ 業務サーバ２のトランザクション処理部 ２２０９ 業務サーバ回覧リスト ２５０１ 伝送路 ２５０４ トランザクション要求送受信部 ２５０５ トランザクション処理部 ２５０６ 処理負荷検出部 ２５０７ 負荷履歴記憶部 ２５０８ 負荷傾向検出部 ２５０９ 負荷閾値記憶部 ２５１０ 業務判定部 ２７０１ 伝送路 ２７０３ トランザクション要求送受信部 ２７０４ トランザクション処理時間検出部 ２７０５ トランザクション処理閾時間記憶部 ２７０６ 管理要求送受信部 ２７０８ トランザクション処理部 ２７０９ 管理情報収集部 ２７１０ 負荷監視マネージャ ２７１１ クライアント管理部 ２７１２ サーバ管理部 ２７１３ クライアント・サーバ統括管理部 ３１０１ マネージャ ３１０２ マネージャ管理情報入出力処理部 ３１０３ サーバ起動部 ３１０４ サーバ振り分け処理部 ３１０５ 通信処理部 ３１１１ 業務サーバプロセス ３１１２ 負荷監視部 ３１１３ クライアント要求処理部 ３１１４ 自己消去部 ３１１５ 通信処理部 ３１２２ クライアント処理部 ３１２３ 通信処理部 ３５０１ アクセス制御装置 ３５０２ アクセス制御管理情報入出力処理部 ３５０３ アクセス制御処理部 ３５０４ 通信処理部 ３５１２ サーバ管理情報入出力処理部 ３５１３ 負荷監視部 ３５１４ アクセス権付与決定部 ３５１５ クライアント要求処理部 ３５１６ 通信処理部 ３５２２ クライアント処理部 ３５２３ 通信処理部 ３９０１ データ量制御装置 ３９０２ 管理情報入出力部 ３９０３ データ入力部 ３９０４ 重要度識別部 ３９０５ データカウント部 ３９０６ データ取捨選択部 ３９０７ データ出力部 ３９０８ データ廃棄部 ４１０２ データ情報入出力処理部 ４１０３ 時刻取得部 ４１０４ データ移動処理部 ４１０５ 記憶部 ４１０６ クライアント要求処理部 ４１０７ 通信処理部 ４１１２ａ，４１１２ｂ 時刻取得部 ４１１３ａ，４１１３ｂ データ移動処理部 ４１１４ａ，４１１４ｂ 記憶部 ４１１５ａ，４１１５ｂ クライアント要求処理部 ４１１６ａ，４１１６ｂ 通信処理部 ４１２２ａ，４１２２ｂ，４１２２ｃクライアント処理
部 ４１２３ａ，４１２３ｂ，４１２３ｃ 通信処理部 ｅ

フロントページの続き (72)発明者 中川路 哲男 鎌倉市大船五丁目１番１号 三菱電機株式 会社情報システム研究所内

Claims (17)

【特許請求の範囲】
1. 【請求項１】 トランザクション処理システムにおい
   て，トランザクションの負荷を監視する負荷監視手段
   と、該負荷監視手段による監視結果に基づいて業務サー
   バプロセス数を制御する業務サーバプロセス数変更手段
   と、該業務サ−バプロセス数変更手段を該制御に基いて
   各業務サーバプロセスが処理要求を受け付けるべき業務
   クライアントを決定する業務クライアント決定手段と、
   各業務サーバプロセスが処理要求を受け付ける業務クラ
   イアントを管理する業務クライアント管理テーブルとを
   設けたことを特徴とする負荷分散方式。
2. 【請求項２】 トランザクション処理システムにおい
   て、トランザクションの負荷を監視する負荷監視手段
   と、該負荷監視手段による監視結果に基づいて業務サー
   バプロセス数を制御する業務サーバプロセス数変更手段
   と、該業務サ−バプロセス数変更手段の該制御に基いて
   各業務サーバプロセスが処理の対象とするデータを決定
   する管理データ決定手段と、各業務サーバプロセスにお
   いて処理の対象とするデータを管理するデータ管理テー
   ブルとを備えたことを特徴とする負荷分散方式。
3. 【請求項３】 トランザクション処理システムにおい
   て、業務クライアントの処理依頼の送信から処理結果の
   受信までの間の任意の処理の任意の時点の時刻を刻印す
   る時刻刻印手段と，該時刻刻印手段が刻印した該任意の
   処理の内指定した処理の指定した時点の時刻から指定し
   た処理の指定した時点間の所要時間を算出する所要時間
   算出手段と，を備えたことを特徴とする負荷分散方式．
4. 【請求項４】 トランザクション処理システムにおい
   て、業務クライアントからの依頼データを業務サ−バが
   受信したデータ受信時刻を刻印するデータ受信時刻刻印
   手段と、業務サーバプロセスにおいてトランザクション
   処理の開始時刻と該処理終了時刻とを刻印するトランザ
   クション処理開始終了時刻刻印手段と，該処理結果を返
   信した時刻を刻印する返信時刻刻印手段と，業務クライ
   アントが該処理結果を受信した時刻を刻印する処理結果
   刻印手段と，これらの任意の時刻から所要時間を算出す
   る所要時間算出手段を備えたことを特徴とする負荷分散
   方式。
5. 【請求項５】 トランザクション処理システムにおい
   て、各業務サーバの処理内容とそのネットワーク上のア
   ドレスの対応表を保持している名前サーバと、名前サー
   バにおいて問い合わせのあった処理を提供している業務
   サーバのアドレスを応答として返信するサーバアドレス
   応答データ送信手段と、該サーバアドレス応答デ−タ送
   信手段において該返信する業務サ−バのアドレスを複数
   の業務クライアントに対して放送通信する放送通信手段
   と，を備えたことを特徴とする負荷分散方式。
6. 【請求項６】 トランザクション処理システムにおい
   て、業務サ−バは，使用メモリ容量の閾値を保持し，プ
   ロセスのメモリ占有量が閾値を超過したらプロセスを退
   避させて縮退運転に移り，プロセスがメモリを開放して
   メモリの占有量が該閾値を下回ったら退避した該プロセ
   スを復旧させて平常運転に移る制御を行う制御部を備え
   ることを特徴とする負荷分散方式。
7. 【請求項７】 トランザクション処理システムにおい
   て、業務サ−バは，負荷の閾値を保持し，トランザクシ
   ョンの処理負荷が該閾値を超過したらトランザクション
   を処理していた業務サーバプロセスを退避し，その処理
   機能を代行する代行業務サーバプロセスを生成して縮退
   運転に移り，業務サ−バプロセスが処理を終了して実行
   待ちになり，負荷が該閾値を下回れば，該代行業務サ−
   バプロセスを消去して前記の退避した業務サ−バプロセ
   スを復旧する制御を行う制御部を備えることを特徴とす
   る負荷分散方式。
8. 【請求項８】 トランザクション処理システムにおい
   て、トランザクションの処理要求をできる業務サーバに
   回覧し要求を処理する業務サ−バを決めるためのトラン
   ザクション回覧を作成するトランザクション回覧発生部
   とトランザクション処理要求に該トランザクション回覧
   を添付して送信するトランザクション要求送受信部を設
   けた業務クライアントと、該トランザクション要求と該
   トランザクション回覧を送受信する送受信部と自業務サ
   ーバの処理負荷を検出するサーバ負荷検出部と回覧リス
   トを解析し業務サーバの処理負荷を回覧リストに記入し
   該送受信部を介して最も処理負荷の低い業務サーバにト
   ランザクション処理要求を回覧する処理負荷トランザク
   ション回覧手段を設けた業務サ−バと，を備えることを
   特徴とする負荷分散方式。
9. 【請求項９】 トランザクション処理システムにおい
   て、業務サ−バは，業務サーバの負荷閾値を記憶する負
   荷閾値記憶手段と、業務サーバの処理負荷を検出する処
   理負荷検出手段と、業務サーバの時系列的な処理負荷履
   歴を記憶する負荷履歴記憶手段と、処理負荷履歴から負
   荷傾向を検出し予測値を算出する負荷傾向検出手段と、
   負荷傾向検出手段が算出した処理負荷の予測値と負荷閾
   値記憶手段に記憶された負荷閾値との比較によりトラン
   ザクション要求を当該業務サーバで行うかどうかを判定
   する業務判定手段と，を備えることを特徴とする負荷分
   散方式。
10. 【請求項１０】 トランザクション処理システムにおい
    て、業務クライアントはトランザクション要求を発行し
    てから処理結果を受信するまでの最大待ち時間を閾値と
    して記憶するトランザクション処理閾時間記憶手段と、
    トランザクション毎の処理要求発行の時点から処理結果
    を受信するまでの経過時間を計測し該経過時間と前記の
    閾値との比較を行い、該経過時間が前記の閾値よりも大
    きいときには任意の指定処理をするトランザクション処
    理時間検出手段と、を備えたことを特徴とする負荷分散
    方式。
11. 【請求項１１】 業務クライアントと業務サ−バと負荷
    監視マネ−ジャとからなるトランザクション処理システ
    ムにおいて、業務クライアントはトランザクション要求
    を発行してから処理結果を受信するまでの最大待ち時間
    を閾値として記憶するトランザクション処理閾時間記憶
    手段と、トランザクション毎の処理要求発行の時点から
    処理結果を受信するまでの経過時間を計測し該経過時間
    と前記の閾値との比較を行い、該経過時間が前記の閾値
    よりも大きいときには負荷監視マネージャに警報を発行
    するトランザクション処理時間検出手段と、を備え，業
    務サーバは負荷監視マネージャからの負荷の照会を受信
    しそれに応答する管理要求送受信手段を備え、負荷監視
    マネージャは、業務サ−バに対して同業務サ−バの負荷
    に応じて増減された間隔でなされる前記の負荷の照会に
    対する回答または業務クライアントからの前記の警報に
    よりトランザクション処理システムの異常部分を検出す
    るクライアント・サーバ統括管理手段を備える，ことを
    特徴とする負荷分散方式。
12. 【請求項１２】 業務クライアントと業務サ−バプロセ
    スとマネ−ジャとからなるトランザクション処理システ
    ムにおいて、業務サ−バプロセスは，業務サ−バプロセ
    スの負荷を把握し高負荷になれば該業務サ−バプロセス
    の作成をマネ−ジャに要求する負荷監視部と、マネ−ジ
    ャから受けた業務サ−バプロセスの条件を満たせば該業
    務サーバプロセスの自己消去を行う自己消去部とを備
    え、マネ−ジャは，業務サ−バプロセスを起動するサ−
    バ起動部と，業務サ−バプロセスの条件を保存し，業務
    クライアントまたは該負荷監視部の要求に基いて，業務
    サ−バプロセスの前記の保存された条件を付し，サ−バ
    起動部を介して該業務サ−バプロセスを起動させるサー
    バ振り分け処理部とを備える，ことを特徴とする負荷分
    散方式。
13. 【請求項１３】 トランザクション処理システムにおい
    て、業務サ−バは業務サーバの負荷状態を知る負荷監視
    部と、業務クライアントのアクセス優先順位を制御する
    情報と該負荷監視部の情報により業務クライアントへア
    クセス権を付与するアクセス権付与決定部とを備えるこ
    とを特徴とする負荷分散方式。
14. 【請求項１４】 トランザクション処理システムにおい
    て，データ量制御装置は，データを入力する入力手段、
    処理条件の設定変更削除の情報を入出力する管理情報入
    出力手段，該管理情報入出力手段の設定した条件により
    該入力手段からの入力データの重要度を識別して絶対出
    力デ−タと任意出力デ−タに分類する重要度識別手段、
    前記の絶対出力デ−タの時間あたりの数をカウントする
    カウント手段、前記カウント手段の時間当りの絶対出力
    デ−タの数と該管理情報入出力手段の設定条件に基き前
    記任意出力データを取捨選択する取捨選択手段、出力デ
    ータを出力する出力手段、とを備えることを特徴とする
    負荷分散方式。
15. 【請求項１５】 トランザクション処理システムにおい
    て、時刻を取得する時刻取得部と、データを記憶する記
    憶部と、他の業務サ−バからのデ−タを該記憶部に格納
    し，該時刻取得部の時刻が所定のデ−タ移動時刻になれ
    ば該記憶部のデータを他の業務サ−バに移動するデータ
    移動処理部と、業務クライアントの要求の処理を行うク
    ライアント要求処理部と，を設けた業務サ−バを備える
    ことを特徴とする負荷分散方式。
16. 【請求項１６】 トランザクション処理システムにおい
    て、業務サ−バは上位業務サ−バと下位業務サ−バより
    なり，下位業務サ−バは時刻を取得する時刻取得部と、
    データを記憶する下位記憶部と、上位業務サ−バからの
    デ−タを該下位記憶部に格納し，該時刻取得部の時刻が
    上位業務サ−バの指定のデ−タ移動時刻になれば該下位
    記憶部のデータを上部業務サ−バに移動するデータ移動
    処理部と、業務クライアントの要求の処理を行うクライ
    アント要求処理部と，を備え，上位業務サ−バはデータ
    を記憶する上位記憶部、データの移動時刻を指定して該
    上位記憶部から該下位記憶部への移動処理及び該指定移
    動時刻になれば該下位記憶部からのデ−タを上位記憶部
    に保存するデータ移動処理部と、業務クライアントの要
    求の処理を行うクライアント要求処理部と，を備えるこ
    とを特徴とする負荷分散方式。
17. 【請求項１７】 業務サ−バのクライアント要求処理部
    は業務クライアントのデ−タに係わる処理要求に対して
    自記憶部のデ−タで対応出来ないときは，他の業務サ−
    バのデ−タを使用して該業務クライアントの要求を処理
    する分散トランザクション処理を行うことを特徴とする
    請求項１５または請求項１６に記載の負荷分散方式．