JP2017097791A - データ処理装置 - Google Patents

Abstract

【課題】通常時は本番データベースサーバのデータが非同期モードで災害対策データベースサーバにコピーされる場合であっても、クライアント端末やクライアントのＳＱＬ文やログ情報を利用することなく、データ転送処理による遅延に由来するデータ欠損が生じることを防止する。
【解決手段】本発明の一実施形態に係るデータ処理装置は、クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文のコピーを受信する第１受信部と、前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更が成功した場合に前記電文を記憶する電文記憶部とを有する。
【選択図】図１

Description

本発明は、データ処理装置に関する。

近年、ビジネスにおいて、ＩＴを用いた計算機システムの重要性は、ますます高まっている。そこで、計算機システムを、本番システムと災害対策システムとに二重化して、本番システムに障害が発生した時には、災害対策システムに切り替えて、サービスを継続させるためのＨＡ技術（Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ技術）が重要となっている。

とりわけ、大規模災害においてもサービスやＩＴを用いた計算機システムの復旧を迅速に行うＤ／Ｒ（Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒ）技術が注目されている。Ｄ／Ｒ技術では、本番システムと災害対策システムとに二重化された計算機システム間でデータのコピーを行うことにより、データ保護を図っている。そのため、データ欠損がないことが最も重要となる。

図１５は、従来のＤ／Ｒシステムの構成を示すブロック図である。従来のＤ／Ｒシステム（Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒ Ｓｙｓｔｅｍ）は、本番システム７３０と遠隔地にある災害対策システム７５０とから構成されている。本番システム７３０では、データの記録、検索等の業務を行う。他方、災害対策システム７５０は、本番システム７３０と同一の内容を記憶しており、本番システム７３０のバックアップサイトとしての役割を果たす。

本番システム７３０は、本番Ｗｅｂ／アプリケーション（ＡＰ）サーバ７３２と、本番データベース（ＤＢ）サーバ７３４とを備え、災害対策システム７５０は、災害対策Ｗｅｂ／アプリケーション（ＡＰ）サーバ７５２と、災害対策データベース（ＤＢ）サーバ７５４とを備える。本番システム７３０に対して、災害対策システム７５０は、遠隔地に設置されており、両システム間は専用回線で接続されている。

平常時においては、ネットワーク７２７経由でクライアント端末７２０ａからリクエストが送信されると、本番Ｗｅｂ／ＡＰサーバ７３２に当該リクエストが転送される。これを受信した本番Ｗｅｂ／ＡＰサーバ７３２は、リクエストの内容に応じた処理を実行し、処理結果を本番ＤＢサーバ７３４に送信する。本番ＤＢサーバは、本番Ｗｅｂ／ＡＰサーバ７３２から受け取った処理結果のデータに基づいて対応のテーブルを更新する。本番システム７３０は、処理結果であるデータを、何らかのタイミングで災害対策システム７５０の災害対策データベース（ＤＢ）サーバ７５４に転送しておく。災害対策ＤＢサーバ７５４は、受け取った処理結果であるデータに基づいて、対応のテーブルを更新する。障害が発生した場合は、システムを切り替え、バックアップサイトであった災害対策システム７５０が業務を引き継いで実行する。

ところで、システム間のデータの転送には、データベース間ネットワークによるコピーも用いられる。本番ＤＢサーバ７３４に格納されるデータと災害対策ＤＢサーバ７５４に格納されるデータとの完全な同一性を担保するためには、まず処理結果を本番ＤＢサーバから災害対策ＤＢサーバに送信し、データ更新完了の通知が返ってきた時点で本番ＤＢサーバに対する更新を実行する、同期モードを採用するのが理想的である。ところが、災害対策システムは、その性質上、本番システムから遠距離に設置されるところ、遠距離で同期モードを採用するのは、ネットワークの遅延があるため、困難である。そのため、本番データベースのデータは、災害対策データベースに非同期モードでコピーされるのが現状である。

しかしながら、本番データベース７３０のデータが非同期モードで災害対策データベース７５０にコピーされる場合、データ転送処理による遅延が発生するため、データ欠損が生じる可能性がある。例えば、１日に１度、業務終了後にデータを転送する場合、データの転送前に、本番システム７３０に障害が生じたときは、最後にデータを転送してから、本番システム７３０に障害が生じたときまでの間に本番システム７３０の本番ＤＢサーバ７３４に反映されたデータを失うという問題が生じる。

そこで、例えば、図１６に示すように、特許文献１に開示されたデータベース管理システムは、データベースの障害が発生した際に、１日単位などでバックアップされたバックアップデータに対し、バックアップ以降にサーバ上で実行された確定したトランザクションをＳＱＬ文に変換して保持しているサーバトランザクションログ８３４と、クライアントが実行し確定したトランザクションをＳＱＬ文に変換してクライアントが保持するクライアントトランザクションログ８２３を収集し、反映させることによりデータベースを復旧させている。

特開２０００−２０３６９号公報

しかしながら、特許文献１に開示された従来例では、インターネットなどの広域網に接続された不特定多数の機器が接続された状況では、クライアントからログを収集することは非常に困難であるという問題がある。

本発明は、上記のような従来技術に伴う課題を解決しようとするものであって、その目的とするところは、通常時は本番データベースサーバのデータが非同期モードで災害対策データベースサーバにコピーされる場合であっても、クライアント端末やクライアントのＳＱＬ文やログ情報を利用することなく、データ転送処理による遅延に由来するデータ欠損が生じることを防止するところにある。

本発明の一実施形態によると、クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文のコピーを受信する第１受信部と、前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更が成功した場合に前記電文を記憶する電文記憶部と、を有するデータ処理装置を提供することができる。

前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更の操作を実行した結果を前記クライアントへ返信する第２電文のコピーを受信する第２受信部と、前記第１電文のコピーまたは前記第２電文のコピーから、前記電文を生成する電文生成部をさらに有することを特徴とするデータ処理装置であってもよい。

本発明の一実施形態によると、クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文のコピーを受信する第１受信部と、前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更が成功した場合に前記第１電文のコピーを記憶するコピー記憶部とを有するデータ処理装置を提供することができる。

別の好ましい態様において、前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更の操作を実行した結果を前記クライアントへ返信する第２電文のコピーを受信する第２受信部を有し、前記コピー記憶部は、前記第２電文のコピーが前記データベースの変更の操作の成功を示す場合に前記第１電文のコピー又は第２電文のコピーを記憶することを特徴とするデータ処理装置であってもよい。

別の好ましい態様において、前記記憶部に記憶された第１電文のコピー又は第２電文のコピーから、前記サーバが生成したデータベース操作文を生成するための電文を生成する電文生成部を有するデータ処理装置であってもよい。

本発明の一実施形態によると、クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文のコピーを受信する第１受信部と、前記第１電文のコピーを記憶するコピー記憶部と、前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更が成功した場合に、該成功にかかる第１電文のコピーにデータベースの変更の操作の成功を示す制御情報を付加する履歴管理部と、を有するデータ処理装置を提供することができる。

前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更の操作を実行した結果を前記クライアントへ返信する第２電文のコピーを受信する第２受信部を有し、前記コピー記憶部は、第２電文のコピーを記憶し、前記履歴管理部は、前記第２電文のコピーが前記データベースの変更の操作の成功を示す場合に、前記第１電文のコピー及び前記第２電文のコピーにデータベースの変更の操作の成功を示す制御情報を付加することを特徴とするデータ処理装置であってもよい。

前記成功を示す制御情報を付加された第１電文のコピー又は第２電文のコピーから、前記サーバが生成したデータベース操作文を生成するための電文を生成する電文生成部と、前記電文を記憶する電文記憶部とをさらに有する、データ処理装置であってもよい。

別の好ましい態様において、前記サーバに障害が発生したことを検知する検知部を有するデータ処理装置であってもよい。

別の好ましい態様において、前記サーバに障害が発生すると、前記サーバとして動作する切替部を有するデータ処理装置であってもよい。

別の好ましい態様において、前記切替部は、前記サーバに障害が発生すると、前記クライアントから前記サーバへの経路情報を更新するデータ処理装置であってもよい。

別の好ましい態様において、前記第１受信部が受信した第１電文のコピーに、前記第１電文による前記データベースのトランザクションと関連付ける第１関連付部と、前記第２受信部が受信した第２電文のコピーが前記データベースのどのトランザクションにおける変更の操作を実行した結果を返信するものであるかを判別する第１判別部と、を有し、前記コピー記憶部は、前記第１判別部により判別された前記第２電文のコピーのトランザクションに関連づけられる第１電文のコピー又は前記第２電文のコピーを記憶するデータ処理装置であってもよい。

別の好ましい態様において、前記第１受信部が受信した第１電文のコピーに、送信元のクライアントの識別子を関連付ける第２関連付部と、前記第２受信部が受信した第２電文の送信先のクライアントの識別子を判別する第２判別部と、を有し、前記コピー記憶部は、前記第２判別部により判別された前記第２電文のコピーのトランザクションに関連づけられる第１電文のコピー又は前記第２電文のコピーを記憶するデータ処理装置であってもよい。

別の好ましい態様において、前記第２関連付部は、前記第１電文のコピーが受信された時刻をさらに関連付け、前記コピー記憶部は、前記第２判別部による判別に加え、前記第２関連付部により関連づけられた時刻と前記第２電文のコピーが受信された時刻とに基づいて、前記第１電文のコピー又は前記第２電文のコピーを記憶するデータ処理装置であってもよい。

本発明の一実施形態によると、クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文のコピーを受信する第１受信部と、前記サーバから前記クライアントに送信するセッション識別情報のコピーを受信するセッション識別情報受信部と、前記第１電文のコピー及び前記セッション識別情報のコピーを記憶するコピー記憶部と、前記コピー記憶部に記憶された前記第１電文のコピー及び前記セッション識別情報のコピーから、クライアントへ返信する第２電文を生成する第２電文生成部と、前記サーバに障害が発生したことを検知する検知部を有し、前記第２電文生成部は、前記検知部が前記サーバに障害が発生したことを検知した後に、前記第２電文を生成することを特徴とするデータ処理装置を提供することができる。

前記第２電文及び前記セッション識別情報をクライアントに返信することを特徴とするデータ処理装置であってもよい。

前記コピー記憶部に記憶された第１電文のコピーから、前記サーバが生成したデータベース操作文を生成するための電文を生成する電文生成部をさらに有し、前記電文生成部は、前記検知部が前記サーバに障害が発生したことを検知したときに、前記電文を生成することを特徴とするデータ処理装置であってもよい。

前記サーバに障害が発生すると、前記サーバとして動作する切替部を有してもよい。

本発明の一実施形態によると、クライアントが第１データベースの更新を要求するために送信する第１電文を受信する第１受信部と、前記第１電文を記憶する第１電文記憶部と、前記クライアントへ返信する第２電文を生成する第２電文生成部と、前記第１データベースに障害が発生したことを検知する検知部を有し、前記第２電文生成部は、前記検知部が前記第１データベースに障害が発生したことを検知した後に、前記第２電文を生成することを特徴とするデータ処理装置が提供されてもよい。

前記第１電文記憶部に記憶された第１電文から、データベース操作文を生成するための電文を生成する電文生成部と、前記データベース操作文を生成するための電文を第２データベースに送信する送信部をさらに有し、前記電文生成部は、前記検知部が前記サーバに障害が発生したことを検知したときに、前記電文を生成することを特徴とするデータ処理装置が提供されてもよい。

前記電文を受信した前記第２データベースの変更が成功したことを示す情報を受信する第２受信部をさらに有し、前記第２電文生成部は、前記第２データベースの変更が成功したことを示す情報を基に第２電文を生成することを特徴とするデータ処理装置が提供されてもよい。

本発明の一実施形態によると、データベース操作文の生成の基礎となる情報を記憶する基礎情報記憶部と、稼動系の切替通知を受信する受信部と、前記受信部により受信された前記切替通知に基づき、前記基礎情報記憶部に記憶されている前記データベース操作文の生成の基礎となる情報をデータベース に対して送信する送信部と、を備えるデータ処理装置が提供される。

前記基礎情報記憶部は、データベースの更新に関する情報のみを記憶してもよい。

前記基礎情報記憶部よりデータベースの更新に関する情報のみを抽出して、前記送信部に伝達する抽出部をさらに備えてもよい。

前記基礎情報記憶部は、前記データベースの更新処理結果をクライアントに対して返信する第２電文と、前記データベース操作文の生成の基礎となる情報に対応するクライアントより受信する第１電文とを記憶し、前記第１電文と前記第２電文とが対応付けられるか否かを照合する照合部をさらに備えてもよい。

前記送信部は、前記照合部において前記第１電文と前記第２電文とが不照合であった場合に、前記データベース操作文の生成の基礎となる情報をデータベースに対して送信してもよい。

本発明の一実施形態によると、クライアントがデータベースの更新を要求するためにサーバへ送信する電文を前記サーバへ中継する中継部と、前記サーバが前記電文から前記データベースを更新するためのデータベース操作文を生成し前記データベースの変更が成功した場合に、前記中継部により中継された電文のコピーを生成する生成部とを有するデータ中継装置が提供される。

本発明によれば、通常時は本番データベースサーバのデータが非同期モードで災害対策データベースサーバにコピーされる場合であっても、クライアント端末やクライアントのＳＱＬ文やログ情報を利用することなく、データ転送処理による遅延に由来するデータ欠損が生じることを防止することができる。

本発明の一実施形態に係るＤ／Ｒシステムの構成の一例を示すブロック図である。 本発明の一実施形態に係るデータ処理装置の構成の一例を示すブロック図である。 本発明の一実施形態に係るリクエストデータ及びレスポンスデータのヘッダテーブルの一例を示す図である。 本発明の一実施形態に係るステートメント文及びリストデータの一例を示す図である。 本発明の一実施形態に係るデータ処理装置の構成の一例を示すブロック図である。 本発明の一実施形態に係るリクエストデータ及びレスポンスデータにデータベースの変更の操作の成功を示す制御情報を付加したことを示す図である。 本発明の他の実施形態に係るＤ／Ｒシステムの構成の一例を示すブロック図である。 本発明の他の実施形態に係るＤ／Ｒシステムの構成の一例を示すブロック図である。 本発明の一実施形態に係る各システム間の関係の一例を示すブロック図である。 本発明の他の実施形態に係るデータ処理装置の構成の一例を示すブロック図である。 本発明の他の実施形態に係るＤ／Ｒシステムの構成の一例を示すブロック図である。 本発明の他の実施形態に係るデータ処理装置の構成の一例を示すブロック図である。 本発明の他の実施形態に係るデータ処理装置の構成の一例を示すブロック図である。 本発明の他の実施形態に係るデータ処理装置の構成の一例を示すブロック図である。 従来のＤ／Ｒシステムの構成の一例を示すブロック図である。 従来のデータベース管理システムの一例を示すブロック図である。

以下、本発明の一実施形態について、図面を参照しながら詳細に説明する。以下に示す実施形態は本発明の実施形態の一例であって、本発明はこれらの実施形態に限定されるものではない。なお、本実施形態で参照する図面において、同一部分または同様な機能を有する部分には同一の符号または類似の符号（数字の後にＡ、Ｂなどを付しただけの符号）を付し、その繰り返しの説明は省略する場合がある。他方、同一部分または同様な機能を有する部分で、類似の符号（数字の後にＡ、Ｂなどを付しただけの符号）を付した場合であっても、類似の符号を付した部分についての区別が不要な場合には、類似の符号を省略する。例えば、クライアント端末について、区別が不要な場合には、単に「クライアント端末」と表記する。

＜第１実施形態＞
［Ｄ／Ｒシステムの構成］
図１を用いて、Ｄ／Ｒシステム（Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒ Ｓｙｓｔｅｍ）の概要を説明する。図１は、本発明の一実施形態に係るＤ／Ｒシステムの構成の一例を示すブロック図である。Ｄ／Ｒシステムは、本番システム３０と遠隔地にある災害対策システム５０とから構成される。本番システム３０では、データの記録、検索等の業務を行う。他方、災害対策システム５０は、本番システム３０と同一の内容を記憶しており、本番システム３０のバックアップとしての役割を果たす。なお、本番システム３０も災害対策システム５０も、正系と副系で構成される（図示せず）。例えば、障害によって、本番システムの正系が停止した場合には、本番システムの副系に切り替わるといった動作をする。他方、大規模災害等によって、本番システム３０の正系及び副系の両系が停止した場合、すなわち、本番システム３０が停止した場合には、災害対策システム５０に切り替わる。以下では、本番システム３０が停止し、災害対策システム５０に切り替わる場合について説明する。

本番システム３０は、本番Ｗｅｂ／アプリケーション（ＡＰ）サーバ３２と、本番データベース（ＤＢ）サーバ３４とを備え、災害対策システム５０は、災害対策Ｗｅｂ／アプリケーション（ＡＰ）サーバ５２と、災害対策データベース（ＤＢ）サーバ５４とを備える。本番システム３０に対して、災害対策システム５０は、遠隔地に設置されており、両システム間は専用回線で接続されている。この例では、本番システムも災害対策システムも、Ｗｅｂ／ＡＰサーバとＤＢサーバというＷｅｂ２階層システムであるが、これに限定されるものではなく、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバというＷｅｂ３階層システムであっても、Ｗｅｂサーバ、ＡＰサーバ及びＤＢサーバを１つにまとめた１階層システムであってもよい。

平常時においては、ネットワーク２７経由でクライアント端末２０ａからリクエストが送信されると、本番Ｗｅｂ／ＡＰサーバ３２に当該リクエストが転送される。これを受信した本番Ｗｅｂ／ＡＰサーバ３２は、リクエストの内容に応じた処理を実行し、処理結果を本番ＤＢサーバ３４に送信する。本番ＤＢサーバは、本番Ｗｅｂ／ＡＰサーバ３２から受け取った処理結果のデータに基づいて対応のテーブルを更新する。本番システム３０は、処理結果であるデータを、何らかのタイミングで災害対策システム５０の災害対策データベース（ＤＢ）サーバ５４に転送しておく。災害対策ＤＢサーバ５４は、受け取った処理結果であるデータに基づいて、対応のテーブルを更新する。障害が発生した場合は、システムを切り替え、バックアップサイトであった災害対策システム５０が業務を引き継いで実行する。この点については、従来の技術と同じである。

本番システム３０は、クライアント端末２０それぞれがネットワークを介して本番サーバ３２に接続する。また、本番サーバ３２は、クライアント端末２０からデータを受信し、ネットワーク２７を介して本番データベース３４の更新を行う。

ネットワーク２７は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）やインターネット等のネットワークであり、無線／有線回線、専用回線等を問わず、クライアント端末２０が本番サーバ３２に接続可能なネットワーク環境が適用される。

また、クライアント端末２０は、多機能携帯電話、携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等の移動通信端末装置、パーソナルコンピュータなどの通信機能及び演算機能を備えた情報処理端末装置等が含まれる。また、本番サーバ３２が提供する画面を表示する表示制御機能としてブラウザを備え、ＣＰＵ、メモリ及び本番サーバとの間の通信制御を遂行する通信制御部等を含む。さらに、マウスやキーボード、タッチパネル等の操作入力装置及び表示装置を備えることができる。

［データ処理装置の構成］
図２を用いて、データ処理装置５２について説明する。図２は、本発明の一実施形態に係るデータ処理装置の構成の一例を示すブロック図である。データ処理装置（災害対策サーバ）は、第１受信部５２１、第２受信部５２２、照合部５２３、電文生成部５２５、検知部５２６、切替部５２７、一時テーブル５４１、トランザクション実行テーブル５４３及びリカバリーテーブル５４５を含む。

第１受信部５２１は、クライアント端末２０が本番ＤＢサーバ３４の更新を要求するために本番Ｗｅｂ／ＡＰサーバ３４へ送信するリクエストデータ（第１電文）のコピーを全量受信する。具体的には、クライアントが、クライアント端末２０のブラウザ等の画面入力により、例えば、資金異動のリクエストデータを送信する場合、送信されたリクエストデータは、ネットワーク２７を介して、本番システム３０の本番Ｗｅｂ／ＡＰサーバ３２にて取得される。このときに、ネットワーク２７から資金異動のリクエストデータのコピーが転送されて、データ処理装置５２の第１受信部５２１が、これを受信するのである。なお、リクエストデータについての詳細は後述する。

