JP4283576B2 - トランザクション同期方法、データベースシステム及びデータベース装置 - Google Patents
トランザクション同期方法、データベースシステム及びデータベース装置 Download PDFInfo
- Publication number
- JP4283576B2 JP4283576B2 JP2003087773A JP2003087773A JP4283576B2 JP 4283576 B2 JP4283576 B2 JP 4283576B2 JP 2003087773 A JP2003087773 A JP 2003087773A JP 2003087773 A JP2003087773 A JP 2003087773A JP 4283576 B2 JP4283576 B2 JP 4283576B2
- Authority
- JP
- Japan
- Prior art keywords
- query
- computer system
- transaction
- server
- transferred
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1474—Saving, restoring, recovering or retrying in transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/953—Organization of data
- Y10S707/959—Network
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99955—Archiving or backup
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明が属する技術分野】
本発明は、データベースシステムに関し、特に、データベースシステム間のトランザクションの転送制御に関する。
【０００２】
【従来の技術】
ビジネスにおいて、ＩＴシステムの重要性はますます高まっている。例えば、金融業界では、ＩＴシステムが停止する障害によって、数千億ドルの損失が生じるといわれている。よって、計算機システムを、正サイトと副サイトとに二重化して、正サイトに障害が発生した時には副サイト系に切り替えて、サービスを継続させるためのＨＡ技術（High Availability技術）が重要となっている。
【０００３】
システム障害の原因には、システムエラー、人為的操作ミス、停電など様々であるが、大規模災害においてもサービスやＩＴシステムの復旧を迅速に行うＤ／Ｒ（Disaster Recover）技術が注目されている。Ｄ／Ｒ技術では、正サイトと副サイトとに二重化された計算機システム間でデータのコピーを行うことにより、データ保護を図っており、データ保護、すなわち、データ欠損がないことが最も重要な要件である。さらに、大規模災害に対応するために、副サイトをより遠隔地に構築したいという要求が高まっている。
【０００４】
従来のＤ／Ｒシステムの構成を図１６に示す。
【０００５】
従来のＤ／Ｒシステム (Disaster Recover system）は、正サイト１００と遠隔地にある副サイト１１０とから構成されている。正サイト１００ではデータの記録、検索等の業務を行う。一方、副サイト１１０は正サイト１００と同一の内容を記憶しており、正サイト１００のバックアップサイトとしての役割を果たす。
【０００６】
各サイト１００、１１０は、ＤＢＭＳ１０３を含むサーバ１０１及びストレージ（ＤＢ）１０２によって構成され、両サイト１００、１１０は、サーバ間ネットワーク１２２及び／又はストレージ間ネットワーク１２１で接続される。
【０００７】
正サイト１００は、クライアント１３０（ＵＡＰ（user application））から入力を受け付け、結果をＤＢ（Database）１０２に反映する。ＵＡＰからの入力は、通常、トランザクションとして認識される。ここで、トランザクションは、ＤＢＭＳ（database management system）に対する標準言語であるＳＱＬを用いた複数の問い合わせから構成される。問い合わせは、挿入（Insert）、更新（Update）、コミット（Commit）などいくつかの種類がある。トランザクションに含まれる問い合わせがコミットないで場合は、問い合わせの結果は、正サイト１００のサーバ１０１のＤＢＭＳ１０３内のバッファに記録されるだけである。そしてコミットが実行されて初めて、一連の問い合わせの結果がストレージ１０２に反映され、トランザクションが確定する。正サイト１００は、トランザクション及びトランザクション処理結果であるデータ（ＤＢＭＳのテーブル等）を、何らかのタイミングで副サイト１０１に転送しておく。障害が発生した場合は、系を切り替え、バックアップサイトであった副サイト１０１が業務を引き継いで実行する。
【０００８】
従来より、サイト間のトランザクションの転送には、サーバ間ネットワーク１２１を用いたコピーが行われてきたが、近年は、ストレージ間ネットワーク１２２によるコピーも用いられるようになっている。これは、コピー時にサーバへの負荷がないこと、ストレージはサーバより信頼性が高いためである（例えば、非特許文献１参照。）。
【０００９】
このコピーには、サーバ間、ストレージ間に関わらず、同期コピーと非同期コピーとがある。
【００１０】
正サイト１００から副サイト１１０への同期コピーでは、正サイトのサーバ１０１が同期コピーを指示すると、データは正サイトに接続されるストレージ（正）１０２のディスクキャッシュに書き込まれる。続いて、ストレージ（正）１０２は、副サイト１１０のストレージ（副）１０２のディスクキャッシュにコピーを行う。さらに、ストレージ（正）１０２は、ストレージ（副）１０２からのデータ受信の応答を受けると、転送元のサーバ１０１へ同期コピー完了の応答を返す。コミットに同期して副サイト１１０へ同期コピーを行うことによって、データ欠損がないデータコピーが実現される。しかし、同期コピーでは、ストレージ（副）１０２からの応答を待つ遅延が生じるため、サイト間距離が長距離となる場合には、この遅延が問題となる。
【００１１】
一方、非同期コピーを用いた場合は、ストレージ（正）１０２のディスクキャッシュにデータが書き込まれた時点で、転送元のサーバ１０１へ応答が返され、ストレージ（副）１０２へのコピーは別のタイミングで行われる。コピーの遅延はないが、転送元サーバ１０１に応答が返った時点で、データが副サイト１１０にコピーされていることが保障されず、データ欠損が生じる可能性がある。
【００１２】
この非同期コピーと同期コピーとを組み合わせた中間的な方法として、非同期コピーの完了確認のためのコマンドを有し、同期が不要な場合は非同期コピーを行うが、同期が必要になった時点で該コマンドを実行し、非同期コピー完了が確認されるまで、以降の処理を中断することにより、データ欠損がないことを実現する方法が提案されている（例えば、特許文献１参照。）。
【００１３】
Ｄ／Ｒシステムでは、障害発生時に副サイト１１０において、ＤＢの整合性確認などの回復処理を行った後、副サイト１１０で業務を継続する。まず、非同期コピーを用いた場合は、データ欠損が生じるため、完全な回復を行うことができない。一方、同期コピーを用いた場合であっても、障害発見後に初めて回復処理を開始するような場合は、多大な回復時間を要する可能性がある。例えば、長期間隔で行われるフルバックアップのコピーと、フルバックアップからの増分バックアップのコピーを利用した回復が行う場合があげられる。すなわち、そのような回復処理では、最初にフルバックアップをリストアした後、増分バックアップのコピーを順次適用していくため、バックアップのサイズ、個数によっては、回復処理に多大な時間を要する。
【００１４】
【特許文献１】
特開２００２−４９５１７号公報
【非特許文献１】
”EMC Symmetrix Remote Data Facility”、［online］、インターネット＜ＵＲＬ：http://japan.emc.com/local/ja/JP/products/product_pdfs/srdf/srdf.pdf＞
【００１５】
【発明が解決しようとする課題】
以上説明した従来のＤ／Ｒシステムでは、以下の問題点がある。
【００１６】
トランザクション欠損なしを実現しようとした場合、同期コピーを用いる方法が一般的であるが、特にサイト間距離が長い場合は、同期コピーの完了待ちによる遅延が問題となる。非同期コピーを用いた場合は、遅延は生じないが、トランザクションが副サイトへコピーされたことを保障できなくなる。すなわちトランザクション欠損なしが実現できない。
【００１７】
また、非同期コピーを用いた場合は、トランザクション欠損が生じることがあり、障害が発生した場合に、完全な回復は行えない。同期コピーを用いた場合であっても、障害回復後に初めて回復処理をスタートし、フルバックアップに対し更新差分（増分バックアップ）を適用していく回復方法では、多大な処理時間を要するため、迅速に業務を回復することができない。
【００１８】
よって、サイト間距離が長距離である場合に、トランザクション処理性能への影響を最小限にしながらトランザクション欠損なしのＤ／Ｒシステムを実現することが望まれている。
【００１９】
また、サイト間距離が長距離であるＤ／Ｒシステムにおいて、障害発生後の迅速な回復を実現することが望まれている。
【００２０】
【課題を解決するための手段】
本発明のトランザクション同期方法は、計算装置及びストレージ装置を有する第１情報処理装置と、計算装置及びストレージ装置を有する第２情報処理装置との間で、１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、前記第１情報処理装置は、クエリを実行する際に、該クエリが前記第２情報処理装置へ転送されているか否かを判定し、該クエリが既に転送されている場合は、該クエリを実行し、該クエリが未転送である場合は、該クエリが前記ストレージ装置の記憶内容への反映を伴うコミット処理であるときには、受け付けたクエリのうち未転送のクエリを前記第２情報処理装置に一括して転送（例えば、同期コピー）する。
【００２１】
また、クエリを実行する際に未転送のクエリを一括して転送（例えば、同期コピー）する第１の転送方法に加え、受け付けたクエリを所定のタイミングで監視し、未転送のクエリがある場合は、前記未転送のクエリを、前記第２情報処理装置に一括して転送（例えば、同期コピー又は非同期コピー）する第２の転送方法によってクエリを転送する。
【００２２】
また、前記第１情報処理装置は、前記コミット処理の実行情報が、前記第２情報処理装置に転送されたか否かを管理し、前記コミット処理の実行後に、該コミット処理の実行情報が前記第２情報処理装置に転送されていない場合は、受け付けたクエリのうち、前記実行情報が未転送のクエリに関する実行情報を、前記第２情報処理装置に一括して転送（例えば、非同期コピー）する。
【００２３】
また、計算装置及びストレージ装置を有する第１情報処理装置と、計算装置及びストレージ装置を有する第２情報処理装置との間で、１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、前記第１情報処理装置は、コミット処理を実行する際に、該コミット処理が未転送である場合は、受け付けたクエリのうち未転送のクエリを、前記第２情報処理装置に一括して転送し、前記第２情報処理装置は、前記第１情報処理装置から転送されたクエリより前に転送されたクエリは、前記第１情報処理装置で既に実行されたと判定し、該判定されたクエリを実行する。
【００２４】
また、計算装置及びストレージ装置を有する第１情報処理装置と、計算装置及びストレージ装置を有する第２情報処理装置との間で、１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、前記第２情報処理装置は、前記第１情報処理装置から転送されたクエリを受信し、前記転送されたクエリの範囲を記録し、当該の転送範囲及び直前の転送範囲に含まれるクエリを調査し、該直前の転送範囲内で、ストレージ装置の記憶内容へ反映を伴うコミット処理が行われていないトランザクションに関する情報を回復用の情報として記録する。
【００２５】
また、計算装置及びストレージ装置を有する第１情報処理装置と、計算装置及びストレージ装置を有する第２情報処理装置との間で、１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、前記第２情報処理装置は、前記第１情報処理装置から転送されたクエリを受信して、障害回復用の情報を生成し、前記第１情報処理装置の障害を検知すると、前記第１情報処理装置からの直前の転送範囲内で、ストレージ装置の記憶内容への反映を伴うコミット処理が行われていないトランザクションについては、当該トランザクションの開始前の状態に戻すロールバック処理の対象として、前記回復用情報から削除し、前記第１情報処理装置からの直前の転送範囲内で、ストレージ装置の記憶内容への反映が行われているトランザクションは、前記回復用情報に記憶する。
【００２６】
【発明の作用及び効果】
本発明のトランザクション同期方法では、第１情報処理装置は、クエリを実行する際に、該クエリが第２情報処理装置へ転送されているか否かを判定し、該クエリが既に転送されている場合は、該クエリを実行し、該クエリが未転送である場合は、該クエリが前記ストレージ装置の記憶内容への反映を伴うコミット処理であるときには、受け付けたクエリのうち未転送のクエリを前記第２情報処理装置に一括して転送するので、コミット処理の実行前に必ず第２情報処理装置側へのクエリの転送が完了していることが保障されているため、遠距離であってもトランザクション処理のスループット性能への影響を抑制しつつ、トランザクション欠損のないＤ／Ｒシステムを実現することができる。
【００２７】
【発明の実施の形態】
図１は、本発明の実施の形態のＤ／Ｒシステムのシステム構成図である。
【００２８】
本実施の形態のＤ／Ｒシステム (Disaster Recover system）は、正サイト１００と遠隔地にある副サイト１１０とから構成されている。正サイト１００では、データの記録、検索等の業務を行う。一方、副サイト１１０は、正サイト１００と同一の内容を記憶しており、正サイト１００のバックアップサイトとしての役割を果たす。
【００２９】
正サイト１００は、ＤＢＭＳ１０３を含むサーバ１０１及びストレージ（ＤＢ）３１１によって構成され、副サイト１１０は、ＤＢＭＳ１０３を含むサーバ１０１及びストレージ（ＤＢ）３２３によって構成される。また、両サイト１００、１１０は、サーバ間ネットワーク１２２及び／又はストレージ間ネットワーク１２１で接続される。
【００３０】
正サイト１００は、クライアント１３０（ＵＡＰ（ｕｓｅｒａｐｐｌｉｃａｔｉｏｎ））から入力を受け付け、結果をＤＢ（Ｄａｔａｂａｓｅ）３１１に反映する。ＵＡＰからの入力は、通常、トランザクションとして認識される。ここで、トランザクションは、ＤＢＭＳ（ｄａｔａｂａｓｅ ｍａｎａｇｅｍｅｎｔｓｙｓｔｅｍ）に対する標準言語であるＳＱＬを用いた複数の問い合わせから構成される。問い合わせは、挿入（Ｉｎｓｅｒｔ）、更新（Ｕｐｄａｔｅ）、コミット（Ｃｏｍｍｉｔ）などいくつかの種類がある。トランザクションに含まれる問い合わせがコミットないで場合は、問い合わせの結果は、正サイト１００のサーバ１０１のＤＢＭＳ１０３内のバッファに記録されるだけである。そしてコミットが実行されて初めて、一連の問い合わせの結果がストレージ３１１に反映され、トランザクションが確定する。正サイト１００は、トランザクション及びトランザクション処理結果であるデータ（ＤＢＭＳのテーブル等）を、何らかのタイミングで副サイト１１０に転送しておく。障害が発生した場合は、系を切り替え、バックアップサイトであった副サイト１１０が業務を引き継いで実行する。
【００３１】
ＤＢＭＳ１０３は、トランザクション管理部（Ｔｒ管理部）２００を有し、トランザクション管理部２００が、正サイト１００と副サイトとの間１１０でトランザクションを転送する。なお、トランザクション管理部２００は、ＤＢＭＳ１０３に備わってなくてもよく、ＴＰモニタなどのソフトウェアによってトランザクション管理部２００が、正サイト１００、副サイト１１０間でトランザクションを管理するようにしてもよい。
【００３２】
図２は、本発明の第１の実施の形態のトランザクション管理部の構成図である。
【００３３】
正サイトのトランザクション管理部３００は、トランザクション受付部（Ｔｒ受付部）３０１、トランザクション同期化・実行部（Ｔｒ同期化・実行部）３０２、トランザクションキュー３１０の３つのソフトウェアコンポーネントより構成される。
【００３４】
クライアント（ＵＡＰ）から入力されたトランザクションは、一度、トランザクションキュー３１０に記録された後に実行される。トランザクションキュー３１０では、トランザクションの内容（トランザクションを構成するクエリ）だけでなく、トランザクションの状態（副サイトへのコピーの有無、実行の有無）も管理する。
【００３５】
トランザクション受付部３０１は、入力されたトランザクションを受け付け、トランザクションキュー３１０へ登録する。
【００３６】
トランザクション同期化・実行部３０２は、トランザクションの実行及びトランザクションのコピーをする。すなわち、トランザクション同期化・実行部３０２は、トランザクションを構成するクエリをトランザクションキュー３１０から取り出すと、該クエリを実行する。また、該クエリの状態に応じて、クエリを副サイトのトランザクション管理部３２０へ転送して、トランザクションをコピーする。
【００３７】
すなわち、図５で詳述するように、トランザクションキュー３１０から取り出したクエリが、副サイトのトランザクション管理部３２０に既にコピーされていたら、クエリを実行する。このクエリがコミットである場合は、該クエリに関わるトランザクションが確定されたことになり、トランザクションの実行結果がストレージ３１１に反映される。クエリがコミットでない場合は、トランザクションの実行途中の結果がＤＢＭＳ１０３中のＤＢバッファに記録される。
【００３８】
一方、トランザクションキュー３１０から取り出したクエリが、副サイトのトランザクション管理部３２０にコピーされていなかったら、トランザクション同期化・実行部３０２は、副サイトへコピーが必要か否かを判定する。該クエリがコミットでない場合は、コピーを行わず該クエリを直ちに実行する。一方、該クエリがコミットである場合は、副サイトのトランザクション管理部３２０に対する同期コピーを実行する。ただし、同期コピーの際には、該クエリだけでなく、トランザクションキュー３１０に記録されている未コピーであるトランザクション情報を一括して同期コピーし、その後にクエリを実行する。従って、トランザクション同期化・実行部３０２により、コミット前に、必ず該コミットに関連するトランザクション情報が副サイトのトランザクション管理部３２０に転送され、コピーされるため、トランザクション欠損が生じないことが保障される。
【００３９】
副サイトのトランザクション管理部３２０は、トランザクション受信・実行部３２１、障害回復部３４０、トランザクションキュー３２２及び回復テーブル３４１によって構成される。トランザクション受信・実行部３２１は、正サイト１００からコピーされたトランザクションを受信し、コミットが確定したトランザクションを実行する。また、正サイト１００で障害が発生した場合は、副サイト１１０では、障害回復処理を実行し、正サイト１００で行っていた業務を引き継いで行う。
【００４０】
トランザクション受信・実行部３２１は、トランザクション受信部３３０とトランザクション実行部３３１によって構成される。トランザクション受信部３３０は、正サイトのトランザクション同期化・実行部３０２と通信を行い、正サイト１００から送信されたトランザクションを受信し、トランザクションキュー３２２へ保存する。トランザクション実行部３３１は、正サイト１００でコミットが実行されたトランザクションを実行する。
【００４１】
このとき、トランザクション受信部３３０は、トランザクション情報のコピー状態（最新の一括同期コピーで送られたかどうか）を管理する。トランザクション実行部は、コピー状態により、トランザクションが正サイトでコミットされているか否かを判断する。既にコミットが実行されていると判断される場合は、該トランザクションのコミットを副サイトでも実行する。一方、正サイトで未だコミットが実行されていないと判断される場合には、必要なトランザクション情報を回復テーブル３４１に保存する。
【００４２】
トランザクション受信・実行部３２１は、コピーが実行される度に回復テーブル３４１にコピーが実行されたトランザクション情報を更新する。回復テーブル３４１へ記録する情報は、正サイト１００でのコミットの実行が確定できないトランザクションの情報である。例えば、コミットそのものが投入されていない（コミットを投入される前に、何らかの障害が発生した）場合、及び、コミットは投入されているが、コミットを実行したかどうかが判断できない場合が、コミットが実行されていないトランザクションとして考えられる。
【００４３】
本実施の形態では、コミットの実行前に該トランザクションに関する情報をコピーしているため、副サイト１１０では、そのコピーを受信した時に、正サイト１００においてコミットが投入されたことは分かる。しかし、副サイト１１０では、該コミットが確かに実行されたかを判定することはできない。副サイト１１０は、該コミットを含むコピーの次のコピーが行われて初めて、該コミットが実行されたことがわかる。すなわち、上述した一括コピーの手順では、正サイト１００は、副サイト１１０へトランザクションをコピーした後、該コピーに係るトランザクションを実行する。そして、該コピーに含まれる全てのトランザクションが実行された後、次のコピーを行うので、コピーが行われた（副サイト１１０でクエリを受信した）ときに、該コピーに含まれるトランザクションは正サイトで全て実行されていると判定できるのである。
【００４４】
障害回復部３４０は、正サイト１００で障害が発生した際に、副サイト１１０で業務を引き継ぐために必要な障害回復処理を行う。障害回復部３４０は、受信したトランザクションについて、正サイト１００においてコミットが投入されたが、コミットが実行されたかを判定できないグレートランザクションを調査し、グレーなトランザクションに関係するデータへのアクセスを制限して、限定的に業務を再開する。同時に、グレーなトランザクションを手動回復する。手動回復が完了した時点で、アクセス制限を解除し、完全に業務を再開する。
【００４５】
以上説明した、正サイト１００から副サイト１１０へのトランザクションのコピーは、同期コピーを用いるとよいが、同期コピーではなく非同期コピーを用いるようにしてもよい。
【００４６】
図３は、本発明の第１の実施の形態の正サイトのトランザクションキュー３１０の構成例を示す説明図である。
【００４７】
トランザクションは一つ又は複数のクエリより構成されるため、クエリ毎にクエリに関する属性をテーブル５００に記録する。テーブルには属性として、トランザクションに一意に与えられるトランザクションＩＤ、クエリの内容、クエリがコピーされたかどうかを表すコピーフラグ、クエリが実行されたかどうかを表す実行フラグが記録される。このフラグは”ＯＮ”、”ＯＦＦ”、”ｎｕｌｌ”の３種の値を取り得る。
【００４８】
また、テーブル５００には、３つのポインタを用意する。第１のポインタ（コピーポインタ：ＰＩ）５０１は、最後にコピーされたクエリを指す。つまり、コピーポインタＰＩの次が、コピーされていないクエリの内、最も古いのクエリである。第２のポインタ（最後尾ポインタ：ＬＩ）５０２は、最後にトランザクションキューに入力されたクエリ（最新のクエリ）を指す。第３のポインタ（実行ポインタ：ＥＩ）５０３は、これから実行処理手順を決定する対象のクエリ（未実行クエリのうち、最も古いクエリ）を指す。
【００４９】
図４は、本発明の第１の実施の形態のトランザクション受付部の処理のフローチャートである。
【００５０】
正サイトのトランザクション受付部３０１は、外部よりトランザクション（トランザクションを構成するクエリ）を受付け、登録可能であれば、受け付けたトランザクションをトランザクションキュー３１０に登録する。登録が行われた場合は、ＬＩポインタが更新される。
【００５１】
まず、各ポインタ（ＰＩ、ＥＩ、ＬＩ）を初期化する（ステップ６０１）。
【００５２】
次に、テーブル５００の内容を消去して、トランザクションキュー３１０を初期化する。フラグの初期化時には、フラグの値は”ｎｕｌｌ”に設定される（ステップ６０２）。
【００５３】
次に、クライアント（ＵＡＰ）からクエリの入力を監視して、クエリの入力があるか否かを判定する（ステップ６０４）。
【００５４】
クエリの入力がある場合には、クエリが登録可能か否かを判定する（ステップ６０６）。すなわち、既にクエリの情報が登録されているが、実行フラグ、コピーフラグとも”ＯＮ”であれば、コピー、実行共に完了しているので、該領域にクエリを上書きしてもよい。また、ＬＩ＋１が指す領域の実行フラグ、コピーフラグとも”ｎｕｌｌ”である場合には、トランザクションキューに未登録の空きがある。
【００５５】
クエリの新規登録が不可能な場合は、クライアント（ＵＡＰ）に対しクエリの受付ができないことを通知し（ステップ６０７）、ステップ６０４へ戻る。
【００５６】
一方、クエリの新規登録が可能な場合は、ＬＩ＋１が指す領域にクエリが属するトランザクションのＩＤ、クエリの内容をセットする（ステップ６０９）。コピーフラグ、実行フラグは共にＯＦＦにセットされる。続いて、ステップ６１０において、ＬＩポインタを更新（ＬＩ＝ＬＩ＋１にインクリメント）し、ステップ６０４へ戻る。
【００５７】
図５は、本発明の第１の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【００５８】
正サイトのトランザクション同期化・実行部３０２では、コピー済みのクエリについては、クエリを実行する。一方、未コピークエリに関しては、クエリがコミットでなければ実行し、クエリがコミットである場合は、キュー内の未コピークエリを一括同期コピーする。
【００５９】
まず、実行ポインタＥＩが指す実行処理手順判定の対象のクエリが未実行であるかを判定する（ステップ７０２）。すなわち、ＥＩが指すクエリが未実行であれば、実行すべきクエリがあることが分かる。
【００６０】
実行すべきクエリがない場合は、実行ポインタＥＩの更新（インクリメント）の可否（すなわち、新たなクエリが入力されたか）を判定する（ステップ７０４）。ＥＩが更新可能なら、ＥＩを更新し（ステップ７０６）、ステップ７０９へ進む。一方、ＥＩが更新不可能なら、ステップ７０４へ戻る。
【００６１】
ステップ７０２において、ＥＩポインタが指すクエリが未実行であると判定されると、該クエリがコピー済みであるか否かを判定する（ステップ７０９）。
【００６２】
ＥＩポインタが指すクエリが未コピーである場合は、該クエリがコミットであるか否かを判定する（ステップ７１１）。該クエリがコミットでない場合は、該クエリを実行し、該クエリの実行フラグをＯＮにする（ステップ７１２）。続いて、ＥＩの更新可否を判定し（ステップ７１３）、ＥＩが更新可能なら、ＥＩを更新し（ステップ７１５）、ステップ７１１へ戻る。一方、ＥＩが更新不可能なら、ステップ７０２へ戻る。
【００６３】
ステップ７１１において、クエリがコミットであると判定されると、ＬＩポインタの値をレジスタＬ０（図示せず）へ退避する（ステップ７１７）。続いて、キュー内の未コピークエリ（ＰＩ＋１からＬ０までのクエリ）を全て、一括同期コピーする（ステップ７１８）。同期コピーの完了後、コピーしたクエリのコピーフラグを全てＯＮにし、ＰＩポインタをＬ０に更新する（ステップ７１９）。そして、ＥＩポインタが指すクエリを実行し、該クエリの実行フラグをＯＮにする（ステップ７２０において）。
【００６４】
続いて、ＥＩの更新可否を判定し（ステップ７２１）、ＥＩが更新可能なら、ＥＩを更新し（ステップ７２３）、ステップ７０９へ戻る。一方、ＥＩが更新不可能なら、ステップ７０２へ戻る。
【００６５】
ステップ７０９において、クエリがコピー済みであると判定されると、ステップ７２５において、該クエリを実行後、実行フラグをＯＮにする。続いて、ステップ７２５において、ＥＩの更新可否を判定し（ステップ７２６）、ＥＩが更新可能なら、ＥＩを更新し（ステップ７２８）、ステップ７０８へ戻る。一方、ＥＩが更新不可能なら、ステップ７０１へ戻る。
【００６６】
図６は、第１の実施の形態のコピー時の正サイト１００と副サイト１１０との間のトランザクションキューの動作例を示す説明図である。
【００６７】
図６（ａ）は、２番目のクエリ（ＥＩポインタ８０４が指すクエリ）を実行するときの、正サイトのトランザクションキュー３１０、及び、副サイトのトランザクションキュー３２２の状態を表す。
【００６８】
ＥＩポインタ８０４が指すクエリは、未実行、未コピー、かつ、コミット（Ｃ）であるため（図５のステップ７１１で”ｙ”）、実行前に、キュー内の未コピークエリ（ウィンドウ８４０に含まれる、ＰＩポインタ８０２の次からＬＩポインタ８０５までのクエリ）は、副サイト１１０へ一括同期コピーされる（図５のステップ７１８）。そして、一括コピーが完了すると、正サイト及び副サイトのトランザクションキュー３１０、３２２は、図６（ａ）に示す状態となる。
【００６９】
その後、正サイトのトランザクションキュー３１０では、コピー済みクエリの最後尾を表すＰＩポインタは、ＰＩポインタが８０２の位置から８０３の位置へ更新される。続いて、コピーが完了したクエリのコピーフラグがＯＮにされ（図５のステップ７１９）、最後に、正サイト１００でＥＩポインタ８０４が指すクエリ（コミット）が実行され、該クエリの実行フラグがＯＮにされる（図５のステップ７２０）。
【００７０】
図６（ｂ）は、ウィンドウ８４０内のクエリのコピーを行ってから次のコピーが行われるまでのトランザクションキュー３１０、３２２の動作を表す。
【００７１】
正サイト１００では、任意のタイミングで、クエリが投入されており、図６（ｂ）に示す状態では、新たに４つのクエリが投入され、ＬＩポインタが８１５の位置へ更新されている。
【００７２】
ここで、コピー済みのクエリに対してはクエリの種類にかかわらず実行が可能なため、ウィンドウ８４０内のクエリ（トランザクションキュー３１０内の３番目、４番目のクエリ）は、副サイト１１０との連携を考慮することなく、正サイト１００で実行される。また、ウィンドウ８４１の外であっても、クエリがコミット以外であれば、副サイト１１０との連携を考慮することなく実行することができる。そのため、トランザクションキュー３１０内の５番目のクエリ（Ｕ：アップデイト）は、次のコピーを行う前に実行される。ただし、クエリがコミットの場合は、コピー後に実行されることになる。
【００７３】
図６（ｃ）は、６番目のクエリ（ＥＩポインタ８２４が指すクエリ）を実行するときのトランザクションキュー３１０、３２２の動作例を表す。
【００７４】
該６番目のクエリは、未実行、未コピー、かつ、コミットであるため（図５のステップ７１１で”ｙ”）、クエリの実行前に、キュー内の未コピークエリ（ウィンドウ８５０に含まれる、ＰＩポインタ８０３の次からＬＩポインタ８１５までのクエリ）は、副サイト１１０へ一括同期コピーされる（図５のステップ７１８）。そして、一括コピーが完了すると、正サイト及び副サイトのトランザクションキュー３１０、３２２は、図６（ｃ）に示す状態となる。
【００７５】
その後、正サイトのトランザクションキュー３１０では、ＰＩポインタをＰＩポインタは８０３の位置から８２３の位置へ更新され、コピーしたクエリのコピーフラグがＯＮにされ（図５のステップ７１９）、最後に、正サイト１００ＥＩ８２４ポインタが指すクエリが実行され、実行フラグがＯＮにされる（図５のステップ７２０）。
【００７６】
図６（ｄ）は、２回目のコピーを行ってから、３回目のコピーが行われるまでの間のトランザクションキュー３１０、３２０の動作を表す。
【００７７】
正サイトのトランザクションキュー３１０では、ウィンドウ８５０内のクエリはコピー済みであり、その種類に関わらず、副サイト１１０との連携を考慮することなく実行可能なため、７番目のクエリが実行されている。
【００７８】
次に、副サイト１１０における処理について説明する。
【００７９】
図７は、本発明の第１の実施の形態のトランザクション受信部３３０の処理のフローチャートである。
【００８０】
副サイトのトランザクション受信部３３０では、正サイトのトランザクション同期化・実行部３０２が送信したトランザクション情報を受信し、トランザクションのコピー状態を管理する。具体的には、トランザクションのコピー状態として、最新のコピーの範囲であるコピーウィンドウ（Ｗｎ）と、Ｗｎの直前のコピー範囲であるコピーウィンドウ（Ｗｐ）とを管理する。
【００８１】
まず、ランザクション受信部３３０では、Ｗｎ、Ｗｐを初期化する（ステップ９０１）。次に、正サイト１００からコピーされるクエリの転送を待つ（ステップ９０３）。コピーがある場合には、転送されたクエリを受付け、Ｗｎ、Ｗｐを更新する（ステップ９０５）。
【００８２】
図８は、本発明の第１の実施の形態のトランザクション実行部３３１の処理のフローチャートである。
【００８３】
トランザクション実行部では、コピーが行われる度に、Ｗｐ内のクエリを実行する。このとき、正サイト１００でコミットが実行されたか否かを判断し、判断できない場合には、回復テーブルに情報を記録する。
【００８４】
まず、直前のコピーウィンドウＷｐ内に未調査のクエリがあるか否かを判定する（ステップ９１１）。未調査クエリがある場合には、該クエリを取り出し（ステップ９１４）、該クエリを実行する（ステップ９１５）。そして、該クエリがコミットであるか否かを判定し（ステップ９１６）、コミットでない場合には、該クエリが属するトランザクションの情報が回復テーブルに登録されているか否かを判定する（ステップ９１７）。そして、該クエリが属するトランザクションの情報が回復テーブルに登録されていない場合は、該クエリが属するトランザクションの情報を登録する（ステップ９１８）。ここで、回復テーブルには、少なくとも、トランザクションのＩＤが登録される。
【００８５】
一方、ステップ９１７において、該クエリが属するトランザクションの情報が回復テーブルに登録されていると判定された場合は、トランザクション情報（クエリの内容やコピーの時間等）を回復テーブルに追加する（ステップ９２０）。なお、トランザクションのＩＤのみを登録する場合には、ステップ９２０の処理は不要である。
【００８６】
ステップ９１６において、クエリがコミットであると判定された場合は、該コミットが正サイト１００側で実行されたことがわかる。なぜなら、Ｗｐ内のクエリは最新のコピーによるものではなく、正サイト１００が、前回コピーしたクエリを全て実行した後に、クエリのコピーを行うからである。従って、該コミットが属する該トランザクション情報を、回復テーブル３４１から削除する（ステップ９１５）。
【００８７】
このようにトランザクション実行部３３１の処理によって、Ｗｐ内のクエリは全て実行される。また、正サイト１００でコミットが実行されたかどうか判断できないトランザクションに関する情報は、回復テーブル３４１に記録される。
【００８８】
図９は、本発明の第１の実施の形態のコピー時の副サイトのトランザクションキューの動作例を示す説明図であり、図９（ａ）及び（ｂ）が通常運用時の、図９（ｃ）が障害発生時の、トランザクションキュー３２２及び回復テーブル３４１の状態を示す。
【００８９】
回復テーブル３４１には、トランザクション毎に、トランザクションＩＤ、フラグ及びトランザクションの内容（クエリ）が記録される。特に重要なのは、トランザクションＩＤとフラグである。回復テーブルには、コミットが実行されていないトランザクションの情報が含まれているが、そこには、コミットそのものが投入されていない場合と、コミットは投入されているが該コミットの実行までは判断できない（グレー）場合の二つのケースがある。フラグは、この２つを分けて管理するためのもので、後者の場合には、フラグの値を”Ｇ”に設定する。
【００９０】
トランザクションの内容には、トランザクションに属するクエリの内容を記録する。ただし、クエリの内容はＤＢＭＳのトランザクションログにも記録されるため、回復テーブル３４１への記録を省略することもできる。
【００９１】
図９（ａ）は、１００１のウィンドウがコピーされた直後の、副側のトランザクションキュー３２２と回復テーブル３４１の状態を表す。副側トランザクションキュー３２２では、ウィンドウ１０００がＷｐ（直前のコピー範囲）、ウィンドウ１００１がＷｎ（最新のコピーの範囲）を表す。コピー直後のため、回復テーブル３４１には何も記録されていない。
【００９２】
図９（ｂ）は、トランザクション実行部３３１が、トランザクションキュー３２２を調査し、回復テーブル３４１を更新した直後の、トランザクションキュー３２２と回復テーブル３４１の状態を表す。トランザクション実行部３３１は、ウィンドウ１０００を調査し、ＩＤが０、１、２であるトランザクションの情報を回復テーブルに記録する。しかし、ＩＤが０と１のトランザクションについては、直前に受信したウィンドウＷｐであるウィンドウ１０００内にコミットがあるため、正サイト１００で既にコミットが実行されたと判断できる。従って、ＩＤが０と１のトランザクションの情報を回復テーブル１０２１から削除する。その結果、回復テーブル１０２１には、ＩＤが２のトランザクションの情報のみが記録される。
【００９３】
トランザクション実行部３３１では、コピーが行われる度に、コミットの実行が判断できないトランザクションの情報を更新していく。グレーかどうかの最終的な判断は、障害が発生した後に行われるため、障害発生前はフラグには値は設定されていない。
【００９４】
次に、正サイト１００で障害が生じた場合は、副サイト１１０で障害回復を行い業務を引き継ぐ処理について説明する。
【００９５】
図１０は、本発明の第１の実施の形態の副サイト１１０での障害回復処理のフローチャートである。
【００９６】
障害発生時は、Ｗｎに未調査のクエリが無くなるまで、最初に、グレーな部分の判定を行う（ステップ１２１４〜１２２５）。
【００９７】
まず、正サイトの障害を検知する（ステップ１２０１）。例えば、定期的に正サイトと副サイトの間でalive checkの通信を行い、予め定めた期間にalive checkが連続して失敗した場合に障害を検知したとすることができる。
【００９８】
次に、最新のコピーの結果であるＷｎ内のクエリを調査し、未調査のクエリがあるか否かを判定する（ステップ１２０３）。そして、未調査のクエリがあれば、該クエリを取り出し（ステップ１２１４）、該クエリがコミットかどうかを調査する（ステップ１２１５）。
【００９９】
該クエリがコミットでない場合は、回復テーブル３４１に該クエリが属するトランザクションに関する情報が既に回復テーブルに記録されているか否かを判定する（ステップ１２１６）。該トランザクションに関する情報が未登録であると判定された場合は、新規に該トランザクションの情報を回復テーブル３４１に登録する（ステップ１２１７）。一方、該トランザクションに関する情報が既に登録されている場合は、回復テーブルの内容部分にクエリの内容を追加登録する（ステップ１２１９）。
【０１００】
ステップ１２１５において、クエリがコミットであると判定されると、該クエリの実行フラグがＯＮであるか否かが判定される（ステップ１２２１）。該クエリの実行フラグがＯＮではない場合は、該クエリが属するトランザクションはグレーと判定される。なぜなら、該コミットは最新のコピーであることから、正サイト１００で最新のコピー範囲に含まれるコミットは実行されたかを判定できないためである。従って、回復テーブルの該クエリ（コミット）が属するトランザクションに関するフラグを”Ｇ”にセットする（ステップ１２２２）。一方、実行フラグがＯＮである場合は、該コミットの実行が確認されたため、該クエリ（コミットと該トランザクションで未実行であるクエリ）を実行して（ステップ１２２４）、該クエリが属するトランザクションの情報を回復テーブルから削除する（ステップ１２２５）。
【０１０１】
障害検知時の、回復テーブルの動作例を図９（ｃ）に示す。ウィンドウ１０００が直前のコピー範囲を表すＷｐであり、ウィンドウ１００１が最新のコピー範囲を表すＷｎである。Ｗｎ１００１を調査した結果、ＩＤが２のトランザクションに関しては、クエリの内容（Ｕ、Ｃ）が追加される。また、Ｗｎ１００１内にコミット（Ｃ）があり、かつ、実行フラグがＯＮでないため、ＩＤが２のトランザクションのコミット（Ｃ）は正サイト１００で実行されているかが分からないので、該トランザクションはグレーと判定され、フラグが”Ｇ”にセットされる。一方、新たなトランザクションとして、ＩＤが３、４のトランザクションが登録されるが、これらはＷｎ１００１内にコミットが含まれていないため、フラグの値はセットされない。
【０１０２】
次に、図１０に戻って、副サイトでの業務再開のための回復処理（ステップ１２０４〜１２１３）について説明する。
【０１０３】
ステップ１２０３においてＷｎ内の調査が終了が確認されると、まず、回復テーブルにおいてフラグが”Ｇ”でない（コミットが投入されていない）トランザクションをロールバックして、該トランザクションの開始以前の状態に戻す（ステップ１２０４）。
【０１０４】
続いて、回復テーブル３４１中でフラグが”Ｇ”であるトランザクション、すなわち、コミットの実行が判断できないグレーなトランザクションを特定する。そして、該トランザクションが使用したリソースを調査し、該リソースへのアクセスが拒否されるようなアクセス制限を設定する（ステップ１２０５）。例えば、ＤＭＢＳのテーブルの特定の行やセルに排他ロックをかけてアクセスを制限する。
【０１０５】
次に、正サイト１００から副サイト１１０に系を切り替え、副サイト１１０においてアクセス制限つきで限定的に業務を再開する（ステップ１２０６）。
【０１０６】
次にステップ１２０８以降で、グレーなトランザクションの回復処理を行う。まず、グレーなトランザクションを全て回復したか否かを判定する（ステップ１２０８）。グレーなトランザクションを回復が終了しておらず、グレーなトランザクションがある場合は、グレーなトランザクションの手動で回復する（ステップ１２０９）。例えば、該トランザクションを発行した企業やユーザに問い合わせることによって手動回復をする。そして、手動回復完了したら、該トランザクションが使用していたリソースに対するアクセス制限を解除する（ステップ１２１０）。一方、グレートランザクションを回復が全て完了した場合、完全な業務を再開する（ステップ１２１２）。
【０１０７】
以上説明した副サイトの処理（図７〜図１０）では、第２情報処理装置である副サイト１１０は、第１情報処理装置である正サイト１００から転送されたクエリを受信し、障害回復用の情報を生成し（図８のステップ９１８、９２０）、正サイト１００の障害を検知すると（図１０のステップ１２０１）、正サイト１００からの直前の転送範囲Ｗｐ内で、ストレージ装置３１１の記憶内容への反映が行われていないトランザクションについては、該トランザクション開始前の状態に戻すロールバック処理の対象とし、前記回復用情報から削除し（図１０のステップ１２２４）、正サイト１００からの直前の転送範囲Ｗｐ内で、ストレージ装置３１１の記憶内容への反映が行われているトランザクションについては、前記回復用情報に追加する（図１０のステップ１２１７、１２１９）。よって、正サイト１００からの直前の転送範囲Ｗｐ内で、ストレージ装置３１１の記憶内容へ反映するコミット処理が行われているトランザクションについては、前記回復用情報に追加する（図１０のステップ１２２２）ことで、手動回復対象とすることができる。
【０１０８】
以上説明した第１の実施の形態では、正、副サイト内のＤＢＭＳにトランザクションキュー３００、３２０を設け、クライアント１３０から入力されたトランザクション情報は、一旦、トランザクションキュー３００に保存され、正サイト１００において、トランザクションをコミットする際には、トランザクションキュー内にある未コピークエリを副サイト１１０へ一括して同期コピーを行い、コミット前に副サイト１１０へのコピーが完了していることが保障されているため、遠距離であってもトランザクション欠損のないＤ／Ｒシステムを実現することができる。
【０１０９】
すなわち、正サイト１００は未転送のクエリの実行時に、受け付けたクエリのうち未転送のクエリを転送し、副サイト１１０は、正サイト１００からクエリを受信するので、正サイト１００から転送されたクエリより前に転送されたクエリは、正サイト１００で既に実行されたと判定することができ、該判定されたクエリを実行して、正サイト１００と副サイト１１０とのトランザクションの同期を図ることができる。
【０１１０】
また、コピー時には、トランザクションキュー３１０内の未コピートランザクションを一括コピーするため、コピーの頻度を下げることができ、遠距離であってもトランザクション処理のスループット性能を維持することができる。
【０１１１】
また、副サイト１１０は、コピーされたトランザクションの順序関係から、正サイト１００でコミットが実行されているかどうかを判断し、コミット済みと判断できる場合は、障害発生前から順次実行しておく。傷害発生時には、コミット済みか判断不能なトランザクションのみを手動回復対象とする。判断が不能なトランザクションが関連するリソースに対してはアクセスを制限し、限定的に業務を再開するので、副サイト１１０では、正サイト１００でのトランザクションのコミット実行を完全に把握することはできないが、転送されたトランザクションを、コミットが実行されたトランザクション、コミットが実行されたかも知れないトランザクションに切り分けることが可能である。従って、障害後の回復作業においては、コミットされたかもしれないトランザクションだけに範囲を限定することができる。
【０１１２】
また、副サイト１１０では、コミット済みのトランザクションについては、順次実行していくことにより、正サイト１００側での変更が準リアルタイムで反映させていくことが可能である。したがって、正サイト１００で障害が発生し、副サイト１１０に系が切り替わる場合にも、データ反映のほとんどが完了しており、迅速な業務再開が可能となる。
【０１１３】
また、障害発生時は、グレーな部分のみアクセスを制限することによって、限定的な業務を再開することが可能となる。
【０１１４】
次に、本発明の第２の実施の形態について説明する。
【０１１５】
図１１は、本発明の第２の実施の形態のトランザクション管理部の別な構成図である。図１１に示す実施の形態では、正サイトのトランザクション管理部３００に、ポーリング部４００が設けられている。
【０１１６】
ポーリング部４００は、トランザクションキューを（例えば、定期的に）監視しており、未コピーのクエリを一括コピーする。
【０１１７】
ポーリング部４００によって、トランザクション同期化・実行部３０２でトランザクションキュー３１０よりクエリを取り出した際に、コピー済みである場合が増えるため、副サイトへのトランザクションのコピーによるトランザクション処理性能への影響を小さくすることができる。トランザクション同期化・実行部３０２では、トランザクションキュー３１０から取り出したクエリが未コピーであれば、前述した第１の実施の形態（図２）と同様の処理を行う。
【０１１８】
図１２は、本発明の第２の実施の形態のポーリング部の処理のフローチャートである。
【０１１９】
正サイトのポーリング部４００が、トランザクションのコピーを定期的に実行するため、トランザクション同期化・実行部３０２の処理において、クエリの実行時に、該クエリがコピー済みである場合が増えるため、正サイトのトランザクション処理への影響を小さくすることができる。
【０１２０】
まず、タイマを初期化（リセット）する（ステップ１１０１）。
【０１２１】
次に、予め定めたΔＴを経過しているか否かを判定する（ステップ１１０３）。
【０１２２】
ΔＴを経過している場合は、トランザクションキュー３１０内に未コピーのクエリがあるか否かを判定する（ステップ１１０５）。
【０１２３】
未コピークエリがある場合には、キュー内の未コピークエリを一括コピーする（ステップ１１０７〜１１１０）。この一括コピーでは、まず、キューの最後備を表すＬＩポインタの値をＬ０に退避し（ステップ１１０７）、未コピーであるＰＩ＋１〜Ｌ０のクエリを一括コピーする（ステップ１１０８）。コピーの完了後、クエリのコピーフラグをＯＮにし、コピー済みクエリの最後尾を表すＰＩポインタをＬ０で更新する（ステップ１１０９）。最後にタイマをリセットし（ステップ１１１０）、ステップ１１０３へ戻る。
【０１２４】
なお、この一括コピー（ステップ１１０７〜１１１０）は、同期コピー又は非同期のどちらでもよく、非同期コピーの場合には、コピーの完了を待たずに、ステップ１１０９において、クエリのコピーフラグをＯＮにし、コピー済みクエリの最後尾を表すＰＩポインタを更新することができる。
【０１２５】
図１３は、本発明の第２の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【０１２６】
ポーリング部４００による非同期コピーが行われない場合のトランザクション同期化・実行部の処理（図５）と、ステップ１３０１において相違する。すなわちステップ７２５においてコピー済みのクエリを実行する前に、非同期コピーが完了しているかが確認される（ステップ１３０１）。非同期コピーの完了を確認してから、コピー済みのクエリが実行される（ステップ７２５）。これらの処理によって、ポーリング部４００で非同期コピーを用いた場合でも、正サイト１００におけるコミットの実行前に、副サイト１１０へのコピーが完了していることを保障させることできる。
【０１２７】
なお、正サイトのポーリング部４００で、非同期コピーではなく、同期コピーを用いると、コピーの度にコピーの完了を確認するので、ステップ１３０１のようなクエリ実行前の非同期コピーの完了確認は不要となる。
【０１２８】
次に、本発明の第３の実施の形態について説明する。
【０１２９】
本発明では、正サイト１００から副サイト１１０へのクエリの同期コピーが実施されるのは、クエリの実行前であるため、クエリの実行状況は副サイト１１０に伝わらない。しかし、実行が終了した時点で、実行状況もコピーすることによって、副サイト１１０にクエリの実行状況を反映させることもできる。
【０１３０】
図１４は、本発明の第３の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【０１３１】
前述した第１の実施の形態のトランザクション同期化・実行部の処理（図５）と、ステップ１５００、１５０１、１５０２、１５０３、１５０４において相違する。すなわち、クエリの実行（ステップ７２０）の直後に、実行状況の通知を行う（ステップ１５００）。ただし、トランザクション処理性能への影響を最小限とするために、非同期コピーを用いる。なぜなら、コミット前の同期コピーはトランザクション欠損をなくすためには確実性が必要であるのに対し、グレー判定容易化のための実行状況の通知は確実性が低くてもよいためである。
【０１３２】
第３の実施の形態においては、クエリの実行状況を通知するため、トランザクションキュー３１０、３２２を、図１５に示すように、実行状況コピーの有無を示すコピーフラグ２（１４０１）を追加して構成する。非同期コピーによって実行状況を通知した時点で、このコピーフラグ２（１４０１）の値をＯＮにする。
【０１３３】
具体的には、クエリがコミットである場合（ステップ７１１）、該クエリを実行（ステップ７２０）した後、コピーフラグ２がＯＮでない（実行状況が未コピーである）クエリを一括して非同期コピーする（ステップ１５００）。そして、コピーしたクエリのコピーフラグ２をＯＮにする（ステップ１５０１）。
【０１３４】
また、クエリがコピー済みである場合（ステップ７０９）、コピー済みクエリを実行（ステップ７２５）した後に、該クエリがコミットかどうかを判定し（ステップ１５０２）、該クエリがコミットである場合には、実行状況が未通知であるクエリを一括して非同期コピーする（ステップ１５０３）。そして、コピーしたクエリのコピーフラグ２をＯＮにする（ステップ１５０４）。
【０１３５】
このように第３の実施の形態では、正サイト１００から副サイト１１０へ、クエリの実行状況を通知することによって、障害発生時の副サイトでのグレー判断処理を容易化することができる。すなわち、Ｗｎ内のコミットであっても、トランザクションの実行を確認することができ、グレーと判定され手動回復に頼らなければならない範囲を狭めることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態のＤ／Ｒシステムのシステム構成図である。
【図２】本発明の第１の実施の形態のトランザクション管理部の構成図である。
【図３】本発明の第１の実施の形態の正サイトのトランザクションキュー３１０の説明図である。
【図４】本発明の第１の実施の形態のトランザクション受付部の処理のフローチャートである。
【図５】本発明の第１の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【図６】本発明の第１の実施の形態のコピー時の正サイト１００と副サイト１１０との間のトランザクションキューの説明図である。
【図７】本発明の第１の実施の形態のトランザクション受信部３３０の処理のフローチャートである。
【図８】本発明の第１の実施の形態のトランザクション実行部３３１の処理のフローチャートである。
【図９】本発明の第１の実施の形態のコピー時の副サイトのトランザクションキューの動作例を示す説明図であり
【図１０】本発明の第１の実施の形態の副サイト１１０での障害回復処理のフローチャートである。
【図１１】本発明の第２の実施の形態のトランザクション管理部の別な構成図である。
【図１２】本発明の第２の実施の形態のポーリング部の処理のフローチャートである。
【図１３】本発明の第２の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【図１４】本発明の第３の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【図１５】本発明の第３の実施の形態の正サイトのトランザクションキュー３１０の説明図である。
【図１６】従来のＤ／Ｒシステムのシステム構成図である。
【符号の説明】
１００ 情報処理装置（正サイト）
１０１ サーバ
１０２ ストレージ
１０３ ＤＢＭＳ（database management system）
１１０ 情報処理装置（副サイト）
１２１ ストレージ間ネットワーク
１２２ サーバ間ネットワーク
１３０ クライアント（ＵＡＰ）
３００ トランザクション管理部（正サイト）
３０１ トランザクション受付部（正サイト）
３０２ トランザクション同期化・実行部（正サイト）
３０５ 未コピートランザクション（一括同期コピー）
３０６ コピー済みトランザクション（実行）
３１０ トランザクションキュー（正サイト）
３１１ ストレージ（正サイト）
３２０ トランザクション管理部（副サイト）
３２１ トランザクション受信・実行部（副サイト）
３２２ トランザクションキュー（副サイト）
３２３ ストレージ（副サイト）
３３０ トランザクション受信部
３３１ トランザクション実行部
３４０ 障害回復部
３４１ 回復テーブル
４００ ポーリング部
４０１ 未コピートランザクション（一括同期／非同期コピー）
【発明が属する技術分野】
本発明は、データベースシステムに関し、特に、データベースシステム間のトランザクションの転送制御に関する。
【０００２】
【従来の技術】
ビジネスにおいて、ＩＴシステムの重要性はますます高まっている。例えば、金融業界では、ＩＴシステムが停止する障害によって、数千億ドルの損失が生じるといわれている。よって、計算機システムを、正サイトと副サイトとに二重化して、正サイトに障害が発生した時には副サイト系に切り替えて、サービスを継続させるためのＨＡ技術（High Availability技術）が重要となっている。
【０００３】
システム障害の原因には、システムエラー、人為的操作ミス、停電など様々であるが、大規模災害においてもサービスやＩＴシステムの復旧を迅速に行うＤ／Ｒ（Disaster Recover）技術が注目されている。Ｄ／Ｒ技術では、正サイトと副サイトとに二重化された計算機システム間でデータのコピーを行うことにより、データ保護を図っており、データ保護、すなわち、データ欠損がないことが最も重要な要件である。さらに、大規模災害に対応するために、副サイトをより遠隔地に構築したいという要求が高まっている。
【０００４】
従来のＤ／Ｒシステムの構成を図１６に示す。
【０００５】
従来のＤ／Ｒシステム (Disaster Recover system）は、正サイト１００と遠隔地にある副サイト１１０とから構成されている。正サイト１００ではデータの記録、検索等の業務を行う。一方、副サイト１１０は正サイト１００と同一の内容を記憶しており、正サイト１００のバックアップサイトとしての役割を果たす。
【０００６】
各サイト１００、１１０は、ＤＢＭＳ１０３を含むサーバ１０１及びストレージ（ＤＢ）１０２によって構成され、両サイト１００、１１０は、サーバ間ネットワーク１２２及び／又はストレージ間ネットワーク１２１で接続される。
【０００７】
正サイト１００は、クライアント１３０（ＵＡＰ（user application））から入力を受け付け、結果をＤＢ（Database）１０２に反映する。ＵＡＰからの入力は、通常、トランザクションとして認識される。ここで、トランザクションは、ＤＢＭＳ（database management system）に対する標準言語であるＳＱＬを用いた複数の問い合わせから構成される。問い合わせは、挿入（Insert）、更新（Update）、コミット（Commit）などいくつかの種類がある。トランザクションに含まれる問い合わせがコミットないで場合は、問い合わせの結果は、正サイト１００のサーバ１０１のＤＢＭＳ１０３内のバッファに記録されるだけである。そしてコミットが実行されて初めて、一連の問い合わせの結果がストレージ１０２に反映され、トランザクションが確定する。正サイト１００は、トランザクション及びトランザクション処理結果であるデータ（ＤＢＭＳのテーブル等）を、何らかのタイミングで副サイト１０１に転送しておく。障害が発生した場合は、系を切り替え、バックアップサイトであった副サイト１０１が業務を引き継いで実行する。
【０００８】
従来より、サイト間のトランザクションの転送には、サーバ間ネットワーク１２１を用いたコピーが行われてきたが、近年は、ストレージ間ネットワーク１２２によるコピーも用いられるようになっている。これは、コピー時にサーバへの負荷がないこと、ストレージはサーバより信頼性が高いためである（例えば、非特許文献１参照。）。
【０００９】
このコピーには、サーバ間、ストレージ間に関わらず、同期コピーと非同期コピーとがある。
【００１０】
正サイト１００から副サイト１１０への同期コピーでは、正サイトのサーバ１０１が同期コピーを指示すると、データは正サイトに接続されるストレージ（正）１０２のディスクキャッシュに書き込まれる。続いて、ストレージ（正）１０２は、副サイト１１０のストレージ（副）１０２のディスクキャッシュにコピーを行う。さらに、ストレージ（正）１０２は、ストレージ（副）１０２からのデータ受信の応答を受けると、転送元のサーバ１０１へ同期コピー完了の応答を返す。コミットに同期して副サイト１１０へ同期コピーを行うことによって、データ欠損がないデータコピーが実現される。しかし、同期コピーでは、ストレージ（副）１０２からの応答を待つ遅延が生じるため、サイト間距離が長距離となる場合には、この遅延が問題となる。
【００１１】
一方、非同期コピーを用いた場合は、ストレージ（正）１０２のディスクキャッシュにデータが書き込まれた時点で、転送元のサーバ１０１へ応答が返され、ストレージ（副）１０２へのコピーは別のタイミングで行われる。コピーの遅延はないが、転送元サーバ１０１に応答が返った時点で、データが副サイト１１０にコピーされていることが保障されず、データ欠損が生じる可能性がある。
【００１２】
この非同期コピーと同期コピーとを組み合わせた中間的な方法として、非同期コピーの完了確認のためのコマンドを有し、同期が不要な場合は非同期コピーを行うが、同期が必要になった時点で該コマンドを実行し、非同期コピー完了が確認されるまで、以降の処理を中断することにより、データ欠損がないことを実現する方法が提案されている（例えば、特許文献１参照。）。
【００１３】
Ｄ／Ｒシステムでは、障害発生時に副サイト１１０において、ＤＢの整合性確認などの回復処理を行った後、副サイト１１０で業務を継続する。まず、非同期コピーを用いた場合は、データ欠損が生じるため、完全な回復を行うことができない。一方、同期コピーを用いた場合であっても、障害発見後に初めて回復処理を開始するような場合は、多大な回復時間を要する可能性がある。例えば、長期間隔で行われるフルバックアップのコピーと、フルバックアップからの増分バックアップのコピーを利用した回復が行う場合があげられる。すなわち、そのような回復処理では、最初にフルバックアップをリストアした後、増分バックアップのコピーを順次適用していくため、バックアップのサイズ、個数によっては、回復処理に多大な時間を要する。
【００１４】
【特許文献１】
特開２００２−４９５１７号公報
【非特許文献１】
”EMC Symmetrix Remote Data Facility”、［online］、インターネット＜ＵＲＬ：http://japan.emc.com/local/ja/JP/products/product_pdfs/srdf/srdf.pdf＞
【００１５】
【発明が解決しようとする課題】
以上説明した従来のＤ／Ｒシステムでは、以下の問題点がある。
【００１６】
トランザクション欠損なしを実現しようとした場合、同期コピーを用いる方法が一般的であるが、特にサイト間距離が長い場合は、同期コピーの完了待ちによる遅延が問題となる。非同期コピーを用いた場合は、遅延は生じないが、トランザクションが副サイトへコピーされたことを保障できなくなる。すなわちトランザクション欠損なしが実現できない。
【００１７】
また、非同期コピーを用いた場合は、トランザクション欠損が生じることがあり、障害が発生した場合に、完全な回復は行えない。同期コピーを用いた場合であっても、障害回復後に初めて回復処理をスタートし、フルバックアップに対し更新差分（増分バックアップ）を適用していく回復方法では、多大な処理時間を要するため、迅速に業務を回復することができない。
【００１８】
よって、サイト間距離が長距離である場合に、トランザクション処理性能への影響を最小限にしながらトランザクション欠損なしのＤ／Ｒシステムを実現することが望まれている。
【００１９】
また、サイト間距離が長距離であるＤ／Ｒシステムにおいて、障害発生後の迅速な回復を実現することが望まれている。
【００２０】
【課題を解決するための手段】
本発明のトランザクション同期方法は、計算装置及びストレージ装置を有する第１情報処理装置と、計算装置及びストレージ装置を有する第２情報処理装置との間で、１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、前記第１情報処理装置は、クエリを実行する際に、該クエリが前記第２情報処理装置へ転送されているか否かを判定し、該クエリが既に転送されている場合は、該クエリを実行し、該クエリが未転送である場合は、該クエリが前記ストレージ装置の記憶内容への反映を伴うコミット処理であるときには、受け付けたクエリのうち未転送のクエリを前記第２情報処理装置に一括して転送（例えば、同期コピー）する。
【００２１】
また、クエリを実行する際に未転送のクエリを一括して転送（例えば、同期コピー）する第１の転送方法に加え、受け付けたクエリを所定のタイミングで監視し、未転送のクエリがある場合は、前記未転送のクエリを、前記第２情報処理装置に一括して転送（例えば、同期コピー又は非同期コピー）する第２の転送方法によってクエリを転送する。
【００２２】
また、前記第１情報処理装置は、前記コミット処理の実行情報が、前記第２情報処理装置に転送されたか否かを管理し、前記コミット処理の実行後に、該コミット処理の実行情報が前記第２情報処理装置に転送されていない場合は、受け付けたクエリのうち、前記実行情報が未転送のクエリに関する実行情報を、前記第２情報処理装置に一括して転送（例えば、非同期コピー）する。
【００２３】
また、計算装置及びストレージ装置を有する第１情報処理装置と、計算装置及びストレージ装置を有する第２情報処理装置との間で、１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、前記第１情報処理装置は、コミット処理を実行する際に、該コミット処理が未転送である場合は、受け付けたクエリのうち未転送のクエリを、前記第２情報処理装置に一括して転送し、前記第２情報処理装置は、前記第１情報処理装置から転送されたクエリより前に転送されたクエリは、前記第１情報処理装置で既に実行されたと判定し、該判定されたクエリを実行する。
【００２４】
また、計算装置及びストレージ装置を有する第１情報処理装置と、計算装置及びストレージ装置を有する第２情報処理装置との間で、１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、前記第２情報処理装置は、前記第１情報処理装置から転送されたクエリを受信し、前記転送されたクエリの範囲を記録し、当該の転送範囲及び直前の転送範囲に含まれるクエリを調査し、該直前の転送範囲内で、ストレージ装置の記憶内容へ反映を伴うコミット処理が行われていないトランザクションに関する情報を回復用の情報として記録する。
【００２５】
また、計算装置及びストレージ装置を有する第１情報処理装置と、計算装置及びストレージ装置を有する第２情報処理装置との間で、１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、前記第２情報処理装置は、前記第１情報処理装置から転送されたクエリを受信して、障害回復用の情報を生成し、前記第１情報処理装置の障害を検知すると、前記第１情報処理装置からの直前の転送範囲内で、ストレージ装置の記憶内容への反映を伴うコミット処理が行われていないトランザクションについては、当該トランザクションの開始前の状態に戻すロールバック処理の対象として、前記回復用情報から削除し、前記第１情報処理装置からの直前の転送範囲内で、ストレージ装置の記憶内容への反映が行われているトランザクションは、前記回復用情報に記憶する。
【００２６】
【発明の作用及び効果】
本発明のトランザクション同期方法では、第１情報処理装置は、クエリを実行する際に、該クエリが第２情報処理装置へ転送されているか否かを判定し、該クエリが既に転送されている場合は、該クエリを実行し、該クエリが未転送である場合は、該クエリが前記ストレージ装置の記憶内容への反映を伴うコミット処理であるときには、受け付けたクエリのうち未転送のクエリを前記第２情報処理装置に一括して転送するので、コミット処理の実行前に必ず第２情報処理装置側へのクエリの転送が完了していることが保障されているため、遠距離であってもトランザクション処理のスループット性能への影響を抑制しつつ、トランザクション欠損のないＤ／Ｒシステムを実現することができる。
【００２７】
【発明の実施の形態】
図１は、本発明の実施の形態のＤ／Ｒシステムのシステム構成図である。
【００２８】
本実施の形態のＤ／Ｒシステム (Disaster Recover system）は、正サイト１００と遠隔地にある副サイト１１０とから構成されている。正サイト１００では、データの記録、検索等の業務を行う。一方、副サイト１１０は、正サイト１００と同一の内容を記憶しており、正サイト１００のバックアップサイトとしての役割を果たす。
【００２９】
正サイト１００は、ＤＢＭＳ１０３を含むサーバ１０１及びストレージ（ＤＢ）３１１によって構成され、副サイト１１０は、ＤＢＭＳ１０３を含むサーバ１０１及びストレージ（ＤＢ）３２３によって構成される。また、両サイト１００、１１０は、サーバ間ネットワーク１２２及び／又はストレージ間ネットワーク１２１で接続される。
【００３０】
正サイト１００は、クライアント１３０（ＵＡＰ（ｕｓｅｒａｐｐｌｉｃａｔｉｏｎ））から入力を受け付け、結果をＤＢ（Ｄａｔａｂａｓｅ）３１１に反映する。ＵＡＰからの入力は、通常、トランザクションとして認識される。ここで、トランザクションは、ＤＢＭＳ（ｄａｔａｂａｓｅ ｍａｎａｇｅｍｅｎｔｓｙｓｔｅｍ）に対する標準言語であるＳＱＬを用いた複数の問い合わせから構成される。問い合わせは、挿入（Ｉｎｓｅｒｔ）、更新（Ｕｐｄａｔｅ）、コミット（Ｃｏｍｍｉｔ）などいくつかの種類がある。トランザクションに含まれる問い合わせがコミットないで場合は、問い合わせの結果は、正サイト１００のサーバ１０１のＤＢＭＳ１０３内のバッファに記録されるだけである。そしてコミットが実行されて初めて、一連の問い合わせの結果がストレージ３１１に反映され、トランザクションが確定する。正サイト１００は、トランザクション及びトランザクション処理結果であるデータ（ＤＢＭＳのテーブル等）を、何らかのタイミングで副サイト１１０に転送しておく。障害が発生した場合は、系を切り替え、バックアップサイトであった副サイト１１０が業務を引き継いで実行する。
【００３１】
ＤＢＭＳ１０３は、トランザクション管理部（Ｔｒ管理部）２００を有し、トランザクション管理部２００が、正サイト１００と副サイトとの間１１０でトランザクションを転送する。なお、トランザクション管理部２００は、ＤＢＭＳ１０３に備わってなくてもよく、ＴＰモニタなどのソフトウェアによってトランザクション管理部２００が、正サイト１００、副サイト１１０間でトランザクションを管理するようにしてもよい。
【００３２】
図２は、本発明の第１の実施の形態のトランザクション管理部の構成図である。
【００３３】
正サイトのトランザクション管理部３００は、トランザクション受付部（Ｔｒ受付部）３０１、トランザクション同期化・実行部（Ｔｒ同期化・実行部）３０２、トランザクションキュー３１０の３つのソフトウェアコンポーネントより構成される。
【００３４】
クライアント（ＵＡＰ）から入力されたトランザクションは、一度、トランザクションキュー３１０に記録された後に実行される。トランザクションキュー３１０では、トランザクションの内容（トランザクションを構成するクエリ）だけでなく、トランザクションの状態（副サイトへのコピーの有無、実行の有無）も管理する。
【００３５】
トランザクション受付部３０１は、入力されたトランザクションを受け付け、トランザクションキュー３１０へ登録する。
【００３６】
トランザクション同期化・実行部３０２は、トランザクションの実行及びトランザクションのコピーをする。すなわち、トランザクション同期化・実行部３０２は、トランザクションを構成するクエリをトランザクションキュー３１０から取り出すと、該クエリを実行する。また、該クエリの状態に応じて、クエリを副サイトのトランザクション管理部３２０へ転送して、トランザクションをコピーする。
【００３７】
すなわち、図５で詳述するように、トランザクションキュー３１０から取り出したクエリが、副サイトのトランザクション管理部３２０に既にコピーされていたら、クエリを実行する。このクエリがコミットである場合は、該クエリに関わるトランザクションが確定されたことになり、トランザクションの実行結果がストレージ３１１に反映される。クエリがコミットでない場合は、トランザクションの実行途中の結果がＤＢＭＳ１０３中のＤＢバッファに記録される。
【００３８】
一方、トランザクションキュー３１０から取り出したクエリが、副サイトのトランザクション管理部３２０にコピーされていなかったら、トランザクション同期化・実行部３０２は、副サイトへコピーが必要か否かを判定する。該クエリがコミットでない場合は、コピーを行わず該クエリを直ちに実行する。一方、該クエリがコミットである場合は、副サイトのトランザクション管理部３２０に対する同期コピーを実行する。ただし、同期コピーの際には、該クエリだけでなく、トランザクションキュー３１０に記録されている未コピーであるトランザクション情報を一括して同期コピーし、その後にクエリを実行する。従って、トランザクション同期化・実行部３０２により、コミット前に、必ず該コミットに関連するトランザクション情報が副サイトのトランザクション管理部３２０に転送され、コピーされるため、トランザクション欠損が生じないことが保障される。
【００３９】
副サイトのトランザクション管理部３２０は、トランザクション受信・実行部３２１、障害回復部３４０、トランザクションキュー３２２及び回復テーブル３４１によって構成される。トランザクション受信・実行部３２１は、正サイト１００からコピーされたトランザクションを受信し、コミットが確定したトランザクションを実行する。また、正サイト１００で障害が発生した場合は、副サイト１１０では、障害回復処理を実行し、正サイト１００で行っていた業務を引き継いで行う。
【００４０】
トランザクション受信・実行部３２１は、トランザクション受信部３３０とトランザクション実行部３３１によって構成される。トランザクション受信部３３０は、正サイトのトランザクション同期化・実行部３０２と通信を行い、正サイト１００から送信されたトランザクションを受信し、トランザクションキュー３２２へ保存する。トランザクション実行部３３１は、正サイト１００でコミットが実行されたトランザクションを実行する。
【００４１】
このとき、トランザクション受信部３３０は、トランザクション情報のコピー状態（最新の一括同期コピーで送られたかどうか）を管理する。トランザクション実行部は、コピー状態により、トランザクションが正サイトでコミットされているか否かを判断する。既にコミットが実行されていると判断される場合は、該トランザクションのコミットを副サイトでも実行する。一方、正サイトで未だコミットが実行されていないと判断される場合には、必要なトランザクション情報を回復テーブル３４１に保存する。
【００４２】
トランザクション受信・実行部３２１は、コピーが実行される度に回復テーブル３４１にコピーが実行されたトランザクション情報を更新する。回復テーブル３４１へ記録する情報は、正サイト１００でのコミットの実行が確定できないトランザクションの情報である。例えば、コミットそのものが投入されていない（コミットを投入される前に、何らかの障害が発生した）場合、及び、コミットは投入されているが、コミットを実行したかどうかが判断できない場合が、コミットが実行されていないトランザクションとして考えられる。
【００４３】
本実施の形態では、コミットの実行前に該トランザクションに関する情報をコピーしているため、副サイト１１０では、そのコピーを受信した時に、正サイト１００においてコミットが投入されたことは分かる。しかし、副サイト１１０では、該コミットが確かに実行されたかを判定することはできない。副サイト１１０は、該コミットを含むコピーの次のコピーが行われて初めて、該コミットが実行されたことがわかる。すなわち、上述した一括コピーの手順では、正サイト１００は、副サイト１１０へトランザクションをコピーした後、該コピーに係るトランザクションを実行する。そして、該コピーに含まれる全てのトランザクションが実行された後、次のコピーを行うので、コピーが行われた（副サイト１１０でクエリを受信した）ときに、該コピーに含まれるトランザクションは正サイトで全て実行されていると判定できるのである。
【００４４】
障害回復部３４０は、正サイト１００で障害が発生した際に、副サイト１１０で業務を引き継ぐために必要な障害回復処理を行う。障害回復部３４０は、受信したトランザクションについて、正サイト１００においてコミットが投入されたが、コミットが実行されたかを判定できないグレートランザクションを調査し、グレーなトランザクションに関係するデータへのアクセスを制限して、限定的に業務を再開する。同時に、グレーなトランザクションを手動回復する。手動回復が完了した時点で、アクセス制限を解除し、完全に業務を再開する。
【００４５】
以上説明した、正サイト１００から副サイト１１０へのトランザクションのコピーは、同期コピーを用いるとよいが、同期コピーではなく非同期コピーを用いるようにしてもよい。
【００４６】
図３は、本発明の第１の実施の形態の正サイトのトランザクションキュー３１０の構成例を示す説明図である。
【００４７】
トランザクションは一つ又は複数のクエリより構成されるため、クエリ毎にクエリに関する属性をテーブル５００に記録する。テーブルには属性として、トランザクションに一意に与えられるトランザクションＩＤ、クエリの内容、クエリがコピーされたかどうかを表すコピーフラグ、クエリが実行されたかどうかを表す実行フラグが記録される。このフラグは”ＯＮ”、”ＯＦＦ”、”ｎｕｌｌ”の３種の値を取り得る。
【００４８】
また、テーブル５００には、３つのポインタを用意する。第１のポインタ（コピーポインタ：ＰＩ）５０１は、最後にコピーされたクエリを指す。つまり、コピーポインタＰＩの次が、コピーされていないクエリの内、最も古いのクエリである。第２のポインタ（最後尾ポインタ：ＬＩ）５０２は、最後にトランザクションキューに入力されたクエリ（最新のクエリ）を指す。第３のポインタ（実行ポインタ：ＥＩ）５０３は、これから実行処理手順を決定する対象のクエリ（未実行クエリのうち、最も古いクエリ）を指す。
【００４９】
図４は、本発明の第１の実施の形態のトランザクション受付部の処理のフローチャートである。
【００５０】
正サイトのトランザクション受付部３０１は、外部よりトランザクション（トランザクションを構成するクエリ）を受付け、登録可能であれば、受け付けたトランザクションをトランザクションキュー３１０に登録する。登録が行われた場合は、ＬＩポインタが更新される。
【００５１】
まず、各ポインタ（ＰＩ、ＥＩ、ＬＩ）を初期化する（ステップ６０１）。
【００５２】
次に、テーブル５００の内容を消去して、トランザクションキュー３１０を初期化する。フラグの初期化時には、フラグの値は”ｎｕｌｌ”に設定される（ステップ６０２）。
【００５３】
次に、クライアント（ＵＡＰ）からクエリの入力を監視して、クエリの入力があるか否かを判定する（ステップ６０４）。
【００５４】
クエリの入力がある場合には、クエリが登録可能か否かを判定する（ステップ６０６）。すなわち、既にクエリの情報が登録されているが、実行フラグ、コピーフラグとも”ＯＮ”であれば、コピー、実行共に完了しているので、該領域にクエリを上書きしてもよい。また、ＬＩ＋１が指す領域の実行フラグ、コピーフラグとも”ｎｕｌｌ”である場合には、トランザクションキューに未登録の空きがある。
【００５５】
クエリの新規登録が不可能な場合は、クライアント（ＵＡＰ）に対しクエリの受付ができないことを通知し（ステップ６０７）、ステップ６０４へ戻る。
【００５６】
一方、クエリの新規登録が可能な場合は、ＬＩ＋１が指す領域にクエリが属するトランザクションのＩＤ、クエリの内容をセットする（ステップ６０９）。コピーフラグ、実行フラグは共にＯＦＦにセットされる。続いて、ステップ６１０において、ＬＩポインタを更新（ＬＩ＝ＬＩ＋１にインクリメント）し、ステップ６０４へ戻る。
【００５７】
図５は、本発明の第１の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【００５８】
正サイトのトランザクション同期化・実行部３０２では、コピー済みのクエリについては、クエリを実行する。一方、未コピークエリに関しては、クエリがコミットでなければ実行し、クエリがコミットである場合は、キュー内の未コピークエリを一括同期コピーする。
【００５９】
まず、実行ポインタＥＩが指す実行処理手順判定の対象のクエリが未実行であるかを判定する（ステップ７０２）。すなわち、ＥＩが指すクエリが未実行であれば、実行すべきクエリがあることが分かる。
【００６０】
実行すべきクエリがない場合は、実行ポインタＥＩの更新（インクリメント）の可否（すなわち、新たなクエリが入力されたか）を判定する（ステップ７０４）。ＥＩが更新可能なら、ＥＩを更新し（ステップ７０６）、ステップ７０９へ進む。一方、ＥＩが更新不可能なら、ステップ７０４へ戻る。
【００６１】
ステップ７０２において、ＥＩポインタが指すクエリが未実行であると判定されると、該クエリがコピー済みであるか否かを判定する（ステップ７０９）。
【００６２】
ＥＩポインタが指すクエリが未コピーである場合は、該クエリがコミットであるか否かを判定する（ステップ７１１）。該クエリがコミットでない場合は、該クエリを実行し、該クエリの実行フラグをＯＮにする（ステップ７１２）。続いて、ＥＩの更新可否を判定し（ステップ７１３）、ＥＩが更新可能なら、ＥＩを更新し（ステップ７１５）、ステップ７１１へ戻る。一方、ＥＩが更新不可能なら、ステップ７０２へ戻る。
【００６３】
ステップ７１１において、クエリがコミットであると判定されると、ＬＩポインタの値をレジスタＬ０（図示せず）へ退避する（ステップ７１７）。続いて、キュー内の未コピークエリ（ＰＩ＋１からＬ０までのクエリ）を全て、一括同期コピーする（ステップ７１８）。同期コピーの完了後、コピーしたクエリのコピーフラグを全てＯＮにし、ＰＩポインタをＬ０に更新する（ステップ７１９）。そして、ＥＩポインタが指すクエリを実行し、該クエリの実行フラグをＯＮにする（ステップ７２０において）。
【００６４】
続いて、ＥＩの更新可否を判定し（ステップ７２１）、ＥＩが更新可能なら、ＥＩを更新し（ステップ７２３）、ステップ７０９へ戻る。一方、ＥＩが更新不可能なら、ステップ７０２へ戻る。
【００６５】
ステップ７０９において、クエリがコピー済みであると判定されると、ステップ７２５において、該クエリを実行後、実行フラグをＯＮにする。続いて、ステップ７２５において、ＥＩの更新可否を判定し（ステップ７２６）、ＥＩが更新可能なら、ＥＩを更新し（ステップ７２８）、ステップ７０８へ戻る。一方、ＥＩが更新不可能なら、ステップ７０１へ戻る。
【００６６】
図６は、第１の実施の形態のコピー時の正サイト１００と副サイト１１０との間のトランザクションキューの動作例を示す説明図である。
【００６７】
図６（ａ）は、２番目のクエリ（ＥＩポインタ８０４が指すクエリ）を実行するときの、正サイトのトランザクションキュー３１０、及び、副サイトのトランザクションキュー３２２の状態を表す。
【００６８】
ＥＩポインタ８０４が指すクエリは、未実行、未コピー、かつ、コミット（Ｃ）であるため（図５のステップ７１１で”ｙ”）、実行前に、キュー内の未コピークエリ（ウィンドウ８４０に含まれる、ＰＩポインタ８０２の次からＬＩポインタ８０５までのクエリ）は、副サイト１１０へ一括同期コピーされる（図５のステップ７１８）。そして、一括コピーが完了すると、正サイト及び副サイトのトランザクションキュー３１０、３２２は、図６（ａ）に示す状態となる。
【００６９】
その後、正サイトのトランザクションキュー３１０では、コピー済みクエリの最後尾を表すＰＩポインタは、ＰＩポインタが８０２の位置から８０３の位置へ更新される。続いて、コピーが完了したクエリのコピーフラグがＯＮにされ（図５のステップ７１９）、最後に、正サイト１００でＥＩポインタ８０４が指すクエリ（コミット）が実行され、該クエリの実行フラグがＯＮにされる（図５のステップ７２０）。
【００７０】
図６（ｂ）は、ウィンドウ８４０内のクエリのコピーを行ってから次のコピーが行われるまでのトランザクションキュー３１０、３２２の動作を表す。
【００７１】
正サイト１００では、任意のタイミングで、クエリが投入されており、図６（ｂ）に示す状態では、新たに４つのクエリが投入され、ＬＩポインタが８１５の位置へ更新されている。
【００７２】
ここで、コピー済みのクエリに対してはクエリの種類にかかわらず実行が可能なため、ウィンドウ８４０内のクエリ（トランザクションキュー３１０内の３番目、４番目のクエリ）は、副サイト１１０との連携を考慮することなく、正サイト１００で実行される。また、ウィンドウ８４１の外であっても、クエリがコミット以外であれば、副サイト１１０との連携を考慮することなく実行することができる。そのため、トランザクションキュー３１０内の５番目のクエリ（Ｕ：アップデイト）は、次のコピーを行う前に実行される。ただし、クエリがコミットの場合は、コピー後に実行されることになる。
【００７３】
図６（ｃ）は、６番目のクエリ（ＥＩポインタ８２４が指すクエリ）を実行するときのトランザクションキュー３１０、３２２の動作例を表す。
【００７４】
該６番目のクエリは、未実行、未コピー、かつ、コミットであるため（図５のステップ７１１で”ｙ”）、クエリの実行前に、キュー内の未コピークエリ（ウィンドウ８５０に含まれる、ＰＩポインタ８０３の次からＬＩポインタ８１５までのクエリ）は、副サイト１１０へ一括同期コピーされる（図５のステップ７１８）。そして、一括コピーが完了すると、正サイト及び副サイトのトランザクションキュー３１０、３２２は、図６（ｃ）に示す状態となる。
【００７５】
その後、正サイトのトランザクションキュー３１０では、ＰＩポインタをＰＩポインタは８０３の位置から８２３の位置へ更新され、コピーしたクエリのコピーフラグがＯＮにされ（図５のステップ７１９）、最後に、正サイト１００ＥＩ８２４ポインタが指すクエリが実行され、実行フラグがＯＮにされる（図５のステップ７２０）。
【００７６】
図６（ｄ）は、２回目のコピーを行ってから、３回目のコピーが行われるまでの間のトランザクションキュー３１０、３２０の動作を表す。
【００７７】
正サイトのトランザクションキュー３１０では、ウィンドウ８５０内のクエリはコピー済みであり、その種類に関わらず、副サイト１１０との連携を考慮することなく実行可能なため、７番目のクエリが実行されている。
【００７８】
次に、副サイト１１０における処理について説明する。
【００７９】
図７は、本発明の第１の実施の形態のトランザクション受信部３３０の処理のフローチャートである。
【００８０】
副サイトのトランザクション受信部３３０では、正サイトのトランザクション同期化・実行部３０２が送信したトランザクション情報を受信し、トランザクションのコピー状態を管理する。具体的には、トランザクションのコピー状態として、最新のコピーの範囲であるコピーウィンドウ（Ｗｎ）と、Ｗｎの直前のコピー範囲であるコピーウィンドウ（Ｗｐ）とを管理する。
【００８１】
まず、ランザクション受信部３３０では、Ｗｎ、Ｗｐを初期化する（ステップ９０１）。次に、正サイト１００からコピーされるクエリの転送を待つ（ステップ９０３）。コピーがある場合には、転送されたクエリを受付け、Ｗｎ、Ｗｐを更新する（ステップ９０５）。
【００８２】
図８は、本発明の第１の実施の形態のトランザクション実行部３３１の処理のフローチャートである。
【００８３】
トランザクション実行部では、コピーが行われる度に、Ｗｐ内のクエリを実行する。このとき、正サイト１００でコミットが実行されたか否かを判断し、判断できない場合には、回復テーブルに情報を記録する。
【００８４】
まず、直前のコピーウィンドウＷｐ内に未調査のクエリがあるか否かを判定する（ステップ９１１）。未調査クエリがある場合には、該クエリを取り出し（ステップ９１４）、該クエリを実行する（ステップ９１５）。そして、該クエリがコミットであるか否かを判定し（ステップ９１６）、コミットでない場合には、該クエリが属するトランザクションの情報が回復テーブルに登録されているか否かを判定する（ステップ９１７）。そして、該クエリが属するトランザクションの情報が回復テーブルに登録されていない場合は、該クエリが属するトランザクションの情報を登録する（ステップ９１８）。ここで、回復テーブルには、少なくとも、トランザクションのＩＤが登録される。
【００８５】
一方、ステップ９１７において、該クエリが属するトランザクションの情報が回復テーブルに登録されていると判定された場合は、トランザクション情報（クエリの内容やコピーの時間等）を回復テーブルに追加する（ステップ９２０）。なお、トランザクションのＩＤのみを登録する場合には、ステップ９２０の処理は不要である。
【００８６】
ステップ９１６において、クエリがコミットであると判定された場合は、該コミットが正サイト１００側で実行されたことがわかる。なぜなら、Ｗｐ内のクエリは最新のコピーによるものではなく、正サイト１００が、前回コピーしたクエリを全て実行した後に、クエリのコピーを行うからである。従って、該コミットが属する該トランザクション情報を、回復テーブル３４１から削除する（ステップ９１５）。
【００８７】
このようにトランザクション実行部３３１の処理によって、Ｗｐ内のクエリは全て実行される。また、正サイト１００でコミットが実行されたかどうか判断できないトランザクションに関する情報は、回復テーブル３４１に記録される。
【００８８】
図９は、本発明の第１の実施の形態のコピー時の副サイトのトランザクションキューの動作例を示す説明図であり、図９（ａ）及び（ｂ）が通常運用時の、図９（ｃ）が障害発生時の、トランザクションキュー３２２及び回復テーブル３４１の状態を示す。
【００８９】
回復テーブル３４１には、トランザクション毎に、トランザクションＩＤ、フラグ及びトランザクションの内容（クエリ）が記録される。特に重要なのは、トランザクションＩＤとフラグである。回復テーブルには、コミットが実行されていないトランザクションの情報が含まれているが、そこには、コミットそのものが投入されていない場合と、コミットは投入されているが該コミットの実行までは判断できない（グレー）場合の二つのケースがある。フラグは、この２つを分けて管理するためのもので、後者の場合には、フラグの値を”Ｇ”に設定する。
【００９０】
トランザクションの内容には、トランザクションに属するクエリの内容を記録する。ただし、クエリの内容はＤＢＭＳのトランザクションログにも記録されるため、回復テーブル３４１への記録を省略することもできる。
【００９１】
図９（ａ）は、１００１のウィンドウがコピーされた直後の、副側のトランザクションキュー３２２と回復テーブル３４１の状態を表す。副側トランザクションキュー３２２では、ウィンドウ１０００がＷｐ（直前のコピー範囲）、ウィンドウ１００１がＷｎ（最新のコピーの範囲）を表す。コピー直後のため、回復テーブル３４１には何も記録されていない。
【００９２】
図９（ｂ）は、トランザクション実行部３３１が、トランザクションキュー３２２を調査し、回復テーブル３４１を更新した直後の、トランザクションキュー３２２と回復テーブル３４１の状態を表す。トランザクション実行部３３１は、ウィンドウ１０００を調査し、ＩＤが０、１、２であるトランザクションの情報を回復テーブルに記録する。しかし、ＩＤが０と１のトランザクションについては、直前に受信したウィンドウＷｐであるウィンドウ１０００内にコミットがあるため、正サイト１００で既にコミットが実行されたと判断できる。従って、ＩＤが０と１のトランザクションの情報を回復テーブル１０２１から削除する。その結果、回復テーブル１０２１には、ＩＤが２のトランザクションの情報のみが記録される。
【００９３】
トランザクション実行部３３１では、コピーが行われる度に、コミットの実行が判断できないトランザクションの情報を更新していく。グレーかどうかの最終的な判断は、障害が発生した後に行われるため、障害発生前はフラグには値は設定されていない。
【００９４】
次に、正サイト１００で障害が生じた場合は、副サイト１１０で障害回復を行い業務を引き継ぐ処理について説明する。
【００９５】
図１０は、本発明の第１の実施の形態の副サイト１１０での障害回復処理のフローチャートである。
【００９６】
障害発生時は、Ｗｎに未調査のクエリが無くなるまで、最初に、グレーな部分の判定を行う（ステップ１２１４〜１２２５）。
【００９７】
まず、正サイトの障害を検知する（ステップ１２０１）。例えば、定期的に正サイトと副サイトの間でalive checkの通信を行い、予め定めた期間にalive checkが連続して失敗した場合に障害を検知したとすることができる。
【００９８】
次に、最新のコピーの結果であるＷｎ内のクエリを調査し、未調査のクエリがあるか否かを判定する（ステップ１２０３）。そして、未調査のクエリがあれば、該クエリを取り出し（ステップ１２１４）、該クエリがコミットかどうかを調査する（ステップ１２１５）。
【００９９】
該クエリがコミットでない場合は、回復テーブル３４１に該クエリが属するトランザクションに関する情報が既に回復テーブルに記録されているか否かを判定する（ステップ１２１６）。該トランザクションに関する情報が未登録であると判定された場合は、新規に該トランザクションの情報を回復テーブル３４１に登録する（ステップ１２１７）。一方、該トランザクションに関する情報が既に登録されている場合は、回復テーブルの内容部分にクエリの内容を追加登録する（ステップ１２１９）。
【０１００】
ステップ１２１５において、クエリがコミットであると判定されると、該クエリの実行フラグがＯＮであるか否かが判定される（ステップ１２２１）。該クエリの実行フラグがＯＮではない場合は、該クエリが属するトランザクションはグレーと判定される。なぜなら、該コミットは最新のコピーであることから、正サイト１００で最新のコピー範囲に含まれるコミットは実行されたかを判定できないためである。従って、回復テーブルの該クエリ（コミット）が属するトランザクションに関するフラグを”Ｇ”にセットする（ステップ１２２２）。一方、実行フラグがＯＮである場合は、該コミットの実行が確認されたため、該クエリ（コミットと該トランザクションで未実行であるクエリ）を実行して（ステップ１２２４）、該クエリが属するトランザクションの情報を回復テーブルから削除する（ステップ１２２５）。
【０１０１】
障害検知時の、回復テーブルの動作例を図９（ｃ）に示す。ウィンドウ１０００が直前のコピー範囲を表すＷｐであり、ウィンドウ１００１が最新のコピー範囲を表すＷｎである。Ｗｎ１００１を調査した結果、ＩＤが２のトランザクションに関しては、クエリの内容（Ｕ、Ｃ）が追加される。また、Ｗｎ１００１内にコミット（Ｃ）があり、かつ、実行フラグがＯＮでないため、ＩＤが２のトランザクションのコミット（Ｃ）は正サイト１００で実行されているかが分からないので、該トランザクションはグレーと判定され、フラグが”Ｇ”にセットされる。一方、新たなトランザクションとして、ＩＤが３、４のトランザクションが登録されるが、これらはＷｎ１００１内にコミットが含まれていないため、フラグの値はセットされない。
【０１０２】
次に、図１０に戻って、副サイトでの業務再開のための回復処理（ステップ１２０４〜１２１３）について説明する。
【０１０３】
ステップ１２０３においてＷｎ内の調査が終了が確認されると、まず、回復テーブルにおいてフラグが”Ｇ”でない（コミットが投入されていない）トランザクションをロールバックして、該トランザクションの開始以前の状態に戻す（ステップ１２０４）。
【０１０４】
続いて、回復テーブル３４１中でフラグが”Ｇ”であるトランザクション、すなわち、コミットの実行が判断できないグレーなトランザクションを特定する。そして、該トランザクションが使用したリソースを調査し、該リソースへのアクセスが拒否されるようなアクセス制限を設定する（ステップ１２０５）。例えば、ＤＭＢＳのテーブルの特定の行やセルに排他ロックをかけてアクセスを制限する。
【０１０５】
次に、正サイト１００から副サイト１１０に系を切り替え、副サイト１１０においてアクセス制限つきで限定的に業務を再開する（ステップ１２０６）。
【０１０６】
次にステップ１２０８以降で、グレーなトランザクションの回復処理を行う。まず、グレーなトランザクションを全て回復したか否かを判定する（ステップ１２０８）。グレーなトランザクションを回復が終了しておらず、グレーなトランザクションがある場合は、グレーなトランザクションの手動で回復する（ステップ１２０９）。例えば、該トランザクションを発行した企業やユーザに問い合わせることによって手動回復をする。そして、手動回復完了したら、該トランザクションが使用していたリソースに対するアクセス制限を解除する（ステップ１２１０）。一方、グレートランザクションを回復が全て完了した場合、完全な業務を再開する（ステップ１２１２）。
【０１０７】
以上説明した副サイトの処理（図７〜図１０）では、第２情報処理装置である副サイト１１０は、第１情報処理装置である正サイト１００から転送されたクエリを受信し、障害回復用の情報を生成し（図８のステップ９１８、９２０）、正サイト１００の障害を検知すると（図１０のステップ１２０１）、正サイト１００からの直前の転送範囲Ｗｐ内で、ストレージ装置３１１の記憶内容への反映が行われていないトランザクションについては、該トランザクション開始前の状態に戻すロールバック処理の対象とし、前記回復用情報から削除し（図１０のステップ１２２４）、正サイト１００からの直前の転送範囲Ｗｐ内で、ストレージ装置３１１の記憶内容への反映が行われているトランザクションについては、前記回復用情報に追加する（図１０のステップ１２１７、１２１９）。よって、正サイト１００からの直前の転送範囲Ｗｐ内で、ストレージ装置３１１の記憶内容へ反映するコミット処理が行われているトランザクションについては、前記回復用情報に追加する（図１０のステップ１２２２）ことで、手動回復対象とすることができる。
【０１０８】
以上説明した第１の実施の形態では、正、副サイト内のＤＢＭＳにトランザクションキュー３００、３２０を設け、クライアント１３０から入力されたトランザクション情報は、一旦、トランザクションキュー３００に保存され、正サイト１００において、トランザクションをコミットする際には、トランザクションキュー内にある未コピークエリを副サイト１１０へ一括して同期コピーを行い、コミット前に副サイト１１０へのコピーが完了していることが保障されているため、遠距離であってもトランザクション欠損のないＤ／Ｒシステムを実現することができる。
【０１０９】
すなわち、正サイト１００は未転送のクエリの実行時に、受け付けたクエリのうち未転送のクエリを転送し、副サイト１１０は、正サイト１００からクエリを受信するので、正サイト１００から転送されたクエリより前に転送されたクエリは、正サイト１００で既に実行されたと判定することができ、該判定されたクエリを実行して、正サイト１００と副サイト１１０とのトランザクションの同期を図ることができる。
【０１１０】
また、コピー時には、トランザクションキュー３１０内の未コピートランザクションを一括コピーするため、コピーの頻度を下げることができ、遠距離であってもトランザクション処理のスループット性能を維持することができる。
【０１１１】
また、副サイト１１０は、コピーされたトランザクションの順序関係から、正サイト１００でコミットが実行されているかどうかを判断し、コミット済みと判断できる場合は、障害発生前から順次実行しておく。傷害発生時には、コミット済みか判断不能なトランザクションのみを手動回復対象とする。判断が不能なトランザクションが関連するリソースに対してはアクセスを制限し、限定的に業務を再開するので、副サイト１１０では、正サイト１００でのトランザクションのコミット実行を完全に把握することはできないが、転送されたトランザクションを、コミットが実行されたトランザクション、コミットが実行されたかも知れないトランザクションに切り分けることが可能である。従って、障害後の回復作業においては、コミットされたかもしれないトランザクションだけに範囲を限定することができる。
【０１１２】
また、副サイト１１０では、コミット済みのトランザクションについては、順次実行していくことにより、正サイト１００側での変更が準リアルタイムで反映させていくことが可能である。したがって、正サイト１００で障害が発生し、副サイト１１０に系が切り替わる場合にも、データ反映のほとんどが完了しており、迅速な業務再開が可能となる。
【０１１３】
また、障害発生時は、グレーな部分のみアクセスを制限することによって、限定的な業務を再開することが可能となる。
【０１１４】
次に、本発明の第２の実施の形態について説明する。
【０１１５】
図１１は、本発明の第２の実施の形態のトランザクション管理部の別な構成図である。図１１に示す実施の形態では、正サイトのトランザクション管理部３００に、ポーリング部４００が設けられている。
【０１１６】
ポーリング部４００は、トランザクションキューを（例えば、定期的に）監視しており、未コピーのクエリを一括コピーする。
【０１１７】
ポーリング部４００によって、トランザクション同期化・実行部３０２でトランザクションキュー３１０よりクエリを取り出した際に、コピー済みである場合が増えるため、副サイトへのトランザクションのコピーによるトランザクション処理性能への影響を小さくすることができる。トランザクション同期化・実行部３０２では、トランザクションキュー３１０から取り出したクエリが未コピーであれば、前述した第１の実施の形態（図２）と同様の処理を行う。
【０１１８】
図１２は、本発明の第２の実施の形態のポーリング部の処理のフローチャートである。
【０１１９】
正サイトのポーリング部４００が、トランザクションのコピーを定期的に実行するため、トランザクション同期化・実行部３０２の処理において、クエリの実行時に、該クエリがコピー済みである場合が増えるため、正サイトのトランザクション処理への影響を小さくすることができる。
【０１２０】
まず、タイマを初期化（リセット）する（ステップ１１０１）。
【０１２１】
次に、予め定めたΔＴを経過しているか否かを判定する（ステップ１１０３）。
【０１２２】
ΔＴを経過している場合は、トランザクションキュー３１０内に未コピーのクエリがあるか否かを判定する（ステップ１１０５）。
【０１２３】
未コピークエリがある場合には、キュー内の未コピークエリを一括コピーする（ステップ１１０７〜１１１０）。この一括コピーでは、まず、キューの最後備を表すＬＩポインタの値をＬ０に退避し（ステップ１１０７）、未コピーであるＰＩ＋１〜Ｌ０のクエリを一括コピーする（ステップ１１０８）。コピーの完了後、クエリのコピーフラグをＯＮにし、コピー済みクエリの最後尾を表すＰＩポインタをＬ０で更新する（ステップ１１０９）。最後にタイマをリセットし（ステップ１１１０）、ステップ１１０３へ戻る。
【０１２４】
なお、この一括コピー（ステップ１１０７〜１１１０）は、同期コピー又は非同期のどちらでもよく、非同期コピーの場合には、コピーの完了を待たずに、ステップ１１０９において、クエリのコピーフラグをＯＮにし、コピー済みクエリの最後尾を表すＰＩポインタを更新することができる。
【０１２５】
図１３は、本発明の第２の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【０１２６】
ポーリング部４００による非同期コピーが行われない場合のトランザクション同期化・実行部の処理（図５）と、ステップ１３０１において相違する。すなわちステップ７２５においてコピー済みのクエリを実行する前に、非同期コピーが完了しているかが確認される（ステップ１３０１）。非同期コピーの完了を確認してから、コピー済みのクエリが実行される（ステップ７２５）。これらの処理によって、ポーリング部４００で非同期コピーを用いた場合でも、正サイト１００におけるコミットの実行前に、副サイト１１０へのコピーが完了していることを保障させることできる。
【０１２７】
なお、正サイトのポーリング部４００で、非同期コピーではなく、同期コピーを用いると、コピーの度にコピーの完了を確認するので、ステップ１３０１のようなクエリ実行前の非同期コピーの完了確認は不要となる。
【０１２８】
次に、本発明の第３の実施の形態について説明する。
【０１２９】
本発明では、正サイト１００から副サイト１１０へのクエリの同期コピーが実施されるのは、クエリの実行前であるため、クエリの実行状況は副サイト１１０に伝わらない。しかし、実行が終了した時点で、実行状況もコピーすることによって、副サイト１１０にクエリの実行状況を反映させることもできる。
【０１３０】
図１４は、本発明の第３の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【０１３１】
前述した第１の実施の形態のトランザクション同期化・実行部の処理（図５）と、ステップ１５００、１５０１、１５０２、１５０３、１５０４において相違する。すなわち、クエリの実行（ステップ７２０）の直後に、実行状況の通知を行う（ステップ１５００）。ただし、トランザクション処理性能への影響を最小限とするために、非同期コピーを用いる。なぜなら、コミット前の同期コピーはトランザクション欠損をなくすためには確実性が必要であるのに対し、グレー判定容易化のための実行状況の通知は確実性が低くてもよいためである。
【０１３２】
第３の実施の形態においては、クエリの実行状況を通知するため、トランザクションキュー３１０、３２２を、図１５に示すように、実行状況コピーの有無を示すコピーフラグ２（１４０１）を追加して構成する。非同期コピーによって実行状況を通知した時点で、このコピーフラグ２（１４０１）の値をＯＮにする。
【０１３３】
具体的には、クエリがコミットである場合（ステップ７１１）、該クエリを実行（ステップ７２０）した後、コピーフラグ２がＯＮでない（実行状況が未コピーである）クエリを一括して非同期コピーする（ステップ１５００）。そして、コピーしたクエリのコピーフラグ２をＯＮにする（ステップ１５０１）。
【０１３４】
また、クエリがコピー済みである場合（ステップ７０９）、コピー済みクエリを実行（ステップ７２５）した後に、該クエリがコミットかどうかを判定し（ステップ１５０２）、該クエリがコミットである場合には、実行状況が未通知であるクエリを一括して非同期コピーする（ステップ１５０３）。そして、コピーしたクエリのコピーフラグ２をＯＮにする（ステップ１５０４）。
【０１３５】
このように第３の実施の形態では、正サイト１００から副サイト１１０へ、クエリの実行状況を通知することによって、障害発生時の副サイトでのグレー判断処理を容易化することができる。すなわち、Ｗｎ内のコミットであっても、トランザクションの実行を確認することができ、グレーと判定され手動回復に頼らなければならない範囲を狭めることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態のＤ／Ｒシステムのシステム構成図である。
【図２】本発明の第１の実施の形態のトランザクション管理部の構成図である。
【図３】本発明の第１の実施の形態の正サイトのトランザクションキュー３１０の説明図である。
【図４】本発明の第１の実施の形態のトランザクション受付部の処理のフローチャートである。
【図５】本発明の第１の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【図６】本発明の第１の実施の形態のコピー時の正サイト１００と副サイト１１０との間のトランザクションキューの説明図である。
【図７】本発明の第１の実施の形態のトランザクション受信部３３０の処理のフローチャートである。
【図８】本発明の第１の実施の形態のトランザクション実行部３３１の処理のフローチャートである。
【図９】本発明の第１の実施の形態のコピー時の副サイトのトランザクションキューの動作例を示す説明図であり
【図１０】本発明の第１の実施の形態の副サイト１１０での障害回復処理のフローチャートである。
【図１１】本発明の第２の実施の形態のトランザクション管理部の別な構成図である。
【図１２】本発明の第２の実施の形態のポーリング部の処理のフローチャートである。
【図１３】本発明の第２の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【図１４】本発明の第３の実施の形態のトランザクション同期化・実行部の処理のフローチャートである。
【図１５】本発明の第３の実施の形態の正サイトのトランザクションキュー３１０の説明図である。
【図１６】従来のＤ／Ｒシステムのシステム構成図である。
【符号の説明】
１００ 情報処理装置（正サイト）
１０１ サーバ
１０２ ストレージ
１０３ ＤＢＭＳ（database management system）
１１０ 情報処理装置（副サイト）
１２１ ストレージ間ネットワーク
１２２ サーバ間ネットワーク
１３０ クライアント（ＵＡＰ）
３００ トランザクション管理部（正サイト）
３０１ トランザクション受付部（正サイト）
３０２ トランザクション同期化・実行部（正サイト）
３０５ 未コピートランザクション（一括同期コピー）
３０６ コピー済みトランザクション（実行）
３１０ トランザクションキュー（正サイト）
３１１ ストレージ（正サイト）
３２０ トランザクション管理部（副サイト）
３２１ トランザクション受信・実行部（副サイト）
３２２ トランザクションキュー（副サイト）
３２３ ストレージ（副サイト）
３３０ トランザクション受信部
３３１ トランザクション実行部
３４０ 障害回復部
３４１ 回復テーブル
４００ ポーリング部
４０１ 未コピートランザクション（一括同期／非同期コピー）
Claims (18)
- サーバ及びストレージ装置を有する第１計算機システムと、サーバ及びストレージ装置を有する第２計算機システムとの間で、それぞれが１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、
前記第１計算機システムが受け付けたクエリを順次実行するステップを有し、
前記第１計算機システムは、前記受け付けられたクエリによって構成されるトランザクションを記録するトランザクションキューを備え、
前記トランザクションキューには、前記トランザクションを構成するクエリが前記第２計算機システムに転送されたか否かを示す情報が記録され、
前記トランザクション同期方法は、
前記第１計算機システムのサーバが、クエリを実行しようとする際に、前記トランザクションキューに記録された情報に基づいて、該クエリが前記第２計算機システムへ転送されているか否かを判定し、
前記第１計算機システムのサーバが、該クエリが既に転送されていると判定した場合は、該クエリを実行し、
前記第１計算機システムのサーバが、該クエリが未転送であると判定した場合は、該クエリが前記ストレージ装置の記憶内容への反映を伴うコミット処理であるときには、受け付けたクエリのうち未転送のクエリを前記第２計算機システムに一括して転送し、その後に前記実行しようとするクエリを実行することを特徴とするトランザクション同期方法。 - 前記第１計算機システムのサーバが、前記実行しようとするクエリが前記第２計算機システムに未転送であると判定した場合でも、該クエリがコミット処理以外であれば、直ちに該クエリを実行することを特徴とする請求項１に記載のトランザクション同期方法。
- 前記クエリは、前記サーバ間を接続するネットワークを介して転送されることを特徴とする請求項１に記載のトランザクション同期方法。
- 前記クエリは、前記ストレージ装置間を接続するネットワークを介して転送されることを特徴とする請求項１に記載のトランザクション同期方法。
- 前記コミット処理であるクエリを実行しようとする際の一括転送に加えて、
前記第１計算機システムのサーバが、前記受け付けたクエリを所定のタイミングで監視し、前記トランザクションキューに未転送のクエリがある場合は、その未転送のクエリを、前記第２計算機システムに一括して転送する追加ステップを更に有することを特徴とする請求項１に記載のトランザクション同期方法。 - 前記追加ステップの転送によって前記第１計算機システムから第２計算機システムへのクエリの非同期コピーが成され、
前記第１計算機システムのサーバが、前記非同期コピーの完了を確認した後に、前記コミット処理を実行することを特徴とする請求項５に記載のトランザクション同期方法。 - 前記トランザクションキューには、前記コミット処理の実行情報が、前記第２計算機システムに転送されたか否かを管理する情報が含まれ、
前記コミット処理の実行後に、該コミット処理の実行情報が前記第２計算機システムに転送されていない場合は、前記第１計算機システムのサーバが、前記受け付けたクエリのうち、前記実行情報が未転送のクエリに関する実行情報を、前記第２計算機システムに一括して転送することを特徴とする請求項１に記載のトランザクション同期方法。 - サーバ及びストレージ装置を有する第１計算機システムと、サーバ及びストレージ装置を有する第２計算機システムとの間で、それぞれが１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、
前記第１計算機システムは、前記受け付けられたクエリによって構成されるトランザクションを記録するトランザクションキューを備え、
前記トランザクションキューには、前記トランザクションを構成するクエリが前記第２計算機システムに転送されたか否かを示す情報が記録され、
前記第１計算機システムのサーバが、コミット処理を実行しようとする際に、前記トランザクションキューに記録された情報に基づいて該コミット処理が未転送であると判定された場合は、受け付けたクエリのうち未転送のクエリを前記第２計算機システムに一括して転送し、その後に前記コミット処理を実行し、
前記第２計算機システムのサーバが、前記第１計算機システムから一括して転送されたクエリを受信したとき、前回に転送されたクエリは、前記第１計算機システムで既に実行されたと判定し、該判定されたクエリを実行することを特徴とするトランザクション同期方法。 - サーバ及びストレージ装置を有する第１計算機システムと、サーバ及びストレージ装置を有する第２計算機システムとの間で、それぞれが１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、
前記第２計算機システムのサーバが、前記第１計算機システムから転送されたクエリを受信し、
前記第２計算機システムのサーバが、前記転送されたクエリの範囲を記録し、
前記第２計算機システムのサーバが、当該の転送範囲及び直前の転送範囲に含まれるクエリを調査し、
前記第２計算機システムのサーバが、該直前の転送範囲内で、ストレージ装置の記憶内容へ反映を伴うコミット処理が行われていないトランザクションに関する情報を回復用の情報として記録することを特徴とするトランザクション同期方法。 - サーバ及びストレージ装置を有する第１計算機システムと、サーバ及びストレージ装置を有する第２計算機システムとの間で、それぞれが１又は２以上のクエリから構成されるトランザクションを同期化するトランザクション同期方法であって、
前記第２計算機システムのサーバが、前記第１計算機システムから転送されたクエリを受信して、障害回復用の情報を生成し、
前記第２計算機システムのサーバが、前記第１計算機システムの障害を検知すると、
前記第２計算機システムのサーバが、前記第１計算機システムからの直前の転送範囲内で、前記ストレージ装置の記憶内容への反映を伴うコミット処理が行われていないトランザクションを、当該トランザクションの開始前の状態に戻すロールバック処理の対象として、前記回復用情報から削除し、
前記第２計算機システムのサーバが、前記第１計算機システムからの直前の転送範囲内で、前記ストレージ装置の記憶内容への反映が行われているトランザクションを、前記回復用情報に記憶することを特徴とするトランザクション同期方法。 - 前記第２計算機システムのサーバが、前記第１計算機システムからの直前の転送範囲内の最新のコピー範囲のトランザクション情報の調査が完了すると、
前記第２計算機システムのサーバが、ロールバック処理の対象となったトランザクションについて、ロールバック処理を行い、
前記第２計算機システムのサーバが、前記回復用情報に記憶されたトランザクションが使用するストレージ装置の記憶内容についてのアクセスを制限し、
前記第２計算機システムのサーバが、前記第２計算機システムにおいて、投入されるトランザクションの処理を開始することを特徴とする請求項１０に記載のトランザクション同期方法。 - 前記第２計算機システムのサーバが、前記アクセスが制限されたストレージ装置の記憶内容についての回復処理が完了した後に、該記憶内容のアクセス制限を解除することを特徴とする請求項１１に記載のトランザクション同期方法。
- サーバ及びストレージ装置を有する第１計算機システムと、サーバ及びストレージ装置を有する第２計算機システムと、前記第１計算機システムと前記第２計算機システムとを接続する通信回線とから構成されるデータベースシステムにおいて、
前記第１計算機システムは、
前記第１計算機システムが受け付けたクエリによって構成されるトランザクションが、前記トランザクションを構成するクエリが前記第２計算機システムに転送されたか否かを示す情報とともに記録されるトランザクションキューと、
クエリを実行する際に、前記トランザクションキューに記録された情報に基づいて、該クエリが前記第２計算機システムへ転送されているか否かを判定するクエリ転送判定手段と、
該クエリが既に転送されている場合は、該クエリを実行するクエリ実行手段と、
該クエリが未転送である場合は、該クエリが前記ストレージ装置の記憶内容への反映を伴うコミット処理であるときには、受け付けたクエリのうち未転送のクエリを、前記第２計算機システムに一括して転送するクエリ転送手段とを備えることを特徴とするデータベースシステム。 - 前記クエリ転送手段は、
受け付けたクエリを所定のタイミングで監視し、
未転送のクエリがある場合は、前記未転送のクエリを、前記第２計算機システムに一括して転送することを特徴とする請求項１３に記載のデータベースシステム。 - 前記第１計算機システムは、
前記コミット処理の実行情報が、前記第２計算機システムに転送されたか否かを管理する転送管理手段を備え、
前記クエリ転送手段は、前記コミット処理の実行後に、該コミット処理の実行情報が前記第２計算機システムに転送されていない場合は、受け付けたクエリのうち、前記実行情報が未転送のクエリに関する実行情報を、前記第２計算機システムに一括して転送することを特徴とする請求項１３に記載のデータベースシステム。 - 前記第２計算機システムは、前記第１計算機システムから一括して転送されたクエリを受信したとき、前回に転送されたクエリは、前記第１計算機システムで既に実行されたと判定し、該判定されたクエリを実行するクエリ実行手段を備えることを特徴とする請求項１３に記載のデータベースシステム。
- 前記第２計算機システムは、
前記第１計算機システムから転送されたクエリを受信して、障害回復用の情報を生成する回復用情報生成手段と、
前記第１計算機システムの障害を検知すると、
前記第１計算機システムからの直前の転送範囲内で、ストレージ装置の記憶内容への反映を伴うコミット処理が行われていないトランザクションについては、当該トランザクションの開始前の状態に戻すロールバック処理の対象として、前記回復用情報から削除し、
前記第１計算機システムからの直前の転送範囲内で、ストレージ装置の記憶内容への反映が行われているトランザクションは、前記回復用情報に記憶する障害回復処理手段と、を備えることを特徴とする請求項１３に記載のデータベースシステム。 - 前記障害回復処理手段は、
前記直前の転送範囲内の最新のコピー範囲のトランザクション情報の調査が完了すると、
ロールバック処理の対象となったトランザクションについて、ロールバック処理を行い、
前記回復用情報に記憶されたトランザクションが使用するストレージ装置の記憶内容についてのアクセスを制限し、
前記第２計算機システムにおいて、投入されるトランザクションの処理を開始することを特徴とする請求項１７に記載のデータベースシステム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003087773A JP4283576B2 (ja) | 2003-03-27 | 2003-03-27 | トランザクション同期方法、データベースシステム及びデータベース装置 |
| US10/637,556 US7181479B2 (en) | 2003-03-27 | 2003-08-11 | Method and database system for duplicating transactions between remote sites |
| US11/647,201 US7593974B2 (en) | 2003-03-27 | 2006-12-29 | Method and database system for duplicating transactions between remote sites |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003087773A JP4283576B2 (ja) | 2003-03-27 | 2003-03-27 | トランザクション同期方法、データベースシステム及びデータベース装置 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004295540A JP2004295540A (ja) | 2004-10-21 |
| JP2004295540A5 JP2004295540A5 (ja) | 2006-05-11 |
| JP4283576B2 true JP4283576B2 (ja) | 2009-06-24 |
Family
ID=32985177
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003087773A Expired - Fee Related JP4283576B2 (ja) | 2003-03-27 | 2003-03-27 | トランザクション同期方法、データベースシステム及びデータベース装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (2) | US7181479B2 (ja) |
| JP (1) | JP4283576B2 (ja) |
Families Citing this family (36)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070266061A1 (en) * | 2004-11-08 | 2007-11-15 | Kenichirou Fujiyama | Data Multiplexing System |
| JP4249719B2 (ja) * | 2005-03-29 | 2009-04-08 | 株式会社日立製作所 | バックアップシステム、プログラム及びバックアップ方法 |
| US7685170B2 (en) * | 2005-08-04 | 2010-03-23 | International Business Machines Corporation | Journaling database queries for database replication |
| US8417680B2 (en) * | 2005-12-02 | 2013-04-09 | International Business Machines Corporation | System for improving access efficiency in database and method thereof |
| US20070203978A1 (en) * | 2006-02-09 | 2007-08-30 | Mats Ljungqvist | Reduction of I/O-operations in a server at a trading system |
| WO2008136107A1 (ja) * | 2007-04-25 | 2008-11-13 | Fujitsu Limited | 切替処理方法 |
| US8051486B2 (en) * | 2007-05-24 | 2011-11-01 | Oracle International Corporation | Indicating SQL injection attack vulnerability with a stored value |
| US20090006402A1 (en) * | 2007-06-28 | 2009-01-01 | Holger Bohle | Methods and systems for the dynamic selection of a locking strategy |
| US8266139B2 (en) * | 2008-02-12 | 2012-09-11 | Microsoft Corporation | System and interface for co-located collaborative web search |
| JP4481338B2 (ja) * | 2008-03-28 | 2010-06-16 | 株式会社日立製作所 | バックアップシステム、ストレージ装置及びデータのバックアップ方法 |
| US8234243B2 (en) * | 2008-06-19 | 2012-07-31 | Microsoft Corporation | Third tier transactional commit for asynchronous replication |
| US9239767B2 (en) * | 2008-12-22 | 2016-01-19 | Rpx Clearinghouse Llc | Selective database replication |
| US8266126B2 (en) * | 2010-03-24 | 2012-09-11 | Matrixx Software, Inc. | System with multiple conditional commit databases |
| GB2493242A (en) | 2010-05-18 | 2013-01-30 | Ibm | Transaction processing system |
| ZA201106261B (en) * | 2010-09-15 | 2012-10-31 | Tata Consultancy Services Ltd | System and method for replicating block of transactions from primary site to secondary site |
| US9424362B2 (en) * | 2010-12-17 | 2016-08-23 | Microsoft Technology Licensing, Llc | Storing and publishing contents of a content store |
| US8914390B2 (en) * | 2011-07-12 | 2014-12-16 | Facebook, Inc. | Repetitive query recognition and processing |
| US8756217B2 (en) | 2011-07-12 | 2014-06-17 | Facebook, Inc. | Speculative switch database |
| US8903951B2 (en) | 2011-07-12 | 2014-12-02 | Facebook, Inc. | Speculative database authentication |
| US9619508B2 (en) | 2011-07-12 | 2017-04-11 | Facebook, Inc. | Speculative begin transaction |
| JP6000608B2 (ja) * | 2012-04-12 | 2016-09-28 | 株式会社東芝 | レプリケーション実行装置 |
| US8856070B2 (en) | 2012-12-21 | 2014-10-07 | International Business Machines Corporation | Consistent replication of transactional updates |
| US9298398B2 (en) | 2013-04-16 | 2016-03-29 | International Business Machines Corporation | Fine-grained control of data placement |
| US9423981B2 (en) | 2013-04-16 | 2016-08-23 | International Business Machines Corporation | Logical region allocation with immediate availability |
| US9104597B2 (en) | 2013-04-16 | 2015-08-11 | International Business Machines Corporation | Destaging cache data using a distributed freezer |
| US9619404B2 (en) | 2013-04-16 | 2017-04-11 | International Business Machines Corporation | Backup cache with immediate availability |
| US9298617B2 (en) | 2013-04-16 | 2016-03-29 | International Business Machines Corporation | Parallel destaging with replicated cache pinning |
| US9104332B2 (en) | 2013-04-16 | 2015-08-11 | International Business Machines Corporation | Managing metadata and data for a logical volume in a distributed and declustered system |
| US9329938B2 (en) | 2013-04-16 | 2016-05-03 | International Business Machines Corporation | Essential metadata replication |
| US9304865B2 (en) * | 2014-03-26 | 2016-04-05 | International Business Machines Corporation | Efficient handing of semi-asynchronous raid write failures |
| WO2017094096A1 (ja) * | 2015-12-01 | 2017-06-08 | 株式会社野村総合研究所 | トランザクション処理システムおよびトランザクション制御方法 |
| US9965538B2 (en) | 2016-01-19 | 2018-05-08 | Microsoft Technology Licensing, Llc | Early thread return with secondary event writes |
| US11354247B2 (en) | 2017-11-10 | 2022-06-07 | Smart IOPS, Inc. | Devices, systems, and methods for configuring a storage device with cache |
| US10394474B2 (en) | 2017-11-10 | 2019-08-27 | Smart IOPS, Inc. | Devices, systems, and methods for reconfiguring storage devices with applications |
| US10949416B2 (en) | 2018-07-13 | 2021-03-16 | International Business Machines Corporation | Workload management across multiple data sites capable of providing active services |
| JP7308887B2 (ja) * | 2020-08-04 | 2023-07-14 | 株式会社三菱Ｕｆｊ銀行 | システム及びプログラム |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5544347A (en) | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
| US5515502A (en) * | 1993-09-30 | 1996-05-07 | Sybase, Inc. | Data backup system with methods for stripe affinity backup to multiple archive devices |
| US6453325B1 (en) * | 1995-05-24 | 2002-09-17 | International Business Machines Corporation | Method and means for backup and restoration of a database system linked to a system for filing data |
| WO1997013201A1 (en) | 1995-10-06 | 1997-04-10 | Advanced Micro Devices, Inc. | Unified multi-function operation scheduler for out-of-order execution in a superscalar processor |
| US6324654B1 (en) | 1998-03-30 | 2001-11-27 | Legato Systems, Inc. | Computer network remote data mirroring system |
| US6422706B1 (en) * | 1999-05-21 | 2002-07-23 | Karur S. Rangan | Apparatus and method for positioning a mirror in a motor vehicle to ensure correct coverage of a critical field of view |
| US6529921B1 (en) * | 1999-06-29 | 2003-03-04 | Microsoft Corporation | Dynamic synchronization of tables |
| US6594676B1 (en) * | 2000-04-10 | 2003-07-15 | International Business Machines Corporation | System and method for recovery of multiple shared database data sets using multiple change accumulation data sets as inputs |
| EP1158409B1 (en) | 2000-05-25 | 2008-05-28 | Hitachi, Ltd. | Storage system making possible data synchronisation confirmation at time of asynchronous remote copy |
| JP4546629B2 (ja) | 2000-05-25 | 2010-09-15 | 株式会社日立製作所 | 記憶システム、記憶システムの応答方法及び記録媒体 |
| US6993539B2 (en) | 2002-03-19 | 2006-01-31 | Network Appliance, Inc. | System and method for determining changes in two snapshots and for transmitting changes to destination snapshot |
| US6785789B1 (en) | 2002-05-10 | 2004-08-31 | Veritas Operating Corporation | Method and apparatus for creating a virtual data copy |
-
2003
- 2003-03-27 JP JP2003087773A patent/JP4283576B2/ja not_active Expired - Fee Related
- 2003-08-11 US US10/637,556 patent/US7181479B2/en not_active Expired - Fee Related
-
2006
- 2006-12-29 US US11/647,201 patent/US7593974B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20040193583A1 (en) | 2004-09-30 |
| US20070226276A1 (en) | 2007-09-27 |
| JP2004295540A (ja) | 2004-10-21 |
| US7181479B2 (en) | 2007-02-20 |
| US7593974B2 (en) | 2009-09-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4283576B2 (ja) | トランザクション同期方法、データベースシステム及びデータベース装置 | |
| US7925633B2 (en) | Disaster recovery system suitable for database system | |
| US7275074B2 (en) | Propagating commit times | |
| CA2550003C (en) | Geographically distributed clusters | |
| JP4668763B2 (ja) | ストレージ装置のリストア方法及びストレージ装置 | |
| CA2550614C (en) | Cluster database with remote data mirroring | |
| JP3790589B2 (ja) | 分散データベーストランザクションのコミットメント方法 | |
| US7668874B2 (en) | Disaster recovery processing method and apparatus and storage unit for the same | |
| JP5049618B2 (ja) | ディザスタリカバリシステムおよび方法 | |
| US7599967B2 (en) | No data loss system with reduced commit latency | |
| US7464113B1 (en) | Disaster recovery with bounded data loss | |
| US20060179347A1 (en) | Reliable standby database failover | |
| US20030220935A1 (en) | Method of logical database snapshot for log-based replication | |
| US20080027987A1 (en) | Replicating data between heterogeneous data systems | |
| US20050262170A1 (en) | Real-time apply mechanism in standby database environments | |
| EP1618475A2 (en) | Flashback database | |
| US20100088556A1 (en) | Fault management system in multistage copy configuration | |
| JP2010033398A (ja) | トランザクションを処理する本番システムと該本番システムのバックアップ・システムである代行システムとを含む本番−代行システム | |
| JP4289056B2 (ja) | 計算機システム間のデータ二重化制御方法 | |
| JP4998010B2 (ja) | データベースシステム管理、データベースシステム、プログラム及び処理装置 | |
| Hvasshovd et al. | Shared-Nothing Approaches | |
| Hu et al. | Failure Handling in an Optimized Two-Safe Approach to Maintaining Remote Backup Systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060320 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060320 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081216 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090216 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090317 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090319 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120327 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120327 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130327 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130327 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |