JP4267094B2 - ２重更新を行うデータベースを有するクライアントサーバーシステム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、データベースマネージメントシステム（ＤＢＭＳ）を有するクライアントサーバーシステムに係り、特にハードウェアやデータベースシステムの障害に対して短時間でシステムを復元する障害回復処理を行うクライアントサーバーシステムに関する。
【０００２】
また、本発明は、２４時間連続稼動することができるクライアントサーバーシステムに関する。
【０００３】
なお、本発明は、クライアントのリクエストによりサーバーがＤＢＭＳを介してデータベースの参照・更新を行うものであればよく、オンライントランザクション処理システムに限られないが、以下の説明ではオンライントランザクション処理システムとして使用した場合にその機能が理解しやすいことが多いため、必要に応じてオンライントランザクション処理システムを例に説明する。
【０００４】
【従来の技術】
一般に、オンライントランザクション処理（ＯＬＴＰ）を行うクライアントサーバーシステムは、サーバーに複数のクライアントがオンライン接続し、クライアントからサーバーに処理のためのメッセージを送り、そのメッセージにしたがってサーバーで一連のデータベースアクセス等の処理を行い、その処理結果を即座にクライアントに送り返す処理を行う。
【０００５】
ここで、オンライントランザクション処理は、クライアントからサーバーに送る１回のメッセージに対する処理を指し、１回のメッセージに対する処理は通常複数のデータベース操作を含み、１つの論理処理単位を形成する。たとえば、データベース内のあるテーブルの値を変更する処理の場合、そのテーブルに関連する他のテーブルの値も変更しなければならない場合には、必要なデータの変更全体が１つトランザクション処理を形成する。このように１つのトランザクション処理が、複数のデータテーブルの値の変更に関係することが多いので、データの値の整合性を確保するため、トランザクション処理は全体として完全に行われるか全く行われないかのいずれかでなければならない。
【０００６】
また、オンライントランザクション処理を行うクライアントサーバーシステムの場合は、複数のクライアントから不定期にメッセージを受けて上述したトランザクション処理を行う。このため、複数のクライアントから同時に処理要求があった場合には、複数のトランザクション処理を同時に実行しなければならない。このような複雑な処理を行うオンライントランザクション処理システムは、多数のトランザクション処理を高速、かつ、データ間の矛盾が生じないように高い信頼性の下で処理することが求められる。
【０００７】
上述した処理に対する高速・高信頼性の要求により、従前はオンライントランザクション処理システムは汎用機からなることが主であった。
【０００８】
汎用機によるオンライントランザクション処理システムでは、使用環境を特化し、種々の処理状態を想定して繰り返しテストすることにより、ハードウェアとソフトウェアの双方においてエラーの発生を最小限にとどめるようにしていた。このため、汎用機によるオンライントランザクション処理システムでは、システム障害が発生する確率がそもそも低いために障害回復処理が必要とされることが少なかった。万一システム障害が発生した場合には、従来の汎用機システムでは予め用意された手順によってシステム回復を図っていたが、その回復処理は通常比較的長い時間を要していた。
【０００９】
これに対して、最近ではネットワークコンピューティングを制御するＯＳ（オペレーティングシステム）によってもオンライントランザクション処理システムを構築できるようになった。ネットワークコンピューティングによるオンライントランザクション処理システムは、汎用機に比べて比較的小型のコンピュータを複数接続してネットワークを構築し、ＯＳの管理の下でトランザクション処理を行うものである。
【００１０】
上記ＯＳの下で構築したオンライントランザクション処理システムにおいても、汎用機同様の処理の高速性と高信頼性が要求される。しかし、ネットワークコンピューティングの処理を管理するＯＳは、ＯＳとしての汎用性や多機能性を追求するために、トランザクション処理における特定の使用条件における繰返しテストを行うことはできない。このため、通常のＯＳには、一般的な障害回復処理の手段が機能として用意されている。一般的な障害回復処理の手段の代表的なものは一部のハードウェアの２重化があり、たとえば、ハードディスクの２重化、ＳＣＳＩバスの２重化などである。ハードウェアの２重化は基本的なハードウェア障害対策といえる。
【００１１】
これに対して、ＡＴ＆Ｔベル研究所の開発によるＯＳである「ＵＮＩＸ」（ＵＮＩＸは商品名）はさらに進んでハードウェア（コンピュータ）全体の２重化を想定し、ハードウェア切替用のハイアベイラビリティ機構（ＨＡ機構）を用意している。
【００１２】
このＨＡ機構は、サーバーに正系ノード（ノードはクライアントサーバーシステムを構成する論理的単位をいうものとする）と待機系ノードを用意している場合に、正系のノードでＬＡＮボード障害や、たとえばマザーボードやＣＰＵ障害のようなサーバー本体の全面障害や、データベースシステムなどのプロセスダウン（プロセスダウンとはシステムとしての機能を失うような全体的なシステムダウンをいうものとする）が発生したときに、待機系ノードは障害発生時に正系ノードで処理を行っていたプログラムを起動し、自動的に待機系ノードによって正系ノードの処理を引き継ぐことによってシステムを回復させる機能である。なお、このＨＡ機構による正系と待機系の切り替えは瞬時のうちに行うことができる。
【００１３】
上記ＨＡ機構によれば、ＵＮＩＸによる２重化ハードウェアを有するトランザクション処理システムにおいて、上述したようなハードウェア障害、またはプログラムの異常な処理に伴うシステムのシャットダウンなどに対して、瞬時にノードを切り替え、素早い障害回復処理を行うことができる。
【００１４】
この他に、以上のＵＮＩＸのＨＡ機構が、システムのノード自体のハードウェア障害を回復するのに対して通信ネットワークの障害に対してシステムを回復するクライアントサーバーシステム（特開平７−３０２２３７号）も提案されている。これもハードウェア面におけるシステムの信頼性向上のための提案の一つと言える。
【００１５】
この特開平７−３０２２３７号が開示するシステムは、クライアントとサーバーを接続するＬＡＮを２重化し、通信経路を選択することができるプロセスをそれぞれクライアントとサーバーに置き、一つの通信経路（ＬＡＮ）に障害があった場合に、他の通信経路（ＬＡＮ）によって通信を行えるようにしたものである。
【００１６】
このシステムによれば、一方の通信ネットワークに障害が発生した場合にも、残る健全な通信ネットワークを選択することにより通信処理を行うことができる。
【００１７】
【発明が解決しようとする課題】
しかし、従来のクライアントサーバーシステムでは、ハードウェア自体の障害やソフトウェアプログラムのプロセスダウンに伴うハードウェア障害に対しては上述したようにハードウェアの切替えによってシステムの回復を図ることができたが、データベースシステム関連のファイルが破損しているなどのソフトウェアの深刻な障害が生じた場合には、障害回復処理を行うことができなかった。
【００１８】
たとえば、上述したＵＮＩＸのＨＡ機構は、正系ノードでＯＬＴＰのプロセスダウンが発生したときに、正系ノードで処理を行っていたデータベースシステムを待機系ノードで起動することにより、待機系ノードによってシステム回復を図るようにしている。しかし、データベースシステムがもともとプログラムエラー（バグ）を有している場合や、プロセスダウンした時にデータベースの関連ファイルが破損してしまった場合には、これらのデータ検索等を行うプログラム（データベースシステム）を起動した待機系ノードでも、結局データベースシステムを使用することができず、システムを回復することができなかった。
【００１９】
ところで、上述したようなプログラムエラーやプロセスダウンなどのソフトウェア障害は、通常多数のトランザクション処理を同時に実行している場合に、処理のタイミングによって発生することが多いことが経験上知られている。この場合に、同時実行数が少ないなどトランザクション処理の条件が緩やかになれば、プログラムエラーが発生せずに同一のトランザクション処理をすることができることが多いことも知られている。
【００２０】
そごで、本発明は、「常時」最新の状態に更新されるデータベースとそのデータベースシステム（データベースのデータを参照、更新するプログラム）を２重に有していれば、一方のデータベースシステムが破損した場合にも、他方のデータベースとデータベースシステムとによってシステムを回復し継続して処理を行うことができる可能性に着目し、２重のデータベースを常時更新するシステムを提供しようとするものである。
【００２１】
ただし、オンライン処理自体は、通常一つのデータベースに対して参照や更新を行うものであるため、一対（２重）のデータベースを常時更新するためには、オンライン処理を実際に行っているシステム以外のシステムが、オンライン処理を行っているシステムの処理結果を常時追随し、かつ、障害発生時のシステム切替えに伴うデータベース間のデータの矛盾が生じないようにシステム構成する必要がある。このようにオンライン処理システムにおいて２重化されたデータベースをほぼ同時に更新するシステムは従来存在していなかった。
【００２２】
すなわち、本発明が解決しようとする課題は、ソフトウェア自体の破損、特にデータベースシステムの破損が生じた場合にも、極めて短い時間の間にソフトウェア障害発生前の状態にシステムを回復することができるクライアントサーバーシステムを提供することにある。
【００２３】
なお、上述したように、ここで、「システムの回復」というのは、システムとして作動が可能になったことのみならず、障害発生時に完了していなかった処理についてユーザーが受け取ったメッセージとシステムのデータベースの値が互い整合した状態に回復し、また、障害発生時の処理と処理再開後の処理でデータ上矛盾が生じないようにするシステム回復も含むものとする。
【００２４】
さらに、本発明が解決しようとする他の課題として、２４時間稼動できるオンライン処理システムを提供することがある。
【００２５】
２４時間稼動できるオンライン処理システムは、ハードウェアを２重化し、正系システムと副系システムのデータの内容を整合させて、極めて短い時間の間に正系システムと副系システムを切り替えることによって実現されるが、正副両系のデータ内容を整合させること、および極めて短い時間の間に正系システムと副系システムを切り替えることは、技術的には上述した障害回復処理を行うクライアントサーバーシステムと共通である。
【００２６】
ただし、２４時間稼動できるためには、上述したような正系・副系システムの迅速な切替えのほかに、２重化したデータベースのそれぞれにおいてデータの整理・再登録の処理が必要であり、このための解決手段が必要である。本発明による２４時間稼動できるオンライン処理システムは、正系システムと副系システムを切れ目なく切り替えることかでき、かつ、その間に各データベースでデータの整理・再登録をすることができるようにしたものである。
【００２７】
すなわち、本発明が解決しようとする他の課題は、障害回復処理を行うクライアントサーバーシステムの延長として２４時間稼動することができるオンライン処理システムを提供することにある。
【００２８】
【課題を解決するための手段】
本願請求項１に係る２重更新を行うデータベースを有するクライアントサーバーシステムは、
少なくとも１つのクライアントと、前記クライアントの接続サーバーを切り替えるゲートウェイと、同一の構成を有する正系サーバーと副系サーバーと、前記正系サーバーと副系サーバーとによってそれぞれ参照および更新される一対のデータベースと、を有するクライアントサーバーシステムにおいて、
前記正系サーバーと副系サーバーはともに、前記クライアントのメッセージに対してオンライン処理を行うオンラインアプリケーション手段と、データベースの参照と更新を行うデータベースシステムと、自系のデータベースに対するデータベース変更メッセージを一時的に蓄積して他系に送出するメッセージキュー送出手段と、他系のデータベースに対するデータベース変更メッセージを自系に受け入れて一時的に蓄積するメッセージキュー受入手段と、前記オンラインアプリケーション手段がデータベース変更メッセージを受けてデータベースに対して行う処理と同一の処理を行うように構成され、前記メッセージキュー受入手段から他系のデータベースのデータベース変更メッセージを入力し、前記データベースシステムを介して自系のデータベースを更新するメッセージキュー起動アプリケーション手段とを有し、
通常の処理においては前記正系サーバーは、そのオンラインアプリケーション手段によってオンライン処理を行い、必要に応じて正系のデータベースシステムを介して正系のデータベースを変更するとともに、正系のデータベースに対するデータベース変更メッセージを正系のメッセージキュー送出手段に送り、
前記副系サーバーは、副系のメッセージキュー受入手段が正系のメッセージキュー送出手段から正系のデータベースに対するデータベース変更メッセージを逐次受け入れ、副系のメッセージキュー起動アプリケーション手段が副系のメッセージキュー受入手段から正系のデータベースに対するデータベース変更メッセージを入力し、副系のデータベースシステムを介して副系のデータベースを更新し、
前記正系サーバーにファイルの破損が発生したときは、前記ゲートウェイの切替えによって処理要求のあった前記クライアントを前記副系サーバーに接続し、副系のオンラインアプリケーション手段によってオンライン処理を行い、必要に応じて副系のデータベースシステムを介して副系のデータベースを変更するとともに、副系のデータベースに対するデータベース変更メッセージを逐次副系のメッセージキュー送出手段に送り、
前記正系サーバーは機能が回復した後に、正系のメッセージキュー受入手段が副系のメッセージキュー送出手段から副系処理中の副系のデータベースに対するデータベース変更メッセージを受け入れ、正系のメッセージキュー起動アプリケーション手段が正系のメッセージキュー受入手段から副系のデータベースに対するデータベース変更メッセージを入力し、正系のデータベースシステムを介して正系のデータベースを更新することを特徴とするものである。
【００２９】
本願請求項２に係る２重更新を行うデータベースを有するクライアントサーバーシステムは、請求項１のクライアントサーバーシステムにおいて、
前記正系および副系のメッセージキュー起動アプリケーション手段は、起動用アプリケーション制御手段を有し、この起動用アプリケーション手段の起動メッセージによって起動し、前記メッセージキュー受入手段から他系のデータベースに対するデータベース変更メッセージを入力して前記データベースシステムを介して自系のデータベースを更新するように構成されていることを特徴とするものである。
【００３０】
本願請求項３に係る２重更新を行うデータベースを有するクライアントサーバーシステムは、請求項１または２に記載のクライアントサーバーシステムにおいて、
前記副系サーバーは、副系のメッセージキュー受入手段と平行して正系のデータベースに対するデータベース変更メッセージを入力する予備メッセージキュー受入手段を有することを特徴とするものである。
【００３１】
本願請求項４に係る２重更新を行うデータベースを有するクライアントサーバーシステムは、請求項１ないし３のいずれかのクライアントサーバーシステムにおいて、
前記正系サーバーあるいは副系サーバーと同一のハードウェア構成を有し、前記正系サーバーがサーバー全体の機能停止を伴うハードウェア障害またはプロセスダウンを生じたときに、前記正系サーバーで起動されていたプログラムを起動して前記正系サーバーが行っていた処理を継続して行う待機系サーバーを有することを特徴とするものである。
【００３２】
本願請求項５に係る２重更新を行うデータベースを有するクライアントサーバーシステムは、請求項４のクライアントサーバーシステムにおいて、
前記待機系サーバーは、起動後に正系のデータベースの破損によって処理不能であるときは、前記正系のデータベースに対するデータベース変更メッセージを副系のメッセージキュー受入手段に送出し、
前記副系サーバーは、そのメッセージキュー起動アプリケーション手段が副系のメッセージキュー受入手段から前記正系のデータベースに対するデータベース変更メッセージを入力し、副系のデータベースシステムを介して副系のデータベースを更新した後に、副系のオンラインアプリケーション手段によってオンライン処理を行うことを特徴とするものである。
【００３３】
本願請求項６に係る２重更新を行うデータベースを有するクライアントサーバーシステムは、請求項１ないし請求項５のいずれかのクライアントサーバーシステムにおいて、
前記正系サーバーがオンライン処理した所定期間中の正系のデータベースのデータを集約してデータベースファイルの形式で一時的に記憶する中間ボリューム記憶装置と、
前記副系サーバーがオンライン処理した所定期間中の副系のデータベースに対するデータベース変更メッセージを一時的に記憶しておく副系メッセージキュー手段とを有し、
前記正系サーバーと前記副系サーバーとが交互に切り替わって切れ目なくオンライン処理を行い、切替えによって前記正系サーバーがオンライン処理を開始すると、副系サーバーにおいて、前記中間ボリューム記憶装置に記憶された切替え前の処理期間の開始時点のデータを集約したデータベースファイルを副系のデータベースに上書きし、続いて前記副系メッセージキュー手段に記憶された切替え前の処理期間のデータベース変更メッセージによって副系のデータベースを更新し、次にオンライン処理に伴って生じる正系のデータベースに対するデータベース変更メッセージを逐次入力して副系のデータベースを最新のデータ状態に更新し、
切替えによって前記副系サーバーがオンライン処理を開始すると、正系サーバーにおいて、切替え前の処理期間中に変更された正系データベースのデータの集約と再登録と前記中間ボリューム記憶装置への複写を行うバッチ処理を行い、前記バッチ処理終了後は、オンライン処理に伴って生じる副系のデータベースに対するデータベース変更メッセージを逐次入力して正系のデータベースを最新のデータ状態に更新することにより、２４時間連続稼動するように構成したことを特徴とするものである。
【００３４】
【発明の実施の形態】
次に本発明の実施の形態について説明する。
図１ないし図４に本発明による「２重更新を行うデータベースを有するクライアントサーバーシステム」の一実施形態の構成と、通常の処理（図１）、正系システムにハードウェア障害が発生したときの処理（図２）、サーバー全体の機能停止を伴わないソフトウェア障害が発生したときの処理（図３）、および、サーバー全体の機能停止を伴うプロセスダウンが発生しかつデータベース関連ファイルが破損した場合の処理（図４）の流れを示す。
【００３５】
図１は、本発明の一実施形態による「２重更新を行うデータベースを有するクライアントサーバーシステム」の構成とその通常処理の流れを示している。
【００３６】
図１において、２重更新を行うデータベースを有するクライアントサーバーシステム１は、クライアント２a，２b，…，２nと、ゲートウェイ３と、正系サーバー４aと、副系サーバー４bと、正系サーバー４aによって参照・更新される正系データベース５aと、副系サーバー４bによって参照・更新される副系データベース５bと、待機系サーバー６とを有している。
【００３７】
クライアント２a，２b，…，２nは、ユーザーの入力により、正系サーバー４aまたは副系サーバー４bに接続し、正系サーバー４aまたは副系サーバー４bに対して所定の処理を要求し、その処理の結果をユーザーに表示しまたは出力する端末装置である。
【００３８】
ゲートウェイ３は、クライアント２a，２b，…，２nのいずれかから接続要求があったときに、システムの状態により接続先サーバー（正系サーバー４aまたは副系サーバー４b）を切り替えて接続する装置である。
【００３９】
正系サーバー４aは、通常処理を行っている時にクライアント２a，２b，…，２nからの処理要求（メッセージ）を処理するサーバーである。正系サーバー４aの内部構成については後述する。正系サーバー４aは、クライアント２a，２b，…，２nの要求に応じて、正系データベース５aのデータをクライアント２a，２b，…，２nに返送したり、必要なデータ処理を行った後に処理結果をクライアント２a，２b，…，２nに返送する装置である。正系サーバー４aの内部構成については後述する。
【００４０】
正系データベース５aは、上記正系サーバー４aによって参照・更新されるデータベースである。正系データベース５aは、物理的に正系サーバー４aから独立した存在でもよく、また、正系サーバー４a付属の記憶装置内に形成されていてもよい。
【００４１】
副系サーバー４bは、正系サーバー４aが何らかの原因によって機能停止したときに、正系サーバー４aの代替として作動し、クライアントサーバーシステム１としての機能を回復するサーバーである。
【００４２】
副系サーバー４bは正系サーバー４aとほぼ同一の構成（内部の処理手段）を有し、この副系サーバー４bの内部構成については後述する。
【００４３】
副系データベース５bは、上記副系サーバー４bによって参照・更新されるデータベースである。副系データベース５bは、後述する処理により、非同期であるが継続的に正系データベース５aの変更を追随して更新し、かつ、正系サーバー４a障害時には正系データベース５aと同一内容によって、回復したシステムのデータベースとして機能する。なお、副系データベース５bは副系サーバー４bから独立した存在でもよく、また、副系サーバー４b付属のものでもよいことは、正系データベース５aと同様である。
【００４４】
待機系サーバー６は、正系サーバー４aや副系サーバー４bと同一のハードウェアを有し、通常はオペレーティングシステムのみが起動した状態でなんら処理を行わないが、正系サーバー４aが障害によって機能停止したときに、正系サーバー４aで処理を行っていたプログラムをメモリーに読み込んで実行し、障害発生時に正系サーバー４aが行っていた処理を継続して行うサーバーである。なお、上記サーバーの機能停止時に予備システムがそのプログラムを起動して処理を継続するシステム構成は、ＵＮＩＸにおいてはＨＡ機構と呼ばれ、汎用機の分野ではホットスタンバイと呼ばれている機能である。本発明は、ＵＮＩＸと同様の機能を有するＯＳに適用可能であるが、理解容易のためにＵＮＩＸにおける「ＨＡ機構」を用語として使用する。
【００４５】
次に正系サーバー４aと副系サーバー４bの内部構成について説明する。
【００４６】
正系サーバー４aは、オンラインアプリケーション手段７aと、メッセージキュー起動アプリケーション手段８a（図においてＭＱ起動アプリケーション手段と表示する）と、データベースシステム９aと、メッセージキュー送出手段１０a（図においてＭＱ送出手段と表示する）と、メッセージキュー受入手段１１a（図においてＭＱ受入手段と表示する）と、起動用アプリケーション制御手段１２aとを有している。
【００４７】
副系サーバー４bは正系サーバー４aとほぼ同様の構成を有している。すなわち、副系サーバー４bは、オンラインアプリケーション手段７bと、メッセージキュー起動アプリケーション手段８b（図においてＭＱ起動アプリケーション手段と表示する）と、データベースシステム９bと、メッセージキュー送出手段１０b（図においてＭＱ送出手段と表示する）と、メッセージキュー受入手段１１b（図においてＭＱ受入手段と表示する）と、起動用アプリケーション制御手段１２bとを有している。ただし、正系サーバー４aと異なる点として、本実施形態では副系サーバー４bは予備メッセージキュー受入手段１３（図において予備ＭＱ受入手段と表示する）を有している。
【００４８】
オンラインアプリケーション手段７a，７bは、クライアント２a，２b，…，２nと接続してクライアント２a，２b，…，２nのメッセージに対してオンライン処理を行う手段である。オンラインアプリケーション手段７a，７bはその処理において、クライアント２a，２b，…，２nの要求に応じてデータベースシステム９a，９bを介してデータベース５a，５bにアクセスし、そのデータをそのままクライアント２a，２b，…，２nのユーザーに送って示したり、そのデータを使用して所定の処理を行い、データベースシステム９a，９bのデータ更新行ったりする。オンラインアプリケーション手段７a，７bは好ましくは、オブジェクト指向プログラミングにおけるオブジェクトであり、メッセージにより所定の処理を行い、メッセージ発信元に処理結果を返信するように構成される。
【００４９】
なお、オンラインアプリケーション手段７a，７bがデータベース５a，５bの更新を行うときは、たとえば所定のテーブルのデータを更新するために関連するすべてのテーブルのデータを矛盾なく更新するものとする。なお、オンラインアプリケーション手段７a，７bは、処理の内容に応じてそれぞれ複数種類存在する。また、正系と副系のオンラインアプリケーション手段７a，７bは同一の内容を有し、同一の処理を行えるようにする。
【００５０】
メッセージキュー起動アプリケーション手段８a，８bは、メッセージキュー受入手段１１a，１１bに格納された他系のデータベースに対するデータベース変更メッセージにしたがってデータベースシステム９a，９bを介して自系のデータベース５a，５bを変更する手段である。
【００５１】
メッセージキュー起動アプリケーション手段８a，８bは、独自のプログラミングと制御により、単独で上述したようにメッセージキュー受入手段１１a，１１bからデータベース５a，５bの変更メッセージを入力し、データベース５a，５bの変更を行うようにしてもよいが、好ましくは図１に示すように、起動用アプリケーション制御手段１２a，１２bを有し、オンラインアプリケーション手段７a，７bと同一の処理行うようにする。
【００５２】
このように構成することにより、メッセージキュー起動アプリケーション手段８a，８bは実質的にはオンラインアプリケーション手段７a，７bの複写で簡単に形成でき、これに起動を制御する簡単な起動用アプリケーション制御手段１２a，１２bを付加するだけで上記機能を果たすことができるのである。
【００５３】
すなわち、オンラインアプリケーション手段７a，７bを複写することにより、メッセージキュー起動アプリケーション手段８a，８bはデータベース５a，５bに対してオンラインアプリケーション手段７a，７bとまったく同一の処理を行うことができる。このように、メッセージキュー起動アプリケーション手段８a，８bがオンラインアプリケーション手段７a，７bと同様の処理を行うことができることにより、他系のデータベースの変更部分を自系のデータベースに反映でき、同期（データを一致させること）を取ることができるのである。
【００５４】
データベースシステム９a，９bは、オンラインアプリケーション手段７a，７bの要求（データベースに対する処理要求メッセージ）を受け、データベースのデータを操作する手段である。データベースシステム９a，９bは、広い意味における「データベース」に含まれているので、データベース５a，５bの一部になっている場合も本発明のシステムに含まれる。
【００５５】
メッセージキュー送出手段１０a，１０bは、自系のデータベースに対するデータベース変更メッセージを一時的に蓄積して他系に送出する手段である。
【００５６】
メッセージキュー受入手段１１a，１１bは、他系のメッセージキュー送出手段１０a，１０bから上述した他系のデータベースに対するデータベース変更メッセージを受け入れて一時的に蓄積する手段である。
【００５７】
起動用アプリケーション制御手段１２a，１２bは、既述したように、メッセージキュー起動アプリケーション手段８a，８bに起動メッセージを送ってこれらを起動するための手段である。既述したようにメッセージキュー起動アプリケーション手段８a，８bがオンラインアプリケーション手段７a，７bの複写からなるときは、起動用アプリケーション制御手段１２a，１２bはオンラインアプリケーション手段７a，７bに対する起動メッセージと同様な起動メッセージをメッセージキュー起動アプリケーション手段８a，８bに送ってこれらを起動する。
【００５８】
予備メッセージキュー受入手段１３は、正系データベース５aと副系データベース５bが何らかの原因によって同時に障害発生した時に備え、正系データベース５aに対するデータベース変更メッセージを記録しておく手段である。
【００５９】
以上が正系サーバー４aと副系サーバー４bの内部の構成であったが、以下に通常の処理における諸構成手段の処理について説明する。
【００６０】
図１にクライアントサーバーシステム１の通常の処理の流れを示す。通常の処理においては、正系サーバー４aがクライアント２a，２b，…，２nとオンライン接続して処理を行う。正系サーバー４aでは、オンラインアプリケーション手段７aが、クライアント２a，２b，…，２nの要求に応じてオンライン処理を行い、必要に応じて正系のデータベースシステム９aを介して正系データベース５aを変更するとともに、正系データベース５aに対するデータベース変更メッセージを逐次正系のメッセージキュー送出手段１０aに送る。
【００６１】
一方正系サーバー４aがオンライン処理を行う間、副系サーバー４bでは、ディファードオンライン処理で正系データベース５aの変更部分を副系データベース５bに反映して更新する。
【００６２】
すなわち、副系サーバー４bでは、副系のメッセージキュー受入手段１１bが正系のメッセージキュー送出手段１０aから正系データベース５aの変更部分を（データベース変更メッセージとして）逐次受け入れ、副系のメッセージキュー起動アプリケーション手段８bがその副系のメッセージキュー受入手段１１bから正系データベース５aに対するデータベース変更メッセージを入力し、副系のデータベースシステム９bを介して副系データベース５bを更新する。
【００６３】
上記処理により、正系サーバー４aでクライアント２a，２b，…，２nの要求に応じて正系データベース５aの変更を行った場合には、そのデータベースの変更が、送出用メッセージキュー蓄積手段１０a（正系）と、受入用メッセージキュー蓄積手段１１b（副系）と、メッセージキュー起動アプリケーション手段８b（副系）と、データベースシステム９b（副系）とを経て、極めて短い時間の後に副系データベース５bに反映される。これにより、副系データベース５bを正系データベース５aはほぼ同時に同期（データベースの内容を一致させること）され、正系データベース５aと副系データベース５bの内容はデータベース変更メッセージを送受信するための時間を除き、ほぼ常時最新の状態に一致される。
【００６４】
次に、この２重更新を行うデータベースを有するクライアントサーバーシステム１において、正系サーバー４aにハードウェア障害を生じた場合の障害回復処理について図２を用いて以下に説明する。
【００６５】
図２に正系サーバー４aがハードウェア障害を生じた場合の障害回復処理を示す。なお図２において、正系サーバー４aのハードウェア障害（データベースシステム９a等は健全な状態）を表すために正系サーバー４aに破線の対角線を付す。
【００６６】
正系サーバー４aがサーバー全体の機能停止を伴うハードウェア障害を生じた場合には、ＨＡ機構（「ＨＡ機構」はＵＮＩＸの場合の呼称であって、他のＯＳによる場合はＵＮＩＸのＨＡ機構に相当する機能）により、待機系サーバー６がハードウェア障害時に正系サーバー４aで起動されていたプログラムを起動し、継続処理のために障害発生時のデータファイルを参照する。この処理により待機系サーバー６には、オンラインアプリケーション手段７a，メッセージキュー起動アプリケーション手段８a，データベースシステム９a，メッセージキュー送出手段１０a，メッセージキュー受入手段１１a，起動用アプリケーション制御手段１２aとそれぞれ同一のオンラインアプリケーション手段７a’，メッセージキュー起動アプリケーション手段８a’，データベースシステム９a’，メッセージキュー送出手段１０a’，メッセージキュー受入手段１１a’，起動用アプリケーション制御手段１２a’が形成される。
【００６７】
待機系サーバー６は正系サーバー４aで行っていた処理を継続して行い、データベースシステム９a’により、継続して正系データベース５aに対して参照及び更新を行う。
【００６８】
図２に表す場合の正系サーバー４aのハードウェア障害は、ハードウェア上の障害であってプログラムやデータは健全であるので、上記オンラインアプリケーション手段７a’，メッセージキュー起動アプリケーション手段８a’，データベースシステム９a’，メッセージキュー送出手段１０a’，メッセージキュー受入手段１１a’，起動用アプリケーション制御手段１２a’はそれぞれ健全に機能し、待機系サーバー６は正系サーバー４aとまったく同一の処理を行うことができるようになる。
【００６９】
待機系サーバー６が正系サーバー４aと同様の処理を行うサーバーとして起動した後は、ゲートウェイ３は、要求処理のあったクライアント２a，２b，…，２nを待機系サーバー６に接続し、待機系サーバー６によりオンライン処理を継続することができる。
【００７０】
上記正系サーバー４aから待機系サーバー６への切替えは極めて短い時間内、かつ、自動的にハードウェア障害を検出して行うことかできる。このため、正系サーバー４aのハードウェア障害に対しては、ＨＡ機構により短時間の切替処理の経過後にシステムとして障害回復をすることができるのである。
【００７１】
なお、上記正系サーバー４aのハードウェア障害発生時の副系データベース５bのデータ更新は、正系サーバー４aが待機系サーバー６に切り替わっただけで副系サーバー４bにおける処理は何ら変わらない。すなわち、メッセージキュー送出手段１０aに蓄積された正系データベース５aの変更メッセージは、そのまま待機系サーバー６のメッセージキュー送出手段１０a’に継承され、システムの障害回復後に当該データベース変更メッセージはメッセージキュー送出手段１０a’からメッセージキュー受入手段１１bと予備メッセージキュー受入手段１３に送られ、メッセージキュー起動アプリケーション手段８bとデータベースシステム９bとによって副系データベース５bに反映され、副系データベース５bが正系データベース５aと同一内容になるように更新される。
【００７２】
以上は、正系サーバー４aのサーバー機能停止を伴うハードウェア障害に対するシステムの障害回復処理であったが、次に正系サーバー４aのサーバーとして機能は損なわれないが、正系データベース５aをはじめとするデータベース関連のファイル破損が発生した場合処理について図３を用いて以下に説明する。
【００７３】
図３に正系サーバー４aの正系データベース５aが破損した場合の障害回復処理の流れを示す。図３において、正系データベース５aの破損を示すために正系データベース５aに破線の対角線を付す。
【００７４】
正系サーバー４aの正系データベース５aが破損した場合は、正系データベース５aのデータの参照及び更新が不可能になるので、副系サーバー４bに切り替えてオンライン処理を行い、必要に応じて副系データベース５bの参照及び更新を行う。正系データベース５aの機能回復後は、副系サーバー４bのオンライン処理間に生じた副系データベース５bの変更を正系データベース５aに反映して、正系データベース５aを更新する。
【００７５】
具体的には、正系サーバー４aの正系データベース５a等が破損したときは、ゲートウェイ３の切り替えによって、処理要求のあったクライアント２a，２b，…，２nを副系サーバー４bに接続する。副系サーバー４bは、図１で説明したように、副系データベース５bが正系データベース５aと一致するように常時更新されているので、直ちにあるいは副系データベース５bと正系データベース５aの同期を確認する極めて短い時間の経過後に副系データベース５bを使用してオンライン処理を開始することができる。正系サーバー４aから副系サーバー４bへの切替え自体は極めて短い時間の間に行うことができる。このようにして副系サーバー４bの処理を開始することにより、２重更新を行うデータベースを有するクライアントサーバーシステム１としては機能が回復し、見かけ上障害回復処理が実現することができるのである。
【００７６】
副系サーバー４bによるオンライン処理では、オンラインアプリケーション手段７bはオンラインアプリケーション手段７aと同一の処理を行うことができるので、クライアント２a，２b，…，２nの要求に応じてデータベースシステム９bを介して必要に応じて副系データベース５bを参照及び更新する。副系データベース５bのデータを変更する場合には、そのデータベース変更メッセージをデータベースシステム９bとともに副系のメッセージキュー送出手段１０bにも出力する。
【００７７】
上記副系のオンラインアプリケーション手段７bは正系のオンラインアプリケーション手段７aと同一の処理を行うができ、かつ、ゲートウェイ３による正系副系の切替えは瞬時に行われるので、ユーザーは、正系サーバー４aと副系サーバー４bの切り替えを意識することなく、オンライン処理をすることができるのである。
【００７８】
副系サーバー４bによってオンライン処理を行っている間に、システムエンジニアにより正系サーバー４aの障害を回復するようにする。たとえば、破損した正系データベース５aを破棄し、障害発生前の健全な状態のデータベースに置き換え、障害発生までのデータの変更を追跡更新するなどの作業を行うことができる。
【００７９】
上述したような正系サーバー４aの回復作業により正系サーバー４aの機能が回復した後は、副系サーバー４bの処理中に副系データベース５bに生じたデータベースの変更部分を正系データベース５aに反映させなければならない。具体的には、データベースシステム９aが回復した後に、正系のメッセージキュー受入手段１１aが、副系のメッセージキュー送出手段１０bから副系処理中の副系データベース５bのデータベース変更メッセージを入力する。次に、正系のメッセージキュー起動アプリケーション手段８aが、起動用アプリケーション制御手段１２aの起動メッセージによって起動し、メッセージキュー受入手段１１aから副系データベース５bのデータベース変更メッセージを入力し、正系のデータベースシステム９aを介して、正系データベース５aを更新する。これにより、正系データベース５aは、障害発生中のデータベースに対する変更を反映し、最新の状態である副系データベース５bと同期することができる。
【００８０】
正系データベース５aが更新された後は、再びゲートウェイ３の切り替えにより、それ以降に処理要求があったクライアント２a，２b，…，２nを正系サーバー４aに接続し、通常の処理の流れに戻すことができる。
【００８１】
以上はサーバー機能停止を伴わないがデータベース関連ファイルが破損した時の障害回復処理であったが、次にサーバー全体の機能停止を伴うソフトウェア障害が生じた場合の障害回復処理について図４を用いて以下に説明する。
【００８２】
図４にサーバー全体の機能停止およびデータベース関連ファイルの破損が発生した場合の障害回復処理の流れを示す。なお図４において、サーバー全体の機能停止およびデータベース関連ファイルの破損を表すために、正系サーバー４aと正系データベース５aにそれぞれ破線の対角線を付す。なお、サーバー全体の機能停止を伴うソフトウェア障害としては、ハードウェア障害に伴ってデータベース関連のファイルも破損したような場合や、データベースシステムのプログラム上の不具合（バグ）等により処理中に全面的なファイル破損が生じたような場合などがある。
【００８３】
正系サーバー４aがソフトウェア障害によってサーバーとしての機能がダウンしたときは、既述したようにＨＡ機構がこれを検知して作動し、待機系サーバー６に障害発生時の正系サーバー４aの処理プログラムを起動させ、待機系サーバー６が自動起動する。ＨＡ機構により、オンラインアプリケーション手段７a、メッセージキュー起動アプリケーション手段８a、データベースシステム９a、メッセージキュー送出手段１０a、メッセージキュー受入手段１１a、起動用アプリケーション制御手段１２aは、それぞれ待機系サーバー６にオンラインアプリケーション手段７a’、メッセージキュー起動アプリケーション手段８a’、データベースシステム９a’、メッセージキュー送出手段１０a’、メッセージキュー受入手段１１a’、起動用アプリケーション制御手段１２a’として起動される。
【００８４】
しかし、この場合は起動されたデータベースシステム９a’が参照する正系データベース５ａも破損しているので、待機系サーバー６が正系サーバー４aとして機能することができない。
【００８５】
そこで、待機系サーバー６からさらに副系サーバー４bに切り替えて、副系サーバー４bによってシステムの回復を図る必要がある。
【００８６】
ここで、副系サーバー４bによってシステムを回復するには、その前に待機系サーバー６に滞留している正系データベース５aのデータベース変更メッセージを副系サーバー４bに送り出し、副系データベース５bを更新して障害発生時の正系データベース５aと同一内容としなければならない。この滞留したデータベース変更メッセージの送出と副系データベース５bの更新の処理の流れを図４で一点鎖線の矢印によって示す。
【００８７】
上記滞留したデータベース変更メッセージを副系サーバー４bに送出して副系データベース５bを更新するには、短時間ではあるがオンライン処理を一時的に中止する。しかる後に、メッセージキュー送出手段１０aを起動したメッセージキュー送出手段１０a’から副系のメッセージキュー受入手段１１bへデータベース変更メッセージを送出する。
【００８８】
次に、副系のメッセージキュー起動アプリケーション手段８aは、起動用アプリケーション制御手段１２bによって起動し、メッセージキュー受入手段１１bから正系データベース５aに対するデータベース変更メッセージ（メッセージキュー送出手段１０a’の滞留分）を入力し、副系のデータベースシステム９bを介して副系データベース５bを更新する。この更新により、副系データベース５bは、障害発生直前の正系データベース５aと同一の内容になり、これを使用してオンライン処理が可能な状態になる。
【００８９】
以上の準備の後、システムはオンライン処理を再開し、ゲートウェイ３の切替えにより、処理要求があったクライアント２a，２b，…，２nを副系サーバー４bに接続する。
【００９０】
副系サーバー４bにおいては、オンラインアプリケーション手段７bがクライアント２a，２b，…，２nの要求に応じて、必要によりデータベースシステム９bを介して副系データベース５bを参照しあるいは更新する。副系データベース５bは、処理開始時には障害発生直前の正系データベース５aと同一内容に更新されているので、データに矛盾を生じることなくオンライン処理を再開することができるのである。
【００９１】
副系処理中に副系データベース５bのデータを更新する場合には、オンラインアプリケーション手段７bはデータベース変更メッセージをデータベースシステム９bとメッセージキュー送出手段１０bの双方に同時に送るようにする。
【００９２】
副系サーバー４bによって以上のようなオンライン処理を行う間に、システムエンジニア等により、正系サーバー４aの機能回復を別途図るようにする。正系サーバー４aの機能が回復した後は、正系のメッセージキュー受入手段１１aが副系のメッセージキュー送出手段１０bから、副系サーバー４b処理中の副系データベース５bに対するデータベース変更メッセージを入力する。次に、正系のメッセージキュー起動アプリケーション手段８aが起動用アプリケーション制御手段１２aの起動メッセージによって起動し、正系のメッセージキュー受入手段１１aから副系処理中の副系データベース５bに対するデータベース変更メッセージを入力し、データベースシステム９aを介して正系データベース５aを更新する。これにより、正系データベース５aは、最新のデータ内容である副系データベース５bと同期される。
【００９３】
正系データベース５aと副系データベース５bの同期をとった後は、正系データベース５aはオンライン処理が可能な状態になるので、ゲートウェイ３の切替えによって、通常の処理に戻すことができるのである。
【００９４】
従来の汎用機を使用したトランザクション処理システムは、テストを繰り返すことによりシステム停止を伴うソフトウェア障害が発生しないようにしていたが、万一深刻なソフトウェア障害によってシステム機能の全体がダウンした場合には、長時間システムを停止し、全面的な復旧をしなければならなかった。また、従来のＵＮＩＸのＨＡ機構を利用した障害回復機能を有するシステムは、単にハードウェアの２重化を図ったものであり、ハードウェア障害時に予備のシステムが起動するが、ハードウェア障害に伴ってデータベース関連ファイルのような重要なソフトウェアに障害が発生した場合は、起動した予備システムによっても結局システムの機能を回復することができず、汎用機の場合と同様にシステムの回復まで長い時間がかかることになった。
【００９５】
これら従来のシステムに対し、本発明による「２重更新を行うデータベースを有するクライアントサーバーシステム１」によれば、ハードウェアのみの障害（図２の場合）、データベース破損等のソフトウェア障害（図３の場合）、ハードウェア障害およびデータベースは損等のソフトウェア障害（図４の場合）のいずれに対しても、迅速にシステムを回復することができ、これによって安価なシステムによって高い信頼性を有するトランザクション処理システムを実現することができるのである。
【００９６】
すなわち、本発明の「２重更新を行うデータベースを有するクライアントサーバーシステム１」によれば、ＵＮＩＸのような汎用的なオペレーションシステムによって、汎用機に比較して小型・廉価のコンピュータを組み合わせてオンライン処理システムを構築でき、かつ、上述したように２重化したデータベースの双方をほぼ常時最新の状態に維持することができることにより、片方のサーバーにハードウェア障害やソフトウェア障害が発生した時に他方のサーバーに切り替えて継続して処理でき、高い信頼性のオンライン処理システムを得ることかできるのである。
【００９７】
なお、極めて稀なことではあるが、正系サーバー４aと副系サーバー４bが同時にもっとも深刻なソフトウェア障害を伴うハードウェア障害となった場合でも、データベース変更メッセージを貯留した予備メッセージキュー受入手段１３とゲートウェイ３の内部の電文トレースにより、システムを回復することができる。この場合は、上述した正系・副系の切替えによるシステム回復より長い時間を必要とするが、正系サーバー４aと副系サーバー４bが同時に機能しないケースは非常に稀であるので回復に多少時間がかかる点はやむを得ないものとする。
【００９８】
以上は障害回復処理を迅速に行うクライアントサーバーシステムについて説明したが、次に２４時間連続稼動するクライアントサーバーシステムをについて以下に説明する。
【００９９】
一般的に２４時間連続稼動するオンライン処理システムは、同一システムを長期間使用した場合のオペレーティングシステムの不安定な動作、データベースファイルのフラグメンテーション、インデックスツリーの変形による処理性能の劣化等の問題を解決しつつ、２４時間連続稼動することができるようにしなければならない。
【０１００】
図１〜図４において説明した２重更新データベースを使用するクライアントサーバーシステム１は、２重化したシステム（正系サーバーと副系サーバー）を有し、一方のシステムによってオンライン処理でき、必要なときにオンライン処理を行うシステムを切り替えることができる。この図１〜図４のクライアントサーバーシステムは、一方のシステムが稼動中に他方のシステムについて種々の保守が可能である点で２４時間連続稼動するオンライン処理システムとしての基本的な機能を有している、ということができる。
【０１０１】
ただし、図１〜図４のクライアントサーバーシステムは、一方のシステムのデータベースの変更を逐一他方のシステムのデータベースに反映するようにしているので、「データの洗い換え」の処理を行っていない。以下に説明する２４時間連続稼動するオンライン処理システムは、すでに説明した「２重更新データベースを使用するクライアントサーバーシステム」にデータの洗い換えをするための中間ボリューム記憶装置を付加し、データの洗い換えという処理を行うようにしたものである。
【０１０２】
「データの洗い換え」の処理は、同一のデータに対する複数回の処理を集計し、不要な途中のデータを整理することによってデータ量を圧縮する処理である。
たとえば、銀行預金を管理するオンライン処理システムにおいては、あるユーザーが自分の口座から引出しをするのに、小額の預金を多数回引き出すことがしばしばみられる。この場合、預金を管理するデータベースでは、預金の引出し回数と同じ回数の取引データが記録され、データベースが管理するデータ数が増加する。
【０１０３】
しかし、預金を管理するデータベースとして必要なデータは、最新の残高である場合が多いので、途中の取引経過を整理し、最新の残高データのみを登録しておけばよいことがある。このような場合に、途中の取引経過を集計し、データ量を圧縮して最新の残高のみを登録する処理が「データの洗い換え」の処理である。銀行預金を管理するデータベースに限られず、一般にオンライン処理を行うシステムでも、データベースの無限な膨張を防止するために、一定の期間ごとにデータを整理し、再登録する処理（データの洗い換え処理）を行うことが必要となる。本発明による２４時間連続稼動するオンライン処理システムでは、上記「データの洗い換え」の処理を正系サーバーと副系サーバーの切替え中に行うようにしている。
【０１０４】
まず、本発明による２４時間連続稼動するオンライン処理システムの構成について説明する。
【０１０５】
図５，６に２重更新を行うデータベースを有しオンライン処理を行う本発明による２４時間連続稼動するクライアントサーバーシステム２１（以下簡単に指し示す場合は２４時間連続稼動オンライン処理システム２１または単にオンライン処理システム２１と略称する）の一実施形態の構成と、正系サーバー稼動時の処理の流れ（図５）と、副系サーバー稼動時の処理の流れ（図６）を示す。なお、理解容易のために図5と図６において図１〜図４と同一部分については同一符号を付して示し、重複する説明を省略する。
【０１０６】
図５に示すように、本実施形態による２４時間連続稼動オンライン処理システム２１は、図１〜図４の２重更新データベースを使用するクライアントサーバーシステム１とほぼ同一の構成を有している。ただし、本実施形態による２４時間連続稼動オンライン処理システム２１は、図１〜図４に示した２重更新データベースを使用するクライアントサーバーシステム１の構成に追加して中間ボリューム記憶装置２２と副系メッセージキュー手段２３（図5において正系サーバー４a中に副系ＭＱ手段２３と示す）とを有している。なお、図５において、図１〜図４に示したクライアントサーバーシステム１の待機系サーバー６と予備受入用メッセージキュー蓄積手段１３を示していないが、これはこれらの諸手段を除かなくてはならないという意味ではなく、単に装置を簡潔に示すためであり、無論これらの諸手段を含んでいてもよい。
【０１０７】
中間ボリューム記憶装置２２は、システム構成上正系データベース５aと副系データベース５bの中間に位置し、正系サーバー４aが稼動した所定期間中の正系データベース５aの更新部分を集約してデータベースファイルの形で一時的に記憶し、それを副系サーバー４bに受け渡すための記憶装置である。
【０１０８】
副系メッセージキュー手段２３は、副系サーバー４bが稼動した所定期間中の副系データベース５bへのデータベース変更メッセージを一時的に記憶しておく手段である。本実施形態では、副系メッセージキュー手段２３は、副系サーバー４bの内部に設けられている。
【０１０９】
次に、図７を用いて本実施形態による２４時間連続稼動オンライン処理システム２１の全体の処理の流れを説明する。
【０１１０】
図７は、正系サーバー４aと副系サーバー４ｂの稼動の切替えのタイムチャートを示している。図７において、横軸は時間経過を示し、縦に正系サーバー４aと中間ボリューム記憶装置２２と副系サーバー４bを配列して示している。
【０１１１】
図７の期間０〜３はそれぞれ適当に定めた期間であり、各期間０〜３の移行ごとに正系サーバー４aまたは副系サーバー４bのいずれかが切り替ってオンライン処理を行う。図７の例では期間０は副系サーバー４b、期間１は正系サーバー４a、期間２は副系サーバー４b、期間３は正系サーバー４aがオンライン処理をしている。サーバー間の切替えはユーザーがシステムの停止を感じることがないほど極めて短い時間のうちに行われる。
【０１１２】
正系サーバー４aがオンライン処理をしている間（期間１，３，…）は、副系サーバー４bは、バッチ的に行うデータの洗い換えと更新と、正系データベース５aの変更に追随して行う更新（この追随更新を便宜上キャッチアップという）を行っている。
【０１１３】
今、期間２に注目すると、期間２ではオンライン処理が副系サーバー４bに切り替わり、副系サーバー４bがオンライン処理を行い、正系サーバー４aではその前の期間１のオンライン処理中に生じた正系データベース５a（図示せず）のデータ変更を集約し（洗い換え処理をし）これを中間ボリューム記憶装置２２に複写するバッチ処理を行う（処理▲４▼）。その後、正系サーバー４aは副系サーバー４bのオンライン処理に伴い副系データベース５b（図示せず）の変更を追随し、キャッチアップする（処理▲５▼）。
【０１１４】
次に、期間２から期間３に移行すると、オンライン処理が正系サーバー４aに切り替わり、正系サーバー４aがオンライン処理を行う。正系サーバー４aは、期間２中にその正系データベース５a（図示せず）が常に副系データベース５bの更新に追随して更新しているので、期間３の開始時点において最新のデータの状態でオンライン処理を開始することができ、オンライン処理の切替えに障害が生じることがない。
【０１１５】
一方期間３中、副系サーバー４bは、データの洗い換えと最新状態への更新を行う。オンライン処理サーバーの切替え直後から、副系サーバー４bは、先に期間２で正系サーバー４aが中間ボリューム記憶装置２２に複写したデータベースファイルを副系データベース５b（図示せず）に上書きする（処理▲１▼）。この上書きされるデータは、期間１までのデータを洗い換え、すなわち集約して再登録したものであるので、処理▲１▼が完了した状態では、副系データベース５b（図示せず）は、期間１の終了時点のデータ状態になる。次に、副系データベース５bには、期間２の副系サーバー４bによるオンライン処理のデータ変更部分を追加して更新する（処理▲２▼）。この処理▲２▼が完了した状態では、副系データベース５b（図示せず）は、期間１の変更データについては洗い換え処理をしていないものの、期間１の終了時点のデータ状態になる。処理▲２▼が完了後、副系サーバー４bは、正系サーバー４aのオンライン処理に伴い、正系データベース５aに生じたデータ変更部分を逐次的に入力し、副系データベース５bを正系データベース５aに追随して更新する（処理▲３▼）。この処理▲３▼により、副系データベース５bは、極めて短い時間をおいて正系データベース５aの変更を追随し、ほぼ常時最新のデータ状態に更新される。
【０１１６】
以上が２４時間連続稼動オンライン処理システム２１のオンライン処理サーバーの切替え、データベースの２重更新の処理であったが、次にこれらの処理が正系サーバー４aと副系サーバー４b等の構成手段間でどのように処理されるかについて図５と図６を用いて以下に説明する。なお、理解を容易にするために図5と図６においてデータベースの更新処理についは図７と同一の符号▲１▼〜▲５▼を付す。
図５は、正系サーバー４aがオンライン処理をしている状態を示している。オンライン処理が正系サーバー４aに切り替わった直後から、中間ボリューム記憶装置２２のデータベースファイルが副系データベース５bに上書きされる（処理▲１▼）。処理▲１▼により、副系データベース５bは、その前の処理期間（注目している期間の前の副系サーバー４bがオンライン処理を行った期間）の当初のデータ状態になる。ただし、データは洗い換え処理を完了した状態に整理されている。処理▲１▼の完了後は、中間ボリューム記憶装置２２と副系データベース５bの接続が切り離される。
【０１１７】
次に、副系メッセージキュー手段２３に蓄積されたデータベース変更メッセージにより、副系データベース５bのデータが更新される（処理▲２▼）。副系メッセージキュー手段２３に蓄積されたデータベース変更メッセージは、後に説明するように、切替え前の処理期間（注目している期間の前の副系サーバー４bがオンライン処理を行った期間）に副系データベース５bに対するデータベース変更メッセージを蓄積したものである。処理▲２▼により、副系データベース５bは、切替え前の処理期間（注目している期間の前の副系サーバー４bがオンライン処理を行った期間）の終了時点のデータ状態になる。
【０１１８】
次に、副系サーバー４bは、正系サーバー４aのオンライン処理に伴って生じるデータベース変更メッセージを逐次入力して、正系データベース５aの更新を追随して極めて短い時間の経過後副系データベース５bのデータを更新する（処理▲３▼）。処理▲３▼により、副系データベース５bは、ほぼ常時最新のデータ状態を維持することができる。
【０１１９】
上記処理▲３▼で副系データベース５bの更新に使用されるデータベース変更メッセージは、図５に示すように、正系の送出用メッセージキュー蓄積手段１０aから副系の受入用メッセージキュー蓄積手段１１bへ送られ、副系のメッセージキュー起動アプリケーション手段８bが起動用アプリケーション制御手段１２bによって起動して受入用メッセージキュー蓄積手段１１bから入力し、データベースシステム９bを介して副系データベース５bを更新するのに使用されるものである。
【０１２０】
この間オンライン処理を行っている正系サーバー４aでは、オンライン処理の切替え後から、オンラインアプリケーション手段７aがオンライン処理を行い、データベースシステム９aを介して正系データベース５aにアクセスし、正系データベース５aを変更する場合は、そのデータベース変更メッセージを自系のデータベースシステム９aとともに送出用メッセージキュー蓄積手段１０aにも送る。送出用メッセージキュー蓄積手段１０aに送られたこれらのデータベース変更メッセージが上述したように副系データベース５bの更新に使用され、これによって副系データベース５bが最新のデータ状態に維持されるのである。
【０１２１】
なお、オンライン処理切替え直後に副系データベース５bは、洗い換えをしたデータをバッチ的に複写する間は上記正系サーバー４aのデータベース変更メッセージによって更新することができないが、データをバッチ的に複写する時間は比較的短いので、この間に生じたデータベース変更メッセージは一時的に正系の送出用メッセージキュー蓄積手段１０aあるいは副系の受入用メッセージキュー蓄積手段１１bに蓄積され、洗い換えしたデータの複写後に副系データベース５bの更新に使用される。
【０１２２】
図５のオンライン処理期間が終了すると、オンライン処理が副系サーバー４bに切り替わって図６の状態になる。
【０１２３】
図６に示すように、オンライン処理が副系サーバー４bに切り替わると、クライアント２a，２b，…，２nのいずれかから処理要求が発せられるとゲートウェイ３の作動によりそのクライアント（図６の例ではクライアント２a）は副系サーバー４bに接続され、副系のオンラインアプリケーション手段７bがオンライン処理を行う。オンラインアプリケーション手段７bは、必要に応じて副系データベース５bにアクセスし、副系データベース５bを変更する場合は、データベースシステム９bを介して副系データベース５bを変更するとともに、そのデータベース変更メッセージを副系の送出用メッセージキュー蓄積手段１０bと副系メッセージキュー手段２３の双方に送出する。副系メッセージキュー手段２３は、副系サーバー４bのオンライン処理期間中のすべてのデータベース変更メッセージを蓄積する。一方、副系の送出用メッセージキュー蓄積手段１０bに送られた副系データベース５bに対するデータベース変更メッセージは正系の受入用メッセージキュー蓄積手段１１aに送られ、正系データベース５aのバッチ処理終了後に正系データベース５aの更新に使用される。
【０１２４】
一方、正系サーバー４aにおいては、オンライン処理が副系サーバー４bに切り替わった直後から、正系データベース５aのデータの洗い換えと中間ボリューム記憶装置２２への複写のバッチ処理が行われる（処理▲４▼）。バッチ処理▲４▼により、切替え前の処理期間（正系サーバー４aがオンライン処理を行った期間）の終了時点のデータが集約され、データベースファイルの形で中間ボリューム記憶装置２２に複写される。バッチ処理▲４▼の終了後、正系データベース５aと中間ボリューム記憶装置２２の接続は切り離され、中間ボリューム記憶装置２２は、次の切替えによって副系データベース５bに複写されるまでアクセスから絶縁された状態になる。
【０１２５】
処理▲４▼が終了すると、正系のメッセージキュー起動アプリケーション手段８aが起動用アプリケーション制御手段１２aによって起動し、受入用メッセージキュー蓄積手段１１aに蓄積された副系データベース５bに対するデータベース変更メッセージを入力し、データベースシステム９aを介して正系データベース５aを更新する（処理▲５▼）。処理▲５▼は逐次行われ、正系データベース５aは副系データベース５bの変更から極めて短い時間経過後更新され、ほぼ常時最新のデータ状態に維持される。これにより、次にオンライン処理が正系サーバー４aに切り替えられたときに、最新のデータ状態である正系データベース５aを参照することができる。この次に正系サーバー４aにオンライン処理が切り替わった状態は図５に示すところであり、以降は図５と図６の状態を交互に繰り返すことになる。上記「２４時間連続稼動オンライン処理システム２１」によれば、オンライン処理をするサーバーを切り替えても直ちに最新のデータ状態のデータベースを使用してオンライン処理を行うことができ、かつ、２４時間の切れ目のない運転を行う中で正副両系のデータベースのデータの洗い換え処理、すなわちデータの集約・再登録を行うことができ、不要なデータによるデータ量の膨大化を防止することができるのである。さらに、２４時間連続稼動オンライン処理システム２１は、図１ないし図４に示した２重更新データベースを使用するクライアントサーバーシステム１の機能をそのまま有しているので、不測のハードウェア障害やソフトウェア障害が発生したときにも、瞬時に健全なシステムに切り替えられ、システムの回復を実現することができるのである。
【０１２６】
【発明の効果】
以上の説明から明らかなように、本願発明による２重更新を行うデータベースを有するクライアントサーバーシステムによれば、従来、ハードウェアを２重化し、障害発生時に障害が発生したシステムのソフトウェアを残るシステムで起動し、起動したシステムを実行することによって障害回復を図るようにしたクライアントサーバーシステムにおいて、データベース等が破損している場合には障害回復することができなかったのに対し、本願発明のクライアントサーバーシステムは常に２重に更新されるデータベースを備えることにより、一方のデータベースならびにその関連ファイルが破損した場合であっても、残る健全なデータベースを参照・更新することにより、直ちにシステムの機能を回復することができる。
【０１２７】
また、正系サーバーがオンライン処理した所定期間中の正系のデータベースのデータを集約してデータベースファイルの形式で一時的に記憶する中間ボリューム記憶装置と、副系サーバーがオンライン処理した所定期間中の副系のデータベースに対するデータベース変更メッセージを一時的に記憶しておく副系メッセージキュー手段とを備えることにより、正系サーバーと副系サーバーを交互に切替えられ、かつ、正系および副系のデータベースの双方をほぼ常時最新のデータ状態に維持するとともに、定期的に正系サーバーのオンライン処理期間中のデータを集約してデータ量を圧縮できる。これにより、切れ目なく連続運転でき、かつ、ハードウェア障害は言うに及ばず、深刻なソフトウェア障害に対しても直ちに障害回復することができる２重更新を行うデータベースを有するクライアントサーバーシステムを得ることができる。
【図面の簡単な説明】
【図１】本発明の一実施形態による２重更新データベースを使用するクライアントサーバーシステムの構成とその通常の処理の流れを示したブロック図。
【図２】本発明の一実施形態による２重更新データベースを使用するクライアントサーバーシステムの構成とハードウェア障害が発生した時の処理の流れを示したブロック図。
【図３】本発明の一実施形態による２重更新データベースを使用するクライアントサーバーシステムの構成とシステムの機能停止を伴わないがデータベース関連ファイルが破損した時の処理の流れを示したブロック図。
【図４】本発明の一実施形態による２重更新データベースを使用するクライアントサーバーシステムの構成とシステムの機能停止を伴うデータベース関連ファイルが破損した時の処理の流れを示したブロック図。
【図５】２４時間連続稼動するように構成した本発明の一実施形態による２重更新データベースを使用するクライアントサーバーシステムの構成と、正系サーバーがオンライン処理をしている状態の処理の流れを示したブロック図。
【図６】２４時間連続稼動するように構成した本発明の一実施形態による２重更新データベースを使用するクライアントサーバーシステムの構成と、副系サーバーがオンライン処理をしている状態の処理の流れを示したブロック図。
【図７】２４時間連続稼動するように構成した本発明の一実施形態による２重更新データベースを使用するクライアントサーバーシステムのオンライン処理の切替えと、データベースの更新処理を示したタイムチャート。
【符号の説明】
１ クライアントサーバーシステム
２ クライアント
３ ゲートウェイ
４a 正系サーバー
４b 副系サーバー
５a 正系データベース
５b 副系データベース
６ 待機系サーバー
７a 正系のオンラインアプリケーション手段
７b 副系のオンラインアプリケーション手段
８a 正系のメッセージキュー起動アプリケーション手段
８b 副系のメッセージキュー起動アプリケーション手段
９a 正系のデータベースシステム
９b 副系のデータベースシステム
１０a 正系のメッセージキュー送出手段
１０b メッセージキュー送出手段
１１a 正系のメッセージキュー受入手段
１１b 副系のメッセージキュー受入手段
１２a 正系の起動用アプリケーション制御手段
１２b 副系の起動用アプリケーション制御手段
１３ 予備メッセージキュー受入手段
２１ ２４時間連続稼動する２重更新を行うデータベースを有するクライアントサーバーシステム
２２ 中間ボリューム記憶装置
２３ 副系メッセージキュー手段