第２受信部５２２は、本番Ｗｅｂ／ＡＰサーバ３２がリクエストデータ（第１電文）から本番ＤＢサーバ３４を更新するためのＳＱＬ文（データベース操作文）を生成するための電文（ステートメント文）を生成し、本番ＤＢ３４の変更の操作を実行した結果をクライアント端末２０に返信するレスポンスデータ（第２電文）のコピーを、ネットワーク２７を介して受信する。具体的には、例えば、クライアント端末２０から、資金異動のリクエストがされた場合、本番Ｗｅｂ／ＡＰサーバ３２は、このリクエストデータからステートメント文及びリストデータを生成する。そして、本番Ｗｅｂ／ＡＰサーバ３２から、ステートメント文及びリストデータが本番ＤＢサーバ３４に送信され、本番ＤＢサーバ３４において、ステートメント文及びリストデータからＳＱＬ文が生成及び実行される。ＳＱＬ文が実行されると、資金異動について、本番ＤＢサーバ３４の対応のテーブルが更新される。その後、本番Ｗｅｂ／ＡＰサーバ３２は、本番ＤＢサーバ３４によって更新された結果を受け取り、レスポンスデータをクライアント端末２０へ送信する。なお、レスポンスデータ、ステートメント文及びリストデータについての詳細は後述する。

トランザクション実行テーブル（コピー記憶部）５４３は、本番Ｗｅｂ／ＡＰサーバ３２がリクエストデータ（第１電文）から本番ＤＢサーバ３４を更新するためのＳＱＬ文（データベース操作文）を生成するためのステートメント文及びリストデータを生成し、本番ＤＢサーバ３４の変更が成功した場合に、リクエストデータ（第１電文）のコピーを記憶する。具体的には、トランザクション実行テーブル５４３は、レスポンスデータ（第２電文）のコピーが本番ＤＢサーバ３４の変更の操作の成功を示す場合に、リクエストデータ（第１電文）のコピーを記憶する。

ここで、照合部５２３を説明する前提として、図３を用いて、リクエストデータのコピー及びレスポンスデータのコピーについて説明する。図３は、本発明の一実施形態に係るリクエストデータのコピー及びレスポンスデータのコピーのテーブルの一例を示す図である。第１受信部５２１が、リクエストデータのコピーを受信すると、一時テーブル５４１は、リクエストデータのコピーを時系列で分類して記憶する。また、第２受信部５２２が、レスポンスデータのコピーを受信すると、一時テーブル５４１は、レスポンスデータのコピーを時系列で分類して記憶する。リクエストデータのコピーを時系列で分類したテーブルが、図３（ａ）に示すテーブルであり、リクエストデータのコピーを時系列で分類したテーブルが、図３（ｂ）である。リクエストデータのコピーを時系列で分類したテーブルには、リクエストデータのコピーのすべてが記憶され、レスポンスデータのコピーを時系列で分類したテーブルには、レスポンスデータのコピーのすべてが記憶される。いずれのデータのコピーも、ヘッダとボディから構成されるが、図３では、ヘッダのみ示す。

図３に示すように、リクエストヘッダテーブル１１０には、時刻１１１、ＩＰアドレス１１２、リクエストの内容１１３とユーザ名（クライアント名）１１４及びユーザＩＤ（クライアントＩＤ）１１５が含まれる。リクエストヘッダテーブル１２１をみると、ユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」が、時刻「９：０１」に、ＩＰアドレス「１９２．１６８．２３６．６１」から「振込承認画面」をリクエストしていることがわかる。また、リクエストヘッダテーブル１２２をみると、ユーザ名「山田太郎」、ユーザＩＤ「９８７６５４３２」が、時刻「９：０２」に、ＩＰアドレス「１９２．１６８．１．７０」から「残高照会」をリクエストしていることがわかる。

他方、レスポンスヘッダテーブル１３０には、時刻１３１、ＩＰアドレス１３２、Ｓｔａｔｕｓ１３３、ユーザ名１３４、ユーザＩＤ１３５がある。レスポンスヘッダテーブル１４１をみると、時刻「９：０２」に、ユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」、ＩＰアドレス「１９２．１６８．２３６．６１」に対して、「Ｓｔａｔｕｓ＝２００」とのレスポンスがなされていることがわかる。これは、本番サーバから、ブラウザ等にステータスコードを返していることを意味するが、ステータスコードが２００番台であるときは、正常処理がなされたことを意味する。ただし、振込完了でも残高不足にて失敗でも正常処理であることには変わりないことから、ステータスコードが２００であることをもって、資金異動が成功したかどうかは判断できない。資金異動が成功したかどうかを判断するには、振込完了を表わすトランザクション名や処理ＩＤなどで判断することになる。

再び図２を用いて、データ処理装置５２の構成について説明する。照合部５２３は、第１関連付部５３１、第１判別部５３３、第２関連付部５３５、第２判別部５３７を含む。

第１関連付部５３１は、第１受信部５２１が受信したリクエストデータ（第１電文）のコピーに、リクエストデータによる本番ＤＢサーバ３４のトランザクションと関連付ける。具体的には、例えば、リクエストデータのコピーにあるリクエストの内容に「振込承認画面」とあれば、リクエストデータによる本番ＤＢサーバのトランザクションも「振込承認画面」であると関連付ける。

第１判別部５３３は、第２受信部５２２が受信したレスポンスデータ（第２電文）のコピーが本番データベース３４のどのトランザクションにおける変更の操作を実行した結果を返信するものであるかを判別する。具体的には、上記のとおり、レスポンスヘッダテーブルには、ユーザ名やユーザＩＤがある。例えば、ユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」が、時刻「９：０１」に、ＩＰアドレス「１９２．１６８．２３６．６１」から「振込承認画面」をリクエストしている。レスポンスヘッダに、ユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」があれば、「振込承認画面」というトランザクションにおける変更の操作を実行した結果を返信するものであることが判別できる。

そして、トランザクション実行テーブル５４３は、本番ＤＢサーバの変更が成功した場合に、第１判別部５３３により判別されたレスポンスデータ（第２電文）のコピーのトランザクションに関連付けられるリクエストデータ（第１電文）のコピー又はレスポンスデータのコピーを記憶する。具体的には、リクエストデータのコピーを時系列で分類したテーブルから、リクエストデータのコピーが取り出され、更新、この例では、資金異動リクエストかどうかが解析される。そして、資金異動リクエストのコピーである場合には、これに対応するレスポンスデータのコピーに振込完了を表わすトランザクション名や処理ＩＤがあれば、資金異動が完了したものと判断され、トランザクション実行テーブル５４３は、資金異動リクエストデータのコピー又は資金異動リクエストデータに対応するレスポンスデータのコピーをテーブルに記憶する。他方、資金異動リクエストかどうかが解析されて、資金異動リクエストではないと判断されたリクエストデータのコピー及びこれに対応するレスポンスデータのコピーは、一時テーブル（図３のテーブル）５４１から、削除される。ここでは、一時的に記憶されることから、一時テーブルと呼ぶ。

第２関連付部５３５は、第１受信部５２１が受信したリクエストデータ（第１電文）のコピーに、送信元のクライアント端末２０の識別子を関連付ける。具体的には、上記のように、リクエストヘッダテーブル１１０には、ＩＰアドレス（クライアント端末の識別子）やブラウザ情報（図示せず）が含まれている。例えば、ユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」が、時刻「９：０１」に、ＩＰアドレス「１９２．１６８．２３６．６１」から「振込承認画面」をリクエストしている。そこで、第２関連付部５３５は、第１受信部５２１が受信したリクエストデータのコピーに、このＩＰアドレス「１９２．１６８．２３６．６１」を関連付けるのである。

また、第２関連付部５３５は、リクエストデータ（第１電文）のコピーが受信された時刻をさらに関連付ける。具体的には、リクエストヘッダテーブル１１０には、時刻のデータが含まれる。例えば、ユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」が、時刻「９：０１」に、ＩＰアドレス「１９２．１６８．２３６．６１」から「振込承認画面」をリクエストしている。そこで、第２関連付部５３５は、第１受信部が受信したリクエストデータのコピーに、時刻「９：０１」を関連付けるのである。

第２判別部５３７は、第２受信部５２２が受信したレスポンスデータ（第２電文）の送信先のクライアント端末２０の識別子を判別する。具体的には、レスポンスヘッダテーブル１３０には、レスポンスの送信先のクライアント端末２０のＩＰアドレス（識別子）が含まれる。例えば、レスポンスヘッダテーブル１４１をみると、時刻「９：０２」に、ＩＰアドレス「１９２．１６８．２３６．６１」に対して、「Ｓｔａｔｕｓ＝２００」とのレスポンスがなされており、ＩＰアドレス「１９２．１６８．２３６．６１」が含まれている。第２判別部は、このＩＰアドレス「１９２．１６８．２３６．６１」を判別するのである。

そして、トランザクション実行テーブル５４３は、本番ＤＢサーバの変更が成功した場合に、第２判別部５３７による判別により判別されたレスポンスデータのコピーのトランザクションに関連付けられるリクエストデータのコピー又はレスポンスデータのコピーを記憶する。例えば、第２判別部５３７は、レスポンスヘッダのＩＰアドレス「１９２．１６８．２３６．６１」やユーザＩＤを判別する。リクエストデータのコピーを時系列で分類したテーブルから、リクエストデータのコピーが取り出され、更新、この例では、資金異動リクエストかどうかが解析される。そして、資金異動リクエストのコピーである場合には、これに対応するレスポンスデータのコピーに振込完了を表わすトランザクション名や処理ＩＤなどがあれば、資金異動が完了したものと判断され、トランザクション実行テーブル５４３は、資金異動リクエストデータのコピー又は資金異動リクエストデータに対応するレスポンスデータのコピーをテーブルに記憶する。他方、資金異動リクエストかどうかが解析されて、資金異動リクエストではないと判断されたリクエストデータのコピー及びこれに対応するレスポンスデータのコピーは、一時テーブル（図３のテーブル）５４１から、削除される。

トランザクション実行テーブル５４３は、また、本番ＤＢサーバの変更が成功した場合に、第２判別部５３７による上記の判別に加え、リクエストデータのコピーが受信された時刻とレスポンスデータのコピーが受信された時刻とに基づいて、リクエストデータのコピー又はレスポンスデータのコピーを記憶してもよい。具体的には、リクエストヘッダテーブル１２１が示すように、ユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」が、時刻「９：０１」に、ＩＰアドレス「１９２．１６８．２３６．６１」から「振込承認画面」をリクエストしている。他方、レスポンスヘッダテーブル１４１が示すように、時刻「９：０２」に、ユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」、ＩＰアドレス「１９２．１６８．２３６．６１」に対して、「Ｓｔａｔｕｓ＝２００」とのレスポンスがなされている。

