JP2006164080A - データ処理方法及びシステム - Google Patents

Abstract

【課題】 各サイトのリソースを有効に活用する。
【解決手段】 第一サイトが、現用の第一ＤＢアクセス部を有し、第二サイトが、現用の第一ＤＢアクセス部に対応した待機用の第一ＤＢアクセス部の他に、現用の第二ＤＢアクセス部を有する。現用の第二ＤＢアクセス部は、自分に割り当てられた第二記憶デバイスにデータを書き込む。サイト間監視サーバが、現用の第一ＤＢアクセス部及び第二ＤＢアクセス部等を監視し、現用の第一ＤＢアクセス部のダウンを検出した場合には、待機用の第一ＤＢアクセス部を現用のＤＢアクセス部に切り替える。
【選択図】図１

Description

本発明は、データ処理技術に関し、例えば、第一のサイトにおいて障害が発生した場合に第二のサイトに移行するためのデータ処理技術に関する。

データ処理技術の一つに、例えば、障害回復処理がある。障害回復処理の一つとして、ディザスタリカバリの技術が知られている。例えば、ディザスタリカバリを実行することができるシステムとして、特開２００４−３０３０２５号公報に開示の技術が知られている。

ディザスタリカバリシステムでは、一般に、或る場所（例えば関東）に第一のサイト（別の言い方をすれば、例えばデータ処理サブシステム）が構築され、第一のサイトが存在する場所とは異なる遠隔地（例えば関西）に、第一のサイトと同じ構成を有した第二のサイトが構築され、両サイト間でのレプリケーションが行われる。第一のサイトが現用系で、第二のサイトが待機系の場合において、例えば第一のサイトで障害が発生したならば、第一のサイトが閉塞し、代わりに、第二のサイトが起動する。

特開２００４−３０３０２５号公報

しかし、上述したシステムでは、第一のサイトで障害が発生するまでの間、第二のサイトは、待機状態にあり、有効に活用されない。

従って、本発明の目的の一つは、各サイトのリソースを有効に活用することにある。本発明の更なる目的は、サイト間でのリカバリも実現することにある。

本発明の他の目的は、後述の説明から明らかになるであろう。

例えば、第一のサイトが、現用の第一ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に割り当てられたプライマリの第一記憶デバイスと、プライマリの第二記憶デバイスとの間でペアを構成するセカンダリの第二記憶デバイスとを備える。第二のサイトが、現用の第二ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に対応した待機用の第一ＤＢアクセス部と、前記現用の第二ＤＢアクセス部に割り当てられた前記プライマリの第二記憶デバイスと、前記プライマリの第一記憶デバイスとの間でペアを構成し、前記待機用のＤＢアクセス部に割り当てられたセカンダリの第一記憶デバイスとを備える。また、サイト間監視サーバが備えられる。サイト間監視サーバは、前記現用の第一ＤＢアクセス部、前記現用の第一ＤＢアクセス部を備える第一サーバ、及び前記第一サイトのうちの少なくとも一つである第一監視対象と、前記現用の第二ＤＢアクセス部、前記現用の第二ＤＢアクセス部を備える第二サーバ、及び前記第二サイトのうちの少なくとも一つである第二監視対象とを監視することができる。

この場合、本発明の第一の観点に従うデータ処理方法は、
前記現用の第一ＤＢアクセス部が、前記プライマリの第一記憶デバイスにデータを書き込むステップと、
前記プライマリの第一記憶デバイスに書かれたデータを、前記セカンダリの第一記憶デバイスにコピーするステップと、
前記現用の第二ＤＢアクセス部が、前記プライマリの第二記憶デバイスにデータを書き込むステップと、
前記プライマリの第二記憶デバイスに書かれたデータを、前記セカンダリの第二記憶デバイスにコピーするステップと、
前記サイト間監視サーバが、前記現用の第一ＤＢアクセス部がダウンしたことを検出するステップと、
前記サイト間監視サーバが、前記現用の第一ＤＢアクセス部のダウンの検出後、前記待機用の第一ＤＢアクセス部を現用の第一ＤＢアクセス部に切り替えるステップとを有する。この場合、前記切り替わり後の現用の第一ＤＢアクセス部は、例えば、ユーザ端末等からアクセス要求を受けた場合には、その第一ＤＢアクセス部に割り当てられている前記セカンダリの第一記憶デバイスにアクセスすることができる。

また、待機用の第一ＤＢアクセス部は、スタンバイ状態と、スタンバイ状態ではなくディスクから読み出されていない状態とのいずれの状態であってもよい。前者の場合、例えば、ダウン前の現用の第一ＤＢアクセス部のリソース情報（例えばＩＰアドレス等）が待機用の第一ＤＢアクセス部に引き継ぐことにより、待機用の第一ＤＢアクセス部を、現用の第一ＤＢアクセス部に切り替えることができる。一方、後者の場合、例えば、サイト間監視サーバが、待機用の第一ＤＢアクセス部に対する起動命令を出力して、待機用の第一ＤＢアクセス部を起動させ、その後に、上記のようなリソース情報をその待機用の第一ＤＢアクセス部に引き継ぐことにより、待機用の第一ＤＢアクセス部を、現用の第一ＤＢアクセス部に切り替えることができる。

ところで、具体的な一つの実施態様としては、以下の態様が考えられる。

例えば、第一のサイトに、少なくとも一つの第一サーバと、前記第一サーバに接続される第一のストレージサブシステムとがある。第二のサイトに、少なくとも一つの第二サーバと、前記第二サーバに接続される第二のストレージサブシステムとがある。前記第一サーバが、少なくとも、現用の第一ＤＢアクセス部を有する。前記第二サーバが、現用の第二ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に対応した待機用の第一ＤＢアクセス部を有する。前記第一ストレージサブシステムは、前記現用の第一ＤＢアクセス部に割り当てられたプライマリの第一記憶デバイスと、プライマリの第二記憶デバイスとの間でペアを構成するセカンダリの第二記憶デバイスとを有する。前記第二ストレージサブシステムは、前記第一ストレージサブシステムに接続されており、前記現用の第二ＤＢアクセス部に割り当てられた前記プライマリの第二記憶デバイスと、前記プライマリの第一記憶デバイスとの間でペアを構成するセカンダリの第一記憶デバイスとを有する。

この場合、本実施態様に係るデータ処理方法は、
前記現用の第一ＤＢアクセス部が、トランザクション処理の結果に基づく第一の処理結果データを、前記プライマリの第一記憶デバイスに書き込むステップと、
前記プライマリの第一記憶デバイスに書かれた前記第一の処理結果データを、前記プライマリの第一記憶デバイスから前記第二ストレージサブシステムの前記セカンダリの第一記憶デバイスにコピーするステップと、
前記現用の第二ＤＢアクセス部が、トランザクション処理の結果に基づく第二の処理結果データを前記プライマリの第二記憶デバイスに書き込むステップと、
前記プライマリの第二記憶デバイスに書かれた前記第二の処理結果データを、前記プライマリの第二記憶デバイスから前記第一ストレージサブシステムの前記セカンダリの第二記憶デバイスにコピーするステップと、
前記現用の第一ＤＢアクセス部がダウンしたことを検出するステップと、
前記ダウンの検出後、前記現用の第一ＤＢアクセス部に対応した前記待機用の第一ＤＢアクセス部に起動命令を出力するステップと、
前記起動命令に応答して前記待機用の第一ＤＢアクセス部が起動するステップと、
前記起動した待機用の第一ＤＢアクセス部を現用の第一ＤＢアクセス部に切り替えるステップと、
切り替わり後の現用の第一ＤＢアクセス部が、トランザクション処理の結果に基づく処理結果データを、前記セカンダリの第一記憶デバイスに書き込むステップと
を有することができる。

このデータ処理方法の第一の実施態様では、前記第一サイトが、前記現用の第一ＤＢアクセス部に対応した別の待機用の第一ＤＢアクセス部を有することができる。この場合、データ処理方法は、前記サイト間監視サーバが、前記用の第一ＤＢアクセス部のダウンの検出後、前記別の待機用の第一ＤＢアクセス部を現用の第一ＤＢアクセス部に切り替えるステップを有することができる。

このデータ処理方法の第二の実施態様では、データ処理方法が、
前記サイト間監視サーバが、各ＤＢアクセス部と別の各ＤＢアクセス部との対応関係を表す情報であるＤＢアクセス部関係情報を所定の記憶域に備えるステップと、
前記サイト間監視サーバが、前記所定の記憶域に記憶されているＤＢアクセス部関係情報を参照することにより、ダウンした現用のＤＢアクセス部に対応した待機用のＤＢアクセス部を特定するステップと
を有することができる。この場合、前記切り替えるステップでは、前記特定された待機用のＤＢアクセス部を現用のＤＢアクセス部に切り替えることができる。

このデータ処理方法の第三の実施態様では、データ処理方法が、
前記サイト間監視サーバが、前記第一監視対象と前記第二監視対象とが正常か否かを表す監視結果情報を所定の記憶域に登録するステップと、
前記サイト間監視サーバが、前記第一監視対象と前記第二監視対象との監視結果に応じて前記監視結果情報を更新するステップと、
前記サイト間監視サーバが、前記第一監視対象にアクセス要求を発行するクライアント端末から、前記第一監視対象にアクセス可能か否かの問合せを受けるステップと、
前記サイト間監視サーバが、前記所定の記憶域に登録されている監視結果情報を参照することにより、前記第一監視対象に前記クライアント端末がアクセス可能か否かを判断するステップと、
前記サイト間監視サーバが、前記判断の結果を前記クライアント端末に送信するステップと、
前記クライアント端末が、前記判断の結果がアクセス可能という判断結果であれば、前記第一監視対象にアクセス要求を出すステップと、
を有することができる。

この実施態様では、更に、例えば、データ処理方法が、
前記第一サイトの複数の現用の第一アクセス部の各々の状態を監視するステップと、
前記第一サイトが前記クライアント端末からアクセス要求を受けるステップと、
前記アクセス要求に応答して、前記監視の結果から正常である現用の第一ＤＢアクセス部を特定するステップと、
前記特定された現用の第一ＤＢアクセス部に前記クライアント端末がアクセスされることを許可するステップと
を有することができる。

このデータ処理方法の第四の実施態様では、前記第一サイトが、複数の現用の第一アクセス部と、複数のプライマリの第一記憶デバイスとを有することができる。前記第二サイトが、複数の待機用の第一ＤＢアクセス部と、前記複数のプライマリの第一記憶デバイスにそれぞれ対応した複数のセカンダリの第一記憶デバイスとを有することができる。現用の第一ＤＢアクセス部と、待機用のＤＢアクセス部とが、１対１で対応付けられてもよい。また、現用の第一ＤＢアクセス部と、プライマリの第一記憶デバイスとも、１対１で対応付けられてもよい。なお、これらの対応関係のうちの少なくとも一つは、例えば、前述したＤＢアクセス部関係情報に記録されていても良い。

このデータ処理方法の第五の実施態様では、前記第二サイトが、前記セカンダリの第一記憶デバイスとの間でペアを構成する更なるセカンダリの第一記憶デバイスを有することができる。前記第一サイトが、前記セカンダリの第二記憶デバイスとの間でペアを構成する更なるセカンダリの第二記憶デバイスとを有することができる。この場合、データ処理方法が、
前記第二サイトにおいて、前記セカンダリの第一記憶デバイスに格納された第一のデータを前記更なるセカンダリの第一記憶デバイスにコピーするステップと、
前記第一サイトにおいて、前記セカンダリの第二記憶デバイスに格納された第二のデータを前記更なるセカンダリの第二記憶デバイスにコピーするステップと、
前記第二サイトにおいて、前記セカンダリの第一記憶デバイスと前記更なるセカンダリの第一記憶デバイスとのペアを解除するステップと、
前記第一サイトにおいて、前記セカンダリの第一記憶デバイスと前記更なるセカンダリの第一記憶デバイスとのペアを解除するステップと、
前記現用の第一ＤＢアクセス部が、前記プライマリの第一記憶デバイスと、前記更なるセカンダリの第二記憶デバイスとの両方に、新たな第一のデータを書き込むステップと、
前記現用の第二ＤＢアクセス部が、前記プライマリの第二記憶デバイスと、前記更なるセカンダリの第一記憶デバイスとの両方に、新たな第二のデータを書き込むステップと、
前記第一監視対象において障害が発生した後、その障害が回復した場合、前記第二サイトにおいて、前記セカンダリの第一記憶デバイスと前記更なるセカンダリの第一記憶デバイスとのペアを形成するステップと、
前記第一サイトにおいて、前記セカンダリの第一記憶デバイスと前記更なるセカンダリの第一記憶デバイスとのペアを形成するステップと、
前記第二サイトにおいて、前記更なるセカンダリの第一記憶デバイスに格納された前記新たな第二のデータを前記セカンダリの第一記憶デバイスにコピーするステップと、
前記セカンダリの第一記憶デバイスに書かれた前記新たな第二のデータを前記第一サイトの前記プライマリの第一記憶デバイスに格納するステップと、
前記プライマリの第二記憶デバイスに格納された前記新たな第二のデータを前記セカンダリの第二記憶デバイスにコピーするステップと、
前記第一サイトにおいて、前記セカンダリの第二記憶デバイスにコピーされた前記新たな第二のデータを前記更なるセカンダリの第二記憶デバイスにコピーするステップと
を有することができる。

このデータ処理方法の第六実施態様では、前記第一サイトが、前記現用の第二ＤＢアクセス部に対応した待機用の第二ＤＢアクセス部を更に備えてもよい。この場合、データ処理方法は、
前記サイト間監視サーバが、前記現用の第二ＤＢアクセス部がダウンしたことを検出するステップと、
前記サイト間監視サーバが、前記現用の第二ＤＢアクセス部のダウンの検出後、前記待機用の第二ＤＢアクセス部を現用の第二ＤＢアクセス部に切り替えるステップと
を有することができる。