Claims (6)

1. 少なくとも１つのクライアントと、前記クライアントの接続サーバーを切り替えるゲートウェイと、同一の構成を有する正系サーバーと副系サーバーと、前記正系サーバーと副系サーバーとによってそれぞれ参照および更新される一対のデータベースと、を有するクライアントサーバーシステムにおいて、
   前記正系サーバーと副系サーバーはともに、前記クライアントのメッセージに対してオンライン処理を行うオンラインアプリケーション手段と、データベースの参照と更新を行うデータベースシステムと、自系のデータベースに対するデータベース変更メッセージを一時的に蓄積して他系に送出するメッセージキュー送出手段と、他系のデータベースに対するデータベース変更メッセージを自系に受け入れて一時的に蓄積するメッセージキュー受入手段と、前記オンラインアプリケーション手段がデータベース変更メッセージを受けてデータベースに対して行う処理と同一の処理を行うように構成され、前記メッセージキュー受入手段から他系のデータベースのデータベース変更メッセージを入力し、前記データベースシステムを介して自系のデータベースを更新するメッセージキュー起動アプリケーション手段とを有し、
   通常の処理においては前記正系サーバーは、そのオンラインアプリケーション手段によってオンライン処理を行い、必要に応じて正系のデータベースシステムを介して正系のデータベースを変更するとともに、正系のデータベースに対するデータベース変更メッセージを正系のメッセージキュー送出手段に送り、
   前記副系サーバーは、副系のメッセージキュー受入手段が正系のメッセージキュー送出手段から正系のデータベースに対するデータベース変更メッセージを逐次受け入れ、副系のメッセージキュー起動アプリケーション手段が副系のメッセージキュー受入手段から正系のデータベースに対するデータベース変更メッセージを入力し、副系のデータベースシステムを介して副系のデータベースを更新し、
   前記正系サーバーにファイルの破損が発生したときは、前記ゲートウェイの切替えによって処理要求のあった前記クライアントを前記副系サーバーに接続し、副系のオンラインアプリケーション手段によってオンライン処理を行い、必要に応じて副系のデータベースシステムを介して副系のデータベースを変更するとともに、副系のデータベースに対するデータベース変更メッセージを逐次副系のメッセージキュー送出手段に送り、
   前記正系サーバーは機能が回復した後に、正系のメッセージキュー受入手段が副系のメッセージキュー送出手段から副系処理中の副系のデータベースに対するデータベース変更メッセージを受け入れ、正系のメッセージキュー起動アプリケーション手段が正系のメッセージキュー受入手段から副系のデータベースに対するデータベース変更メッセージを入力し、正系のデータベースシステムを介して正系のデータベースを更新することを特徴とする２重更新を行うデータベースを有するクライアントサーバーシステム。