また、リクエストヘッダテーブル１２１とレスポンスヘッダテーブル１４１を対照すると、同じユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」、ＩＰアドレス「１９２．１６８．２３６．６１」があることから、ユーザ名「株式会社Ａ」、ユーザＩＤ「２３４５１０２２」による資金異動のリクエストが処理成功であったということがわかる。トランザクション実行テーブル５４３は、この例のように、レスポンスデータのコピーが本番データベースの変更の操作の成功を示す場合に、リクエストデータのコピー又はレスポンスデータのコピーを記憶してもよい。

図４を用いて、ステートメント文及びリストデータについて説明する。図４は、本発明の一実施形態に係るステートメント文及びリストデータの一例を示す図である。電文生成部５２５は、トランザクション実行テーブル５４３に記憶されたリクエストデータ（第１電文）のコピー又はレスポンスデータ（第２電文）のコピーから、本番Ｗｅｂ／ＡＰサーバ３２が生成したＳＱＬ文を生成するためのステートメント文及びリストデータを生成する。図４に示すように、ステートメント文及びリストデータには、「ＹＯＦＦＫＦＫＭ０６０１Ｐ」というデータが含まれているが、これは、振込を示すデータである。また、図４（ａ）及び（ｂ）を対照すると明らかなとおり、ステートメント文及びリストデータには、同じ「２０１５ ０８／２６ １５：４４：２６ ７８０００６７７６０ａｄｍｉｎ００１ ＹＯＦＦＫＦＫＭ０６０１Ｐ ５１７１３１８ｆ―９ｅｂａ―４２２６―ａｅ６７―０６３ｄｆｅ１３７０ｃ２」というデータがあり、このデータによって、ステートメント文とリストデータを紐づけることが可能となる。

リクエストデータのコピーからステートメント文及びリストデータを作成する場合、具体的には、プログラムで、トランザクション実行テーブル５４３から、仕向け情報、被仕向け情報及び金額情報を取得し、振込サービスプログラムを呼び出し、仕向け情報、被仕向け情報及び金額情報をパラメータとして渡して、実行する。ここで、振込サービスプログラムは、本番システムにおいても同一のプログラムが用いられているが、本実施形態では、本番システムと異なり、データ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）は、災害対策ＤＢサーバに接続されていない。そのため、振込サービスプログラムは、災害対策ＤＢサーバに接続前に停止し、停止した時点で、処理結果を出力する。この処理結果が、図４に示すようなステートメント文及びリストデータである。そして、リカバリーテーブル（電文記憶部）５４５は、このステートメント文及びリストデータをそれぞれ記憶する。なお、図４（ａ）に示すように、災害対策ＤＢサーバに接続前に停止した時点における処理結果であるので、ステートメント文は、「ＣＲＰ＿ＮＯ＝？」のように、「？」が入っており、ＳＱＬ文にはなっていない。

レスポンスデータのコピーからステートメント文及びリストデータを作成する場合、レスポンスデータのコピーには、仕向け情報、被仕向け情報、金額情報及び振込完了情報が含まれていることから、リクエストデータのコピーからステートメント文及びリストデータを作成する場合と同様に、プログラムで、トランザクション実行テーブル５４３から、仕向け情報、被仕向け情報及び金額情報を取得し、振込サービスプログラムを呼び出し、仕向け情報、被仕向け情報及び金額情報をパラメータとして渡して、実行する。その結果、ステートメント文及びリストデータが得られ、リカバリーテーブル５４５は、このステートメント文及びリストデータをそれぞれ記憶する。

検知部５２６は、本番Ｗｅｂ／ＡＰサーバを含む本番システムに障害（災害）が発生したことを検知する。具体的には、災害対策システム５０のデータ処理装置５２の検知部５２６が本番システム３０に対して、常に信号を送信し、これに対して、本番システム３０が検知部５２６に対して、応答信号を送信しているところ、この応答信号がなくなったときに、検知部５２６は、災害が発生したものとみなすのである。

切替部５２７は、検知部５２６が本番Ｗｅｂ／ＡＰサーバ３２に障害（災害）が発生したことを検知すると、データ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）５２を本番Ｗｅｂ／ＡＰサーバ３２として動作することに切り替える。また、切替部５２７は、本番Ｗｅｂ／ＡＰサーバ３２に障害が発生すると、クライアント端末２０から本番Ｗｅｂ／ＡＰサーバ３２への経路情報を更新する。すなわち、ＤＮＳサーバ（図示せず）の設定変更によって、クライアント端末２０の接続先が、災害対策Ｗｅｂ／ＡＰサーバに切り替わるのである。また、本番Ｗｅｂ／ＡＰサーバ３２に障害が発生すると、本番ＤＢサーバ３４のデータが非同期で災害対策ＤＢサーバ５４にコピーされることが止まる。

ここで、上記の切り替えを行った後、リカバリーテーブル５４５から災害対策ＤＢサーバ５４にステートメント文及びリストデータを転送するときに、転送するステートメント文及びリストデータは限られる。すなわち、平常時は、本番ＤＢサーバ３４から災害対策ＤＢサーバ５４にデータが非同期で転送されているため、未だ転送されていないデータに対応するステートメント文及びリストデータだけ転送すればよい。そこで、リカバリーテーブル５４５のデータと災害対策ＤＢサーバ５４のデータとを突合して、未だ転送されていないデータに対応するステートメント文及びリストデータが、災害対策ＤＢサーバ５４に転送されることになる。具体的には、リカバリーテーブル５４５の時刻情報とユーザ名又はユーザＩＤの情報と災害対策ＤＢサーバ５４の時刻情報とユーザ名又はユーザＩＤの情報とを突合して、未だ転送されていないデータを転送するのである。なお、未だ転送されていないデータを転送する方法としては、以下の方法が考えられる。すなわち、平常時に本番ＤＢサーバ３４から災害対策ＤＢサーバ５４にデータが非同期で転送したタイミングで、転送が完了したこと表わす信号をデータ処理装置に送信する。そして、この信号を受信したデータ処理装置がリカバリーテーブル５４５に記憶されているデータを破棄しておく。その後、検知部５２６が、災害が発生したことを検知したときまでにリカバリーテーブル５４５に記憶されるデータが未だ転送されていないデータとなるから、これを災害対策ＤＢサーバ５４に転送するのである。

従来の技術では、平常時においては、データ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）５２は、特段、活用されていない。他方、本実施形態によれば、平常時において、データ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）の一時テーブル５４１は、上記のとおり、リクエストデータのコピー及びレスポンスデータのコピーを記憶する。そして、トランザクション実行テーブル５４３は、リクエストデータが、資金異動リクエストの場合、レスポンスデータのコピーが振込完了を表わすトランザクション名や処理ＩＤなどを含んでいれば、資金異動が完了したものと判断し、当該リクエストデータのコピー及びレスポンスデータのコピーを記憶する。このトランザクション実行テーブル５４３から特定のデータを取得して、振込サービスプログラムを実行して、ステートメント文及びリストデータを作成し、リカバリーテーブル５４５に記憶する。その後、未だ災害対策ＤＢサーバ５４に転送されていないデータに対応するステートメント文及びリストデータが、災害対策ＤＢサーバを更新するために用いられるといったように有効活用されるという効果を奏する。

また、本実施形態では、トランザクションには、複数の種類がある。例えば、「振込承認画面」、「残高照会」、「ファイルアップロード」、「ＴＯＰ」などである。このトランザクションのうち、「振込承認画面」の場合には、リクエストデータが資金異動であることから、本番ＤＢサーバ３４のデータは更新される。他方、トランザクションが「残高照会」の場合には、本番ＤＢサーバ３４のデータは更新されない。そして、本実施形態では、トランザクション実行テーブル５４３は、レスポンスデータのコピーが本番データベース３４の変更の操作の成功を示す場合、例えば、資金異動の場合に、リクエストデータのコピー又はレスポンスデータのコピーを記憶する。そのため、リクエストデータのコピー又はレスポンスデータのコピーのいずれか１つのデータから、資金異動のような更新のみをデータとして復元することができるという効果を奏する。

また、従来の技術では、人が、災害が発生したことを認識した上で、データ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）５２を本番Ｗｅｂ／ＡＰサーバ３２として動作することに切り替えることを手動で行っていた。そして、この切り替えを手動で行うには、時間を要していた。他方、本実施形態によれば、検知部が、本番Ｗｅｂ／ＡＰサーバを含む本番システムに障害（災害）が発生したことを検知すると、切替部は、データ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）５２を本番Ｗｅｂ／ＡＰサーバ３２として動作することに自動的に切り替える。したがって、本実施形態によれば、データ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）５２を本番Ｗｅｂ／ＡＰサーバ３２として動作することに切り替えることに要する時間が短くなるという効果を奏する。

また、本実施形態によれば、データ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）５２は、上記のとおり、トランザクション実行テーブル５４３に記憶されたリクエストデータのコピー又はレスポンスデータのコピーから、ステートメント文及びリストデータを生成し、リカバリーテーブル５４５は、ステートメント文及びリストデータを記憶する。そして、本番Ｗｅｂ／ＡＰサーバ３２を含む本番システムに障害（災害）が発生した場合、データ処理装置５２は、ステートメント文及びリストデータのうち、平常時に転送されていなかったデータに対応するステートメント文及びリストデータが、災害対策ＤＢサーバ５４に転送される。そして、災害対策ＤＢサーバ５４で、転送されたステートメント文及びリストデータから、ＳＱＬ文が生成、実行され、災害対策ＤＢサーバのデータが更新される。そのため、平常時は本番ＤＢサーバ３４のデータが非同期で災害対策ＤＢサーバ５４にコピーされる場合であっても、クライアント端末２０やクライアントのＳＱＬ文やログ情報を利用することなく、データ転送処理による遅延に由来するデータ欠損が生じることを防止することができる。

さらに、リクエストデータには、例えば、クライアントＩＤやパスワードのデータ（図３には図示せず）も含まれる。例えば、資金異動などのリクエストデータがあり、本番ＤＢサーバが更新され、その後、本番ＤＢサーバに障害が発生し、しかも、その資金異動などのリクエストデータについて、本番ＤＢサーバから災害対策ＤＢサーバにデータの転送がされていなかった場合には、クライアントＩＤやパスワードのデータを利用することができる。具体的には、クライアントＩＤやパスワードのデータから、ダミークライアントを生成し、ログインして、資金異動などの取引を行うことによって、取引を復元して、災害対策ＤＢサーバを更新することができる。

＜第２実施形態＞
図５及び図６を用いて、履歴管理部を備えるデータ処理装置について説明する。図５は、本発明の一実施形態に係るデータ処理装置の構成の一例を示すブロック図である。図６は、本発明の一実施形態に係るリクエストデータ及びレスポンスデータにデータベースの変更の操作の成功を示す制御情報を付加したことを示す図である。本実施形態は、第１実施形態と概ね同じである。そこで、重複する部分についての説明は省略し、異なる点を説明する。本実施形態に係るデータ処理装置５２Ｃは、第１実施形態と異なり、履歴管理部５３０を備える。また、本実施形態に係るデータ処理装置５２Ｃのコピー記憶部５５１は、すべてのリクエストデータ（第１電文）のコピー及びレスポンスデータ（第２電文）のコピーを記憶する。

履歴管理部５３０は、本番Ｗｅｂ／ＡＰサーバがリクエストデータから本番ＤＢサーバを更新するためのＳＱＬ文（データベース操作文）を生成するためのステートメント文及びリストデータを生成し、このステートメント文及びリストデータを基に本番ＤＢサーバの変更が成功した場合に、この成功にかかるリクエストデータのコピーに本番ＤＢサーバの変更の成功を示す制御情報を付加する。図６に示すように、リクエストヘッダテーブル１２１の制御情報１１６は、本番ＤＢサーバの変更が成功したことを示す制御情報が入力されている。他方、リクエストヘッダテーブル１２２乃至１２４には、このような制御情報が入力されない。残高照会やＴＯＰ画面、ファイルアップロードでは、本番ＤＢサーバが変更されないからである。

また、履歴管理部５３０は、レスポンスデータのコピーが本番ＤＢサーバの変更が成功した場合に、リクエストデータのコピー及びレスポンスデータのコピーに本番ＤＢサーバの変更の成功を示す制御情報を付加してもよい。図６に示すように、リクエストヘッダテーブル１２１の制御情報１１６及びレスポンスヘッダテーブル１４１の制御情報１３７は、本番ＤＢサーバの変更が成功したことを示す制御情報が入力されている。

電文生成部５２５は、本番ＤＢサーバの変更の成功を示す制御情報を付加されたリクエストデータのコピーまたはレスポンスデータのコピーから、本番Ｗｅｂ／ＡＰサーバが生成したＳＱＬ文を生成するためのステートメント文及びリストデータを生成する。すなわち、電文生成部５２５は、コピー記憶部５５１に記憶されたすべてのリクエストデータのコピーまたはレスポンスデータのコピーのうち、図６に示すような本番ＤＢサーバの変更の成功を示す制御情報を付加されたリクエストデータのコピーまたはレスポンスデータのコピーに限って、これらのデータのコピーからステートメント文及びリストデータを生成するのである。

電文記憶部５５３は、電文生成部５２５で生成されたステートメント文及びリクエストデータを記憶する。

本実施形態でも、第１実施形態と同様に、平常時においては、特段活用されていないデータ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）を有効活用することができるという効果を奏する。また、本実施形態でも、第１実施形態と同様に、データ処理装置を本番Ｗｅｂ／ＡＰサーバとして動作することに切り替えることに要する時間が短くなるという効果を奏する。さらに、本実施形態でも、第１実施形態と同様に、平常時は本番ＤＢサーバのデータが非同期で災害対策ＤＢサーバにコピーされる場合であっても、クライアント端末やクライアントのＳＱＬ文やログ情報を利用することなく、データ転送処理による遅延に由来するデータ欠損が生じることを防止することができる。

また、本実施形態でも、第１実施形態と同様に、リクエストデータのコピー又はレスポンスデータのコピーのいずれか１つのデータから、資金異動のような更新のみをデータとして復元することができる。

さらに、本実施形態でも、第１実施形と同様に、リクエストデータ中のクライアントＩＤやパスワードのデータから、ダミークライアントを生成し、ログインして、資金異動などの取引を行うことによって、取引を復元して、災害対策データベースを更新することができる。

＜第３実施形態＞
図７は、本発明の他の実施形態に係るＤ／Ｒシステムの構成の一例を示すブロック図である。本実施形態は、第１実施形態と概ね同じである。そこで、重複する部分についての説明は省略し、異なる点を説明する。本実施形態は、第１実施形態の検知部５２６がデータ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）５２の内部になく、外部に検知部３６がある。この検知部３６が災害を検知して、災害であることを表わす信号をデータ処理装置５２に送信する。本実施形態に係るデータ処理装置には、第１実施形態のデータ処理装置と異なり、検知部３６が送信するデータを受信する災害情報データ受信部（図示せず）がある。

一例として、本番システム３０が正系システム３０ａ、副系システム３０ｂを含み、正系システム３０ａと副系システム３０ｂが互いを監視し、検知部３６が統合監視をしている。正系システム３０ａと副系システム３０ｂの監視が停止した場合、無通信となるので、そのタイミングで、検知部３６は、災害が生じたことを示すデータをデータ処理装置５２の災害情報データ受信部に送信する。災害情報データ受信部が、このデータを受信すると、切替部は、データ処理装置５２を本番Ｗｅｂ／ＡＰサーバ３２として動作することに自動的に切り替える。なお、地震の検知には、地震計を併用してもよい。

また、別の例として、検知部３６が、本番システム３０の正系システム３０ａ、副系システム３０ｂを監視するシステム統合監視をし、統合監視で本番システム３０のすべてが停止したと判断できた場合に、検知部３６が、データ処理装置５２の災害情報データ受信部に、災害であることを表わす信号を送信してもよい。この場合、検知部３６は、地震が生じる前にこれから地震が生じることを検知して稼働するため、検知部３６が停止する前に、災害情報データ受信部に災害であることを表わす信号を送信することは可能である。なお、地震の検知には、地震計を併用してもよい。

また、さらに別の例として、検知部３６が、本番システム３０の正系システム３０ａ、副系システム３０ｂを監視するシステム統合監視をし、統合監視で本番システム３０のすべて又は一部が停止したと判断できた場合に、検知部３６が、データ処理装置５２の災害情報データ受信部に、災害であることを表わす信号を送信してもよい。

本実施形態でも、第１実施形態及び第２実施形態と同様に、平常時においては、特段活用されていないデータ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）を有効活用することができるという効果を奏する。また、本実施形態でも、第１実施形態及び第２実施形態と同様に、データ処理装置を本番Ｗｅｂ／ＡＰサーバとして動作することに切り替えることに要する時間が短くなるという効果を奏する。さらに、本実施形態でも、第１実施形態及び第２実施形態と同様に、平常時は本番ＤＢサーバのデータが非同期で災害対策ＤＢサーバにコピーされる場合であっても、クライアント端末やクライアントのＳＱＬ文やログ情報を利用することなく、データ転送処理による遅延に由来するデータ欠損が生じることを防止することができる。

また、本実施形態でも、第１実施形態及び第２実施形態と同様に、リクエストデータのコピー又はレスポンスデータのコピーのいずれか１つのデータから、資金異動のような更新のみをデータとして復元することができる。

さらに、本実施形態でも、第１実施形態及び第２実施形態と同様に、リクエストデータ中のクライアントＩＤやパスワードのデータから、ダミークライアントを生成し、ログインして、資金異動などの取引を行うことによって、取引を復元して、災害対策データベースを更新することができる。

＜第４実施形態＞
図８を用いて、クライアント端末２０とネットワーク２７の途中にデータ中継装置６０がある場合について説明する。図８は、本発明の他の実施形態に係るＤ／Ｒシステムの構成の一例を示すブロック図である。データ中継装置６０は、中継部６０１と生成部６０３とを含む。

中継部６０１は、クライアント端末２０が本番データベース３４の更新を要求するために本番Ｗｅｂ／ＡＰサーバ３２へ送信するリクエストデータを本番Ｗｅｂ／ＡＰサーバ３２へ中継する。中継部６０１は、例えば、インターネットサービスプロバイダである。

生成部６０３は、本番Ｗｅｂ／ＡＰサーバ３２がリクエストデータから本番ＤＢサーバ３４を更新するためのＳＱＬ文（データベース操作文）を生成するためのステートメント文及びリストデータを生成し本番データベース３２の変更が成功した場合に、中継部６０１により中継されたリクエストデータのコピーを生成する。

本実施形態によれば、データ中継装置６０を用いて、リクエストデータのコピーを生成することが可能となる。そして、第１実施形態乃至第３実施形態と同様に、リクエストデータ中のクライアントＩＤやパスワードのデータから、ダミークライアントを生成し、ログインして、資金異動などの取引を行うことによって、取引を復元して、災害対策ＤＢサーバを更新することができる。本実施形態によれば、インターネットサービスプロバイダなどのデータ中継装置を用いて、契約企業と顧客データを転送・解析するようなサービスを提供することができる。

＜第５実施形態＞
上記の実施形態では、本番システムが単一のシステムからなる場合について説明したが、本番システムが複数のシステム又は複数のサービスからなり、かつ各システムが連携している場合もある。この場合も、上記実施形態と概ね同じであり、一部が異なる。そこで、ここでは、重複する箇所についての説明は省略する。

単一のシステムの場合、災害対策Ｗｅｂ／ＡＰサーバは、記憶しているステートメント文及びリストデータを災害対策ＤＢサーバに転送して、このステートメント文及びリストデータからＳＱＬ文を生成、実行して、災害対策ＤＢサーバに記憶されているデータを更新することになるが、記憶しているステートメント文及びリストデータをすべて転送するわけではない。なぜなら、上記実施形態においても、非同期で本番ＤＢサーバから災害対策ＤＢサーバにデータが転送されているため、災害対策ＤＢサーバに転送されていないデータに対応するステートメント文及びリストデータだけ転送した上で、災害対策ＤＢサーバに記憶されているデータを更新すればよいからである。

図９に示すように、本番システムが複数のシステム又は複数のサービスからなり、かつ各システムが連携している場合についても、災害対策Ｗｅｂ／ＡＰサーバに記憶しているステートメント文及びリストデータのすべてを災害対策ＤＢサーバに転送して、災害対策ＤＢサーバに記憶されているデータを更新するわけではない点では同じである。もっとも、本番システムが複数のシステム又は複数のサービスからなり、かつ各システムが連携している場合には、各システム内で、災害対策ＤＢサーバに転送されていないステートメント文及びリストデータを突合後、システム間でも突合する。