ところで、例えば、第一のサイトに、現用の第一ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に割り当てられたプライマリの第一記憶デバイスと、現用の第二ＤＢアクセス部に対応した待機用の第二ＤＢアクセス部と、プライマリの第二記憶デバイスとの間でペアを構成するセカンダリの第二記憶デバイスとが備えられる。第二のサイトに、現用の第二ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に対応した待機用の第一ＤＢアクセス部と、前記現用の第二ＤＢアクセス部に割り当てられた前記プライマリの第二記憶デバイスと、前記プライマリの第一記憶デバイスとの間でペアを構成し、前記待機用のＤＢアクセス部に割り当てられたセカンダリの第一記憶デバイスとが備えられる。前記現用の第一ＤＢアクセス部が、前記プライマリの第一記憶デバイスにデータを書き込み、前記プライマリの第一記憶デバイスに書かれたデータが、前記セカンダリの第一記憶デバイスにコピーされる。前記現用の第二ＤＢアクセス部が、前記プライマリの第二記憶デバイスにデータを書き込み、前記プライマリの第二記憶デバイスに書かれたデータが、前記セカンダリの第二記憶デバイスにコピーされる。この場合、本発明の第二の側面に従うサーバは、少なくとも一つのコンピュータプログラムを記憶する記憶域と、前記記憶域から前記少なくとも一つのコンピュータプログラムを読み込んで動作するプロセッサとを有する。コンピュータプログラムを読み込んだプロセッサは、
前記現用の第一ＤＢアクセス部、前記現用の第一ＤＢアクセス部を備える第一サーバ、及び前記第一サイトのうちの少なくとも一つである第一監視対象と、前記現用の第二ＤＢアクセス部、前記現用の第二ＤＢアクセス部を備える第二サーバ、及び前記第二サイトのうちの少なくとも一つである第二監視対象とを監視し、
前記監視により、前記現用の第一ＤＢアクセス部がダウンしたことを検出した場合、前記待機用の第一ＤＢアクセス部を現用の第一ＤＢアクセス部に切り替え、
前記監視により、前記現用の第二ＤＢアクセス部がダウンしたことを検出した場合、前記待機用の第二ＤＢアクセス部を現用の第二ＤＢアクセス部に切り替える
ことを行うことができる。

本発明によれば、各サイトのリソースを有効に活用することができる。

以下、図面を参照して、本発明の一実施形態について説明する。なお、以下の説明では、データベースを「ＤＢ」と略記する場合がある。また、以下の説明において、「ソフトウェア」という言葉は、プロセッサに読み込まれて動作するコンピュータプログラムを意味するものとする。

図１は、本発明の一実施形態に係るデータ処理システムの構成例を示す。

この実施形態に係るデータ処理システム３では、例えば、幾つかの特徴点があり、その概要は、以下の通りである。

第一の特徴点は、第一サイト１Ａ及び第二サイト１Ｂがそれぞれアクティブになったものが１システムで実現される点である。そのため、第一サイト１Ａが稼動しているが第二サイトが全く稼動していないといった、リソースの無駄を節約することができる。

第二の特徴点は、システム障害（例えばマシン障害或いはディスク障害）による影響を局所化するために、店群毎に収容先を振り分けることができる点である。具体的には、例えば、第一サイト１Ａに、第一の処理に関わるデータ（例えば支店Ａ乃至支店Ｍを有する関東地区に関する業務データ）が集約され、第二サイト１Ｂに、第二の処理に関わるデータ（例えば、支店Ｎ乃至支店Ｘを有する関西地区に関する業務データ）が集約されることが可能である。すなわち、点群の業務を提供する構成が実現することができる。より具体的には、各サイト１Ａ、１Ｂに存在する各ストレージ（例えばＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成を有するストレージサブシステム）に、各点群のデータを格納することができる。

第三の特徴点は、第一サイト１Ａと第二サイト１Ｂとの間で、データの相互バックアップを実現することができる点である。これは、例えば、後述するように、ストレージサブシステム４３Ａ、４３Ｂ間のリモートコピー機能と、各サイト１Ａ、１Ｂのサーバに搭載されたＤＢアクセス部によるサイト間の相互バックアップにより、実現することができる。

第四の特徴点は、例えば、第一サイトで障害が発生した等の場合には、第一サイト１Ａから第二サイト１Ｂへのサイト切り替え時には、１つのサイト１Ｂのリソースで、複数のサイト分の処理を実行することになる点である。

第五の特徴点は、各サイト１Ａ、１Ｂの状態は、別途設置されたサイト間監視サーバ４９によって行われる点である。この場合、第一サイト１Ａを利用することができる第一ユーザ端末１１Ａや、第二サイト１Ｂを利用することができる第二ユーザ端末１１Ｂは、当該サーバ４９に、利用したいサイトの状態を問い合わせた後に、そのサイトに接続することができる。

以下、実施形態に係るデータ処理システム３について詳細に説明する。

この実施形態に係るデータ処理システム３には、複数のサイトとして、例えば、第一のサイト１Ａと、第二のサイト１Ｂとが備えられる。また、各サイト１Ａ、１Ｂに障害が発生したか否か等を監視するサイト間監視サーバ４９も備えられる。第一のサイト１Ａと第二のサイト１Ｂは、ＳＡＮ（Storage Area Network）４７等の通信ネットワーク（又は専用線）を介して互いに接続されている。また、第一のサイト１Ａと第二のサイト１Ｂは、通信ネットワーク或いは専用線を介して、サイト間監視サーバ４９にも接続されている。

第一のサイト１Ａと第二のサイト１Ｂは、実質的に同じ構成にすることができる。図１では、第一のサイト１Ａに関わる構成要素の参照符号は、親番号と枝符号Ａとから構成され、第二のサイト１Ｂに関わる構成要素の参照符号は、親番号と枝符号Ｂとから構成される。第一のデータ処理システム１Ａと第二のデータ処理システム１Ｂとにおいて、同一の構成要素については、原則として、同一の親番号を付してある（後述のＤＢアクセス部については、説明の便宜上、そのようにはしていない）。以下、説明の重複を省くため、第一のサイト１Ａの構成について代表的に説明する。その説明と、図１とを参照すれば、第二のサイト１Ｂについては十分に理解することができるはずである。

第一のサイト１Ａは、少なくとも一つのサーバとして、例えば、第一サーバ１５Ａ及び１７Ａを備える。また、第一のサイト１Ａは、第一サーバ１５Ａ又は１７Ａから出力されたデータを記憶する第一のストレージサブシステム４３Ａを備える。

第一ストレージサブシステム４３Ａは、図示しない物理的な記憶デバイス上に用意される複数の論理ボリューム５１Ａ、５３Ａ、５５Ａ及び５７Ａと、それらの複数の論理ボリュームへのアクセスを制御する第一ストレージ制御装置４５Ａとを備える。第一ストレージ制御装置４５Ａは、上記の図示しない物理的な記憶デバイスと、第一サーバ１５Ａ及び１７Ａとに接続される。

第一サーバ１５Ａは、例えば、原則として現用のサーバであり、別の第一サーバ１７Ａは、例えば、原則として待機用のサーバである。ここで、「現用のサーバ」とは、例えば、主に現用のＤＢアクセス部（ＤＢアクセス部については後に詳述する）を備えるサーバであり、「待機用のサーバ」とは、例えば、主に待機用のＤＢアクセス部を備えるサーバである。現用のサーバのＤＢアクセス部がダウンした場合、そのＤＢアクセス部が現用から待機用に切り替わり、且つ、そのＤＢアクセス部に対応した待機用のＤＢアクセス部であって、待機用のサーバに存在するＤＢアクセス部が、待機用から現用に切り替わることがあるが、それでも、現用のサーバは、主に現用のＤＢアクセス部を備える場合には以前として現用であり、同様に、待機用のサーバは、主に待機用のＤＢアクセス部を備える場合には以前として待機用である。

第一サーバ１５Ａも１７Ａも、第一の通信ネットワーク（以下、第一ネットワーク）１３Ａを介して、少なくとも一つのユーザ端末１１Ａ（以下、第一ユーザ端末１１Ａ）に接続されている。また、第一サーバ１５Ａも１７Ａも、専用線或いは所定の通信ネットワーク等を介して、第一のストレージサブシステム４３Ａに接続されている。さらに、第一サーバ１５Ａも１７Ａも、専用線等を介して、サイト間監視サーバ４９に接続されている。また、各サーバ１５Ａ、１７Ａ、１５Ｂ及び１７Ｂは、第三の通信ネットワーク（例えばインターネット）１３Ｃに接続されている。また、第一ネットワーク１３Ａ及び第二ネットワーク１３Ｂは、第三ネットワーク１３Ｃに接続されている。このため、第一ユーザ端末１１Ａは、第一ネットワーク１３Ａ及び第三ネットワーク１３Ｃを介して、第二サイト内のＤＢアクセス部にアクセスすることができる。同様に、第二ユーザ端末１１Ｂは、第二ネットワーク１３Ｂ及び第三ネットワーク１３Ｃを介して、第一サイト内のＤＢアクセス部にアクセスすることができる。なお、第一ネットワーク１３Ａ、第二ネットワーク１３Ｂ及び第三ネットワーク１３Ｃは、別々のネットワークであっても良いし、同一のネットワークであっても良い。どのような構成であれ、同一のサイト内に存在する複数のサーバも、別々のサイトに分散して存在する複数のサーバも、それぞれ互いに通信することができるようになっている。

第一サーバ１５Ａと１７Ａは、実質的に同じ構成にすることができる。以下、第一サーバ１５Ａを代表的に例に採り説明する。第一サーバ１５Ａは、第一サーバ監視部１９Ａと、複数のＤＢアクセス部とを備える。

第一サーバ監視部１９Ａは、ハードウェア、ソフトウェア、又はそれらの組み合わせにより、構築することができる。第一サーバ監視部１９Ａは、サイト間監視サーバ４９と、待機用の第一サーバ１７Ａの第一サーバ監視部４１Ａとに接続されている。第一サーバ監視部１９は、待機用の第一サーバ１７Ａに障害が発生したか否かを監視することができる。具体的には、例えば、第一サーバ監視部１９Ａは、待機用の第一サーバ１７Ａからのハートビート信号の有無に応じて、待機用の第一サーバ１７Ａに障害が発生したか否かを検出することができる。また、例えば、第一サーバ監視部１９Ａは、待機用の第一サーバ１７Ａと、サイト間監視サーバ４９とに、それぞれ、ハートビート信号を送信することで、現用の第一サーバ１５Ａに障害が発生したか否かを、待機用の第一サーバ１７Ａとサイト間監視サーバ４９とに検出させることができる。また、第一サーバ監視部１９Ａは、自分を搭載するサーバ内に存在する各ＤＢアクセス部毎に、正常であるかどうかや障害が発生したかどうか等のＤＢアクセス部状態を検出し管理することができる。

ＤＢアクセス部は、ストレージサブシステム４３が備える論理ボリューム（以下、単に「ＶＯＬ」と記載することがある）へのアクセスを制御する構成要素である。ＤＢアクセス部は、ＣＰＵ等のプロセッサに読み込まれることにより動作するコンピュータプログラムとすることができるが、ハードウェア、或いはハードウェアとコンピュータプログラムとの組み合わせとして実現されても良い。一つのサーバ１５又は１７には、少なくとも一つのＤＢアクセス部を搭載することができる。

具体的には、この実施形態では、第一のサイト１Ａ（例えば現用の第一サーバ１５Ａ）に、その第一サイト１Ａにおいて原則として現用になるＤＢアクセス部１Ａ−１乃至１Ａ−４が備えられ（図１には○○−１のみ明記、以下同様）、それらのＤＢアクセス部１Ａ−１乃至１Ａ−４にそれぞれ対応した待機用のＤＢアクセス部３Ａ−１乃至３Ａ−４が、第二のサイト１Ｂ（例えば現用の第二サーバ１５Ｂ）に備えられる。また、同一のサイト１Ａ（例えば待機用の第一サーバ１７Ａ）に、現用のＤＢアクセス部１Ａ−１乃至１Ａ−４にそれぞれ対応した別の待機用のＤＢアクセス部２Ａ−１乃至２Ａ−４が備えられる。更に、第二のサイト１Ｂ（例えば待機用の第二サーバ１７Ｂ）に、待機用のＤＢアクセス部３Ａ−１乃至３Ａ−４（又は２Ａ−１乃至２Ａ−４）にそれぞれ対応したまた別の待機用のＤＢアクセス部４Ａ−１乃至４Ａ−４が備えられる。このような構成により、例えば、現用のＤＢアクセス部１Ａ−１に障害が発生した場合には、待機用のＤＢアクセス部３Ａ−１（又は２Ａ−１）が起動し、ＤＢアクセス部１Ａ−１の処理を引き継ぐことができる。また、例えば、起動した待機用のＤＢアクセス部３Ａ−１（又は２Ａ−１）にも障害が発生した場合には、更なる待機用のＤＢアクセス部４Ａ−１が起動し、処理を引き継ぐことができる。

第一データ処理システム１Ａに存在する各ＤＢアクセス部には、同一のデータ処理システム１Ａ（例えば第一ストレージサブシステム４３Ａ）に存在する複数の論理ボリュームのうちの少なくとも一つを割り当てることができる。例えば、現用になるＤＢアクセス部１Ａ−１に対しては、正ＤＢＶＯＬ５１Ａと、正ログＶＯＬ５３Ａとを割り当てることができる。また、待機用のＤＢアクセス部１Ｂ−１に対しては、副ＤＢＶＯＬ５５Ａと、副ログＶＯＬ５７Ａとを割り当てることができる。なお、正ＤＢＶＯＬ５１Ａと正ログＶＯＬ５３Ａとは、それぞれ、第二サイト１Ｂにおける副ＤＢＶＯＬ５１Ｂと副ログＶＯＬ５３Ｂとペアになることができる。また、副ＤＢＶＯＬ５５Ａと副ログＶＯＬ５７Ａとは、それぞれ、第二サイト１Ｂにおける正ＤＢＶＯＬ５５Ｂと正ログＶＯＬ５７Ｂとペアになることができる。正ＤＢＶＯＬ５５Ｂと正ログＶＯＬ５７Ｂとは、第二サイト１Ｂにおいて原則として現用になるＤＢアクセス部３Ｂ−１に割り当てることができる。このような構成により、例えば、ＤＢアクセス部１Ａ−１によって或るデータが正ＤＢＶＯＬ５１Ａ及び正ログＶＯＬ５３Ａに書かれた場合には、そのデータ（或いは更新前のデータとの差分）が、例えば、ＳＡＮ４７等のネットワーク（又は専用線）を介して、第二ストレージサブシステム４３Ｂの副ＤＢＶＯＬ５１Ｂ及び副ログＶＯＬ５３Ｂに書かれる。同様に、例えば、ＤＢアクセス部３Ｂ−１によって或るデータが正ＤＢＶＯＬ５５Ｂ及び正ログＶＯＬ５７Ｂに書かれた場合には、そのデータ（或いは更新前のデータとの差分）が、例えば、ＳＡＮ４７等のネットワーク（又は専用線）を介して、第一ストレージサブシステム４３Ａの副ＤＢＶＯＬ５５Ａ及び副ログＶＯＬ５７Ａに書かれる。このような処理は、第一ストレージサブシステム４３Ａに備えられる第一ストレージ制御装置４５Ａや、第二ストレージサブシステム４３Ｂに備えられる第二ストレージ制御装置４５Ｂにより、実行することができる。

