(57)【要約】【課題】口座単位でのデータベース間の整合性を確保し、オンライン処理実行時に前日分の夜間バッチによるデータベースの更新処理を実行する。【解決手段】複数の業務サーバ２と、データベースサーバ３とを有するデータベース更新システムであって、データベースサーバ３は、複数のデータベース３５と、複数のデータベースに対する更新対象の口座番号を抽出し、抽出した各口座番号の更新処理を実行する業務サーバ２を特定する特定手段３２と、抽出した口座番号各々を特定した業務サーバ２にそれぞれ送信する送信手段３３とを有し、業務サーバ２各々は、データベースサーバ３から口座番号を取得し、当該口座番号単位で複数のデータベース３５を更新する更新手段２１を有し、更新手段２１は、取得した口座番号のレコード単位で前記複数のデータベース３５各々をロックし、全てのデータベース３５の更新が終了したタイミングでコミットを発行する。【選択図】図１
2008033395.tif 000002
【特許請求の範囲】
【請求項１】
複数の業務サーバと、データベースサーバとを有するデータベース更新システムであって、
前記データベースサーバは、
複数のデータベースと、
前記複数のデータベースに対する更新対象の口座番号を抽出し、抽出した各口座番号の更新処理を実行する業務サーバを、前記複数の業務サーバの中から特定する特定手段と、
前記抽出した口座番号各々を、前記特定した業務サーバにそれぞれ送信する送信手段と、を有し、
前記業務サーバ各々は、
前記データベースサーバから口座番号を取得し、当該口座番号単位で前記複数のデータベースを更新する更新手段を有し、
前記更新手段は、前記取得した口座番号のレコード単位で前記複数のデータベース各々をロックし、全てのデータベースの更新が終了したタイミングでコミットを発行すること
を特徴とするデータベース更新システム。
【請求項２】
請求項１記載のデータベース更新システムであって、
前記データベースサーバの前記特定手段が抽出する口座番号は、バッチ更新対象の口座番号であって、
前記業務サーバの更新手段は、前記バッチ更新対象の口座番号の更新処理を、オンライン処理中に行うこと
を特徴とするデータベース更新システム。
【請求項３】
請求項１記載のデータベース更新システムであって、
前記データベースサーバの送信手段は、前記抽出した口座番号を、メッセージキューイング方式を用いて特定した業務サーバに送信すること
を特徴とするデータベース更新システム。
【請求項４】
請求項１記載のデータベース更新システムであって、
前記データベースサーバは、前記複数の業務サーバ各々の状態が設定されたサーバ状態記憶手段を、さらに有し、
前記特定手段は、前記サーバ状態記憶手段を参照し、利用可能ないずれかの業務サーバを、口座番号の更新処理を実行する業務サーバとして特定すること
を特徴とするデータベース更新システム。
【請求項５】
請求項１記載のデータベース更新システムであって、
前記データベースサーバは、各口座番号の処理状態を記憶する口座処理記憶手段を、さらに有し、
前記業務サーバの更新手段は、口座番号単位で前記複数のデータベースを更新した後、前記口座処理記憶手段の当該口座番号の処理状態を更新すること
を特徴とするデータベース更新システム。
【請求項６】
複数の業務サーバと、データベースサーバとを有するシステムにおける、データベースの更新方法であって、
前記データベースサーバは、複数のデータベースと、処理部とを有し、
前記処理部は、
前記複数のデータベースに対する更新対象の口座番号を抽出するステップと、
前記抽出した各口座番号の更新処理を実行する業務サーバを、前記複数の業務サーバの中から特定する特定ステップと、
前記抽出した口座番号各々を、前記特定した業務サーバにそれぞれ送信する送信ステップと、を行い、
前記業務サーバ各々は、
前記データベースサーバから口座番号を取得し、当該口座番号単位で前記複数のデータベースを更新する更新ステップを行い、
前記更新ステップは、前記取得した口座番号のレコード単位で前記複数のデータベース各々をロックし、全てのデータベースの更新が終了したタイミングでコミットを発行すること
を特徴とするデータベースの更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のデータベースを更新するデータベース更新システムおよびデータベースの更新方法に関する。
【背景技術】
【０００２】
金融機関の勘定系システムなど、大規模なデータベースに対して、一貫性があり障害に対しての復旧を可能とするために、トランザクション処理が利用されている。特許文献１では、勘定系システムにおいて、トランザクション処理を利用することにより、複数のデータベースに対して一貫性および整合性を確保したデータベースの更新処理を行うことが記載されている。
【特許文献１】特開２００３−１６２６３３
【発明の開示】
【発明が解決しようとする課題】
【０００３】
さて、夜間バッチ処理で大量データを処理する場合、または、障害が発生した場合など、夜間バッチ処理が遅延し、翌日のオンライン開始時刻までに終了しない場合がある。オンライン処理の開始は、データベース全体の整合性を確保するため、一般的に夜間バッチ処理の終了を前提としている。このため、夜間バッチ処理が遅延した場合、夜間バッチ処理が終了するまでオンライン処理を開始できず、したがってオンライン処理の開始が遅れてしまうという問題が発生する。
【０００４】
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、口座単位でのデータベース間の整合性を確保し、オンライン処理実行時に前日分の夜間バッチによるデータベースの更新処理を実行することにある。
【課題を解決するための手段】
【０００５】
上記課題を解決するために、本発明では、例えば、複数の業務サーバと、データベースサーバとを有するデータベース更新システムである。データベースサーバは、複数のデータベースと、複数のデータベースに対する更新対象の口座番号を抽出し、抽出した各口座番号の更新処理を実行する業務サーバを、前記複数の業務サーバの中から特定する特定手段と、抽出した口座番号各々を特定した業務サーバにそれぞれ送信する送信手段と、を有する。業務サーバ各々は、データベースサーバから口座番号を取得し、当該口座番号単位で前記複数のデータベースを更新する更新手段を有し、更新手段は、取得した口座番号のレコード単位で前記複数のデータベース各々をロックし、全てのデータベースの更新が終了したタイミングでコミットを発行する。
【０００６】
また、本発明は、複数の業務サーバと、データベースサーバとを有するシステムにおける、データベースの更新方法である。データベースサーバは、複数のデータベースと、処理部とを有し、処理部は、複数のデータベースに対する更新対象の口座番号を抽出するステップと、抽出した各口座番号の更新処理を実行する業務サーバを、前記複数の業務サーバの中から特定する特定ステップと、抽出した口座番号各々を特定した業務サーバにそれぞれ送信する送信ステップと、を行う。業務サーバ各々は、データベースサーバから口座番号を取得し、当該口座番号単位で前記複数のデータベースを更新する更新ステップを行い、更新ステップは、取得した口座番号のレコード単位で前記複数のデータベース各々をロックし、全てのデータベースの更新が終了したタイミングでコミットを発行する。
【発明の効果】
【０００７】
本発明では、口座単位でのデータベース間の整合性を確保し、オンライン処理実行時に前日分の夜間バッチによるデータベースの更新処理を実行することができる。
【発明を実施するための最良の形態】
【０００８】
以下、本発明の実施の形態について説明する。
【０００９】
図１は、本発明の一実施形態が適用されたデータベース更新システムの全体構成図である。なお、本実施形態のデータベース更新システムは、インターネットなどのネットワークを介して株取引を行うオンライントレードのシステムであるものとする。
【００１０】
図示するデータベース更新システムは、ユーザ端末１と、複数の業務サーバ２と、データベースサーバ（以下、ＤＢサーバ）３と、を有する。そして、業務サーバ２とユーザ端末１とはインターネットなどのネットワーク８を介して接続され、また、業務サーバ２とＤＢサーバ３とはＬＡＮなどのネットワークにより接続されている。ユーザ端末１は、ユーザ（投資家）の指示を受け付けて、株式の売買など各種の要求を、ネットワーク８を介して業務サーバ２に送信する。
【００１１】
業務サーバ２各々は、例えばＷｅｂアプリケーションサーバであって、ＤＢ更新部２１と、オンライン業務処理部２２と、受信キュー２３と、を有する。ＤＢ更新部２１は、夜間に行うバッチ処理のデータをＤＢサーバ３から取得し、口座番号単位にＤＢサーバ３の各種データベース群３５を更新する。オンライン業務処理部２２は、オンライン開始後に、ユーザ端末１から送信された各種の要求を受け付け、株式の発注処理など所定の業務処理を行う。受信キュー２３は、ＤＢサーバ３から受信したデータを格納するデータ格納領域である。
【００１２】
ＤＢサーバ３は、更新情報生成部３１と、サーバ特定部３２と、送信部３３と、更新情報データベース（以下、「更新情報ＤＢ」）３４と、各種データベース群（以下「各種ＤＢ群」）３５と、サーバ毎に設けられた送信キュー３６と、サーバ状態テーブル３７と、口座処理テーブル３８と、を有する。
【００１３】
更新情報生成部３１は、図示しないバックシステムから更新データファイルを取得し、当該更新データファイルに基づいて更新情報が記憶された更新情報ＤＢ３４を生成する。なお、更新データファイルは、夜間に行われるバッチ処理対象のデータファイルであって、例えば入出金未清算データ、株式預かりデータなどが含まれる。また、更新情報ＤＢ３４には、ユーザの口座番号（口座情報）毎に、例えば口座残高、清算金額など株式の買い付け余力データを各種ＤＢ群３５に反映させるための更新情報が格納される。
【００１４】
サーバ特定部３２は、更新情報ＤＢ３４に記憶された各口座番号の更新処理を実行する業務サーバ２を特定する。送信部３３は、更新情報ＤＢ３４に記憶された各口座番号を、サーバ特定部３２が特定した業務サーバ２に送信する。なお、本実施形態では、送信部３３は、口座番号を対応する業務サーバの送信キュー３６に出力し、メッセージキューイング（message queueing）方式を用いて送信キュー３６に出力された口座番号を、非同期に各業務サーバ２に送信するものとする。送信キュー３６は、業務サーバ２に送信するデータを格納するデータ格納領域である。各種ＤＢ群３５は、余力管理ＤＢ、口座ＤＢなど複数のデータベースから構成される。
【００１５】
サーバ状態テーブル３７は、各業務サーバ２の状態が設定されたテーブルである。口座処理テーブル３８は、更新情報ＤＢ３４に記憶された口座番号各々の処理状態が設定される。なお、サーバ状態テーブル３７および口座処理テーブル３８については、後述する
上記説明したユーザ端末１、業務サーバ２、およびＤＢサーバ３は、いずれも、例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワークと接続するための通信制御装置９０６と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。
【００１６】
例えば、ユーザ端末１、業務サーバ２およびＤＢサーバ３の各機能は、ユーザ端末１用のプログラムの場合はユーザ端末１のＣＰＵ９０１が、業務サーバ２用のプログラムの場合は業務サーバ２のＣＰＵ９０１が、そして、ＤＢサーバ３用のプログラムの場合はＤＢサーバ３のＣＰＵ９０１が、それぞれ実行することにより実現される。なお、入力装置９０４および出力装置９０５については、各装置が必要に応じて備えるものとする。
【００１７】
次に、サーバ状態テーブル３７について説明する。
【００１８】
図３は、サーバ状態テーブル３７の一例を示す図である。図示するサーバ状態テーブル３７は、業務サーバ２毎に、サーバＩＤ３７１と、利用フラグ３７２と、動作指示３７３と、動作ステータス３７４とを有する。サーバＩＤ３７１は、各業務サーバ２を識別するための識別情報である。利用フラグ３７２は、バッチ処理対象データの更新処理を実行可能なサーバか否かを判定するためのフラグである。図示する利用フラグ３７２には、「ＯＮ（実行可能）」または「ＯＦＦ（実行不可）」が設定される。
【００１９】
動作指示３７３には、業務サーバ２に対する動作モードが設定される。本実施形態では、「ＲＵＮ（通常処理）」、「ＨＯＬＤ（所定の時間待機）」または「ＳＫＩＰ（リードスキップ、読み捨て）」のいずれかが設定されるものとする。動作ステータス３７４には、業務サーバ２の状態が設定される。本実施形態では、「未起動」、「処理中」または「処理完了」のいずれかが設定されるものとする。
【００２０】
なお、サーバ状態テーブル３７の利用フラグ３７２および動作指示３７３は、各業務サーバ２の稼動状態に応じて、システム管理者または図示しないシステム監視サーバがあらかじめ設定するものとする。
【００２１】
次に、口座処理テーブル３８について説明する。
【００２２】
図４は、口座処理テーブル３８の一例を示す図である。図示する口座処理テーブル３８は、ユーザの口座毎に、口座番号３８１と、処理サーバＩＤ３８２と、処理ステータス３８３とを有する。処理サーバＩＤ３８２には、対応する口座番号の更新処理を実行する業務サーバ２のサーバＩＤが設定される。処理ステータス３８３には、対応する口座番号の処理状態が設定される。本実施形態の処理ステータス３８３には、「未送信」、「未処理」、「正常処理」または「異常処理」のいずれかが設定されるものとする。
【００２３】
次に、本実施形態の更新準備処理について説明する。
【００２４】
図５は、ＤＢサーバ３が行う更新準備処理のフローチャートである。
【００２５】
まず、ＤＢサーバ３の更新情報生成部３１は、夜間に行われるバッチ処理対象のデータが記憶された更新データファイルをバックシステム（不図示）から取得し、当該更新データファイルに基づいて更新情報ＤＢ３４を生成する（Ｓ１１）。なお、更新情報ＤＢ３４は、口座番号毎に、当日分の株式の買い付け余力データなどを各種ＤＢ群３５に反映させるための更新情報が記憶されたデータベースである。
【００２６】
そして、ＤＢサーバ３のサーバ特定部３２は、サーバ状態テーブル３７（図３参照）を参照して、更新情報ＤＢ３４に記憶された各口座番号を抽出する。そして、サーバ特定部３２は抽出した口座番号各々の更新処理を実行する業務サーバ２を特定し、口座処理テーブル３８（図４参照）を生成する（Ｓ１２）。すなわち、サーバ特定部３２は、更新情報ＤＢ３４に設定された各口座番号を、口座処理テーブル３８の口座番号３８１のデータ項目欄にそれぞれ設定する。そして、サーバ特定部３２は、設定した口座番号各々について、当該口座番号の更新処理を実行する業務サーバ２を、サーバ状態テーブル３７の利用フラグ３７２が「ＯＮ」になっている業務サーバ２の中から特定する。そして、サーバ特定部３２は、特定した業務サーバ２のサーバＩＤを、口座処理テーブル３８の対応する口座番号の処理サーバＩＤ３８２に設定する。
【００２７】
なお、サーバ特定部３２は、利用フラグが「ＯＮ」になっている業務サーバ２間での処理負荷が均等になるように、分散して業務サーバ２を特定することが好ましい。例えば、サーバ特定部３２は、利用フラグが「ＯＮ」になっている各業務サーバ２を、順番に割り当てることが考えられる。また、サーバ特定部３２は、口座処理テーブル３８の処理ステータス３８３には、「未送信」を設定する。
【００２８】
そして、ＤＢサーバ３の送信部３３は、口座処理テーブル３８を参照して、業務サーバ２毎に処理依頼メッセージ生成し、生成した処理依頼メッセージを対応する業務サーバ用の送信キュー３６に出力する（Ｓ１３）。そして、送信部３３は、送信キュー３６に処理依頼メッセージを出力したタイミングで、口座処理テーブル３８の対応する口座番号の処理ステータスを「未送信」から「未処理」に更新する（Ｓ１４）。
【００２９】
図６は、Ｓ１３の送信キュー３６へ処理依頼メッセージを出力する処理を説明するための説明図である。図６に示す説明図では、業務サーバＡ用の処理依頼メッセージ６１と、業務サーバＢ用の処理依頼メッセージ６２とが、例として記載されている。送信部３３は、業務サーバＡ用の処理依頼メッセージ６１については、口座処理テーブル３８の処理サーバＩＤ３８２に「業務サーバＡ」が設定されている口座番号を全て抽出し、先頭に「処理開始」のメッセージを、最後に「処理終了」のメッセージを付加して、図示するような処理依頼メッセージ６１を生成する。そして、送信部３３は、生成した処理依頼メッセージ６１を、業務サーバＡ用の送信キュー３６ａに出力する。なお、送信部３３は、業務サーバＢ用の処理依頼メッセージ６２についても同様に生成し、業務サーバＢ用の送信キュー３６ｂに出力する。
【００３０】
そして、送信部３３は、業務サーバＡ用の送信キュー３６ａに出力された処理依頼メッセージ６１を業務サーバＡ２ａに、また、業務サーバＢ用の送信キュー３６ｂに出力された処理依頼メッセージ６２を業務サーバＢ２ｂに、メッセージキューイング方式を用いてそれぞれ送信する。そして、業務サーバＡ２ａは、ＤＢサーバ３が送信した処理依頼メッセージを受信キュー２３ａに書き込む。また、業務サーバＢ２ｂは、ＤＢサーバ３が送信した処理依頼メッセージを受信キュー２３ｂに書き込む。
【００３１】
次に、各業務サーバ２が行う、各種ＤＢ群３５への口座番号単位の更新処理について説明する。
【００３２】
本実施形態の業務サーバ２は、オンライン処理の開始後（オンライン業務処理部２２がユーザ端末１から受け付けた株式の売買要求などの処理を開始した後）であっても、以下に説明する夜間に行われるはずの前日分のバッチ処理対象データの更新処理を実行することができる。
【００３３】
図７は、各業務サーバ２の更新処理のフローチャートである。
【００３４】
図６で説明したように、ＤＢサーバ３が送信した処理依頼メッセージが、各業務サーバ２の受信キュー２３に書き込まれる。そして、業務サーバ２のＤＢ更新部２１は、受信キュー２３に書き込まれたメッセージを読み出す（Ｓ２１）。本実施形態では、ＤＢ更新部２１は、Ｓ２１で読み出した各メッセージに対する一連の処理をトランザクション処理として実行する。そして、ＤＢ更新部２１は、トランザクション処理が成功した場合、処理結果を確定させるためにコミット（commit）を発行（出力）する。
【００３５】
そして、ＤＢ更新部２１は、ＤＢサーバ３のサーバ状態テーブル３７を参照し、自業務サーバ２の動作指示３７３を特定する。そして、ＤＢ更新部２１は、特定した動作指示３７３が、「ＲＵＮ（通常処理）」、「ＨＯＬＤ（所定の時間待機）」、「ＳＫＩＰ（読み捨て）」のいずれであるか判別する（Ｓ２２）。
【００３６】
動作指示が「ＨＯＬＤ」の場合、ＤＢ更新部２１は、所定の時間（例えば、３０秒）待機し（Ｓ３３）、所定の時間が経過した後、Ｓ２２に戻り以降の処理を行う。また、動作指示が「ＳＫＩＰ」の場合、ＤＢ更新部２１は、Ｓ２１で読み出したメッセージを処理することなく読み捨てて（リードスキップして）、コミットを発行する（Ｓ３４）。そして、ＤＢ更新部２１は、Ｓ２１に戻り、受信キュー２３から次のメッセージを読み出す。
【００３７】
動作指示が「ＲＵＮ」の場合、ＤＢ更新部２１は、Ｓ２１で読み出したメッセージの種別を判別する（Ｓ２３）。「処理開始」メッセージの場合、ＤＢ更新部２１は、ＤＢサーバ３のサーバ状態テーブル３７にアクセスし、自業務サーバの動作ステータスを「未起動」から「処理中」に更新して、更新結果を確定させるためにコミットを発行する（Ｓ２４）。そして、ＤＢ更新部２１は、Ｓ２１に戻り、受信キュー２３から次のメッセージを読み出す。
【００３８】
また、「処理終了」メッセージの場合、ＤＢ更新部２１は、サーバ状態テーブル３７にアクセスし、自業務サーバの動作ステータスを「処理中」から「処理完」に更新し、コミットを発行する（Ｓ２５）。そして、ＤＢ更新部２１は、Ｓ２１に戻り、受信キュー２３から次のメッセージを読み出す。
【００３９】
また、「口座番号」が指定されたメッセージの場合、ＤＢ更新部２１は、各種ＤＢ群３５の全てのデータベースに対して、指定された口座番号のレコードをロック（排他制御）する（Ｓ２６）。本実施形態では、オンライン処理の開始後であっても、ＤＢ更新部２１は、前日分のバッチ処理データの更新処理を行うことができる。そのため、ＤＢ更新部２１は、オンライン処理からの各種ＤＢ群３５へアクセス競合を回避するために、レコード単位でロックを行うこととする。
【００４０】
そして、ＤＢ更新部２１は、ＤＢサーバ３の更新情報ＤＢ３４から対象口座番号のレコードを読み出し、当該レコードの更新情報に基づいて、各種ＤＢ群３５の対象口座番号のレコードをそれぞれ更新する（Ｓ２７）。ＤＢサーバ３は、各種ＤＢ群３５のデータベース毎に、更新に成功したか、または失敗したかの更新結果を、業務サーバ２に送信する。
【００４１】
各種ＤＢ群３５の全てデータベースの更新が成功した場合（Ｓ２８：ＹＥＳ）、業務サーバ２のＤＢ更新部２１は、口座処理テーブル３８の対象口座番号の処理ステータスを「未処理」から「正常終了」に変更する（Ｓ２９）。そして、ＤＢ更新部２１は、ＤＢサーバ３にコミットを発行し、各種ＤＢ群３５のロックを解除する（Ｓ３０）。これにより、Ｓ２１で読み出した口座番号のトランザクション処理が確定し、当該口座番号の各種ＤＢ群３５に対するＳ２７の更新処理が完了する。そして、ＤＢ更新部２１は、Ｓ２１に戻り、受信キュー２３から次のメッセージを読み出して、次のトランザクションを実行する。
【００４２】
一方、各種ＤＢ群３５の少なくとも１つのデータベースの更新に失敗した場合（Ｓ２８：ＮＯ）、ＤＢ更新部２１は、口座処理テーブル３８の対象口座番号の処理ステータスを「未処理」から「異常終了」に変更する（Ｓ３１）。そして、ＤＢ更新部２１は、ロールバック（roll back）をＤＢサーバ３に送信し、各種ＤＢ群３５のロックを解除する（Ｓ３２）。これにより、Ｓ２１で読み出した口座番号のトランザクション処理がアボート（abort）され、当該口座番号の各種ＤＢ群３５に対するＳ２７の更新処理が全て取り消される。そして、ＤＢ更新部２１は、Ｓ２１に戻り、受信キュー２３から次のメッセージを読み出して、次のトランザクションを実行する。
【００４３】
本実施形態では、口座単位にコミットを発行し、口座単位に各種ＤＢ群３５を更新する。これにより、口座単位でのデータベース間の整合性が確保され、オンライン処理実行時に前日分のバッチ処理データの更新処理を実行することができる。
【００４４】
また、本実施形態のＤＢサーバ３は、複数の業務サーバ２の状態が設定されたサーバ状態テーブル３７を有する。これにより、ＤＢサーバ３は、サーバ状態テーブル３７を参照し、利用可能な状態の業務サーバ２に、更新対象の口座番号を振り分けることができる。また、システム管理者は、サーバ状態テーブル３７の動作ステータスを参照することにより、各業務サーバ２の稼動状態を把握することができる。すなわち、サーバ状態テーブル３７の動作ステータスが、「処理完」になっている場合、対応する業務サーバ２の更新処理が終了したことを把握することができる。
【００４５】
また、本実施形態では、更新対象の口座番号はＤＢサーバ３により複数の業務サーバ２に振り分けられ、複数の業務サーバ２の並行稼動によりバッチ更新データの更新処理が行われる。これにより、バッチ更新データの更新処理時間を短縮することができ、大量データが発生した場合であっても並行稼動する業務サーバ２の数を増やすことで処理能力を向上させることができる。
【００４６】
また、本実施形態のＤＢサーバ３は、各口座の処理状態が記憶された口座処理テーブル３８を有する。これにより、システム管理者は、口座処理テーブル３８を参照することで、全口座の処理状態を把握することができ、システム運用負荷をより軽減することができる。また、システム管理者は、口座処理テーブル３８の処理ステータスを参照し、「異常終了」となった口座のみの再実行を行うことができる。
【００４７】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【図面の簡単な説明】
【００４８】
【図１】本発明の一実施形態が適用されたデータベース更新システムの構成図である。
【図２】各装置のハードウェア構成例を示す図である。
【図３】サーバ状態テーブルの一例を示す図である。
【図４】口座処理テーブルの一例を示す図である。
【図５】ＤＢサーバの更新準備処理のフローチャートである。
【図６】送信キューへ処理依頼メッセージを出力する処理を説明するための説明図である。
【図７】業務サーバの更新処理のフローチャートである。
【符号の説明】
【００４９】
１：ユーザ端末、２：業務サーバ、２１：ＤＢ更新部、２２：オンライン業務処理部、２３：受信キュー、３：ＤＢサーバ、３１：更新情報生成部、３２：サーバ特定部、３３：送信部、３４：更新情報ＤＢ、３５：各種ＤＢ群、３６：サーバ別送信キュー、３７：サーバ状態テーブル、３８：口座処理テーブル、８：ネットワーク
【図１】
2008033395.tif 000003
【図２】
2008033395.tif 000004
【図３】
2008033395.tif 000005
【図４】
2008033395.tif 000006
【図５】
2008033395.tif 000007
【図６】
2008033395.tif 000008
【図７】
2008033395.tif 000009