具体的には、バックシステム７０以外のフロントシステムが、バックシステム７０と整合をとることになる。この例では、フロントシステムは、顧客との接点を取り持つシステムであり、例えば、インターネットバンキングシステムである。また、バックシステムは、約定した取引を記録し、その内容を元帳などに反映させるシステムであり、例えば、口座管理システムである。例えば、クライアントが、クライアント端末から、インターネットバンキングを利用して、振込を完了させた場合、当該クライアントからすると、振込が完了したものと認識される。ところが、口座管理システムにおいて、当該クライアントの振込が完了しないまま、災害が発生してしまう場合がある。この場合、フロントシステムとバックシステムで突合をとって、振込が完了したことを災害対策ＤＢサーバのテーブルに反映する必要があるのである。

本実施形態でも、第１実施形態乃至第３実施形態と同様に、平常時においては、特段活用されていないデータ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）を有効活用することができるという効果を奏する。また、本実施形態でも、第１実施形態乃至第３実施形態と同様に、データ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）を本番Ｗｅｂ／ＡＰサーバとして動作することに切り替えることに要する時間が短くなるという効果を奏する。さらに、本実施形態でも、第１実施形態乃至第３実施形態と同様に、平常時は本番ＤＢサーバのデータが非同期で災害対策ＤＢサーバにコピーされる場合であっても、クライアント端末やクライアントのＳＱＬ文やログ情報を利用することなく、データ転送処理による遅延に由来するデータ欠損が生じることを防止することができる。

また、本実施形態でも、第１実施形態乃至第３実施形態と同様に、リクエストデータのコピー又はレスポンスデータのコピーのいずれか１つのデータから、資金異動のような更新のみをデータとして復元することができる。

さらに、本実施形態でも、第１実施形態乃至第４実施形態と同様に、リクエストデータ中のクライアントＩＤやパスワードのデータから、ダミークライアントを生成し、ログインして、資金異動などの取引を行うことによって、取引を復元して、災害対策データベースを更新することができる。

＜第６実施形態＞
図１０は、本発明の他の実施形態に係るデータ処理装置の構成の一例を示すブロック図である。本実施形態は、第１実施形態と概ね同じである。そこで、重複する部分についての説明は省略し、異なる点を説明する。本実施形態に係るデータ処理装置５２Ｄは、第１実施形態のデータ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）５２の構成に加えて、セッション識別情報受信部５２８がある。

セッション識別情報受信部５２８は、本番Ｗｅｂ／ＡＰサーバ３２から、セッション識別情報を受信する。ここで、セッション識別情報とは、セッションを識別する情報をいう。この例では、クライアント端末２０があるサービス（例えば、インターネットを介して振込を行うサービス）を利用するときに、クライアント端末２０がログイン画面を開くと、本番Ｗｅｂ／ＡＰサーバがログイン画面を返す。そして、クライアント端末２０がログインすると、本番Ｗｅｂ／ＡＰサーバ３２は、セッション識別情報を発行し、次の画面を返すときにレスポンスにセッション識別情報を含める。続けて、クライアント端末２０がリクエストデータ（例えば、資金異動のデータ）を本番Ｗｅｂ／ＡＰサーバ３２に送信するときに、渡されたセッション識別情報を含める。セッション識別情報受信部５２８は、本番Ｗｅｂ／ＡＰサーバ３２がクライアント端末２０にレスポンスを返すときに、セッション識別情報のコピーを受信するが、これに限定されるものではなく、クライアント端末２０がリクエストデータを本番Ｗｅｂ／ＡＰサーバ３２に送信するときに、セッション識別情報のコピーを受信してもよい。

従来技術では、クライアント端末からのリクエストデータ（第１電文）が本番Ｗｅｂ／ＡＰサーバで処理はされたが、本番ＤＢサーバでデータベースの更新がされる前に、本番システムに障害が生じた場合には、データベースの更新がなされないといった問題やクライアント端末がレスポンスデータ（第２電文）を受信できないといった問題がある。

他方、本実施形態によれば、クライアント端末２０が本番ＤＢサーバ３４のデータベースの更新を要求するために本番Ｗｅｂ／ＡＰサーバ３２にリクエストデータを送信するときに、データ処理装置５２Ｄの第１受信部５２１は、リクエストデータのコピーを受信し、コピー記憶部５６１は、このリクエストデータのコピーを記憶する。また、セッション情報受信部５２８は、セッション識別情報のコピーを受信し、コピー記憶部５６１は、セッション識別情報のコピーを記憶する。クライアント端末からのリクエストデータ（第１電文）が本番Ｗｅｂ／ＡＰサーバで処理はされたが、本番ＤＢサーバでデータベースの更新がされる前に、本番システムに障害が生じた場合、検知部５２６が、この障害を検知すると、切替部５２７は、データ処理装置５２Ｄが、本番Ｗｅｂ／ＡＰサーバとして動作することに切り替える。そして、検知部５２６が、障害を検知すると、電文生成部５２５は、ステートメント文及びリストデータを生成する。そして、ステートメント文及びリストデータからＳＱＬ文を生成・実行し、災害対策ＤＢサーバ５４のデータベースを更新する。その後、クライアント端末２０にレスポンスデータ（第２電文）及びセッション識別情報のコピーを返信する。セッション識別情報のコピーがなければ、クライアント端末２０は、レスポンスデータを受信できない。このように、本実施形態では、クライアント端末からのリクエストデータが本番Ｗｅｂ／ＡＰサーバで処理はされたが、本番ＤＢサーバでデータベースの更新がされる前に、本番システムに障害が生じた場合であっても、災害対策ＤＢサーバのデータベースが更新され、クライアント端末がレスポンスデータを受信することができるという効果を奏する。

また、従来技術では、リクエストデータが本番Ｗｅｂ／ＡＰサーバ３２で処理され、本番ＤＢサーバ３４でデータベースの更新はされたものの、クライアント端末２０がレスポンスデータを受信する前に、本番システム３０に障害が生じた場合には、クライアント端末２０がレスポンスデータを受信できないといった問題がある。なお、この問題が生じる場合としては、本番ＤＢサーバ３４でデータベースが更新され、かつ、災害対策ＤＢサーバ５４のデータベースが更新されていない場合と、本番ＤＢサーバ３４でデータベースが更新され、かつ、災害対策ＤＢサーバ５４のデータベースが更新されている場合がある。

他方、本実施形態では、本番ＤＢサーバ３４でデータベースが更新され、かつ、災害対策ＤＢサーバ５４のデータベースが更新されていない場合と、本番ＤＢサーバ３４でデータベースが更新され、かつ、災害対策ＤＢサーバ５４のデータベースが更新されている場合のいずれの場合であっても、上記問題は生じないという効果を奏する。

まず、本番ＤＢサーバ３４でデータベースが更新され、かつ、災害対策ＤＢサーバ５４のデータベースが更新されていない場合に、クライアント端末２０が本番Ｗｅｂ／ＡＰサーバ３２からレスポンスデータを受信する前に、本番システム３０に障害が生じたときには、コピー記憶部５６１に記憶されたリクエストデータのコピーとレスポンスデータのコピーとを突合する。すなわち、リクエストデータのコピーとレスポンスデータのコピーのユーザ名、ユーザＩＤ、ＩＰアドレス等を突合すると、対応するレスポンスデータのコピーが存在しないリクエストデータのコピーが判明する。このリクエストデータに対応するレスポンスデータがクライアント端末２０に返信されていないことがわかる。そこで、電文生成部５２５Ｃは、このリクエストデータのコピーからステートメント文及びリストデータを生成し、これらは、災害対策ＤＢサーバ５４に転送される。そして、災害対策ＤＢサーバ５４は、ステートメント文及びリストデータからＳＱＬ文を生成し、データベースを更新し、クライアント端末２０にレスポンスデータを送信することになる。

次に、本番ＤＢサーバ３４でデータベースが更新され、かつ、災害対策ＤＢサーバ５４のデータベースが更新されている場合に、クライアント端末２０が本番Ｗｅｂ／ＡＰサーバ３２からレスポンスデータを受信する前に、本番システム３０に障害が生じたときに、コピー記憶部５６１に記憶されたリクエストデータのコピーとレスポンスデータのコピーとを突合すると、対応するレスポンスデータのコピーが存在しないリクエストデータのコピーが判明する。もっとも、対応するレスポンスデータのコピーが存在しないリクエストデータについても、災害対策ＤＢサーバ５４のデータベース自体は更新されてはいる。そのため、対応するレスポンスデータのコピーが存在しないリクエストデータからステートメント文及びリストデータを生成して、これらが災害対策ＤＢサーバ５４に転送されると、二重に更新されてしまうため、これを避ける必要がある。そこで、既に更新されたデータのうち、レスポンスデータが返信されていないデータをデータベースから抽出して、第２電文生成部５２９は、レスポンスデータを生成する。具体的には、対応するレスポンスデータのコピーが存在しないリクエストデータには、ユーザ名、ユーザＩＤ、ＩＰアドレス、時刻などの情報があるので、災害対策ＤＢサーバ５４のデータベースから、対応するレスポンスデータのコピーが存在しないリクエストデータのユーザ名、ユーザＩＤ、ＩＰアドレス等と合致するデータを抽出する。抽出したデータには、仕向け情報、被仕向け情報、金額情報、時刻等のデータがあるので、これらのデータから、第２電文生成部５２９は、レスポンスデータを生成するのである。

本実施形態でも、第１実施形態乃至第３実施形態と同様に、平常時においては、特段活用されていないデータ処理装置（災害対策Ｗｅｂ／ＡＰサーバ）を有効活用することができるという効果を奏する。また、本実施形態でも、第１実施形態乃至第３実施形態と同様に、データ処理装置を本番Ｗｅｂ／ＡＰサーバとして動作することに切り替えることに要する時間が短くなるという効果を奏する。さらに、本実施形態でも、第１実施形態乃至第３実施形態と同様に、平常時は本番ＤＢサーバのデータが非同期で災害対策ＤＢサーバにコピーされる場合であっても、クライアント端末やクライアントのＳＱＬ文やログ情報を利用することなく、データ転送処理による遅延に由来するデータ欠損が生じることを防止することができる。