以上、第一の系統のＤＢアクセス部（○○−○のうちの第二番目が「Ａ」で表記されたＤＢアクセス部）、換言すれば、第一のサイト１Ａに関わるＤＢアクセス部（また別の言い方をすれば、第一のサイトについてのＤＢアクセス部）について説明したが、それについての説明は、第二の系統のＤＢアクセス部（○○−○のうちの第二番目が「Ｂ」で表記されたＤＢアクセス部）、換言すれば、第二のサイト１Ｂに関わるＤＢアクセス部（また別の言い方をすれば、第二のサイトについてのＤＢアクセス部）にも適用することができる。また、ＤＢアクセス部の引継ぎの順序は、上記の順序に限らず、他の順序であっても良い。

サイト間監視サーバ４９は、ＣＰＵ２９や記憶域２７や通信インターフェース回路（以下、通信Ｉ／Ｆ）３１等のハードウェア資源を備えた情報処理装置である。記憶域２７は、所定の記憶資源、例えば、メモリ及びハードディスクのうちの少なくとも一方に実現される記憶領域である。記憶域２７には、例えば、ＣＰＵ２９に読み込まれることにより実行される監視ソフトウェア（以下、「監視ソフト」と略記）２５が格納されている。サイト間監視ソフト２５には、障害監視／通知部２１と、接続切替部２３とが備えられている。サイト間監視ソフト２５を読み込んだＣＰＵ２９は、例えば、各サイト毎にダウンしたか否かを監視したり、例えば第一サイト１Ａで障害が発生しダウンしたことを検出した場合には障害発生を第二サイト１Ｂの所定のノード（例えば現用の第二サーバ１５Ｂ）に通知したり、障害が発生した第一サイト１Ａ（例えばＤＢアクセス部１Ａ−１）に接続されている第一ユーザ端末１１の接続先を第二サイト１Ｂ（例えば待機用ＤＢアクセス部３Ａ−１）に切り替えたりすることができる。サイト間監視サーバ４９は、例えば、通信Ｉ／Ｆ３１を介してハートビート信号が入力されたか否かを監視することにより、監視先のサーバ１５Ａ、１７Ａ、１５Ｂ又は１７Ｂにおいて障害が発生したか否かを検出することができる。サイト間監視サーバ４９は、例えば、第一サーバ１５Ａも１７Ａもダウンしたと検出された場合に、第一サイト１Ａがダウンしたと判定することができる。

図２は、本発明の一実施形態に係るデータ処理システムに備えられるサーバ及びストレージサブシステムの構成例を示す。

この実施形態では、現用の第一サーバ１５Ａは、正ホストコンピュータになることができ、待機用の第二サーバ１７Ｂは、その第一サーバ１５Ａに対する副ホストコンピュータになることができる。また、第一ストレージサブシステム４３Ａは、正ストレージサブシステムになることができ、第二ストレージサブシステム４３Ｂは、第一ストレージサブシステム４３Ａに対する副ストレージサブシステムになることができる。第一サーバ１５Ａと第二サーバ１７Ｂ（勿論、他のサーバ１５Ｂ及び１７Ａ）は、実質的に同じ構成にすることができる。また、第一ストレージサブシステム４３Ａと第二ストレージサブシステム４３Ｂも、実質的に同じ構成にすることができる。図２では、同一の構成要素には同一の親番号を付し、枝符号を変えることで、どのサーバ或いはどのストレージサブシステムに存在する構成要素であるかを識別することができる。以下、第一サーバ１５Ａ及び第一ストレージサブシステム４３Ａを代表的に例に採り説明する。

第一サーバ１５Ａは、ＣＰＵ７９Ａや記憶域６９ＡやＩ／Ｆ等のハードウェア資源を備えた情報処理装置である。記憶域６９Ａは、所定の記憶資源、例えば、メモリ及びハードディスクのうちの少なくとも一方に実現される記憶領域である。記憶域６９Ａには、例えば、ＤＢアクセス部１Ａ−１乃至１Ａ−４と、待機用のＤＢアクセス部１Ｂ−１乃至１Ｂ−４（図示せず）と、ＤＢ−ＶＯＬマッピングテーブル６７Ａとを格納することができる。また、記憶域６９Ａには、ＤＢバッファ６３Ａと、ログバッファ６５Ａとを設けることができる。

ＤＢアクセス部１Ａ−１は（他のＤＢアクセス部についても同様）、ＤＢアクセス制御部７１Ａと、チェックポイント処理部７３Ａと、ログ管理部７５Ａと、ＤＢ遅延書き込み処理部７７Ａとを有している。

ＤＢアクセス制御部７１Ａは、第一ユーザ端末１１Ａからのクエリーを受けて処理を実行する。ＤＢアクセス制御部７１Ａは、ＤＢ−ＶＯＬマッピングテーブル６７Ａを参照することで、そのクエリーに応じたアクセス先が、どのストレージサブシステムに存在する論理ボリュームであるかを特定することができる。ＤＢアクセス制御部７１Ａは、受信したクエリーに応じたアクセス先が、第一ストレージサブシステム４３Ａ内のＶＯＬであると特定された場合には、ＤＢバッファ６３Ａ及び／又はログバッファ６５Ａを介して、正ＤＢＶＯＬ５１Ａ及び／又は正ログＶＯＬ５３Ａへのアクセスを行う。一方、ＤＢアクセス制御部７１Ａは、受信したクエリーに応じたアクセス先が第二ストレージサブシステム４３Ｂ内の論理ボリュームであると特定された場合には、第二ストレージサブシステム４３Ｂに接続されている現用の第二サーバ１５Ｂに、そのクエリーを転送する。

チェックポイント処理部７３Ａは、ＤＢバッファ６３Ａの内容を第一ストレージサブシステム４３Ａ内の論理ボリュームへ反映させる必要が生じた場合（例えば、ＤＢバッファ６３Ａ上のレコードが更新されたことを示すログレコードが所定件数に達した場合）に、特定のステータス情報（ＤＢバッファ６３Ａで更新された全ＤＢブロックと、その更新時点における最新のログレコードのログ用ＶＯＬでの位置とを示すステータス情報）の書き込み要求を、第一ストレージサブシステム４３Ａに送信する。なお、チェックポイント時にトランザクションが完結していないものもあるため、このステータス情報は、最新のログレコードの位置以外にも、未完了のトランザクションに関連する古いログレコード（例えば最も古いログレコード）の位置を示す場合もあってもよい。また、ステータス情報がＶＯＬ上で更新されるのが遅延している場合もあってもよい。いずれの場合にも、このステータス情報は、ＤＢアクセス部がリスタートする際に参照を開始するログの位置を示す情報として利用されても良い。

ログ管理部７５Ａは、ログバッファ６５Ａの空き容量が所定容量以下になったか否か等を管理することができる。ログ管理部７５Ａは、ＤＢバッファ６３Ａに対して行われたデータベース処理の内容を示すログ情報（ログブロック２６２ａ）をログバッファ６５Ａに書く。また、ログ管理部７５Ａは、そのログバッファ６５Ａに書かれたログブロック２６２ａの書き込み要求を第一ストレージサブシステム４３Ａへ送信する。ログ管理部７５Ａは、その書込み要求を、所定の条件に達したことを検出した場合に、発行することができる。所定の条件とは、例えば、トランザクションのコミット時になった、ログ情報の記録が開始されてから所定の時間が経過した、又は、ログバッファ６５Ａの空き容量が所定容量以下になった等である。

ＤＢ遅延書き込み処理部７７Ａは、ＤＢバッファ６３Ａ上のＤＢデータ（ＤＢブロック２４２ａ）の書き込み要求を第一ストレージサブシステム４３Ａに送信する。ＤＢ遅延書込み処理部７７Ａは、その処理を、所定の条件に達したことが検出された場合に、実行することができる。ここで、所定の条件とは、例えば、データベース処理が開始されてから所定の時間が経過した、又は、ＤＢバッファ６３Ａの空き容量が所定容量以下になった等である。

以上のＤＢアクセス制御部７１Ａ、チェックポイント処理部７３Ａ、ログ管理部７５Ａ及びＤＢ遅延書き込み処理部７７Ａとして第一サーバ１５Ａを機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体或いは通信ネットワークを介して磁気ディスク等にダウンロードされた後、メモリにロードされて実行することができる。このようなコンピュータプログラムの実行方式は、第一サーバ１５Ａのみならず、他のサーバやストレージサブシステム等についても適用することができる。

第一ストレージサブシステム４３Ａは、既に説明してあるように、第一ストレージ制御装置４５Ａと、論理ボリューム５１Ａ、９６Ａ及び５３Ａを構築することができる少なくとも一つの物理的な記憶デバイス（例えばハードディスクドライブ）９２Ａとを備える。第一ストレージ制御装置４５Ａは、第一サーバ１５Ａや１７Ａに接続するためのＩ／Ｆや、ＳＡＮ４７に接続するためのＩ／Ｆや、キャッシュメモリ９５Ａや、キャッシュメモリ９５Ａと同一又は別のメモリ上に備えられる記憶域９１Ａや、ＣＰＵ９３Ａや、物理記憶デバイス９２Ａに接続されるディスクアクセス制御部９７Ａを備える。記憶域９１Ａには、例えば、ＣＰＵ９３Ａに読み込まれることにより動作することができるディスク制御処理部８５Ａや、リモートコピー管理テーブル８７Ａを記憶させることができる。

ディスク制御処理部８５Ａは、第一ストレージサブシステム４３Ａ全体の動作を制御することができる。ディスク制御処理部８５Ａは、例えば、コマンド処理部８１Ａと、リモートコピー処理部８３Ａとを備えている。

コマンド処理部８１Ａは、ＤＢブロック２４２ａ、上記ステータス情報又はログブロック２６２ａの書き込み要求を第一サーバ１５Ａから受信し、その受信した書き込み要求の内容に従って、正ＤＢＶＯＬ５１Ａ、正ステータス用ＶＯＬ９６Ａ、正ログ用ディスクＶＯＬ５３Ａ、又はそれらに格納されるデータブロックを格納したキャッシュメモリ９５Ａの更新を行う。

リモートコピー処理部８３Ａは、リモートコピー管理テーブル８７Ａを参照し、そのテーブル８７Ａに書かれている情報に基づいて、正ＶＯＬ５１Ａ、９６Ａ又は５３Ａの更新と同期又は非同期で、そのＶＯＬに対応した副ＶＯＬ５１Ｂ、９６Ｂ又は５３Ｂに、リモートコピーを行う。なお、この場合、第二ストレージサブシステム４３Ｂに搭載されているリモートコピー処理部８３Ｂは、ＤＢブロック２４２ａ、上記ステータス情報又はログブロック２６２ａの書き込み要求を第一ストレージサブシステム４３Ａから受信し、その受信した書き込み要求の内容に従って、第二ストレージサブシステム４３Ｂ内の副ＤＢＶＯＬ５１Ｂ、副ステータス用ＶＯＬ９６Ｂ、副ログＶＯＬ５３Ｂ、又はそれらのデータブロックを格納するキャッシュメモリ９５Ｂの更新を行うことができる。

この実施形態において、第一ストレージサブシステム４３Ａは、ログブロック２６２ａの書き込み要求については、そのログブロック２６２ａの書き込みと同期して第二ストレージサブシステム４３Ｂへのリモートコピー処理（以下、「同期リモートコピー処理」と称する場合あり）を行い、ＤＢブロック２４２ａやステータス情報の書き込みについては、第一ストレージサブシステム４３Ａでの書き込みとは非同期で第二ストレージサブシステム４３Ｂへのリモートコピー処理（以下、「非同期リモートコピー処理」と称する場合あり）を行う。以下、それについて、説明する。

図３は、同期リモートコピー処理の流れの一例を示す。

例えば、ＤＢアクセス制御部７１Ａが、或るトランザクション処理により正ＤＢＶＯＬ５１Ａへのアクセスが要求された場合、正ＤＢＶＯＬ５１Ａに対するＲＥＡＤコマンドを第一ストレージサブシステム４３Ａに発行することにより、正ＤＢＶＯＬ５１ＡからＤＢブロック２４２ａを取得してＤＢバッファ６３Ａへ格納する。そして、ＤＢアクセス制御部７１Ａは、ＤＢバッファ６３Ａ上のＤＢブロック２４２ａに対してデータベース処理を行った後、その処理内容を示すログブロック２６２ａを生成し、そのログブロック２６２ａをログバッファ６５Ａに格納する。

ログ管理部７５Ａは、所定の条件（例えば、トランザクションのコミット時になった、ログ情報の記録が開始されてから所定の時間が経過した、又は、ログバッファ６５Ａの空き容量が所定量よりも少なくなった等）に達した場合に、ログバッファ６５Ａに格納されているログブロック２６２ａの正ログＶＯＬ５３Ａへの書き込み要求として、ログブロック２６２ａの書き込みを行う為の書込み要求を生成し、生成した書込み要求とログブロック２６２ａとを第一ストレージサブシステム４３Ａに送信する（ステップＳ１）。

第一ストレージサブシステム４３Ａは、その書込み要求に応答して、第一サーバ１５Ａから受信したログブロック２６２ａをキャッシュメモリ９５Ａに書き込み、且つ、キャッシュメモリ９５Ａ上のログブロック２６２ａと、そのブロック２６２ａのリモートコピー要求とを第二ストレージサブシステム４３Ｂに送信する（Ｓ２）。リモートコピー要求の発行は、リモートコピー処理部８３Ａにより行うことができる。また、キャッシュメモリ９５Ａに書かれたログブロック２６２ａは、ディスク制御処理部８５Ａにより、正ログＶＯＬ５３Ａに書き込まれる。

第二ストレージサブシステム４３Ｂは、第一ストレージサブシステム４３Ａからのリモートコピー要求に応答して、第一ストレージサブシステム４３Ａからのログブロック２６２ａをキャッシュメモリ９５Ｂに書き込み（Ｓ３）、書き込みが完了したことを示すリモートコピー完了通知を生成し、生成したリモートコピー完了通知を第一ストレージサブシステム４３Ｂに送信する（Ｓ４）。リモートコピー完了通知の生成及び発行は、リモートコピー処理部８３Ｂにより行うことができる。また、キャッシュメモリ９５Ｂに書かれたログブロック２６２ａは、ディスク制御処理部８５Ｂにより、副ログＶＯＬ５３Ｂに書き込まれる。

第一ストレージサブシステム４３Ａは、第二ストレージサブシステム４３Ｂからリモートコピー完了通知を受信した場合に、ログブロック２６２ａの書き込みが完了したことを示すログ書込み完了通知を生成し、その完了通知を第一サーバ１５Ａに送信する（Ｓ５）。