2. 前記正系および副系のメッセージキュー起動アプリケーション手段は、起動用アプリケーション制御手段を有し、この起動用アプリケーション手段の起動メッセージによって起動し、前記メッセージキュー受入手段から他系のデータベースに対するデータベース変更メッセージを入力して前記データベースシステムを介して自系のデータベースを更新するように構成されていることを特徴とする請求項１に記載の２重更新を行うデータベースを有するクライアントサーバーシステム。
3. 前記副系サーバーは、副系のメッセージキュー受入手段と平行して正系のデータベースに対するデータベース変更メッセージを入力する予備メッセージキュー受入手段を有することを特徴とする請求項１または２に記載の２重更新を行うデータベースを有するクライアントサーバーシステム。
4. 前記正系サーバーあるいは副系サーバーと同一のハードウェア構成を有し、前記正系サーバーがサーバー全体の機能停止を伴うハードウェア障害またはプロセスダウンを生じたときに、前記正系サーバーで起動されていたプログラムを起動して前記正系サーバーが行っていた処理を継続して行う待機系サーバーを有することを特徴とする請求項１ないし３のいずれかに記載の２重更新を行うデータベースを有するクライアントサーバーシステム。
5. 前記待機系サーバーは、起動後に正系のデータベースの破損によって処理不能であるときは、前記正系のデータベースに対するデータベース変更メッセージを副系のメッセージキュー受入手段に送出し、
   前記副系サーバーは、そのメッセージキュー起動アプリケーション手段が副系のメッセージキュー受入手段から前記正系のデータベースに対するデータベース変更メッセージを入力し、副系のデータベースシステムを介して副系のデータベースを更新した後に、副系のオンラインアプリケーション手段によってオンライン処理を行うことを特徴とする請求項４に記載の２重更新を行うデータベースを有するクライアントサーバーシステム。