また、本実施形態でも、第１実施形態乃至第３実施形態と同様に、リクエストデータのコピーから、資金異動のような更新のみをデータとして復元することができる。

さらに、本実施形態でも、第１実施形乃至第４実施形態と同様に、リクエストデータ中のクライアントＩＤやパスワードのデータから、ダミークライアントを生成し、ログインして、資金異動などの取引を行うことによって、取引を復元して、災害対策データベースを更新することができる。

＜第７実施形態＞
図１１及び図１２を用いて、本番Ｗｅｂ／ＡＰサーバがデータ処理装置として機能する場合について説明する。図１１は、本発明の他の実施形態に係るＤ／Ｒシステムの構成の一例を示すブロック図である。図１２は、本発明の他の実施形態に係るデータ処理装置の構成の一例を示すブロック図である。第６実施形態では、本番システム全体に障害が生じた場合について説明したが、第７実施形態では、本番ＤＢサーバ３４ｃにのみ障害が生じ、本番Ｗｅｂ／ＡＰサーバ３２ｃには障害が生じない場合について説明する。

本実施形態では、図１１に示すように、本番Ｗｅｂ／ＡＰサーバ３２ｃがデータ処理装置である。また、本番Ｗｅｂ／ＡＰサーバ３２ｃと災害対策ＤＢサーバ５４とがネットワーク４３で接続されている。

データ処理装置（本番Ｗｅｂ／ＡＰサーバ）３２ｃは、第１受信部３２１、第２受信部３２２、第１電文記憶部３２４、電文生成部３２５、検知部３２６、送信部３２８及び第２電文生成部３２９を備える。

第１受信部３２１は、クライアントが本番ＤＢサーバ３４ｃ（第１データベース）の更新を要求するために送信するリクエストデータ（第１電文）を受信する。第１電文記憶部３２４は、当該リクエストデータを記憶する。

検知部３２６は、本番ＤＢサーバ３４ｃに障害が発生したことを検知する。具体的には、検知部３２６が、本番ＤＢサーバ３４ｃに対して、常に信号を送信し、これに対して、本番ＤＢサーバ３４ｃが検知部３２６に対して、応答信号を送信しているところ、この応答信号がなくなったときに、検知部３２６は、災害が発生したものとみなすのである。

電文生成部３２５は、第１電文記憶部３２４に記憶されたリクエストデータから、ＳＱＬ文を生成するためのステートメント文及びリストデータを生成する。具体的には、電文生成部３２５は、第１電文記憶部３２４に記憶されたリクエストデータのうち、未だクライアントにレスポンスデータの返信がないデータについてのみ、ステートメント文及びリストデータを生成する。

送信部３２８は、ネットワーク４３を介して、災害対策ＤＢサーバ５４（第２データベース）に電文生成部３２５が生成したステートメント文及びリストデータを送信する。ステートメント文及びリストデータを受信した災害対策ＤＢサーバ５４は、これらを基にＳＱＬ文を生成・実行し、その結果をデータ処理装置３２ｃに送信する。

第２受信部３２２は、災害対策ＤＢサーバ５４の変更が成功したことを示す情報を受信する。

第２電文生成部３２９は、クライアントへ返信するレスポンスデータ（第２電文）を生成する。第２電文生成部３２９は、検知部３２６が本番ＤＢサーバ３４ｃに障害が発生したことを検知した後に、レスポンスデータを生成する。第２電文生成部３２９は、災害対策ＤＢサーバ５４の変更が成功したことを示す情報を基にレスポンスデータを生成する。

従来の技術では、クライアントがリクエストデータを送信した後、本番ＤＢサーバ３４ｃに障害が発生した場合、レスポンスデータが返信されることはない。しかし、本実施形態では、クライアントがリクエストデータを送信した後に本番ＤＢサーバ３４ｃに障害が発生した場合でも、第１電文記憶部３２４に記憶されたリクエストデータからステートメント文及びリストデータを生成し、これらを災害対策ＤＢサーバ５４に送信し、災害対策ＤＢサーバ５４でＳＱＬ文を生成・実行した後、災害対策ＤＢサーバ５４の変更が成功したことを示す情報が返信され、その情報を基にレスポンスデータが生成され、クライアントに返信される。そのため、クライアントにとって、有益なサービスを提供することができるという効果を奏する。

＜第８実施形態＞
図１３は、本発明の他の実施形態に係るデータ処理装置の構成の一例を示すブロック図である。データ処理装置６２は、受信部６２１、照合部６２３、基礎情報記憶部６２４及び送信部６２５を含む。

基礎情報記憶部６２４は、クライアントから本番Ｗｅｂ／Ａｐサーバ（図示せず）に送信するリクエストデータ（第１電文）を記憶し、本番ＤＢサーバのデータベースでの更新処理結果をクライアントに対して返信するレスポンスデータ（第２電文）を記憶する。

また、基礎情報記憶部６２４は、リクエストデータまたはレスポンスデータから生成されるＳＱＬ文の生成の基礎となる情報を記憶する。具体的には、基礎情報記憶部６２４は、ステートメント文及びリストデータを記憶する。この例では、基礎情報記憶部６２４は、災害対策ＤＢサーバ５４のデータベースの更新に関する情報のみを記憶する。データベースの更新に関する情報は、例えば、資金異動に関するデータである。したがって、基礎情報記憶部６２４は、資金異動に関するデータのステートメント文及びリストデータを記憶する。

受信部６２１は、稼働系の切替通知を受信する。例えば、本番システム（図示せず）の本番Ｗｅｂ／ＡＰサーバや本番ＤＢサーバに災害などによって障害が生じた場合に、受信部６２１は、本番システムから切り替えるための通知を受信する。

照合部６２３は、リクエストデータとレスポンスデータとが対応付けられるか否かを照合する。具体的には、基礎情報記憶部６２４に記憶されたリクエストデータとレスポンスデータとを突合すると、対応するレスポンスデータが存在しないリクエストデータが判明する。リクエストデータとレスポンスデータとが不照合である場合とは、対応するレスポンスデータが存在しないリクエストデータがある場合をいう。

送信部６２５は、受信部６２１により受信された切替通知に基づき、リクエストデータとレスポンスデータとが不照合である場合に、基礎情報記憶部６２４に記憶されているＳＱＬ文の生成の基礎となる情報、例えば、資金異動に関するデータのステートメント文及びリストデータを災害対策ＤＢサーバ５４のデータベースに送信する。すなわち、対応するレスポンスデータが存在しないリクエストデータから生成したステートメント文及びリストデータを災害対策ＤＢサーバ５４のデータベースに送信する。

従来の技術では、平常時においては、データ処理装置（災害対策Ｗｅｂ／Ａｐサーバ）は、特段、活用されていない。他方、本実施形態によれば、データ処理装置の基礎情報記憶部６２４は、資金異動に関するデータのステートメント文及びリストデータを記憶し、この資金異動テーブルから、未だ本番ＤＢサーバから災害対策ＤＢサーバに転送されていないデータに対応するステートメント文及びリストデータを作成し、記憶し、その後、ステートメント文及びリストデータは、災害対策ＤＢを更新するために用いられるといったように有効活用されるという効果を奏する。また、本実施形態によれば、切替通知を受信したことをトリガーとして、データ処理装置の基礎情報記憶部６２４に記憶されていた資金異動に関するデータのステートメント文及びリストデータのみが災害対策ＤＢサーバに送信され、ＳＱＬ文が生成・実行されるという効果を奏する。

＜第９実施形態＞
図１４は、本発明の他の実施形態に係るデータ処理装置の構成の一例を示すブロック図である。本実施形態は、第８実施形態と概ね同じであるが、一部が異なる。そこで、重複する部分についての説明は省略し、異なる点を説明する。本実施形態に係るデータ処理装置６２ａは、第８実施形態のデータ処理装置６２の構成に加えて、抽出部６２６を含む。

基礎情報記憶部６２４は、クライアントから本番Ｗｅｂ／Ａｐサーバ（図示せず）に送信するリクエストデータ（第１電文）を記憶し、本番ＤＢサーバのデータベースでの更新処理結果をクライアントに対して返信するレスポンスデータ（第２電文）を記憶する。そして、リクエストデータまたはレスポンスデータからＳＱＬ文の生成の基礎となる情報を生成し、記憶する。具体的には、記憶部６２４は、ステートメント文及びリストデータを記憶する。

抽出部６２６は、基礎情報記憶部６２４に記憶されたステートメント文及びリストデータのうち、データベースの更新に関する情報、すなわち、資金異動に関するデータのステートメント文及びリストデータを抽出する。

そして、送信部６２５は、受信部６２１により受信された切替通知に基づき、リクエストデータとレスポンスデータとが不照合である場合に、基礎情報記憶部６２４に記憶されているＳＱＬ文の生成の基礎となる情報、例えば、資金異動に関するデータのステートメント文及びリストデータを災害対策ＤＢサーバ５４のデータベースに送信する。

本実施形態も、第８実施形態と同様に、データ処理装置の基礎情報記憶部６２４は、ステートメント文及びリストデータを記憶し、その後、ステートメント文及びリストデータは、災害対策ＤＢを更新するために用いられるといったように有効活用されるという効果を奏する。また、本実施形態によれば、切替通知を受信したことをトリガーとして、データ処理装置の基礎情報記憶部６２４に記憶されていた資金異動に関するデータのステートメント文及びリストデータのみが災害対策ＤＢサーバに送信され、ＳＱＬ文が生成・実行されるという効果を奏する。

なお、上記では、具体例として、資金異動や残高照会など金融機関を前提とした説明をした。もっとも、本発明は、金融機関におけるシステムに限定されるものではなく、他の会社や機関におけるシステムであってもよい。この場合には、本番データベースの更新が必要なトランザクションは、各会社や機関によって異なる。

また、本発明は上記の実施形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