図４は、非同期リモートコピー処理の流れの一例を示す。以下の説明では、書込み対象としてＤＢブロックを例に採り説明するが、ステータス情報にも非同期リモートコピー処理を適用することができる。

例えば、第一サーバ１５ＡにおけるＤＢ遅延書き込み処理部７７Ａが、所定の条件に達した場合に（例えば、ＤＢバッファ６３Ａの空き容量が所定容量以下になった場合に）、ＤＢバッファ６３Ａ上のＤＢブロック２４２ａとそれの書き込み要求とを第一ストレージサブシステム４３Ａに送信する（Ｓ１１）。

第一ストレージサブシステム４３Ａは、ＤＢブロック２４２ａの書込み要求を受信した場合、第一サーバ１５ＡからのＤＢブロック２４２ａをキャッシュメモリ９５Ａに書き込み（Ｓ１２）、そのＤＢブロック２４２ａの書き込みが完了したことを示す書込み完了通知を生成して、その通知を第一サーバ１５Ａに送信する（Ｓ１３）。キャッシュメモリ９５Ａに書かれたＤＢブロック２４２ａは、ディスク制御処理部８５Ａにより、正ＤＢＶＯＬ５１Ａに書き込まれる。

その後、第一ストレージサブシステム４３Ａは、キャッシュメモリ９５Ａ又は正ＤＢＶＯＬ５１Ａに蓄積されたＤＢブロック２４２ａと、それのリモートコピー要求とを第二ストレージサブシステム４３Ｂに送信する（Ｓ１４）。

第二ストレージサブシステム４３Ｂは、第一ストレージサブシステム４３Ａからのリモートコピー要求に応答して、第一ストレージサブシステム４３ＡからのＤＢブロック２４２ａをキャッシュメモリ９５Ｂに書き込み（Ｓ１５）、書き込みが完了したことを示すリモートコピー完了通知を生成し、生成したリモートコピー完了通知を第一ストレージサブシステム４３Ｂに送信する（Ｓ１６）。キャッシュメモリ９５Ｂに書かれたＤＢブロック２４２ａは、ディスク制御処理部８５Ｂにより、副ＤＢＶＯＬ５１Ｂに書き込まれる。

図５Ａは、ＤＢ−ＶＯＬマッピングテーブルの構成例を示す。

ＤＢ−ＶＯＬマッピングテーブル６７Ａには、各データベース領域毎に、種々の情報要素として、例えば、データベース領域ＩＤ、ファイルＩＤ、種別、サブサーバ名、正ストレージサブシステムＩＤ、正ＶＯＬＩＤ、副ストレージサブシステムＩＤ及び副ＶＯＬＩＤが対応付けられている。

データベース領域とは、或る一又は複数の論理ボリューム上の全部又は一部の記憶領域である。データベース領域の種類としては、例えば、ＤＢブロックが格納されるＤＢブロック領域と、ログブロックが格納されるログブロック領域とがある。ＤＢブロック領域については、例えば、データベース領域を識別するためのデータベース領域ＩＤとして、「ＤＢＡＲＥＡ」と表記され、種別は「ＤＢ」と表記される。ログブロック領域については、例えば、データベース領域ＩＤは「ＬＯＧ」と表記され、種別は「ログ」と表記される。

ファイルＩＤは、データベース領域ＩＤから識別されるデータベース領域に存在する一又は複数のファイルのうちの特定のファイルを識別するためのＩＤである。

サブサーバＩＤは、対応付けられたデータベース領域にアクセスするＤＢアクセス部のＩＤ（例えば名称）である。

正ストレージサブシステムＩＤは、対応付けられたデータベース領域を有するストレージサブシステムのＩＤである。

正ＶＯＬＩＤは、対応付けられたデータベース領域を有する正ＶＯＬのＩＤ（例えば論理ユニット番号（ＬＵＮ））である。

副ストレージサブシステムＩＤは、正ストレージサブシステムとペアを構成することができるストレージサブシステムのＩＤである。

副ＶＯＬＩＤは、対応付けられたデータベース領域を有する正ＶＯＬとペアを構成することができる副ＶＯＬのＩＤである。

このＤＢ−ＶＯＬマッピングテーブル６７Ａに記録されている情報に従って、データベース処理、換言すれば、論理ボリュームへの書込み処理が実行される（その処理の一例については後に詳述する）。なお、ＤＢ−ＶＯＬマッピングテーブル６７Ｂも、上記のマッピングテーブル６７Ａと同じ構成にすることができる。ＤＢ−ＶＯＬマッピングテーブルは、例えば、図示の通り、各サーバに備えられるが、他のコンピュータ（例えばストレージサブシステム）に備えられても良い。

図５Ｂは、リモートコピー管理テーブルの構成例を示す。図５Ｂには、第一ストレージサブシステム４３Ａに備えられるリモートコピー管理テーブル８７Ａを代表的に示すが、図示のテーブル８７Ａの構成は、第二ストレージサブシステム４３Ｂに備えられるリモートコピー管理テーブル８７Ｂにも適用することができる。

リモートコピー管理テーブル８７Ａには、例えば、書き込み処理が同期または非同期のいずれで行われるかを示すコピーモードと、ペア状態と、そのコピーモードで書き込み処理が行われる正ストレージサブシステム及び副ストレージサブシステムの各々のＩＤと、そのコピーモードにおけるコピー元となる正ＶＯＬのＩＤとが登録される。また、その正ＶＯＬにアクセス可能なサーバ（及び／又はＤＢアクセス部）として割り当てられているサーバ（及び／又はＤＢアクセス部）のＩＤ（例えば名称）と、そのコピーモードにおけるコピー先となる副ＶＯＬのＩＤと、その副ＶＯＬにアクセス可能なサーバ（及び／又はＤＢアクセス部）として割り当てられているサーバ（及び／又はＤＢアクセス部）のＩＤとも登録される。なお、ペア状態とは、ボリュームペアに関する状態であり、例えば、ボリュームペアが形成されており且つ正ＶＯＬから副ＶＯＬへのコピーが行われる「ペア」という状態と、ボリュームペアが形成されているが副ＶＯＬから正ＶＯＬへのコピーが行われる「反転」という状態と、ボリュームペアが形成されていない「解除」という状態を採用することができる。

図５Ａに記載のＤＢ−ＶＯＬマッピングテーブル６７Ａと、図５Ｂに記載のリモートコピー管理テーブル８７Ａとにより、ログブロックやＤＢブロックをそれぞれ同期または非同期のどちらでどういうコピー方向（正ＶＯＬから副ＶＯＬへのコピーである正方向なのか或いは副ＶＯＬから正ＶＯＬへのコピーである反転方向なのか）でデータを書き込めばよいかがわかる。

例えば、ＤＢアクセス部１Ａ−１は、自分がアクセスできるデータベース領域が、データベース領域ＩＤ「ＤＢＡＲＥＡ１」、「ＬＯＧ１」及び「ＬＯＧ２」の少なくとも一つであることを、ＤＢ−ＶＯＬマッピングテーブル６７Ａを参照することにより、特定することができる。ＤＢアクセス部１Ａ−１は、例えば、データベース領域ＩＤが「ＬＯＧ１」であるデータベース領域にログブロックを格納する場合、そのＩＤに対応した正ストレージサブシステムＩＤ「ＣＴＬ＃Ａ１」及び正ＶＯＬＩＤ「ＶＯＬ１２−Ａ」をテーブル６７Ａから特定し、特定されたストレージサブシステムの正ログＶＯＬに上記ログブロックを書き込むことの書き込み要求を発行する。また、その書込み要求を受信したストレージサブシステム４３Ａにおいて、リモートコピー処理部８３Ａが、その書込み要求の発行先である正ストレージサブシステムＩＤ「ＣＴＬ＃Ａ１」及び正ＶＯＬＩＤ「ＶＯＬ１２−Ａ」に対応したコピーモードが「同期」であり、ペア状態が「ペア」であり、対応した副ストレージサブシステムが「ＣＴＬ＃Ｂ２」であり副ＶＯＬＩＤが「ＶＯＬ２１−Ｂ」であることを、リモートコピー管理テーブル８７Ａから特定する。それにより、リモートコピー処理部８３Ａ及び８３Ｂにより、正方向での同期リモートコピー処理が行われ、データベース領域ＩＤ「ＬＯＧ１」のログブロック（第一サーバ１５から正ストレージサブシステムに受信されたログブロック）が、副ストレージサブシステム「ＣＴＬ＃Ｂ２」及び副ＶＯＬＩＤ「ＶＯＬ２１−Ｂ」に対応した副ログＶＯＬに書き込まれる。

上記の図５Ａ及び図５Ｂによれば、一つのＤＢアクセス部（及び／又は一つのサーバ１５Ａ、１７Ａ、１５Ｂ又は１７Ｂ）には、少なくとも一つのデータベース領域が割り当てられる場合があるが、一つのデータベース領域が、同時期に複数のＤＢアクセス部（及び／又は複数のサーバ）に割り当てられることはない。すなわち、本実施形態では、或るデータベース領域を、そのデータベース領域にテーブル６７Ａ（及び／又はテーブル８７Ａ）上で対応付けられた或るＤＢアクセス部（及び／又はサーバ）が更新することができ、そうではないＤＢアクセス部（及び／又はサーバ）が更新することはできないように構成されている。

以下、この実施形態についてより詳細に説明する。なお、以下の説明では、第一サイト１ＡのＩＤを「サイトＡ」とし、第二サイト１ＢのＩＤを「サイトＢ」とする。また、第一サーバ１５ＡのＩＤを「サーバＡ１」とし、第一サーバ１７ＡのＩＤを「サーバＡ２」とし、第二サーバ１５ＢのＩＤを「サーバＢ１」とし、第二サーバ１７ＢのＩＤを「サーバＢ２」とする。以下の説明では、それらのＩＤを用いてサイト或いはサーバを説明する場合がある。

図６Ａは、サイト間監視サーバ４９で管理されている情報の一例を示す。

サイト間監視サーバ４９では、例えばサイト間監視ソフト２５により、記憶域２７を用いて情報が管理される。その情報としては、例えば、サーバ状態テーブル１０４と、監視結果テーブル１０３がある。

サーバ状態テーブル１０４は、各サイト１Ａ、１Ｂに存在する各サーバを管理するためのテーブルである。サーバ状態テーブル１０４には、例えば、各サーバ毎に、そのサーバが存在するサイトのＩＤと、そのサーバのＩＤと、応答待ち時間長と、サーバの状態とが登録される。ここで、応答待ち時間長とは、サーバからの応答が来なくなってからの待ち時間の長さである。記憶域２７には、その待ち時間長の閾値も記憶させておくことができる。サーバの状態としては、例えば、正常、障害（障害が発生したことを示す）、及び停止（意図的に停止させたことを示す）の三種類を採用することができる。

監視結果テーブル１０３は、各サイトの監視結果を管理するためのテーブルである。監視結果テーブル１０３には、例えば、各サイト毎に、サイトのＩＤと状態とが登録される。サイトの状態としては、例えば、正常、障害（障害が発生したことを示す）、及び停止（意図的に停止させたことを示す）の三種類を採用することができる。

サイト間監視ソフト２５は、例えば、或るサーバからの応答待ち時間長が所定の待ち時間長閾値を超えた場合に、サーバ状態テーブル１０４において、そのサーバの状態を「正常」から「障害」に更新する。また、サイト監視ソフト２５は、或るサイトに存在する全てのサーバの状態がサーバ状態テーブル１０４上で「障害」になっていることを検出した場合には、監視結果テーブル１０３において、そのサイトの状態を「正常」から「障害」に更新する。

図６Ｂは、ＤＢアクセス部管理テーブルの構成例を示す。

ＤＢアクセス部管理テーブル１０１は、サーバに存在するＤＢアクセス部に関する情報を管理するためのテーブルである。このテーブル１０１は、例えば、サイト間監視サーバ４９の記憶域２７に記憶させることができるが、それに限らず、例えば、第一サーバ１５Ａ、１７Ａの記憶域６９Ａ、及び／又は、第二サーバ１５Ｂ、１７Ｂの記憶域６９Ｂにも記憶させることができる。ＤＢアクセス部管理テーブル１０１には、データ処理システム３に存在する全ての又は一部のＤＢアクセス部（例えば或るサーバに存在する複数のＤＢアクセス部）の各々について、例えば、そのＤＢアクセス部のＩＤ（サブサーバＩＤ）や、そのＤＢアクセス部が存在するサイトのＩＤや、そのＤＢアクセス部が現用と待機用のどちらであるかや、そのＤＢアクセス部の状態（例えば、正常、障害或いは停止）や、そのＤＢアクセス部及びそのＤＢアクセス部に対応したＤＢアクセス部が存在するサーバのＩＤが登録される。また、ＤＢアクセス管理テーブル１０１には、各ＤＢアクセス部について、そのＤＢアクセス部に対応した別のＤＢアクセス部のＩＤも、その別のＤＢアクセス部を備えるサーバのＩＤに関連付けて、登録することができる。また、登録されるサーバのＩＤとしては、例えば、現用のサーバ（正サーバ）のＩＤ、そのサーバに対応した待機用のサーバのＩＤ、その現用のサーバに対応した副側の現用のサーバのＩＤ、及び、その副側の現用サーバに対応した待機用サーバのＩＤを採用することができる。

例えば、サイト間監視サーバ４９（及び／又は、第一サーバ監視部１９Ａ）が、ＤＢアクセス部管理テーブル１０１を参照することにより、各ＤＢアクセス部についての種々の情報を特定するができる。また、サイト間監視サーバ４９は、その特定された内容に基づく種々の処理も実行することができる。

図７は、或るサーバにおける各ＤＢアクセス部をサーバ監視部が監視する方法の一例を説明するための図である。

この図７は、第一サーバ１５Ａを例に採ったものである。第一サーバ１５Ａの記憶域６９Ａには、例えば、所定の共有領域１１１が用意されている。共有領域１１１には、複数のＤＢアクセス部にそれぞれ割り当てられた複数のサブ共有領域１１１Ａ、１１１Ｂ、…が存在する。

この構成の下、例えば、ＤＢアクセス部１Ａ−１は、自分に割り当てられているサブ共有領域１１１Ａに定期的に（又は不定期に）アクセスし、その領域１１１Ａに、所定の情報を書く（例えばフラグを立てる）。それに対して、第一サーバ監視部１９Ａは、定期的に（又は不定期に）、サブ共有領域１１１Ａにアクセスし、サブ共有領域１１１Ａに情報が書かれていればそれを別の情報に更新するか或いは消去する（例えばフラグを倒す）。ここで、第一サーバ監視部１９Ａは、所定回数（例えば一回以上）サブ共有領域１１１Ａにアクセスしても、サブ共有領域１１１Ａに所定情報が書かれていない場合には、ＤＢアクセス部１Ａ−１がダウンしたと判断して、ＤＢアクセス部管理テーブル１０１において、そのＤＢアクセス部１Ａ−１の状態を「障害」に更新する。その後、所定情報が書かれたことを検出した場合には、第一サーバ監視部１９Ａは、ＤＢアクセス部１Ａ−１の状態を「正常」に更新する。