6. 前記正系サーバーがオンライン処理した所定期間中の正系のデータベースのデータを集約してデータベースファイルの形式で一時的に記憶する中間ボリューム記憶装置と、
   前記副系サーバーがオンライン処理した所定期間中の副系のデータベースに対するデータベース変更メッセージを一時的に記憶しておく副系メッセージキュー手段とを有し、
   前記正系サーバーと前記副系サーバーとが交互に切り替わって切れ目なくオンライン処理を行い、切替えによって前記正系サーバーがオンライン処理を開始すると、副系サーバーにおいて、前記中間ボリューム記憶装置に記憶された切替え前の処理期間の開始時点のデータを集約したデータベースファイルを副系のデータベースに上書きし、続いて前記副系メッセージキュー手段に記憶された切替え前の処理期間のデータベース変更メッセージによって副系のデータベースを更新し、次にオンライン処理に伴って生じる正系のデータベースに対するデータベース変更メッセージを逐次入力して副系のデータベースを最新のデータ状態に更新し、
   切替えによって前記副系サーバーがオンライン処理を開始すると、正系サーバーにおいて、切替え前の処理期間中に変更された正系データベースのデータの集約と再登録と前記中間ボリューム記憶装置への複写を行うバッチ処理を行い、前記バッチ処理終了後は、オンライン処理に伴って生じる副系のデータベースに対するデータベース変更メッセージを逐次入力して正系のデータベースを最新のデータ状態に更新することにより、２４時間連続稼動するように構成したことを特徴とする請求項１ないし５のいずれかに記載の２重更新を行うデータベースを有するクライアントサーバーシステム。

Images