２０：クライアント端末 ２７：ネットワーク
３０：本番システム ３０ａ：本番システムの正系システム
３０ｂ：本番システムの副系システム ３２：本番Ｗｅｂ／ＡＰサーバ
３４：本番データベースサーバ ３６：検知部
４２：サーバ間ネットワーク ４３：ネットワーク
４４：データベースサーバ間ネットワーク
５０：災害対策システム ５０ａ：災害対策システムの正系システム
５０ｂ：災害対策システムの副系システム
５２：災害対策Ｗｅｂ／ＡＰサーバ
５４：災害対策データベースサーバ ６０：中継装置
７０：バックシステム ７２：バックシステムのＷｅｂ／ＡＰサーバ
７４：バックシステムのデータベースサーバ
８０：フロントシステム ８２：フロントシステムのＷｅｂ／ＡＰサーバ
８４：フロントシステムのデータベースサーバ
１１０：リクエストテーブル １１１：時刻 １１２：ＩＰアドレス
１１３：ＰＯＳＴデータ １１３：リクエストの内容
１１４：ユーザ名 １１５：ユーザＩＤ
１２１、１２２、１２３、１２４：リクエストヘッダテーブル
１３０：レスポンスヘッダテーブル １３１：時刻 １３２：ＩＰアドレス
１３３：Ｓｔａｔｕｓ １３４：ユーザ名 １３５：ユーザＩＤ
１４１、１４２、１４３、１４４：レスポンスヘッダテーブル
３２１：第１受信部 ３２２：第２受信部 ３２４：第１電文記憶部
３２５：電文生成部 ３２６：検知部
送信部：３２８ ３２９：第２電文生成部
５２１：第１受信部 ５２２：第２受信部 ５２３：照合部
５２５：電文生成部 ５２６：検知部
５２７：切替部 ５３１：第１関連付部
５３３：第１判別部 ５３５：第２関連付部 ５３７：第２判別部
５４１：一時テーブル ５４３：トランザクション実行テーブル
５４５：リカバリーテーブル
５５１：コピー記憶部 ５５３：電文記憶部
５６１：コピー記憶部
６０１：中継部 ６０３：生成部 ６２１：受信部 ６２３：照合部 ６２４：基礎情報記憶部 ６２５：送信部
６２６：抽出部 ７２０：クライアント端末 ７２７：ネットワーク
７３０：本番システム ７３２：本番Ｗｅｂ／ＡＰサーバ
７３４：本番データベースサーバ
７４２：サーバ間ネットワーク ７４４：データベース間ネットワーク
７５０：災害対策システム ７５２：災害対策Ｗｅｂ／ＡＰサーバ
７５４：災害対策データベースサーバ
８２０：クライアント端末 ８２７：ネットワーク
８２３：クライアントトランザクションログ ８３２：サーバ
８３４：サーバトランザクションログ ８３６：バックアップデータ
８３８：ＤＢＭＳ

Claims (27)

1. クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文のコピーを受信する第１受信部と、
   前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更が成功した場合に前記電文を記憶する電文記憶部と、
   を有するデータ処理装置。
2. 前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更の操作を実行した結果を前記クライアントへ返信する第２電文のコピーを受信する第２受信部と、
   前記第１電文のコピーまたは前記第２電文のコピーから、前記電文を生成する電文生成部をさらに有することを特徴とする請求項１に記載のデータ処理装置。
3. クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文のコピーを受信する第１受信部と、
   前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更が成功した場合に該成功にかかる前記第１電文のコピーを記憶するコピー記憶部と
   を有するデータ処理装置。
4. 前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更の操作を実行した結果を前記クライアントへ返信する第２電文のコピーを受信する第２受信部を有し、
   前記コピー記憶部は、前記第２電文のコピーが前記データベースの変更の操作の成功を示す場合に該成功にかかる前記第１電文のコピー又は第２電文のコピーを記憶することを特徴とする請求項３に記載のデータ処理装置。
5. 前記記憶部に記憶された第１電文のコピー又は第２電文のコピーから、前記サーバが生成したデータベース操作文を生成するための電文を生成する電文生成部を有する、請求項３または４に記載のデータ処理装置。
6. クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文のコピーを受信する第１受信部と、
   前記第１電文のコピーを記憶するコピー記憶部と、
   前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更が成功した場合に、該成功にかかる第１電文のコピーにデータベースの変更の操作の成功を示す制御情報を付加する履歴管理部と、
   を有するデータ処理装置。
7. 前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更の操作を実行した結果を前記クライアントへ返信する第２電文のコピーを受信する第２受信部を有し、
   前記コピー記憶部は、第２電文のコピーを記憶し、
   前記履歴管理部は、前記第２電文のコピーが前記データベースの変更の操作の成功を示す場合に、前記第１電文のコピー及び前記第２電文のコピーにデータベースの変更の操作の成功を示す制御情報を付加することを特徴とする請求項６に記載のデータ処理装置。
8. 前記成功を示す制御情報を付加された第１電文のコピー又は第２電文のコピーから、前記サーバが生成したデータベース操作文を生成するための電文を生成する電文生成部と、
   前記電文を記憶する電文記憶部と、
   をさらに有する、請求項６または７に記載のデータ処理装置。
9. 前記サーバに障害が発生したことを検知する検知部を有する、請求項２、５または８に記載のデータ処理装置。
10. 前記サーバに障害が発生すると、前記サーバとして動作する切替部を有する、請求項５、８または９に記載のデータ処理装置。
11. 前記切替部は、前記サーバに障害が発生すると、前記クライアントから前記サーバへの経路情報を更新する請求項１０に記載のデータ処理装置。
12. 前記第１受信部が受信した第１電文のコピーに、前記第１電文による前記データベースのトランザクションと関連付ける第１関連付部と、
    前記第２受信部が受信した第２電文のコピーが前記データベースのどのトランザクションにおける変更の操作を実行した結果を返信するものであるかを判別する第１判別部と、
    を有し、
    前記コピー記憶部は、前記第１判別部により判別された前記第２電文のコピーのトランザクションに関連づけられる第１電文のコピー又は第２電文のコピーを記憶する、請求項４または８に記載のデータ処理装置。
13. 前記第１受信部が受信した第１電文のコピーに、送信元のクライアントの識別子を関連付ける第２関連付部と、
    前記第２受信部が受信した第２電文の送信先のクライアントの識別子を判別する第２判別部と、
    を有し、
    前記コピー記憶部は、前記第２判別部により判別された前記第２電文のコピーのトランザクションに関連づけられる第１電文のコピー又は第２電文のコピーを記憶する、請求項４または８に記載のデータ処理装置。
14. 前記第２関連付部は、前記第１電文のコピーが受信された時刻をさらに関連付け、
    前記コピー記憶部は、前記第２判別部による判別に加え、前記第２関連付部により関連づけられた時刻と前記第２電文のコピーが受信された時刻とに基づいて、前記第１電文のコピー又は前記第２電文のコピーを記憶する、請求項１３に記載のデータ処理装置。
15. クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文のコピーを受信する第１受信部と、
    前記サーバから前記クライアントに送信するセッション識別情報のコピーを受信するセッション識別情報受信部と、
    前記第１電文のコピー及び前記セッション識別情報のコピーを記憶するコピー記憶部と、
    前記コピー記憶部に記憶された前記第１電文のコピー及び前記セッション識別情報のコピーから、クライアントへ返信する第２電文を生成する第２電文生成部と、
    前記サーバに障害が発生したことを検知する検知部を有し、
    前記第２電文生成部は、前記検知部が前記サーバに障害が発生したことを検知した後に、前記第２電文を生成することを特徴とするデータ処理装置。
16. 前記第２電文及び前記セッション識別情報をクライアントに返信することを特徴とする請求項１５に記載のデータ処理装置。
17. 前記コピー記憶部に記憶された第１電文のコピーから、前記サーバが生成したデータベース操作文を生成するための電文を生成する電文生成部をさらに有し、
    前記電文生成部は、前記検知部が前記サーバに障害が発生したことを検知したときに、前記電文を生成することを特徴とする請求項１２または請求項１６に記載のデータ処理装置。
18. 前記サーバに障害が発生すると、前記サーバとして動作する切替部を有する、請求項１５乃至請求項１７のいずれか一に記載のデータ処理装置。
19. クライアントが第１データベースの更新を要求するために送信する第１電文を受信する第１受信部と、
    前記第１電文を記憶する第１電文記憶部と、
    前記クライアントへ返信する第２電文を生成する第２電文生成部と、
    前記第１データベースに障害が発生したことを検知する検知部を有し、
    前記第２電文生成部は、前記検知部が前記第１データベースに障害が発生したことを検知した後に、前記第２電文を生成することを特徴とするデータ処理装置。
20. 前記第１電文記憶部に記憶された第１電文から、データベース操作文を生成するための電文を生成する電文生成部と、
    前記データベース操作文を生成するための電文を第２データベースに送信する送信部をさらに有し、
    前記電文生成部は、前記検知部が前記サーバに障害が発生したことを検知したときに、前記電文を生成することを特徴とする請求項１９に記載のデータ処理装置。
21. 前記電文を受信した前記第２データベースの変更が成功したことを示す情報を受信する第２受信部をさらに有し、
    前記第２電文生成部は、前記第２データベースの変更が成功したことを示す情報を基に第２電文を生成することを特徴とする請求項２０に記載のデータ処理装置。
22. データベース操作文の生成の基礎となる情報を記憶する基礎情報記憶部と、
    稼動系の切替通知を受信する受信部と、
    前記受信部により受信された前記切替通知に基づき、前記基礎情報記憶部に記憶されている前記データベース操作文の生成の基礎となる情報をデータベースに対して送信する送信部と、
    を備えるデータ処理装置。
23. 前記基礎情報記憶部は、データベースの更新に関する情報のみを記憶する、請求項２２に記載のデータ処理装置。
24. 前記基礎情報記憶部よりデータベースの更新に関する情報のみを抽出して、前記送信部に伝達する抽出部をさらに備える、請求項２２に記載のデータ処理装置。
25. 前記基礎情報記憶部は、前記データベースの更新処理結果をクライアントに対して返信する第２電文と、前記データベース操作文の生成の基礎となる情報に対応するクライアントより受信する第１電文とを記憶し、
    前記第１電文と前記第２電文とが対応付けられるか否かを照合する照合部をさらに備える、請求項２３または２４に記載のデータ処理装置。
26. 前記送信部は、前記照合部において前記第１電文と前記第２電文とが不照合であった場合に、前記データベース操作文の生成の基礎となる情報をデータベースに対して送信する、請求項２５に記載のデータ処理装置。
27. クライアントがデータベースの更新を要求するためにサーバへ送信する第１電文を前記サーバへ中継する中継部と、
    前記サーバが前記第１電文から前記データベースを更新するためのデータベース操作文を生成するための電文を生成し前記データベースの変更が成功した場合に、前記中継部により中継された第１電文のコピーを生成する生成部と
    を有するデータ中継装置。
    

Images