以上の監視方法は、他のＤＢアクセス部１Ａ−２等についても適用することができる。また、ＤＢアクセス部の監視は、この方法に限らず、他の方法（例えばハートビートを利用する方法）も採用することができる。また、上記の監視方法は、サイト間監視サーバ４９が行う監視方法に適用されても良いが、サイト間監視サーバ４９が行う監視方法にも、種々の方法を採用することができる。

図８は、本発明の実施形態に係るデータ処理システムにおいて行われる一つの処理流れの一例の概要を示す。

サイト間監視ソフト２５は、例えば各サーバのサーバ監視部と通信することにより、各サーバ１５Ａ、１５Ｂ、１７Ａ及び１７Ｂの状態を監視することができる。また、サイト間監視ソフト２５は、例えば、各サーバのサーバ監視部から、そのサーバ監視部が監視しているＤＢアクセス部の状態を通知してもらうことにより、各サーバにおける各ＤＢアクセス部の状態も監視することができる。

ここでは、例えば、サイト間監視ソフト２５は、少なくとも現用のサーバ１５Ａ、１５Ｂを監視している（Ｓ２１）。サイト間監視ソフト２５は、監視の結果に基づいて、必要に応じて（例えば、正常であったサーバに障害が発生した場合に）、監視の結果を、監視結果テーブル１０３及び／又はサーバ状態テーブル１０４に反映する（Ｓ２２）。

例えば、第一ユーザ端末１１Ａは、第一サイト１Ａに接続しようとする場合には、サイト間監視サーバ４９にアクセスし、第一サイト１Ａの状態を問い合わせる（Ｓ２３）。この処理は、ユーザの操作に応答して行われても良いし、第一ユーザ端末１１Ａにインストールされたコンピュータプログラムにより自動的に行われても良い。

サイト間監視ソフト２５は、その問い合わせに応答して、第一サイト１Ａの状態を監視結果テーブル１０３から取得し（Ｓ２４）、取得された状態を表す情報を、問い合わせ元である第一ユーザ端末１１Ａに送信する（Ｓ２５）。

第一ユーザ端末１１Ａは、サイト間監視ソフト２５から受信した情報が表す状態が「正常」である場合には、第一サイト１Ａに所望のクエリーを発行する（Ｓ２６）。ここでは、例えば、第一ユーザ端末１１Ａは、現用の第一サーバ１５ＡのＩＤ（例えばＩＰアドレス）、又は、現用となっているＤＢアクセス部のＩＤ（例えばＩＰアドレス）を用いて、クエリーを発行することができる。また、発行するクエリーとしては、クリエイトテーブル１０５を採用することができる。クリエイトテーブル１０５には、例えば、桁数ｎを表すCHAR(n)等の要素の他に、データの格納先とするデータベース領域のＩＤ（例えば、ＤＢＡＲＥＡ１、ＤＢＡＲＥＡ２）が記述される。

第一ユーザ端末１１Ａから発行されたクエリー（例えばクリエイトテーブル１０５）を、例えば、現用のＤＢアクセス部１Ａ−１が受ける。これは、例えば、第一サーバ１５ＡにおいてＤＢアクセス部管理テーブル１０１が備えられている場合には、第一サーバ１５Ａの第一サーバ監視部１９Ａが、ＤＢアクセス部管理テーブル１０１を参照することで、現用のＤＢアクセス部１Ａ−１は正常であるかどうかを判断することができ、正常と判断された場合に、第一ユーザ端末１１Ａからのクエリーを受け付け担当として、ＤＢアクセス部１Ａ−１を第一ユーザ端末１１Ａに割り当てることができる。

ＤＢアクセス部１Ａ−１は、クエリー（例えばクリエイトテーブル１０５）の内容と、ＤＢ−ＶＯＬマッピングテーブル６７Ａとに基づいて、自分が第一サイト内の論理ボリュームにアクセスするか、或いは、他のＤＢアクセス部に論理ボリュームにアクセスさせるかの判断を行う（Ｓ２７）。具体的には、例えば、ＤＢアクセス部１Ａ−１は、クエリーに記述されているデータベース領域ＩＤに対応付けられた正ストレージサブシステムＩＤ及び正ＶＯＬＩＤ等をＤＢ−ＶＯＬマッピングテーブル６７Ａから把握する。

例えば、Ｓ２７Ｂにより、自分が論理ボリュームにアクセスすると判断された場合、ＤＢアクセス部１Ａ−１は、トランザクション処理により派生したＤＢブロック（例えばCOMMITにより確定したデータのブロック）を、ＤＢバッファ６３Ａを介して、自分に対応した正ＤＢ用ＶＯＬ５１Ａに書き込む（Ｓ２８）。

また、例えば、Ｓ２７Ｂにより、ＤＢアクセス部１Ａ−２が論理ボリュームにアクセスすべきであると判断された場合、ＤＢアクセス部１Ａ−１は、ＤＢアクセス部１Ａ−２に、論理ボリュームにアクセスすることを命じる（Ｓ２９）。この場合、ＤＢアクセス部１Ａ−２が、トランザクション処理により派生したＤＢブロックを、ＤＢバッファ６３Ａを介して、自分に対応した正ＤＢ用ＶＯＬ５２Ａに書き込む（Ｓ３０）。書き込み先となるＶＯＬ５２ＡのＩＤは、例えば、ＤＢアクセス部１Ａ−１から通知されても良いし、データベース領域ＩＤからＤＢアクセス部１Ａ−２によって特定されても良い。

また、例えば、Ｓ２７Ｂにより、第二サイト１Ｂの現用第二サーバ１５Ｂに存在するＤＢアクセス部３Ｂ−１が論理ボリュームにアクセスすべきであると判断された場合、ＤＢアクセス部１Ａ−１は、第一サーバ監視部１９Ａから第三ネットワーク１３Ｃ（図示せず）等を介して、第二サイト１Ｂの第二サーバ１５ＢにあるＤＢアクセス部３Ｂ−１に、論理ボリュームにアクセスすることを命じる（Ｓ３１）。この場合、ＤＢアクセス部３Ｂ−１が、トランザクション処理により派生したＤＢブロックを、ＤＢバッファ６３Ｂを介して、自分に対応した正ＤＢ用ＶＯＬ５５Ｂに書き込む（Ｓ３２）。書き込み先となるＶＯＬ５５ＢのＩＤは、例えば、ＤＢアクセス部１Ａ−１から通知されても良いし、データベース領域ＩＤからＤＢアクセス部３Ｂ−１によって特定されても良い。

以上が、本実施形態における一つの処理流れの概要である。なお、この実施形態では、前述したように、サイト間で、同期リモートコピー処理或いは非同期リモートコピー処理が行われる。例えば、図８の例では、図示しないリモートコピー管理テーブル８７Ａ（及び／又は８７Ｂ）において、正ＤＢＶＯＬ５１Ａと副ＤＢＶＯＬ５１Ｂとの状態、正ＤＢＶＯＬ５２Ａと副ＤＢＶＯＬ５２Ｂとの状態、及び、正ＤＢ用ＶＯＬ５５Ｂと副ＤＢＶＯＬ５５Ａとの状態が、それぞれ、「ペア」になっているものとする。この場合、図８において点線で示すように、正ＤＢＶＯＬから副ＤＢＶＯＬに、非同期リモートコピー処理が行われる。この処理は、第一ストレージ制御装置４５Ａのリモートコピー処理部８３Ａと、第二ストレージ制御装置４５Ｂのリモートコピー処理部８３Ｂとにより、行われる。

以下、本実施形態に係るデータ処理システム３において行われる処理の具体的な流れについて幾つか説明する。

図９は、第一ユーザ端末１１Ａが行う処理の流れの一例を示す。この図に示す流れは、第二ユーザ端末１１Ｂにも適用することができる。

第一ユーザ端末１１Ａは、サイト間監視サーバ４９に、第一サイト１Ａの状態を問い合わせる（Ｓ６１）。

第一ユーザ端末１１Ａは、その問い合わせに応答して、第一サイト１Ａの状態を表す情報を受けた場合、その情報が表す状態が「障害」（又は「停止」）でなければ（Ｓ６２でＹＥＳ）、第一サーバ１５ＡのＤＢアクセス部に接続要求を出す（Ｓ６３）。ここでは、例えば、第一ユーザ端末１１Ａは、第一サーバ１５ＡのＩＰアドレスを有した接続要求を出しても良いし、特定のＤＢアクセス部（例えば１Ａ−１）のＩＰアドレスを有した接続要求を出しても良い。

第一ユーザ端末１１Ａから出された接続要求は、例えば、第一サーバ監視部１９Ａが受ける。第一サーバ監視部１９Ａは、ＤＢアクセス部管理テーブル１０１を参照し、ＤＢアクセス部の状態を把握する。第一サーバ監視部１９Ａは、例えば、第一サーバ１５Ａに対する接続要求を受けた場合には、状態が「正常」であるＤＢアクセス部の中から特定のＤＢアクセス部を第一ユーザ端末１１Ａに接続することを認める（接続ＯＫを出す）。また、例えば、第一サーバ監視部１９Ａは、ＤＢアクセス部１Ａ−１に対する接続要求を受けた場合には、そのＤＢアクセス部１Ａ−１の状態が「正常」であれば、接続ＯＫを出し、その状態が「障害」又は「停止」であれば、接続を認めない（接続ＮＧを出す）。ここで、もし、例えば、他のＤＢアクセス部１Ａ−２乃至１Ａ−４のうちいずれかの状態が「正常」であれば、第一サーバ監視部１９Ａは、他のＤＢアクセス部１Ａ−２乃至１Ａ−４のいずれかを、第一ユーザ端末１１Ａに対して接続させても良い。その場合には、接続ＯＫが出されても良い。

第一ユーザ端末１１Ａは、Ｓ６３の接続要求に対して接続ＯＫが出された場合には、接続されたＤＢアクセス部に所定の処理、例えば、トランザクション処理を要求する（Ｓ６９）。

一方、第一ユーザ端末１１Ａは、第一サーバ１５Ａから接続ＮＧを受けた場合には、同一サイト１Ａに属する別の第一サーバ１７ＡのＤＢアクセス部に接続要求を出す（Ｓ６５）。その場合には、第一サーバ監視部４１Ａによって、第一サーバ監視部１９Ａと同様の上記処理が行われ、接続ＯＫか接続ＮＧが出される。ここで、第一サーバ１７Ａから接続ＯＫを受けた場合には、第一ユーザ端末１１Ａは、接続されたＤＢアクセス部に対して所定の処理、例えばトランザクション処理を要求することができる（Ｓ６９）。また、接続ＮＧを受けた場合には、第一ユーザ端末１１Ａは、しばらく待つか、或いは、第二サイト１Ｂの第二サーバ１５Ｂ又は１７Ｂに接続要求を出すことができる。

第一ユーザ端末１１Ａは、Ｓ６１の問い合わせに応答して受けた状態が「障害」又は「停止」の場合には、第二サイト１Ｂに対して、第一サイト１Ａに対するＳ６３乃至Ｓ６５の処理と同様の処理を実行する（Ｓ６６乃至Ｓ６８）。

Ｓ６９の後に、例えば接続したＤＢアクセス部で障害が発生しそれが検出された場合には（Ｓ７０でＹＥＳ）、Ｓ６１が再び行われる。

図１０は、サイト間監視ソフトが行う処理の流れの一例を示す。

サイト間監視ソフト２５は、所定のタイミングで（例えば、ユーザ端末１１Ａ又は１１Ｂから第一サイト１Ａ又は第二サイト１Ｂの問い合わせを受けた場合に）、監視結果テーブル１０３を参照し、第一サイト１Ａ及び第サイト１Ｂの状態を取得する（Ｓ７１及びＳ７２）。

サイト間監視ソフト２５は、第一サイト１Ａの状態が「障害」になっていれば（Ｓ７３でＹＥＳ）、第一サイト１Ａの全サーバ１５Ａ、１７Ａに復旧の有無を問い合わせ、全サーバ１５Ａ、１７Ａからの応答を待つ（Ｓ７４）。全サーバ１５Ａ、１７Ａから応答があれば（Ｓ７４でＹＥＳ）、サイト間監視ソフト２５は、各サーバ１５Ａ、１７Ａ、１５Ｂ、１７Ｂに第一サイト１Ａへのフェールバック処理を行わせ（Ｓ７５）、且つ、監視結果テーブル１０３における第一サイト１Ａの状態を「正常」に更新する（Ｓ７６）。それに対し、少なくとも一つのサーバ１５Ａ及び／又は１７Ａから応答が無ければ（Ｓ７４でＮＯ）、サイト間監視ソフト２５は、第二サイト１Ｂの状態を監視結果テーブル１０３から取得し、第二サイトの状態が「障害」かどうかを判断する（Ｓ７８）。

サイト間監視ソフト２５は、第二サイト１Ｂの状態が「障害」になっていれば（Ｓ７９でＹＥＳ）、第二サイト１Ｂの全サーバ１５Ｂ、１７Ｂに復旧の有無を問い合わせ、全サーバ１５Ｂ、１７Ｂからの応答を待つ（Ｓ８０）。全サーバ１５Ｂ、１７Ｂから応答があれば（Ｓ８０でＹＥＳ）、サイト間監視ソフト２５は、各サーバ１５Ａ、１７Ａ、１５Ｂ、１７Ｂに第二サイト１Ｂへのフェールバック処理を行わせ（Ｓ８１）、且つ、監視結果テーブル１０３における第二サイト１Ｂの状態を「正常」に更新する（Ｓ８２）。それに対し、少なくとも一つのサーバ１５Ｂ及び／又は１７Ｂから応答が無ければ（Ｓ８０でＮＯ）、サイト間監視ソフト２５は、第一サイト１Ａの状態を監視結果テーブル１０３から取得し、第一サイトの状態が「障害」かどうかを判断する（Ｓ８４）。

Ｓ７８でＹＥＳ又はＳ８４でＹＥＳならば、第一サイト１Ａでも第二サイト１Ｂでも障害が発生しているということである。この場合、サイト間監視ソフト２５は、所定のエラー処理、例えば、両サイトに障害が発生していることを表すメッセージを所定ノード（例えば問い合わせ元のユーザ端末１１Ａ又は１１Ｂ）に表示させる（Ｓ８５）。

図１１は、サイト間監視ソフトが行うサーバに対する監視処理の流れの一例を示す。この図は、例えば、第一サーバに対する漢詩処理の流れを例に採って示しているが、この図に示す処理流れは、第二サーバに対しても適用することができる。

サイト間監視ソフト２５は、第一サーバ１５Ａ及び１７Ａの状態をサーバ状態テーブル１０４から取得する（Ｓ７１）。

サイト間監視ソフト２５は、第一サーバ１５Ａ又は１７Ａに対する信号に対して応答があった場合（Ｓ７２でＹＥＳ）、サーバ状態テーブル１０４において、応答の送信元のサーバ１５Ａ又は１７Ａに対応した状態が「障害」又は「停止」になっていれば、その状態を「正常」に更新すると共に、監視結果テーブル１０３における第一サイト１Ａの状態も「正常」に更新する（Ｓ７３）。

サイト間監視ソフト２５は、第一サーバ１５Ａ又は１７Ａに対する信号に対して応答がいずれのサーバからも無い場合（Ｓ７２でＮＯ）、サーバ状態テーブル１０４から、各サーバ１５Ａ及び１７Ａの状態を取得し、各サーバ１５Ａ及び１７Ａの状態を判断する（Ｓ７４）。

サイト間監視ソフト２５は、サーバ１５Ａ及び１７Ａの両方の状態が「障害」又は「停止」であれば（Ｓ７４でＹＥＳ）、第二サイトへのフェールオーバ処理を実行し（Ｓ７７）、且つ、監視結果テーブル１０３における第一サイト１Ａの状態を「障害」又は「停止」に更新する（Ｓ７８）。

サイト間監視ソフト２５は、サーバ１５Ａ及び１７Ａのいずれかの状態が「障害」及び「停止」でなければ（Ｓ７４でＮＯ）、サーバ状態テーブル１０４において、第一サーバ１５Ａ及び１７Ａの待ち時間長を更新する（Ｓ７５）。サイト間監視ソフト２５は、更新後の待ち時間長と、所定の待ち時間長閾値とを比較し、両方のサーバの待ち時間長が所定の待ち時間長閾値を超えた場合には、Ｓ７７及びＳ７８の処理を実行する。さらに、その場合、サイト間監視ソフト２５は、サーバ状態テーブル１０４において、各サーバ１５Ａ及び１５Ｂの状態を「障害」に更新することができる。

図１２は、現用の第一サーバのＤＢアクセス部１Ａ−１がダウンした場合に行われるサイト内フェールオーバ処理の流れの一例を示す。図１３Ａは、図１２のサイト内フェールオーバ処理の説明図である。図１３Ｂは、図１２のサイト内フェールオーバ処理の流れにおける監視結果テーブル１０３を示す。図１３Ｃは、図１２のサイト内フェールオーバ処理の流れにおけるＤＢアクセス部管理テーブル１０１の或る一レコードの更新結果を示す。図１３Ｄは、図１２のサイト内フェールオーバ処理の流れにおけるＤＢアクセス部管理テーブル１０１の別の一レコードの更新結果を示す。図１４は、図１２のサイト内フェールオーバ処理の流れにおけるＤＢ−ＶＯＬマッピングテーブル６７Ａの更新結果を示す。以下、図１２乃至図１４を参照して、サイト内フェールオーバ処理の一例について説明する。

例えばＤＢアクセス部１Ａ−１に障害が発生してダウンした場合、第一サーバ１５Ａの第一サーバ監視部１９Ａが、ＤＢアクセス部１Ａ−１のダウンを検出する（Ｓ１０１）。この場合、第一サイト１Ａ全体がダウンしたわけではないので、図１３Ｂに示すように、サイト間監視ソフト２５によって監視結果テーブル１０３が更新されることはない。

第一サーバ監視部１９Ａは、ＤＢアクセス部１Ａ−１のダウンを検出した場合、ＤＢアクセス部１Ａ−１にシャットダウンを要求し（Ｓ１０２）、それにより、ＤＢアクセス部１Ａ−１にシャットダウンさせる。第一サーバ監視部１９Ａは、サーバ１５Ａ内のＤＢアクセス部を監視することを一旦終える（Ｓ１０３）。

第一サーバ監視部１９Ａは、ＤＢアクセス部１Ａ−１の引継ぎ先、換言すれば、ＤＢアクセス部１Ａ−１に代えて現用のＤＢアクセス部となる待機用のＤＢアクセス部（つまり引き継ぎ先）の判定を行う（Ｓ１０４）。例えば、第一サーバ監視部１９Ａが、サイト間監視ソフト２５に、ＤＢアクセス部１Ａ−１のダウンを通知する。サイト間監視ソフト２５が、ＤＢアクセス部管理テーブル１０１を参照し、ダウンしたＤＢアクセス部１Ａ−１のＩＤに対応付けられた一以上のＩＤの中から所定の又は任意のＩＤをＤＢアクセス部管理テーブル１０１から抽出し、抽出したＩＤに関するＤＢアクセス部に関する情報（例えばどのサーバに存在するか等）を第一サーバ監視部１９Ａに通知する。それにより、第一サーバ監視部１９Ａが、引き継ぎ先を判定することができる。

引き継ぎ先として判定されたＤＢアクセス部は、例えば、待機用の第一サーバ１７Ａに存在するＤＢアクセス部２Ａ−１であったとする。この場合、第一サーバ監視部１９Ａと４１Ａとの間で、ＤＢアクセス部１Ａ−１に関わるリソースをＤＢアクセス部２Ａ−１に引き継がせる（Ｓ１０５）。この処理では、例えば、ＤＢアクセス部１Ａ−１のＩＰアドレスがＤＢアクセス部２Ａ−１に割り当てられたり、ＤＢアクセス部１Ａ−１に割り当てられていたデータベース領域のＩＤ（換言すれば、そのデータベース領域を有するＶＯＬのＩＤ）が、ＤＢアクセス部２Ａ−１に割り当てられたりする。

第一サーバ監視部１９Ａは、ＤＢアクセス部２Ａ−１に起動要求を発行する（Ｓ１０６）。それにより、ＤＢアクセス部２Ａ−１が、起動する（Ｓ１０７）。また、これにより、待機用であったＤＢアクセス部２Ａ−１が現用になる。ＤＢアクセス部２Ａ−１は、起動処理が完了した場合には、起動完了通知を第一サーバ監視部１９Ａ（及び／又はサイト間監視ソフト２５）に発行する（Ｓ１０８）。

第一サーバ監視部１９Ａ（及び／又は、サイト間監視ソフト２５）は、起動完了通知をＤＢアクセス部２Ａ−１から受けたならば（Ｓ１０９）、これまでの処理の結果を、ＤＢ−ＶＯＬマッピングテーブル６７Ａ（及び／又は、ＤＢアクセス部管理テーブル１０１）に反映させ、監視を再開する（Ｓ１１０）。また、第一サーバ監視部１９Ａ（及び／又は、サイト間監視ソフト２５）は、切り替え通知を第一サーバ監視部４１Ａ（及び／又は、サイト間監視ソフト２５）に発行する（Ｓ１１１）。第一サーバ監視部４１Ａ（及び／又は、サイト間監視ソフト２５）は、切り替え通知を受けたならば（Ｓ１１２）、これまでの処理の結果を、ＤＢアクセス部管理テーブル１０１や、ＤＢ−ＶＯＬマッピングテーブル６７Ａ（及び／又は、ＤＢアクセス部管理テーブル１０１）に反映させる（Ｓ１１３）。

Ｓ１１０による処理により、例えば、ＤＢアクセス部管理テーブル１０１において、ＤＢアクセス部１Ａ−１について、「現用」が「待機」に更新され、状態が「障害」に更新される（図１３Ｃ参照）。また、ＤＢアクセス部２Ａ−１についての情報もあれば、ＤＢアクセス部２Ａ−１について、「待機」が「現用」に更新される（図１３Ｄ参照）。

また、Ｓ１１０による処理により、例えば、ＤＢ−ＶＯＬマッピングテーブル６７Ａにおいて、サブサーバＩＤ「ＤＢアクセス部１Ａ−１」が、「ＤＢアクセス部２Ａ−１」に更新される（図１４参照）。

図１３Ｃ乃至図１４のうちの少なくとも図１３Ｄの更新結果は、Ｓ１１３による処理の結果についても同様である。

図１５は、第一サイト１Ａがダウンした場合に行われるサイト間フェールオーバ処理の流れの一例を示す。図１６Ａは、図１５のサイト間フェールオーバ処理の説明図である。図１６Ｂは、図１６のサイト間フェールオーバ処理の流れにおける監視結果テーブル１０３の更新結果を示す。図１６Ｃは、図１５のサイト間フェールオーバ処理の流れにおけるＤＢアクセス部管理テーブル１０１Ｂの或る一レコードの更新結果を示す。図１６Ｄは、図１５のサイト間フェールオーバ処理の流れにおけるＤＢアクセス部管理テーブル１０１Ｂの別の一レコードの更新結果を示す。図１７Ａは、図１２のサイト間フェールオーバ処理の流れにおけるＤＢ−ＶＯＬマッピングテーブル６７Ｂの更新結果を示す。図１７Ｂは、図１２のサイト間フェールオーバ処理の流れにおけるリモートコピー管理テーブル８７Ｂの更新結果を示す。以下、図１５乃至図１７Ｂを参照して、サイト間フェールオーバ処理の一例について説明する。

例えば第一サイト１Ａで障害が発生した場合（一例として、第一サーバ１５Ａ及び１７Ａの両方の状態が「障害」の場合）、サイト間監視ソフト２５によりそれが検知される（Ｓ１２１）。

サイト間監視ソフト２５は、監視結果テーブル１０３において、第一サイト１Ａの状態を「障害」に更新し（Ｓ１２２及び図１６Ｂ）、第二サイト１Ｂの各サーバ監視部１９Ｂ、４１Ｂに、サイト間フェールオーバを通知する（Ｓ１２３）。図１５及び図１６Ａでは、第二サーバ１７Ｂの第二サーバ監視部４１Ｂがサイト間フェールオーバ通知を受けた場合に行われる処理の流れを例に採っている（その流れは、別の第二サーバ監視部１９Ｂにも適用できる）。

第二サーバ監視部４１Ｂは、サイト間フェールオーバの通知を受けた場合、第一サイト１ＡにアクセスされるＶＯＬが形成しているボリュームペアの解除を第二ストレージサブシステム４３Ｂに命令する（Ｓ１２５）。第一サイト１Ａそれ自体がダウンしているため、第二ストレージサブシステム４３Ｂの各ＶＯＬの更新結果がリモートコピーにより第一ストレージサブシステム４３Ａに送信する必要が無いからである。このＳ１２５では、例えば、第二サーバ監視部４１Ｂが、ＤＢ−ＶＯＬマッピングテーブル６７Ｂ及びＤＢアクセス部管理テーブル１０１Ｂを参照し、第二サーバ１７Ｂが備えるＤＢアクセス部に割り当てられているＶＯＬであって、第一サイト１Ａに存在するＤＢアクセス部に割り当てられているＶＯＬとペアを構成しているＶＯＬを特定し、その特定されたＶＯＬが構成するボリュームペアの解除を第二ストレージサブシステム４３Ｂに命令する。この場合、第二ストレージサブシステム４３Ｂの第二ストレージ制御装置４５Ｂが、その命令に応答し、リモートコピー管理テーブル８７Ｂにおいて、その命令に関わるＶＯＬのペア状態を、「解除」に更新することができる。また、正サイトＩＤを第二サイトのＩＤに更新することもできる（図１７Ｂ参照）。

第二サーバ監視部４１Ｂは、第二サーバ１７Ｂに存在する複数のＤＢアクセス部のうち、第一サイト１Ａに関わるＤＢアクセス部４Ａ−１乃至４Ａ−４を特定し、特定されたＤＢアクセス部に起動要求を出す（Ｓ１２６）。ＤＢアクセス部の特定は、例えば、ＤＢアクセス部管理テーブル１０１Ｂを参照することにより、行うことができる。以下、ＤＢアクセス部４Ａ−１に起動命令が出された後の処理を例に採って説明する。

ＤＢアクセス部４Ａ−１が、起動命令に応答して起動する（Ｓ１２７）。これにより、待機用であったＤＢアクセス部４Ａ−１が現用になる。ＤＢアクセス部４Ａ−１は、起動処理が完了した場合には、起動完了通知を第二サーバ監視部１９Ｂに発行する（Ｓ１２８）。また、第二サーバ監視部１９Ｂは、その起動完了通知を、サイト間監視ソフト２５に通知することができる。

第二サーバ監視部４１Ｂ（及び／又は、サイト間監視ソフト２５）は、起動完了通知を受けたならば（Ｓ１２９）、これまでの処理の結果を、ＤＢ−ＶＯＬマッピングテーブル６７Ｂ（及び／又は、ＤＢアクセス部管理テーブル１０１Ｂ）に反映させる。第二サーバ監視部４１Ｂは、各ＤＢアクセス部４Ａ−１乃至４Ａ−４の監視を始める（Ｓ１３０）。

Ｓ１３０による処理により、例えば、ＤＢアクセス部管理テーブル１０１Ｂにおいて、ＤＢアクセス部１Ａ−１の情報があれば、「現用」が「待機」に更新され、状態が「障害」に更新される（図１６Ｃ参照）。また、例えば、ＤＢアクセス部４Ａ−１については、「待機」から「現用」に更新される（図１６Ｄ参照）。例えば、現用になったＤＢアクセス部４Ａ−１は、ＤＢ−ＶＯＬマッピングテーブルを参照することにより、自分がどのＶＯＬにアクセスしたら良いかを判断することができる。ここでは、例えば、ＤＢアクセス部４Ａ−１が利用できるＤＢ用ＶＯＬは、ＤＢアクセス部１Ａ−１がアクセスしていた正ＤＢＶＯＬに対応した副ＤＢＶＯＬとすることができる。また、サイト間監視ソフト２５は、ＤＢアクセス部１Ａ−１に割り当てられていたリソース情報（例えばＩＰアドレス）を管理しており、そのリソース情報を第一ユーザ端末１１Ａに提供することにより、第一ユーザ端末１１Ａがそのリソース情報を用いてＤＢアクセス部１Ａ−１にアクセスする方法を採った場合には、ＤＢアクセス部４Ａ−１にアクセスするようにすることができる。

また、Ｓ１３０による処理により、例えば、ＤＢ−ＶＯＬマッピングテーブル６７Ｂにおいて、サブサーバＩＤ「ＤＢアクセス部１Ａ−１」が、「ＤＢアクセス部４Ａ−１」に更新される（図１７Ａ参照）。

以上が、サイト間フェールオーバ処理の流れの一例である。なお、この説明では、待機用ＤＢアクセス部４Ａ−１が現用になることを例に採ったが、待機用ＤＢアクセス部３Ａ−１と４Ａ−１とのどちらが現用になるかは、システム３において予め所定の場所に定義されていてもよいし（例えば第二サーバ監視部１９Ｂ、４１Ｂに定義されていても良いし）、第二サーバ監視部１９Ｂと４１Ｂとのネゴシエーションの結果（例えばどちらのサーバの負荷の方が小さいかの判別）により決められても良い。

図１８は、計画切り替え処理の流れの一例を示す。

計画切り替え処理とは、第一サイト１Ａ（又は第二サイト１Ｂ）全体を擬似的にダウンさせて、サイト間フェールオーバ処理を実行することにある。サイトは、擬似的にダウンするに過ぎないので、実際には、ダウンしたとされたサイト内のストレージサブシステムは稼動することができ、それにより、フェールオーバ先のサイト内のストレージサブシステムと、フェールオーバ元のサイト（擬似的にダウンしたサイト）内のストレージサブシステムとの間で、リモートコピー処理を行うことができる。以下、第一サイト１Ａを擬似的にダウンさせる場合を例に採り、計画切り替え処理の具体的な流れの一例を説明する。

サイト間監視ソフト２５が、所定のタイミング（例えば予め設定された時刻）で、計画切り替え指示を、各第一サーバ１５Ａ、１５Ｂの第一サーバ監視部１９Ａ、４１Ｂに発行する。

例えば、第一サーバ監視部１９Ａは、計画切り替え指示を受けた場合（Ｓ１４２）、現用のＤＢアクセス部（例えば１Ａ−１）に、停止要求を出す（Ｓ１４３）。

ＤＢアクセス部１Ａ−１は、停止要求を受けた場合（Ｓ１４４）、自分の動作を停止する処理を実行し（シャットダウンし）（Ｓ１４５）、それが終了したならば、停止完了通知を第一サーバ監視部１９Ａに発行する（Ｓ１４６）。

第一サーバ監視部１９Ａは、これまでの処理結果をＤＢアクセス部管理テーブル１０１やＤＢ−ＶＯＬマッピングテーブル６７Ａに反映させ、現用であったＤＢアクセス部１Ａ−１乃至１Ａ−４の監視を解除する（Ｓ１４７）。

第一サーバ監視部１９Ａは、リソースを切り離し（例えば、現用であったＤＢアクセス部のＩＰアドレスを無効にし）、監視終了をサイト間監視ソフト２５に通知する（Ｓ１４９）。

サイト間監視ソフト２５は、第一サーバ監視部１９Ａ及び４１Ａから監視終了の通知を受けた場合には、監視結果テーブル１０３において、第一サイト１Ａの状態を「停止」に更新する（Ｓ１５０）。サイト間監視ソフト２５は、サイト間フェールオーバ通知を各第二サーバ１５Ｂ、１７Ｂの第二サーバ監視部１９Ｂ、４１Ｂに送信する（Ｓ１５１）。

第二サーバ監視部４１Ｂは、サイト間フェールオーバ通知を受けた場合（Ｓ１５２）、テイクオーバ処理を実行する（Ｓ１５３）。具体的には、例えば、第二サーバ監視部４１Ｂは、ＤＢ−ＶＯＬマッピングテーブル６７Ｂ及びＤＢアクセス部管理テーブル１０１Ｂを参照し、第二サーバ１７Ｂが備えるＤＢアクセス部に割り当てられているＶＯＬであって、第一サイト１Ａに存在するＤＢアクセス部に割り当てられているＶＯＬとペアを構成しているＶＯＬを特定し、その特定されたＶＯＬが構成するボリュームペアの反転及びコピーの実行を第二ストレージサブシステム４３Ｂに命令する。この場合、第二ストレージサブシステム４３Ｂの第二ストレージ制御装置４５Ｂが、その命令に応答し、リモートコピー管理テーブル８７Ｂにおいて、その命令に関わるＶＯＬのペア状態を、「反転」に更新し、且つ、副ＶＯＬから正ＶＯＬへのリモートコピー処理を実行する。

その後は、図１５のＳ１２６乃至Ｓ１３０と同様の処理が行われる（Ｓ１５４乃至Ｓ１５８）。

ところで、この実施形態に係るデータ処理システム３では、上述したシステム構成により、デュアルバッチ処理を実行することができる。以下、それについて詳細に説明する。

図１９は、デュアルバッチ処理を行う前に行われる通常処理（例えばオンライン処理）の説明図である。

この実施形態では、例えば、ストレージサブシステム４３Ａと４３Ｂとの間だけでなく、同一のストレージサブシステム４３Ａ又は４３Ｂにおいても、ボリュームペアを構成することができる。図１９の例では、第一ストレージサブシステム４３Ａには、正ＤＢＶＯＬ２−２と副ＤＢＶＯＬ２−３とのボリュームペアを構成することができる。また、第二ストレージサブシステム４３Ｂには、正ＤＢＶＯＬ１−２と副ＤＢＶＯＬ１−３とのボリュームペアを構成することができる。

この実施形態では、第一ストレージサブシステム４３Ａの第一ストレージ制御装置４５Ａの記憶域９１Ａに、図２０に例示するようなＶＯＬペア管理テーブル６８が用意される。ＶＯＬ管理テーブル６８には、第一ストレージサブシステム４３Ａが備える各ＶＯＬペア毎に、ペア状態、正ＶＯＬＩＤ及び副ＶＯＬＩＤが登録される。第一ストレージ制御装置４５Ａのディスク制御処理部８５Ａは、ＶＯＬペア管理テーブル６８を参照することにより、自分を備えるストレージサブシステム４３Ａ内のＶＯＬペアに関する情報を取得することができる。なお、この段落の説明は、第二ストレージサブシステム４３Ｂにも適用することができる。

再び図１９を参照する。通常処理では、例えば、第一サイト１Ａにおいて、現用であるＤＢアクセス部１Ａ−１は、自分に割り当てられている正ＤＢＶＯＬ１−１にＤＢブロックを書く。正ＤＢＶＯＬ１−１に書かれたＤＢブロックは、リモートコピー処理部８３Ａにより、ＤＢＶＯＬ１−１から、それとペアを構成するＤＢＶＯＬ１−２にコピーされる（つまりリモートコピーが行われる）。更に、ＤＢＶＯＬ１−２にコピーされるＤＢブロックは、ディスク制御処理部８５Ｂにより、そのＤＢＶＯＬ１−２とＶＯＬペアを構成するＤＢＶＯＬ１−３にコピーされる（つまりストレージ内コピーが行われる）。

また、通常処理では、第二サイト１Ｂにおいて、現用であるＤＢアクセス部３Ｂ−１は、自分に割り当てられている正ＤＢＶＯＬ２−１にＤＢブロックを書く。正ＤＢＶＯＬ２−１に書かれたＤＢブロックは、リモートコピー処理部８３Ａ及び８３Ｂにより（図示せず）、ＤＢＶＯＬ２−１から、それとペアを構成するＤＢＶＯＬ２−２にコピーされる（つまりリモートコピーが行われる）。更に、ＤＢＶＯＬ２−２にコピーされるＤＢブロックは、ディスク制御処理部８５Ａにより、そのＤＢＶＯＬ２−２とＶＯＬペアを構成するＤＢＶＯＬ２−３にコピーされる（つまりストレージ内コピーが行われる）。

以上のような流れにより、各サイトに対応した処理結果を表すデータが、自分のサイトと別のサイトの両方に反映され、且つ、別のサイトでは、その処理結果を表すデータが多重化されて管理される。

図２１は、デュアルバッチ処理におけるバッチ更新処理の説明図である。

第一サイト１Ａにおいて、例えば第一サーバ監視部１９Ａが、第一ストレージサブシステム４３内で構成されているＶＯＬペアの解除を第一ストレージサブシステム４３Ａに命じる。それに応答して、第一ストレージ制御装置４５が、ＶＯＬペア管理テーブル６８を参照して、第一ストレージサブシステム４３Ａ内に存在するＶＯＬペアを特定し、特定されたＶＯＬペアの状態を「解除」に更新する。第二サイト１Ｂにおいても、同様の処理が行われ、それにより、第二ストレージサブシステム４３Ｂ内に存在するＶＯＬペアが無くなる。

その後、ＤＢアクセス部１Ａ−１が、第一ユーザ端末１１Ａからのクエリーに応答して、バッチ処理を実行する。具体的には、ＤＢアクセス部１Ａ−１は、ユーザ端末１１Ａからのクエリーに応答した処理を実行し、その処理結果を、自分に割り当てられているＤＢＶＯＬ１−１と、ＶＯＬペア解除前に副ＶＯＬであったＤＢＶＯＬ（換言すれば、リモートコピーのためのペアの構成要素になっていないＶＯＬ）２−３との両方に反映する（つまり、ＤＢＶＯＬ１−１及び２−３に同じデータが書かれる）。ＤＢＶＯＬ１−１は、第二ストレージサブシステムのＤＢＶＯＬ１−２との間でＶＯＬペアを構成しているので、上述したリモートコピー処理により、ＤＢＶＯＬ１−１の更新結果はＤＢＶＯＬ１−２に反映される。

第二サイト１ＢにおけるＤＢアクセス部３Ｂ−１も、第二ユーザ端末１１Ｂから、第一ユーザ端末１１Ａが出したクエリーと同じクエリー（例えば、銀行口座の残高と所定の利率との積を求める）を受け、それにより、ＤＢアクセス部１Ａ−１と同様のバッチ処理を行う。そのバッチ処理の処理結果データは、ＤＢアクセス部３Ｂ−１に割り当てられているＤＢＶＯＬ２−１と、ＶＯＬペア解除前に副ＶＯＬであったＤＢＶＯＬ（換言すれば、リモートコピーのためのペアの構成要素になっていないＶＯＬ）１−３との両方に反映される（つまり、ＤＢＶＯＬ２−１及び１−３に同じデータが書かれる）。ＤＢＶＯＬ２−１は、第一ストレージサブシステムのＤＢＶＯＬ２−２との間でＶＯＬペアを構成しているので、上述したリモートコピー処理により、ＤＢＶＯＬ２−１の更新結果はＤＢＶＯＬ２−２に反映される。

以上のようなバッチ更新処理により、結果として、ＶＯＬペアが解除されたものの、ＤＢＶＯＬ２−３内のデータとＤＢＶＯＬ２−２内のデータとは同じになり、同様に、ＤＢＶＯＬ１−２内のデータとＤＢＶＯＬ１−３内のデータとを同じすることができる。

このようなバッチ更新処理が行われている場合に、例えば、第一サーバ１５Ａと第一ストレージサブシステム４３Ａとの間の接続が、障害発生により切断されたとする。この場合、以下のような復旧処理が行われることにより、障害発生によってデータの整合性がとれなくなることが防止される。

図２２は、デュアルバッチ処理におけるデータ復旧処理の説明図である。

例えば、図２１に例示したバッチ更新処理が行われている場合に、第一サーバ１５Ａと第一ストレージサブシステム４３Ａとの間の接続が、障害発生により切断されたとすると、ＤＢＶＯＬ１−１の更新内容は、ＤＢＶＯＬ１−３の更新内容よりも古い更新内容である。また、ＤＢＶＯＬ２−３の更新内容は、ＤＢＶＯＬ２−１の更新内容よりも古い更新内容である。

まず、障害発生前のＶＯＬペアの関係を反転させる処理が行われる。具体的には、例えば、ストレージ制御装置４５Ａ及び４５Ｂの少なくとも一方により、リモートコピー管理テーブル８７Ａ及び８７Ｂの少なくとも一方のペア状態が、「反転」に更新される。また、例えば、ストレージ制御装置４５Ａ及び４５Ｂの各々により、ＶＯＬペア管理テーブル６８のペア状態が、「解除」から「反転」に更新される。これらの処理の少なくとも一つは、ストレージ制御装置４５Ａ及び４５Ｂのうちの少なくとも一方が、或るノードから反転命令を受けることにより実行することができる。この或るノードとは、例えば、同一のサイトに属するサーバ１５Ａ又は１５Ｂとすることができる。

ストレージ制御装置４５Ｂは、例えば、更新後のＶＯＬペア管理テーブル６８Ｂに従って、ＤＢＶＯＬ１−３内のデータをＤＢＶＯＬ１−２にコピーする。また、ストレージ制御装置４５Ｂは、更新後のリモートコピー管理テーブル８７Ｂに従って、ＤＢＶＯＬ１−２内のデータを、第一ストレージサブシステム４３Ａ内のＤＢＶＯＬ１−１にコピーする。

また、ストレージ制御装置４５Ｂは、更新後のリモートコピー管理テーブル８７Ｂに従って、ＤＢＶＯＬ２−１内のデータを、第一ストレージサブシステム４３Ａ内のＤＢＶＯＬ２−２にコピーする。第一ストレージ制御装置４５Ａは、更新後のＶＯＬペア管理テーブル６８Ａに従って、ＤＢＶＯＬ２−２内のデータをＤＢＶＯＬ２−３にコピーする。

この復旧処理により、障害発生によってデータの整合性がとれなくなることを防止することができる。

以上、本発明の好適な実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、各サイトに必ずしも複数のサーバを備える必要は無く、少なくとも一つのサーバ１５Ａ又は１５Ｂが存在すればよい。また、例えば、ＤＢアクセス部の待機用から現用への切り替えは、必ずしも、サイト間監視サーバが、切り替え先のＤＢアクセス部に起動命令を出して、待機用のＤＢアクセス部を起動させなくてもよい。具体的には、例えば、待機用のＤＢアクセス部をスタンバイ状態（例えばディスクからメモリにロードされた状態）にしておき、現用のリソースに関する情報が待機用に引き継がれた場合に、その待機用が現用に切り替わることができる。

図１は、本発明の一実施形態に係るデータ処理システムの構成例を示す。 図２は、本発明の一実施形態に係るデータ処理システムに備えられるサーバ及びストレージサブシステムの構成例を示す。 図３は、同期リモートコピー処理の流れの一例を示す。 図４は、非同期リモートコピー処理の流れの一例を示す。 図５Ａは、ＤＢ−ＶＯＬマッピングテーブルの構成例を示す。図５Ｂは、リモートコピー管理テーブルの構成例を示す。 図６Ａは、サイト間監視サーバ４９で管理されている情報の一例を示す。図６Ｂは、ＤＢアクセス部管理テーブルの構成例を示す。 図７は、或るサーバにおける各ＤＢアクセス部をサーバ監視部が監視する方法の一例を説明するための図である。 図８は、本発明の実施形態に係るデータ処理システムにおいて行われる一つの処理流れの一例の概要を示す。 図９は、第一ユーザ端末１１Ａが行う処理の流れの一例を示す。 図１０は、サイト間監視ソフトが行う処理の流れの一例を示す。 図１１は、サイト間監視ソフトが行うサーバに対する監視処理の流れの一例を示す。 図１２は、現用の第一サーバのＤＢアクセス部１Ａ−１がダウンした場合に行われるサイト内フェールオーバ処理の流れの一例を示す。 図１３Ａは、図１２のサイト内フェールオーバ処理の説明図である。図１３Ｂは、図１２のサイト内フェールオーバ処理の流れにおける監視結果テーブル１０３を示す。図１３Ｃは、図１２のサイト内フェールオーバ処理の流れにおけるＤＢアクセス部管理テーブル１０１の或る一レコードの更新結果を示す。図１３Ｄは、図１２のサイト内フェールオーバ処理の流れにおけるＤＢアクセス部管理テーブル１０１の別の一レコードの更新結果を示す。 図１４は、図１２のサイト内フェールオーバ処理の流れにおけるＤＢ−ＶＯＬマッピングテーブル６７Ａの更新結果を示す。 図１５は、第一サイト１Ａがダウンした場合に行われるサイト間フェールオーバ処理の流れの一例を示す。 図１６Ａは、図１５のサイト間フェールオーバ処理の説明図である。図１６Ｂは、図１６のサイト間フェールオーバ処理の流れにおける監視結果テーブル１０３の更新結果を示す。図１６Ｃは、図１５のサイト間フェールオーバ処理の流れにおけるＤＢアクセス部管理テーブル１０１Ｂの或る一レコードの更新結果を示す。図１６Ｄは、図１５のサイト間フェールオーバ処理の流れにおけるＤＢアクセス部管理テーブル１０１Ｂの別の一レコードの更新結果を示す。 図１７Ａは、図１２のサイト間フェールオーバ処理の流れにおけるＤＢ−ＶＯＬマッピングテーブル６７Ｂの更新結果を示す。図１７Ｂは、図１２のサイト間フェールオーバ処理の流れにおけるリモートコピー管理テーブル８７Ｂの更新結果を示す。 図１８は、計画切り替え処理の流れの一例を示す。 図１９は、デュアルバッチ処理を行う前に行われる通常処理（例えばオンライン処理）の説明図である。 図２０は、ＶＯＬペア管理テーブルの構成例を示す。 図２１は、デュアルバッチ処理におけるバッチ更新処理の説明図である。 図２２は、デュアルバッチ処理におけるデータ復旧処理の説明図である。

符号の説明

１Ａ…第一サイト、１Ｂ…第二サイト、１１Ａ…第一ユーザ端末、１１Ｂ…第二ユーザ端末、１５Ａ…現用の第一サーバ、１５Ｂ…現用の第二サーバ、１７Ａ…待機用の第一サーバ、１７Ｂ…待機用の第二サーバ、１９Ａ…第一サーバ監視部、１９Ｂ…第二サーバ監視部、２１…障害監視／通知部、２３…接続切替部、２５…サイト間監視ソフトウェア、４１Ａ…第一サーバ監視部、４１Ｂ…第二サーバ監視部、４９…サイト間監視サーバ

Claims (9)

1. 第一のサイトが、現用の第一ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に割り当てられたプライマリの第一記憶デバイスと、プライマリの第二記憶デバイスとの間でペアを構成するセカンダリの第二記憶デバイスとを備え、
   第二のサイトが、現用の第二ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に対応した待機用の第一ＤＢアクセス部と、前記現用の第二ＤＢアクセス部に割り当てられた前記プライマリの第二記憶デバイスと、前記プライマリの第一記憶デバイスとの間でペアを構成し、前記待機用のＤＢアクセス部に割り当てられたセカンダリの第一記憶デバイスとを備え、
   前記現用の第一ＤＢアクセス部、前記現用の第一ＤＢアクセス部を備える第一サーバ、及び前記第一サイトのうちの少なくとも一つである第一監視対象と、前記現用の第二ＤＢアクセス部、前記現用の第二ＤＢアクセス部を備える第二サーバ、及び前記第二サイトのうちの少なくとも一つである第二監視対象とを監視するサイト間監視サーバが備えられ、
   前記現用の第一ＤＢアクセス部が、前記プライマリの第一記憶デバイスにデータを書き込むステップと、
   前記プライマリの第一記憶デバイスに書かれたデータを、前記セカンダリの第一記憶デバイスにコピーするステップと、
   前記現用の第二ＤＢアクセス部が、前記プライマリの第二記憶デバイスにデータを書き込むステップと、
   前記プライマリの第二記憶デバイスに書かれたデータを、前記セカンダリの第二記憶デバイスにコピーするステップと、
   前記サイト間監視サーバが、前記現用の第一ＤＢアクセス部がダウンしたことを検出するステップと、
   前記サイト間監視サーバが、前記現用の第一ＤＢアクセス部のダウンの検出後、前記待機用の第一ＤＢアクセス部を現用の第一ＤＢアクセス部に切り替えるステップと
   を有するデータ処理方法。
2. 前記第一サイトが、前記現用の第一ＤＢアクセス部に対応した別の待機用の第一ＤＢアクセス部を有し、
   前記サイト間監視サーバが、前記現用の第一ＤＢアクセス部のダウンの検出後、前記別の待機用の第一ＤＢアクセス部を現用の第一ＤＢアクセス部に切り替えるステップ、
   を有する請求項１記載のデータ処理方法。
3. 前記サイト間監視サーバが、各ＤＢアクセス部と別の各ＤＢアクセス部との対応関係を表す情報であるＤＢアクセス部関係情報を所定の記憶域に備えるステップと、
   前記サイト間監視サーバが、前記所定の記憶域に記憶されているＤＢアクセス部関係情報を参照することにより、ダウンした現用のＤＢアクセス部に対応した待機用のＤＢアクセス部を特定するステップと
   を有し、前記切り替えるステップでは、前記特定された待機用のＤＢアクセス部を現用のＤＢアクセス部に切り替える、
   請求項１記載のデータ処理方法。
4. 前記サイト間監視サーバが、前記第一監視対象と前記第二監視対象とが正常か否かを表す監視結果情報を所定の記憶域に登録するステップと、
   前記サイト間監視サーバが、前記第一監視対象と前記第二監視対象との監視結果に応じて前記監視結果情報を更新するステップと、
   前記サイト間監視サーバが、前記第一監視対象にアクセス要求を発行するクライアント端末から、前記第一監視対象にアクセス可能か否かの問合せを受けるステップと、
   前記サイト間監視サーバが、前記所定の記憶域に登録されている監視結果情報を参照することにより、前記第一監視対象に前記クライアント端末がアクセス可能か否かを判断するステップと、
   前記サイト間監視サーバが、前記判断の結果を前記クライアント端末に送信するステップと、
   前記クライアント端末が、前記判断の結果がアクセス可能という判断結果であれば、前記第一監視対象にアクセス要求を出すステップと、
   を有する請求項１記載のデータ処理方法。
5. 前記第一サイトが、複数の現用の第一アクセス部と、複数のプライマリの第一記憶デバイスとを有し、
   前記第二サイトが、複数の待機用の第一ＤＢアクセス部と、前記複数のプライマリの第一記憶デバイスにそれぞれ対応した複数のセカンダリの第一記憶デバイスとを有し、
   現用の第一ＤＢアクセス部と、待機用のＤＢアクセス部とが、１対１で対応付けられ、且つ、現用の第一ＤＢアクセス部と、プライマリの第一記憶デバイスとも、１対１で対応付けられている、
   請求項１記載のデータ処理方法。
6. 前記第二サイトが、前記セカンダリの第一記憶デバイスとの間でペアを構成する更なるセカンダリの第一記憶デバイスを有し、
   前記第一サイトが、前記セカンダリの第二記憶デバイスとの間でペアを構成する更なるセカンダリの第二記憶デバイスとを有し、
   前記第二サイトにおいて、前記セカンダリの第一記憶デバイスに格納された第一のデータを前記更なるセカンダリの第一記憶デバイスにコピーするステップと、
   前記第一サイトにおいて、前記セカンダリの第二記憶デバイスに格納された第二のデータを前記更なるセカンダリの第二記憶デバイスにコピーするステップと、
   前記第二サイトにおいて、前記セカンダリの第一記憶デバイスと前記更なるセカンダリの第一記憶デバイスとのペアを解除するステップと、
   前記第一サイトにおいて、前記セカンダリの第一記憶デバイスと前記更なるセカンダリの第一記憶デバイスとのペアを解除するステップと、
   前記現用の第一ＤＢアクセス部が、前記プライマリの第一記憶デバイスと、前記更なるセカンダリの第二記憶デバイスとの両方に、新たな第一のデータを書き込むステップと、
   前記現用の第二ＤＢアクセス部が、前記プライマリの第二記憶デバイスと、前記更なるセカンダリの第一記憶デバイスとの両方に、新たな第二のデータを書き込むステップと、
   前記第一監視対象において障害が発生した後、その障害が回復した場合、前記第二サイトにおいて、前記セカンダリの第一記憶デバイスと前記更なるセカンダリの第一記憶デバイスとのペアを形成するステップと、
   前記第一サイトにおいて、前記セカンダリの第一記憶デバイスと前記更なるセカンダリの第一記憶デバイスとのペアを形成するステップと、
   前記第二サイトにおいて、前記更なるセカンダリの第一記憶デバイスに格納された前記新たな第二のデータを前記セカンダリの第一記憶デバイスにコピーするステップと、
   前記セカンダリの第一記憶デバイスに書かれた前記新たな第二のデータを前記第一サイトの前記プライマリの第一記憶デバイスに格納するステップと、
   前記プライマリの第二記憶デバイスに格納された前記新たな第二のデータを前記セカンダリの第二記憶デバイスにコピーするステップと、
   前記第一サイトにおいて、前記セカンダリの第二記憶デバイスにコピーされた前記新たな第二のデータを前記更なるセカンダリの第二記憶デバイスにコピーするステップと
   を有する請求項１記載のデータ処理方法。
7. 前記第一サイトが、前記現用の第二ＤＢアクセス部に対応した待機用の第二ＤＢアクセス部を更に備え、
   前記サイト間監視サーバが、前記現用の第二ＤＢアクセス部がダウンしたことを検出するステップと、
   前記サイト間監視サーバが、前記現用の第二ＤＢアクセス部のダウンの検出後、前記待機用の第二ＤＢアクセス部を現用の第二ＤＢアクセス部に切り替えるステップと
   を有する請求項１記載のデータ処理方法。
8. 第一のサイトに、現用の第一ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に割り当てられたプライマリの第一記憶デバイスと、現用の第二ＤＢアクセス部に対応した待機用の第二ＤＢアクセス部と、プライマリの第二記憶デバイスとの間でペアを構成するセカンダリの第二記憶デバイスとが備えられ、
   第二のサイトに、前記現用の第二ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に対応した待機用の第一ＤＢアクセス部と、前記現用の第二ＤＢアクセス部に割り当てられた前記プライマリの第二記憶デバイスと、前記プライマリの第一記憶デバイスとの間でペアを構成し、前記待機用のＤＢアクセス部に割り当てられたセカンダリの第一記憶デバイスとが備えられ、
   前記現用の第一ＤＢアクセス部が、前記プライマリの第一記憶デバイスにデータを書き込み、前記プライマリの第一記憶デバイスに書かれたデータが、前記セカンダリの第一記憶デバイスにコピーされ、
   前記現用の第二ＤＢアクセス部が、前記プライマリの第二記憶デバイスにデータを書き込み、前記プライマリの第二記憶デバイスに書かれたデータが、前記セカンダリの第二記憶デバイスにコピーされ、
   少なくとも一つのコンピュータプログラムを記憶する記憶域と、
   前記記憶域から前記少なくとも一つのコンピュータプログラムを読み込んで動作するプロセッサと
   を備え、
   前記プロセッサが、
   前記現用の第一ＤＢアクセス部、前記現用の第一ＤＢアクセス部を備える第一サーバ、及び前記第一サイトのうちの少なくとも一つである第一監視対象と、前記現用の第二ＤＢアクセス部、前記現用の第二ＤＢアクセス部を備える第二サーバ、及び前記第二サイトのうちの少なくとも一つである第二監視対象とを監視し、
   前記監視により、前記現用の第一ＤＢアクセス部がダウンしたことを検出した場合、前記待機用の第一ＤＢアクセス部を現用の第一ＤＢアクセス部に切り替え、
   前記監視により、前記現用の第二ＤＢアクセス部がダウンしたことを検出した場合、前記待機用の第二ＤＢアクセス部を現用の第二ＤＢアクセス部に切り替える、
   装置。
9. 第一のサイトに、現用の第一ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に割り当てられたプライマリの第一記憶デバイスと、現用の第二ＤＢアクセス部に対応した待機用の第二ＤＢアクセス部と、プライマリの第二記憶デバイスとの間でペアを構成するセカンダリの第二記憶デバイスとが備えられ、
   第二のサイトに、前記現用の第二ＤＢアクセス部と、前記現用の第一ＤＢアクセス部に対応した待機用の第一ＤＢアクセス部と、前記現用の第二ＤＢアクセス部に割り当てられた前記プライマリの第二記憶デバイスと、前記プライマリの第一記憶デバイスとの間でペアを構成し、前記待機用のＤＢアクセス部に割り当てられたセカンダリの第一記憶デバイスとが備えられ、
   前記現用の第一ＤＢアクセス部が、前記プライマリの第一記憶デバイスにデータを書き込み、前記プライマリの第一記憶デバイスに書かれたデータが、前記セカンダリの第一記憶デバイスにコピーされ、
   前記現用の第二ＤＢアクセス部が、前記プライマリの第二記憶デバイスにデータを書き込み、前記プライマリの第二記憶デバイスに書かれたデータが、前記セカンダリの第二記憶デバイスにコピーされ、
   前記現用の第一ＤＢアクセス部、前記現用の第一ＤＢアクセス部を備える第一サーバ、及び前記第一サイトのうちの少なくとも一つである第一監視対象と、前記現用の第二ＤＢアクセス部、前記現用の第二ＤＢアクセス部を備える第二サーバ、及び前記第二サイトのうちの少なくとも一つである第二監視対象とを監視するステップと、
   前記監視により、前記現用の第一ＤＢアクセス部がダウンしたことを検出した場合、前記待機用の第一ＤＢアクセス部を現用の第一ＤＢアクセス部に切り替えるステップと、
   前記監視により、前記現用の第二ＤＢアクセス部がダウンしたことを検出した場合、前記待機用の第二ＤＢアクセス部を現用の第二ＤＢアクセス部に切り替えるステップと
   をコンピュータに実行させるためのコンピュータ読み取り可能なコンピュータプログラム。
   

Images