JP2007219598A - 多重化データベースシステム及びその同期化方法、データベースサーバ、並びに、データベースサーバプログラム - Google Patents

Abstract

【課題】 複数のトランザクションを並行処理しても各データベース間で矛盾の生じることがない多重化データベースシステムにおける同期化方法を提供する。
【解決手段】 仲介装置２００が、クライアント３００からの処理要求を複数のサーバ１００に転送し、各サーバ１００から受信した応答結果のうち正当なものをクライアント３００に返す多重化データベースシステムにおいて、仲介装置２００は処理要求に順序番号を付与する。各サーバ１００は該順序番号に基づき処理要求を並べ替えるとともに、サーバ１００においてロック競合等が生じないようＤＢＭＳ１２０への投入順序を制御する。
【選択図】 図１

Description

本発明は、複数のデータベースマネージメントシステム（ＤＢＭＳ）を並列動作させた多重化データベースシステムに関し、特に各データベース間の同期技術に関する。

従来の多重化データベースシステムは、例えば特許文献１に記載されたものが知られている。このシステムでは、図２２に示すように、それぞれデータベースを備えた２つの計算機１０１０と計算機１０２０が通信回線により接続されている。各計算機１０１０と１０２０とは、いわゆる二相コミット制御によりデータベース間の同期が図られている。

計算機１０１０は、各種の業務処理を実行する応用プログラム１０１１と、データベース１０１４の検索及び更新の制御を行うとともにトランザクションモニタ１０１３を介して他の計算機１０２０のデータベース１０２４における更新処理との同期を取るデータベース管理システム１０１２と、いわゆる二相コミット制御によってデータベース１０１４と１０２４の更新処理の同期をとるトランザクションモニタ１０１３とから構成される。計算機１０２０についても計算機１０１０と同様に、応用プログラム１０２１と、データベース管理システム１０２２と、トランザクションモニタ１０２３とから構成されている。

本システムにおいて、計算機１０１０のデータベース１０１４と計算機１０２０のデータベース１０２４で同じデータを保持し、更新があった場合でも両方のデータベース１０１４と１０２４に同じ更新が反映される処理手順について説明する。

応用プログラム１０１１は、あるトランザクション内でデータベース１０１４と１０２４を同一クエリで更新する。データベース１０１４は、データベース管理システム１０１２が更新し、データベース１０２４はデータベース管理システム１０２２が更新する。

そして、応用プログラム１０１１は、トランザクションの最後に今までの更新を確定する「ＣＯＭＭＩＴ要求」又は今までの更新を取り消す「ＲＯＬＬＢＡＣＫ要求」を発行する。「ＣＯＭＭＩＴ要求」又は「ＲＯＬＬＢＡＣＫ要求」は、トランザクションモニタ１０１３によってデータベース管理システム１０１２と、トランザクションモニタ１０２３を経由してデータベース管理システム１０２２へ送られる。

例えば、トランザクションモニタ１０１３が「ＣＯＭＭＩＴ要求」を転送した場合、データベース管理システム１０１２と１０２２は、ＣＯＭＭＩＴ実行の可否をトランザクションモニタ１０１３へ返答する。この際、データベース管理システム１０１２と１０２２は実際にはＣＯＭＭＩＴを実行せず、実行の可否のみを答えるのみである。

トランザクションモニタ１０１３及び１０２３は、データベース管理システム１０１２及び１０２２の双方から「ＣＯＭＭＩＴ可」の応答を受け取ると、それぞれデータベース管理システム１０１２及び１０２２に「ＣＯＭＭＩＴ実行」を送信する。「ＣＯＭＭＩＴ実行」を受け取ったデータベース管理システム１０１１２と１０２２は、実際にＣＯＭＭＩＴを実行する。

一方、例えばトランザクションモニタ１０１３が、データベース管理システム１０１２又は１０２２の一方から「ＣＯＭＭＩＴ不可」の応答を受け取った場合、他方の応答が「ＣＯＭＭＩＴ可」であったとしても、データベース管理システム１０１２と１０２２に対して「ＲＯＬＬＢＡＣＫ実行」を送信し、トランザクションをキャンセルする。「ＲＯＬＬＢＡＣＫ実行」を受け取ったデータベース管理システム１０１２と１０２２は、実際にＲＯＬＬＢＡＣＫを実行する。

以上のようにして、どちらか一方のデータベースだけ更新が反映されることを防ぎ、両方のデータベースに対して常に同一の更新が行われるようにすることで、データベース間の同期を保つ。
特開平６−１６１８６２号公報

しかしながら、上述の従来技術は、複数のデータベースにおける一トランザクションのデータベースの同期を図る方法であって、複数のトランザクション間でのデータベースの同期を制御することはできない。つまり、複数のトランザクションが並行に実行されている状態で、且つ、それらのトランザクションが同一のテーブルの同一行にほぼ同時にアクセスした場合には、データベースの同期が崩れたり、クライアントへ返す返答が一意に決まらないなどの問題が生じる。この問題点について以下に具体的に例示する。

図２３に示すｔｅｓｔ＿ｔａｂｌｅという名前のテーブルを考える。この時、図２４に示すトランザクションＴ１及びＴ２がほぼ同時に実行される場合を考える。トランザクションＴ１はｉｄ＝１０１の行を更新し、トランザクションＴ２はｉｄ＝１０１の行とｉｄ＝１０２の行を更新する。どちらのトランザクションのＵＰＤＡＴＥが先に実行されるかによって、ｉｄ＝１０１の値は異なってしまう。

２つのトランザクション中のＵＰＤＡＴＥが実行される順序は以下の２通りが考えられる。

（１）Ｔ１のＵＰＤＡＴＥの後にＴ２のＵＰＤＡＴＥ
（２）Ｔ２のＵＰＤＡＴＥの後にＴ１のＵＰＤＡＴＥ
（１）の場合、２つのトランザクション実行後にはＴ２のＵＰＤＡＴＥが残り、ｄｅｐａｒｔｍｅｎｔ＝２となる。一方（２）の場合、２つのトランザクション実行後にはＴ１のＵＰＤＡＴＥが残り、ｄｅｐａｒｔｍｅｎｔ＝１となる。すなわち、（１）と（２）では最終的なテーブルｔｅｓｔ＿ｔａｂｌｅのデータが異なる。

つまり、複数のデータベースの初期状態が同じで、且つ、同じトランザクションを実行したとしても、あるＤＢＭＳでは（１）の順で実行し、別のＤＢＭＳは（２）の順で実行した場合、２つのデータベースは同期状態（同じデータを保持している状態）が崩れてしまう問題が発生する。

また、別の例として、図２５に示すトランザクションＴ３及びＴ４がほぼ同時に実行される場合を考える。トランザクションＴ４のＳＥＬＥＣＴがトランザクションＴ３のＣＯＭＭＩＴの前に実行されるか又は後に実行されるかで、トランザクションＴ４のＳＥＬＥＣＴで得られる値は異なってしまう。

トランザクションＴ４のＳＥＬＥＣＴとトランザクションＴ３のＣＯＭＭＩＴが実行される順序は以下の２通りが考えられる。

（３）Ｔ４のＳＥＬＥＣＴの後にＴ３のＣＯＭＭＩＴ
（４）Ｔ３のＣＯＭＭＩＴの後にＴ４のＳＥＬＥＣＴ
（３）の場合、トランザクションＴ４のＳＥＬＥＣＴ実行後には、トランザクションＴ３のＵＰＤＡＴＥが反映されていない古い値ｄｅｐａｒｔｍｅｎｔ＝３が得られる。一方（４）の場合、トランザクションＴ４のＳＥＬＥＣＴ実行後には、トランザクションＴ３のＵＰＤＡＴＥが反映された値ｄｅｐａｒｔｍｅｎｔ＝１が得られる。

つまり、複数のデータベースの初期状態が同じで、且つ、同じトランザクションを実行したとしても、あるＤＢＭＳは（３）の順で実行し、別のＤＢＭＳは（４）の順で実行した場合、得られる値が異なってしまう。

本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、複数のトランザクションを並行処理しても各データベース間で矛盾の生じることがない多重化データベースシステムにおける同期化方法を提供することにある。

上記目的を達成するために、本願発明は、複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおいて、各データベースサーバは、仲介装置から受信した処理要求の実行順序を制御する実行順序制御手段と、実行順序制御手段で順序制御された処理要求を実行するデータベース管理システムとを備える。

仲介装置は、クライアントから受信した処理要求に順序番号を付して各データベースサーバに転送する。

一方、各データベースサーバの実行順序制御手段は、まず、仲介装置から受信した処理要求を該処理要求に付された順序番号にしたがって並べ替える。そして、実行順序制御手段は、並び替えられた処理要求について、順序番号順に、（イ）処理要求の実行によりデータベース管理システムにおいてロック競合が生じる可能性があるか否かを判定し、（ロ）ロック競合が生じる可能性がある場合には該処理要求を所定の記憶手段に記憶し、（ハ）ロック競合が生じる可能性がない場合にはデータベース管理システムに転送する。一方、実行順序制御手段は、前記記憶手段に記憶されている処理要求がロック競合を起こす可能性がなくなると該処理要求をデータベース管理システムに転送する。

本発明によれば、仲介装置においてクライアントコンピュータから受信した各処理要求に順序番号が付されるので、例えば通信障害等により各データベースサーバが受信する処理要求の順序が入れ替わった場合でも全てのデータベースサーバにおいて一意の順序で処理要求の処理が可能となる。また、各データベースサーバの実行制御部は、データベース管理システムでロック競合が生じる可能性のある処理要求を所定の記憶手段に一時保存し、ロック競合が生じる可能性がなくなってから当該処理要求をデータベース管理システムに投入する。これにより、各データベースサーバ間におけるロック競合に基づく処理結果の相違を防止できる。すなわち、各データベースサーバの同期が図れる。

また、本願発明では、さらに、各データベースサーバの実行順序制御手段が、並び替えられた処理要求について、順序番号順に、（イ）第１の処理要求と該第１の処理要求より新しい順序番号を有する第２の処理要求との間で各処理要求の実行順序の先後により処理結果が異なる可能性があるか否かを判定し、（ロ）処理結果が異なる可能性がない場合には各処理要求をデータベース管理システムに転送し、（ハ）処理結果が異なる可能性がある場合には前記第１の処理要求をデータベース管理システムに転送するとともに、前記第２の処理要求を所定の記憶手段に記憶する。一方、前記記憶手段に記憶されている第２の処理要求に対応する第１の処理要求の実行がデータベース管理システムにおいて完了すると、該第２の処理要求をデータベース管理システムに転送する。

本発明によれば、実行順序の先後により処理結果が相違する可能性のある２つの処理要求について、全てのデータベースサーバにおいて、古い順序番号が付された処理要求の実行が完了した後に新しい順序番号が付された処理要求が実行されることが保証される。これにより、各データベースサーバの同期が図れる。

以上説明したように本発明によれば、複数のトランザクションを並行処理させても各データベースサーバのデータベース管理システムでは常に一意の順番で処理要求が実行されるので、各データベースサーバ間の矛盾を未然に防止できる。

本発明の一実施の形態に係る多重化データベースシステムについて図面を参照して説明する。図１は本実施の形態に係る多重化データベースシステムの全体構成を説明するブロック図である。

この多重化データベースシステムは、図１に示すように、複数のデータベースサーバ（以下「サーバ」と言う）１００と仲介装置２００とをネットワークを介して接続したものであり、１以上のクライアントコンピュータ（以下「クライアント」と言う）３００からアクセスされる。本実施の形態では、図１に示すように、２台のサーバ１００ａ及び１００ｂを有しており、２台のクライアント３００ａ及び３００ｂからアクセスされる。以降の説明において各サーバ１００を他のサーバ１００と区別する場合には添え字「ａ」「ｂ」を付加するものとする。クライアント３００についても同様である。なお、各装置間のネットワーク形態やプロトコルは不問である。本実施の形態では、ＴＣＰ／ＩＰを用いたネットワーク上において同期通信を行うものとする。

仲介装置２００は、クライアント３００側のＩＰアドレスをクライアント３００に公開しており、クライアント３００はデータベースにアクセスしたいときには当該ＩＰアドレス宛にクエリを送信する。またクエリに対する応答の発信元アドレスは当該ＩＰアドレスとなっている。これは、クライアント３００からみると、１つのデータベースサーバとパケットを送受信していることと等価なため、このデータベースサーバを仮想サーバ４００と考えることができる。この仮想サーバ４００の目的は、サーバ１００が冗長化されていることを隠蔽するためである。つまり、サーバ１００ａ及び１００ｂが両方稼働していようと、また片方のサーバ１００ａがダウンして他方のサーバ１００ｂのみが稼働していようと、さらに新たなサーバが追加されようと、クライアント３００には影響はなく、設定・動作を変更する必要がない。

仲介装置２００は、図１に示すように、サーバ制御部２１０と、順序番号付与部２２０と、トランザクションＩＤ付与部２３０とを備えている。

仲介装置２００のサーバ制御部２１０は、クライアント３００からクエリを受信すると、当該クエリを正常稼働中のサーバ１００に転送する。このときサーバ制御部２１０から各サーバ１００に転送するクエリには、順序番号付与部２２０及びトランザクションＩＤ付与部２３０により順序番号及びトランザクションＩＤが付与される。各サーバ１００では仲介装置２００を介してクライアント３００から受信したクエリを処理し、処理結果を仲介装置２００に返す。仲介装置２００のサーバ制御部２１０は、各サーバ１００から受信した応答を互いに比較して応答の正当性を判断することによりサーバ１００における障害を検出し、正当な応答の１つをクライアント３００に返す。正当でない応答を返したサーバ１００又は無応答のサーバ１００は障害が発生したと判断し、当該サーバ１００をシステムから切り離す。

応答の正当性判断方法は、例えば、サーバ１００が３台以上ある場合には多数決で決める方法や、受信した応答を所定のルールに基づいて判断する方法がある。例えば、クライアント３００からの「参照」要求に対して「更新成功」という応答が返ってきた場合、正常であればそのような応答はあり得ないので（「参照成功」など参照に関する応答のはず）、この応答は正しくないと判断する。また、応答パケット中にデータ長フィールドがある場合、このデータ長フィールドの値と実際に受信した応答パケット長を比較し、異なる場合は正しくないと判断する。また、複数のサーバ１００の中からＭａｓｔｅｒサーバを予め１台決めておき、このサーバ１００からの応答を常に正しいと判断する。また、上記複数の方法を併用する方法もある。例えば、３台で多数決を行った結果、応答の中身が全てバラバラであり、多数派のパケットを決められない場合はＭａｓｔｅｒサーバの応答を正しいと判断する。正常稼働しているサーバが１つだけの場合は、そのサーバからの応答を正常と判断する。

順序番号付与部２２０は、サーバ制御部２１０がクライアント３００から受信したクエリに対して順序番号を付与する。順序番号が付与されたクエリは、前述したようにサーバ制御部２１０により各サーバ１００に送信される。ここで、順序番号とは、仲介装置２００におけるクエリの受信順序を一意に特定するためのものであり、数字や文字列などの表現形態や降順・昇順の区別等は不問である。本実施の形態では、処理の簡便性という観点から昇順の連番を用いる。なお、順序番号の付与は、各クエリがどのトランザクションに属しているかとは無関係に、単純に仲介装置２００が受信した順番で付与する。また、順序番号が付せられたクエリはサーバ制御部２１０から各サーバ１００に送信されるが、この送信順序は順序番号通りである必要はない。これは、後述するように、各サーバ１００において当該順序番号に基づいてクエリの順序を再現可能だからである。

トランザクションＩＤ付与部２３０は、サーバ制御部２１０がクライアント３００から受信したクエリに対してトランザクションＩＤを付与する。詳しくは、トランザクションＩＤ付与部２３０は、クエリが新たなトランザクションを開始するものである場合、新たなトランザクションＩＤを生成し、これを当該クエリに付与する。また、クエリが既存のトランザクションに属するものの場合、当該トランザクションのトランザクションＩＤを付与する。

データベースサーバ１００は、実行順序制御部１１０と、データベース管理システム（ＤＢＭＳ）１２０と、記憶装置１３０とを備えている。

実行順序制御部１１０は、仲介装置２００から受信したクエリを当該クエリに付与された順序番号にしたがって並べ替え、順序番号順にＤＢＭＳ１２０に送信する。なお、ＤＢＭＳ１２０に送信するクエリは、仲介装置２００で付せられた順序番号及びトランザクションＩＤは取り除かれたものである。ここで、実行順序制御部１１０は、送信しようとするクエリが所定の条件を満たす場合には、前記順序番号に関わらず当該クエリを所定の記憶装置に一時的に待機させ、他のクエリを先にＤＢＭＳ１２０に送信する。この処理については後述する。

ＤＢＭＳ１２０は、ＳＱＬ（Structured Query Language）を解して処理を行うＲＤＢＭＳ（Relational Database Management System）である。このＤＢＭＳ１２０は、複数のトランザクションの並行処理をサポートしたものであり、トランザクション隔離レベルとして少なくともＲＥＡＤ ＣＯＭＭＩＴＥＤとＳＥＲＩＡＬＩＺＡＢＬＥをサポートしている。このようなＤＢＭＳ１２０としては種々の市中品があり、例えばＴｈｅ ＰｏｓｔｇｒｅＳＱＬ Ｇｌｏｂａｌ Ｄｅｖｅｌｏｐｍｅｎｔ ＧｒｏｕｐによるＰｏｓｔｇｒｅＳＱＬ（http://www.postgres.org/）や、Ｏｒａｃｌｅ社によるＯｒａｃｌｅ（登録商標）（http://www.oracle.com）などが挙げられる。

記憶装置１３０は、ＤＢＭＳ１２０が実際にデータを記憶する媒体であり、磁気記憶装置や光学式記憶装置や光磁気式記憶装置などが挙げられる。この記憶装置１３０は、サーバ１００に内蔵しても外付けであってもよく、さらにはネットワークを介して他の装置に設けてもよい。

次に、実行順序制御部１１０の詳細について図２〜３を参照して説明する。図２は実行順序制御部１１０のブロック図である。図２に示すように、実行順序制御部１１０は、クエリ並べ替え部１１１と、テーブルロック管理部１１２と、行ロック管理部１１３と、ＣＯＭＭＩＴ実行管理部１１４と、クエリ実行管理部１１５と、所定の記憶手段に記憶されたクエリ完了情報１１６とを備えている。

クエリ並べ替え部１１１は、仲介装置２００から受信したクエリを、該クエリに付与された順序番号に基づき並べ替えて、順次、後段のテーブルロック管理部１１２に渡す。このような処理を行うため、クエリ並べ替え部１１１は受信したクエリを一時記憶するためのバッファ領域（図示省略）を備える。

ところで、このクエリ並べ替え部１１１により、全てのサーバ１００は、仲介装置２００が各クライアント３００から受信したクエリの受信順序を一意に把握できる。したがって、各サーバ１００において当該順序に従って各クエリを順次ＤＢＭＳ１２０に投入すれば各サーバ１００間での処理結果の矛盾は生じないと考えることもできる。しかしながら、この種のＤＢＭＳ１２０では、処理の高速化等の観点から複数のトランザクションを並列実行できるようになっているので、クエリの投入順序とその実行順序が保証されないのが一般的である。したがって、全てのサーバ１００で仲介装置２００が受信した順番でＤＢＭＳ１２０にクエリを順次投入しても、各サーバ１００間での処理結果の同一性が保証されない。

この問題を解決するためには、ＤＢＭＳ１２０においてクエリの並列処理を行わないように前記順序番号に基づいてクエリを１つずつＤＢＭＳ１２０に投入することも考えられるが、この場合には処理能力が著しく低減するので現実的ではない。

そこで、本発明に係る実行順序制御部１１０では、テーブルロック管理部１１２と、行ロック管理部１１３と、ＣＯＭＭＩＴ実行管理部１１４と、クエリ実行管理部１１５とが互いに協働して、各サーバ１００のＤＢＭＳ１２０において一意の処理結果が得られるように、クエリ並べ替え部１１１で昇順に並び替えられたクエリのＤＢＭＳ１２０への投入順序とタイミングを制御する。この順序制御の方法について図３を参照して説明する。

図３の表は、２つのＳＱＬ間で順序制御が必要か否かを表したものである。図３に示すように、ＬＯＣＫ ＴＡＢＬＥと、ＩＮＳＥＲＴ・ＵＰＤＡＴＥ・ＤＥＬＥＴＥ・ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥ・他のＬＯＣＫ ＴＡＢＬＥとの間では、アクセス先が同一テーブルの場合にテーブルロック競合が発生するため順序制御が必要となる。ＤＢＭＳ１２０がＡＣＣＥＳＳ ＥＸＣＬＵＳＩＶＥ ＭＯＤＥをサポートする場合には、ＬＯＣＫ ＴＡＢＬＥとＳＥＬＥＣＴとの間でも順序制御が必要となる。ここで、ＡＣＣＥＳＳ ＥＸＣＬＵＳＩＶＥ ＭＯＤＥとは、他の全てのロックモードと競合し、同時に起こる全ての操作からロックしたテーブルを保護するモードを意味する。例えば、前述のＰｏｓｔｇｒｅＳＱＬでは当該モードをサポートしている。これらのテーブルロックに起因する順序制御はテーブルロック管理部１１２で行う。

また、図３に示すように、更新クエリ同士は、すなわちＵＰＤＡＴＥとＤＥＬＥＴＥとＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥとは、アクセス先が同一テーブルの同一行の場合に行ロック競合が生じるため相互に順序制御が必要となる。実際に行ロック競合を起こすか否かは、更新クエリを実行する前にＳＥＬＥＣＴでどの行を更新するかを検査することにより知ることができる。同一行を更新しないならば順序制御は不要である。この行ロックに起因する順序制御は行ロック管理部１１３で行う。

さらに、図３に示すように、ＣＯＭＭＩＴと、ＵＰＤＡＴＥ・ＤＥＬＥＴＥ・ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥ・ＳＥＬＥＣＴ・ＳＥＴ ＴＲＡＮＳＡＣＴＩＯＮ ＩＳＯＬＡＴＩＯＮ ＬＥＶＥＬ ＳＥＲＩＡＬＩＺＡＢＬＥとは、ＣＯＭＭＩＴを契機に今までの更新が確定しデータが実際に更新するため実行順序の前後により処理結果が異なる場合がある。したがって順序制御が必要となる。なお、ＤＤＬ文（データ定義言語文）もＣＯＭＭＩＴと同様である。この順序制御はＣＯＭＭＩＴ実行管理部１１４で行う。

テーブルロック管理部１１２は、図２に示すように、テーブルロック管理表１１２ａと、ＦＩＦＯ型のキュー１１２ｂとを備えている。テーブルロック管理部１１２は、（１）前段のクエリ並べ替え部１１１から渡されたクエリがテーブルロック競合を起こす可能性がある場合に当該クエリをキュー１１２ｂに保存し、テーブルロック競合を起こす可能性がない場合には当該クエリを後段の行ロック管理部１１３に渡し、（２）キュー１１２ｂに保存してあるクエリがテーブルロック競合を起こす可能性がなくなった場合、当該クエリをキュー１１２ｂから取り出して後段の行ロック管理部１１３に渡す。テーブルロック管理部１１２の詳細動作については後述する。

テーブルロック管理表１１２ａは、ＤＢＭＳ１２０全体に対して１つ設けられており、ＤＢＭＳ１２０内の各テーブルについてのテーブルロック状況を記憶・管理するものである。図４にテーブルロック管理表１１２ａの一例を示す。図４に示すように、テーブルロック管理表１１２ａは、テーブル名，実行中のトランザクションのトランザクションＩＤ，ロック状況という情報を保持する。トランザクションＩＤは、仲介装置２００で生成されクエリに付与されたものである。このトランザクションＩＤの欄は、トランザクションは複数並行して実行している場合には複数のトランザクションＩＤが格納される。ロック状況の欄は、「ＬＯＣＫ」「ＷＡＩＴＩＮＧ」「ＵＮＬＯＣＫ」という３つの値を取りうる。

「ＬＯＣＫ」は、当該テーブルについて現在ＬＯＣＫ ＴＡＢＬＥを実行中のトランザクションが存在することを意味する。テーブルロック管理部１１２は、テーブルロック管理表１１２ａを参照し、クエリ並べ替え部１１１から渡されたクエリの対象テーブルが「ＬＯＣＫ」であり、且つ、当該クエリがＬＯＣＫ ＴＡＢＬＥを実行中のトランザクションに属さない場合には、当該クエリをキュー１１２ｂに保持する。

「ＷＡＩＴＩＮＧ」は、ＬＯＣＫ ＴＡＢＬＥを実行しようとしたが他のトランザクションが実行中であるため、当該ＬＯＣＫ ＴＡＢＬＥがキュー１１２ｂに保持されている状態を意味する。テーブルロック管理部１１２は、実行中のトランザクションがＬＯＣＫ ＴＡＢＬＥのトランザクションだけになると、ロック状況を「ＬＯＣＫ」に変更し、ＬＯＣＫ ＴＡＢＬＥを実行する。また、ＬＯＣＫ ＴＡＢＬＥ以外の実行中トランザクションに属するクエリは順次後段の行ロック管理部１１３に渡す。さらに、新規に開始されるトランザクションのクエリをキュー１１２ｂに保持する。

「ＵＮＬＯＣＫ」は、ＬＯＣＫ ＴＡＢＬＥを実行中でもないし、実行待ちでもない状態を意味する。テーブルロック管理部１１２は、前段のクエリ並べ替え部１１１から渡されたクエリがＬＯＣＫ ＴＡＢＬＥであり、且つ、他のトランザクションが実行中ならば当該ＬＯＣＫ ＴＡＢＬＥの対象テーブルについてテーブルロック管理表１１２ａのロック状況を「ＷＡＩＴＩＮＧ」に変更し、ＬＯＣＫ ＴＡＢＬＥをキュー１１２ｂにつなぐ。一方、他のトランザクションが実行中でないならば「ＬＯＣＫ」に変更し、ＬＯＣＫ ＴＡＢＬＥを行ロック管理部１１３へ渡す。前段のクエリ並べ替え部１１１から渡されたクエリがＬＯＣＫ ＴＡＢＬＥ以外の場合、テーブルロック管理部１１２は、当該クエリを行ロック管理部１１３へ渡す。

行ロック管理部１１３は、図２に示すように、行ロック管理表１１３ａと、ＦＩＦＯ型のキュー１１３ｂとを備えている。行ロック管理部１１３は、（１）前段のテーブルロック管理部１１２から渡されたクエリが行ロック競合を起こす可能性がある場合に当該クエリをキュー１１３ｂに保存し、行ロック競合を起こす可能性がない場合には当該クエリを後段のＣＯＭＭＩＴ実行管理部１１４に渡し、（２）キュー１１３ｂに保存してあるクエリが行ロック競合を起こす可能性がなくなった場合、当該クエリをキュー１１３ｂから取り出して後段のＣＯＭＭＩＴ実行管理部１１４に渡す。行ロック管理部１１３の詳細動作については後述する。

行ロック管理表１１３ａは、ＤＢＭＳ１２０内の各テーブルについて１つずつ設けられており、各テーブルにおける行ロック状況を記憶・管理するものである。図５に行ロック管理表１１３ａの一例を示す。図５に示すように、行ロック管理表１１３ａは、テーブル内の各行を一意に識別するための行ＩＤと、この行ＩＤで特定される行について行ロックしているトランザクションのトランザクションＩＤという情報を保持する。行ＩＤは、当該テーブルに設定された主キーであってもよいし、ＤＢＭＳによってはシステムによって自動付与されたＩＤ（例えば、上述のＰｏｓｔｇｒｅＳＱＬではＯＩＤ）であってもよい。

行ロック管理部１１３は、前段のテーブルロック管理部１１２から渡されたクエリが、ＵＰＤＡＴＥ，ＤＥＬＥＴＥ，ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥの何れかの場合、これらのクエリを実行する前に、ＳＥＬＥＣＴでアクセスする行を検出する。検出方法は、元のクエリのＷＨＥＲＥ句を使って行ＩＤを取得し、行ロック管理表１１３ａに蓄積されている行ＩＤと比較する。もし、重複がなければその行ＩＤとトランザクションＩＤを行ロック管理表１１３ａに登録し、当該クエリを後段のＣＯＭＭＩＴ実行管理部１１４に渡し、重複があれば行ロック競合が生じる可能性があるため当該クエリをキュー１１３ｂに保持する。前段のテーブルロック管理部１１２から渡されたクエリが、ＵＰＤＡＴＥ等でない場合には、当該クエリを後段のＣＯＭＭＩＴ実行管理部１１４に渡す。

ＣＯＭＭＩＴ実行管理部１１４は、図２に示すように、ＣＯＭＭＩＴ実行管理表１１４ａと、ＦＩＦＯ型のキュー１１４ｂとを備えている。ＣＯＭＭＩＴ実行管理部１１４は、（１）前段の行ロック管理部１１３から渡されたクエリが他のクエリとの間で実行順序の先後で処理結果が異なる可能性がある場合に当該クエリーをキュー１１４ｂに保存し、それ以外の場合には当該クエリを後段のクエリ実行管理部１１５に渡し、（２）キュー１１４ｂに保存してあるクエリを実行しても処理結果が一意に決定できる場合、当該クエリをキュー１１４ｂから取り出して後段のクエリ実行管理部１１５に渡す。ＣＯＭＭＩＴ実行管理部１１４の詳細動作については後述する。

ＣＯＭＭＩＴ実行管理表１１４ａは、ＤＢＭＳ１２０内の各テーブルについて１つずつ設けられており、各テーブルにおけるトランザクションのＣＯＭＭＩＴ状況を記憶・管理するものである。図６にＣＯＭＭＩＴ実行管理表１１４ａの一例を示す。図６に示すように、ＣＯＭＭＩＴ実行管理表１１４ａは、ＣＯＭＭＩＴの実行状況と、現在実行中の対象クエリ数を表す対象クエリカウンタという情報を保持する。ＣＯＭＭＩＴ状況は、ＣＯＭＭＩＴを実行中であることを示す「ＣＯＭＭＩＴ」と、他の対象クエリが実行中であるため実行待ちの状態であることを示す「ＷＡＩＴＩＮＧ」と，実行中でも実行待ちでもない状態を示す「ＮＵＬＬ」という３つの値を取りうる。対象クエリカウンタは、現在実行中の対象クエリ数に応じて増減し、０の時にＣＯＭＭＩＴを実行できる状態となることを意味する。なお、ここで対象クエリとは、前述したように、ＣＯＭＭＩＴ，ＵＰＤＡＴＥ，ＤＥＬＥＴＥ，ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥ，ＳＥＬＥＣＴ，ＳＥＴ ＴＲＡＮＳＡＣＴＩＯＮ ＩＳＯＬＡＴＩＯＮ ＬＥＶＥＬ ＳＥＲＩＡＬＩＺＡＢＬＥである。

クエリ実行管理部１１５は、前段のＣＯＭＭＩＴ実行管理部１１４から渡されたクエリを順次ＤＢＭＳ１２０に投入し、ＤＢＭＳ１２０でのクエリの処理結果に応じてクエリ完了情報１１６を更新する。

クエリ完了情報１１６の一例を図７に示す。図７に示すように、クエリ完了情報１１６は、ＣＯＭＭＩＴ実行管理対象フラグ、ＣＯＭＭＩＴ完了フラグ、終了したトランザクションＩＤという３つの情報を保持する。ＣＯＭＭＩＴ実行管理対象フラグは、ＣＯＭＭＩＴ実行管理の対象のクエリ（ＣＯＭＭＩＴ，ＵＰＤＡＴＥ，ＤＥＬＥＴＥ，ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥ，ＳＥＬＥＣＴ，ＳＥＴ ＴＲＡＮＳＡＣＴＩＯＮ ＩＳＯＬＡＴＩＯＮ ＬＥＶＥＬ ＳＥＲＩＡＬＩＺＡＢＬＥ）の実行が完了した時に、クエリ実行管理部１１５により「ＯＮ」に更新され、またＣＯＭＭＩＴ実行管理部１１４により「ＯＦＦ」に更新される。ＣＯＭＭＩＴ完了フラグは、ＣＯＭＭＩＴクエリの実行が完了した時に、クエリ実行管理部１１５により「ＯＮ」に更新され、またＣＯＭＭＩＴ実行管理部１１４により「ＯＦＦ」に更新される。終了したトランザクションＩＤは、ＣＯＭＭＩＴクエリの実行が完了した時に、当該クエリの属するトランザクションＩＤがクエリ実行管理部１１５によって追加され、またテーブルロック管理部１１２及び行ロック管理部１１３がそれぞれ独立して削除を行う。このため、終了したトランザクションＩＤは、それぞれテーブルロック管理部１１２及び行ロック管理部１１３に対応して２つのフィールドで管理する。

次に、実行順序制御部１１０のテーブルロック管理部１１２・行ロック管理部１１３・ＣＯＭＭＩＴ実行管理部１１４・クエリ実行管理部１１５の動作についてフローチャートを参照して詳述する。

まず、図８〜図１３のフローチャートを参照してテーブルロック管理部１１２の動作について説明する。

図８に示すように、テーブルロック管理部１１２は、所定の初期化処理を行うと（ステップＳ１）、終了したトランザクションが存在するか否か（ステップＳ２）、及び、前段のクエリ並べ替え部１１１からクエリを受信したか否かを監視し（ステップＳ３）、それぞれのイベント検出により以下の動作を行う。

テーブルロック管理部１１２は、クエリ完了情報１１６を参照してトランザクションの終了を検出した場合（ステップＳ２）、テーブルロック管理表１１２ａ及びクエリ完了情報１１６から当該トランザクションのＩＤを削除する（ステップＳ４）。このステップＳ４で削除したトランザクションが処理対象としていたテーブルについて、テーブルロック管理表１１２ａのロック状況が「ＵＮＬＯＣＫ」であった場合（ステップＳ５）、前記イベント検出の処理（ステップＳ２，Ｓ３）に戻る。

一方、前記ステップＳ４で削除したトランザクションが処理対象としていたテーブルについて、テーブルロック管理表１１２ａのロック状況が「ＬＯＣＫ」であった場合（ステップＳ６）、図９に示すように、当該ロック状況を「ＵＮＬＯＣＫ」に更新する（ステップＳ７）。なお、このケースは、ＬＯＣＫ ＴＡＢＬＥクエリを実行したトランザクションのみが実行されていた状況で、且つ、そのトランザクションがちょうど終了した状態である。次に、テーブルロック管理部１１２は、キュー１１２ｂが空になるまで（ステップＳ８）、当該キュー１１２ｂの先頭から順にクエリを取り出す（ステップＳ９）。取り出したクエリがＬＯＣＫ ＴＡＢＬＥクエリであり（ステップＳ１０）且つ当該クエリの対象テーブルに対する他のトランザクションが無い場合には（ステップＳ１１）、当該クエリの対象テーブルについてテーブルロック管理表１１２ａのロック状況を「ＬＯＣＫ」に更新するとともに（ステップＳ１２）、当該クエリを後段の行ロック管理部１１３へ渡し（ステップＳ１３）、前記イベント検出の処理（ステップＳ２，Ｓ３）に戻る。当該クエリの対象テーブルに対する他のトランザクションが存在する場合には（ステップＳ１１）、テーブルロック管理表１１２ａのロック状況を「ＷＡＩＴＩＮＧ」に更新し（ステップＳ１４）、前記イベント検出の処理（ステップＳ２，Ｓ３）に戻る。前記ステップＳ９で取り出したクエリがＢＥＧＩＮクエリの場合（ステップＳ１０，Ｓ１５）、取り出したクエリの属するトランザクションのＩＤをテーブルロック管理表１１２ａに登録し（ステップＳ１６）、当該クエリを後段の行ロック管理部１１３へ渡し（ステップＳ１７）、キュー１１２ｂからのクエリの取り出し処理に（ステップＳ８，Ｓ９）に戻る。前記ステップＳ９で取り出したクエリがその他のものの場合（ステップＳ１０，Ｓ１５）、当該クエリを後段の行ロック管理部１１３へ渡し（ステップＳ１７）、キュー１１２ｂからのクエリの取り出し処理に（ステップＳ８，Ｓ９）に戻る。

他方、前記ステップＳ４で削除したトランザクションが処理対象としていたテーブルについて、テーブルロック管理表１１２ａのロック状況が「ＬＯＣＫ」でなかった場合（ステップＳ６）、すなわちロック状況が「ＷＡＩＴＩＮＧ」の場合には、キュー１１２ｂの先頭はＬＯＣＫ ＴＡＢＬＥクエリが存在していることになる。この場合、テーブルロック管理部１１２は図１０に示すように、キュー１１２ｂの先頭のＬＯＣＫ ＴＡＢＬＥクエリのトランザクションだけが、ロック状況が「ＷＡＩＴＩＮＧ」となっている当該対象テーブルに対してトランザクション実行中であれば（ステップＳ１８）、当該ロック状況を「ＬＯＣＫ」に更新し（ステップＳ１９）、キュー１１２ｂの先頭からＬＯＣＫ ＴＡＢＬＥクエリを取り出して後段の行ロック管理部１１３へ渡す（ステップＳ２０）。当該処理の後に、前記イベント検出の処理（ステップＳ２，Ｓ３）に戻る。

テーブルロック管理部１１２は、前段のクエリ並べ替え部１１１からのクエリ受信を検出すると（ステップＳ３）、図８に示すように、当該受信クエリがＲＯＬＬＢＡＣＫクエリの場合には（ステップＳ２１）、受信クエリが属するトランザクションのＩＤを終了したトランザクションＩＤとしてクエリ完了情報１１６に登録する（ステップＳ２２）。

次に、受信クエリの対象となるテーブルについてテーブルロック管理表１１２ａのロック状況が「ＬＯＣＫ」の場合には（ステップＳ２３）、図１１に示すように、受信クエリが現在実行中のトランザクションに属していれば、当該クエリを後段の行ロック管理部１１３に渡し（ステップＳ２４，Ｓ２５）、他のトランザクションに属していれば当該クエリをキュー１１２ｂに保持する（ステップＳ２４，Ｓ２６）。当該処理の後に、前記イベント検出の処理（ステップＳ２，Ｓ３）に戻る。

一方、受信クエリの対象となるテーブルについてテーブルロック管理表１１２ａのロック状況が「ＷＡＩＴＩＮＧ」の場合には（ステップＳ２７）、図１２に示すように、当該受信クエリがＢＥＧＩＮ又はＬＯＣＫ ＴＡＢＬＥであれば（ステップＳ２８）、当該クエリをキュー１１２ｂに保持し（ステップＳ２９）、それ以外の場合には当該クエリを後段の行ロック管理部１１３に渡す（ステップＳ３０）。当該処理の後に、前記イベント検出の処理（ステップＳ２，Ｓ３）に戻る。

一方、受信クエリの対象となるテーブルについてテーブルロック管理表１１２ａのロック状況が「ＷＡＩＴＩＮＧ」でない場合（ステップＳ２７）、すなわち、ロック状況が「ＵＮＬＯＣＫ」の場合、図１３に示すように、受信クエリがＬＯＣＫ ＴＡＢＬＥであり（ステップＳ３１）、且つ、その対象テーブルに対する他のトランザクションが存在しない場合には（ステップＳ３２）、当該対象テーブルについてのテーブルロック管理表１１２ａのロック状況を「ＬＯＣＫ」に更新し（ステップＳ３３）、当該クエリを後段の行ロック管理部１１３に渡す（ステップＳ３４）。受信クエリがＬＯＣＫ ＴＡＢＬＥであるが（ステップＳ３１）、その対象テーブルに対する他のトランザクションが存在する場合には（ステップＳ３２）、当該クエリをキュー１１２ｂに保持し（ステップＳ３５）、当該クエリの対象テーブルについてテーブルロック管理表１１２ａのロック状況を「ＷＡＩＴＩＮＧ」に更新する（ステップＳ３６）。受信クエリがＢＥＧＩＮの場合には（ステップＳ３７）、テーブルロック管理表１１２ａに当該クエリの属するトランザクションＩＤを登録するとともに（ステップＳ３８）、当該クエリを後段の行ロック管理部１１３に渡す（ステップＳ３４）。それ以外の受信クエリはそのまま後段の行ロック管理部１１３に渡す（ステップＳ３４）。これらの処理の後に、前記イベント検出の処理（ステップＳ２，Ｓ３）に戻る。

次に、図１４〜図１５のフローチャートを参照して行ロック管理部１１３の動作について説明する。

図１４に示すように、行ロック管理部１１３は、所定の初期化処理を行うと（ステップＳ１０１）、終了したトランザクションが存在するか否か（ステップＳ１０２）、及び、前段のテーブルロック管理部１１２からクエリを受信したか否かを監視し（ステップＳ１０３）、それぞれのイベント検出により以下の動作を行う。

行ロック管理部１１３は、トランザクションの終了を検出した場合（ステップＳ１０２）、行ロック管理表１１３ａ及びクエリ完了情報１１６から当該トランザクションのＩＤを持つ行を全て削除する（ステップＳ１０４）。次に、行ロック管理部１１３のキュー１１３ｂ内の位置を指し示すポインタを当該キュー１１３ｂの先頭に設定する（ステップＳ１０５）。そして、当該ポインタの示す位置にクエリが存在するかを確認し（ステップＳ１０６）、クエリがない場合には前記イベント検出の処理（ステップＳ１０２，Ｓ１０３）に戻る。一方、クエリがある場合には、当該クエリをキュー１１３ｂから取り出し（ステップ１０７）、当該クエリの行ＩＤが行ロック管理表１１３ａに登録されているかを判定する（ステップＳ１０８）。登録されていない場合、当該クエリの行ＩＤとトランザクションＩＤを行ロック管理表１１３ａに登録するとともに（ステップＳ１０９）、当該クエリを後段のＣＯＭＭＩＴ実行管理部１１４に渡し（ステップＳ１１０）、ポインタを１つ進めて処理を前記ステップＳ１０６に移す（ステップＳ１１１）。一方、当該クエリの行ＩＤが行ロック管理表１１３ａに登録されていない場合には、ポインタを１つ進めて処理を前記ステップＳ１０６に移す（ステップＳ１１１）。

行ロック管理部１１３は、前段のテーブルロック管理部１１２からのクエリを受信すると（ステップＳ１０３）、該クエリが行ロック管理部１１３の管理対象クエリであるかを判定し（ステップＳ１１２）、対象クエリでない場合には受信クエリを後段のＣＯＭＭＩＴ実行管理部１１４に渡し（ステップＳ１１３）、前記イベント検出の処理（ステップＳ１０２，Ｓ１０３）に戻る。なお、ここで対象クエリとは、図３を参照して前述したように、ＵＰＤＡＴＥ，ＤＥＬＥＴＥ，ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥである。

前段のテーブルロック管理部１１２からの受信クエリが対象クエリの場合（ステップＳ１１２）、行ロック管理部１１３は、図１５に示すように、当該対象クエリのＷＨＥＲＥ句を流用して行ＩＤを取得するＳＥＬＥＣＴ文を生成する（ステップＳ１１４）。次に、当該ＳＥＬＥＣＴ文を後段のＣＯＭＭＩＴ実行管理部１１４に渡し（ステップＳ１１５）、その処理結果から対象クエリが更新対象（行ロック対象）とする行の行ＩＤを取得する（ステップＳ１１６）。次に、該行ＩＤが行ロック管理表１１３ａに登録されているかを判定し（ステップＳ１１７）、登録済の場合には行ロック競合が生じないよう当該対象クエリをキュー１１３ｂに保持する（ステップＳ１１８）。一方、未登録ならば取得した行ＩＤ及び対象クエリのトランザクションＩＤを行ロック管理表１１３ａに登録するとともに（ステップＳ１１９）、当該クエリを後段のＣＯＭＭＩＴ実行管理部１１４に渡す（ステップＳ１２０）。以上の処理の後、前記イベント検出の処理（ステップＳ１０２，Ｓ１０３）に戻る。

次に、図１６〜図２０のフローチャートを参照してＣＯＭＭＩＴ実行管理部１１４の動作について説明する。

図１６に示すように、テーブルロック管理部１１２は、所定の初期化処理を行うと（ステップＳ２０１）、対象クエリ又はＣＯＭＭＩＴクエリが終了したか否か（ステップＳ２０２）、及び、前段の行ロック管理部１１３からクエリを受信したか否かを監視し（ステップＳ２０３）、それぞれのイベント検出により以下の動作を行う。なお、ここで対象クエリとは、図３を参照して前述したように、ＣＯＭＭＩＴ，ＵＰＤＡＴＥ，ＤＥＬＥＴＥ，ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥ，ＳＥＬＥＣＴ，ＳＥＴ ＴＲＡＮＳＡＣＴＩＯＮ ＩＳＯＬＡＴＩＯＮ ＬＥＶＥＬ ＳＥＲＩＡＬＩＺＡＢＬＥである。また、対象クエリ又はＣＯＭＭＩＴクエリの終了検出は、クエリ完了情報１１６のＣＯＭＭＩＴ実行管理対象フラグ及びＣＯＭＭＩＴ完了フラグをそれぞれ監視すればよい。

ＣＯＭＭＩＴ実行管理部１１４は、対象クエリ又はＣＯＭＭＩＴクエリの終了を検出した場合（ステップＳ２０２）、クエリ完了情報１１６のＣＯＭＭＩＴ実行管理対象フラグ又はＣＯＭＭＩＴ完了フラグをＯＦＦに更新する（ステップＳ２０４）。次に、ＣＯＭＭＩＴ実行管理表１１４ａのＣＯＭＭＩＴ状況が「ＣＯＭＭＩＴ」であるかを判定する（ステップＳ２０５）。

ＣＯＭＭＩＴ実行管理表１１４ａのＣＯＭＭＩＴ状況が「ＣＯＭＭＩＴ」の場合は、ＣＯＭＭＩＴクエリのみが実行されていた状況で、そのＣＯＭＭＩＴクエリが終了した状況を意味する。この場合、ＣＯＭＭＩＴ実行管理部１１４は、図１７に示すように、まずＣＯＭＭＩＴ状況を「ＮＵＬＬ」に更新する（ステップＳ２０６）。

次いで、ＣＯＭＭＩＴ実行管理部１１４は、キュー１１４ｂが空であるかを判定し（ステップＳ２０７）、キュー１１４ｂが空の場合には前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。キュー１１４ｂにクエリが保持されている場合、当該キュー１１４ｂの先頭がＣＯＭＭＩＴクエリでないならば（ステップＳ２０８）、ＣＯＭＭＩＴ実行管理表１１４ａの対象クエリカウンタを１増加させ（ステップＳ２０９）、当該クエリをキュー１１４ｂから取り出して後段のクエリ実行管理部１１５に渡し（ステップＳ２１０）、処理をステップＳ２０７に移す。

一方、当該キュー１１４ｂの先頭がＣＯＭＭＩＴクエリの場合（ステップＳ２０８）、ＣＯＭＭＩＴ実行管理表１１４ａの対象クエリカウンタが０でないならば（ステップＳ２１１）、ＣＯＭＭＩＴ実行管理表１１３ａのＣＯＭＭＩＴ状況を「ＷＡＩＴＩＮＧ」に更新し（ステップＳ２１２）、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。ＣＯＭＭＩＴ実行管理表１１４ａの対象クエリカウンタが０の場合には（ステップＳ２１１）、ＣＯＭＭＩＴ状況を「ＣＯＭＭＩＴ」に更新し（ステップＳ２１３）、当該ＣＯＭＭＩＴクエリをキュー１１４ｂから取り出して後段のクエリ実行管理部１１５に渡す（ステップＳ２１４）。これらの処理の後、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。

前記ステップＳ２０５において、ＣＯＭＭＩＴ実行管理表１１４ａのＣＯＭＭＩＴ状況が「ＣＯＭＭＩＴ」でない場合は、図１６に示すように、ＣＯＭＭＩＴ実行管理表１１４ａの対象クエリカウンタを１減少させる（ステップＳ２１５）。次いで、現在のＣＯＭＭＩＴ状況が「ＮＵＬＬ」の場合は（ステップＳ２１６）、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。

前記ステップＳ２１６において、現在のＣＯＭＭＩＴ状況が「ＮＵＬＬ」でない場合、すなわちＣＯＭＭＩＴ状況が「ＷＡＩＴＩＮＧ」の場合、ＣＯＭＭＩＴ実行管理部１１４のキュー１１４ｂの先頭はＣＯＭＭＩＴクエリとなっている。ＣＯＭＭＩＴ実行管理部１１４は、図１８に示すように、ＣＯＭＭＩＴ実行管理表１１４ａの対象クエリカウンタが０でないならば（ステップＳ２１７）、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。対象クエリカウンタが０の場合には（ステップＳ２１７）、キュー１１４ｂの先頭からＣＯＭＭＩＴクエリを取り出し（ステップＳ２１８）、ＣＯＭＭＩＴ状況を「ＣＯＭＭＩＴ」に更新し（ステップＳ２１９）、当該ＣＯＭＭＩＴクエリを後段のクエリ実行管理部１１５へ渡す（ステップＳ２２０）。これらの処理の後、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。

ＣＯＭＭＩＴ実行管理部１１４は、前段の行ロック管理部１１３からのクエリを受信すると（ステップＳ２０３）、図１６に示すように、まずＣＯＭＭＩＴ実行管理表１１４ａのＣＯＭＭＩＴ状況が「ＮＵＬＬ」であるかを判定する（ステップＳ２２１）。

ＣＯＭＭＩＴ状況が「ＮＵＬＬ」の場合、図１９に示すように、受信クエリが前記対象クエリでないならば（ステップＳ２２２）、当該受信クエリを後段のクエリ実行管理部１１５へ渡し（ステップＳ２２３）、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。受信クエリが前記対象クエリであり（ステップＳ２２２）、且つ、ＣＯＭＭＩＴ以外の場合には（ステップＳ２２４）、ＣＯＭＭＩＴ実行管理表１１４ａの対象クエリカウンタを１増加させ（ステップＳ２２５）、当該受信クエリを後段のクエリ実行管理部１１５に渡し（ステップＳ２２６）、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。

受信クエリがＣＯＭＭＩＴの場合には（ステップＳ２２４）、ＣＯＭＭＩＴ実行管理表１１４ａの対象クエリカウンタが０か否かを判定する（ステップＳ２２７）。対象クエリカウンタが０の場合、ＣＯＭＭＩＴ状況を「ＣＯＭＭＩＴ」に更新し（ステップＳ２２８）、当該ＣＯＭＭＩＴクエリを後段のクエリ実行管理部１１５へ渡し（ステップＳ２２９）、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。対象クエリカウンタが０でない場合、ＣＯＭＭＩＴ実行管理部１１４のキュー１１４ｂに当該ＣＯＭＭＩＴクエリを保持し（ステップＳ２３０）、ＣＯＭＭＩＴ実行管理表１１４ａのＣＯＭＭＩＴ状況を「ＷＡＩＴＩＮＧ」に更新し（ステップＳ２３１）、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。

前記ステップＳ２２１においてＣＯＭＭＩＴ状況が「ＮＵＬＬ」でない場合、図２０に示すように、受信クエリが前記対象クエリならば（ステップＳ２３２）、当該受信クエリをＣＯＭＭＩＴ実行管理部１１４のキュー１１４ｂに保持し（ステップＳ２３３）、受信クエリが前記対象クエリでないならば（ステップＳ２３２）、当該受信クエリを後段のクエリ実行管理部１１５に渡す（ステップＳ２３４）。これらの処理の後、前記イベント検出の処理（ステップＳ２０２，Ｓ２０３）に戻る。

次に、図２１のフローチャートを参照してクエリ実行管理部１１５の動作について説明する。

図２１に示すように、クエリ実行管理部１１５は、所定の初期化処理を行うと（ステップＳ３０１）、実行するクエリがあるか否かの監視、具体的には前段のＣＯＭＭＩＴ実行管理部１１４からクエリを受信したか否かの監視（ステップＳ３０２）、対象クエリの実行が完了したか否かの監視（ステップＳ３０３）、ＣＯＭＭＩＴクエリの実行が完了した否かの監視（ステップＳ３０４）を行い、それぞれのイベント検出により以下の動作を行う。

クエリ実行管理部１１５は、前段のＣＯＭＭＩＴ実行管理部１１４からのクエリ受信を検出すると（ステップＳ３０２）、当該受信クエリをＤＢＭＳ１２０に投入する（ステップＳ３０５）。

また、クエリ実行管理部１１５は、対象クエリの実行完了を検出すると（ステップＳ３０３）、クエリ完了情報１１６のＣＯＭＭＩＴ実行管理対象フラグを「ＯＮ」に更新する（ステップＳ３０６）。なお、ここでの対象クエリは、ＣＯＭＭＩＴ，ＵＰＤＡＴＥ，ＤＥＬＥＴＥ，ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥ，ＳＥＴ ＴＲＡＮＳＡＣＴＩＯＮ ＩＳＯＬＡＴＩＯＮ ＬＥＶＥＬである。

さらに、クエリ実行管理部１１５は、ＣＯＭＭＩＴクエリの実行完了を検出すると（ステップＳ３０４）、つまりトランザクションの終了を検出すると、クエリ完了情報１１６のＣＯＭＭＩＴ完了フラグを「ＯＮ」に更新する（ステップＳ３０７）。

このような実行順序制御部１１０の処理により、各サーバ１００のＤＢＭＳ１２０に投入されるクエリの順序は各サーバ１００間で同じものとなり、且つ、ＤＢＭＳ１２０に投入されたクエリの実行によって処理結果が一意となるので、各サーバ１００の同期を図ることができる。

以上、本発明の実施形態について詳述したが、上記実施の形態は例示的なものであり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲に示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれるものである。

例えば、各ＤＢＭＳ１２０は要求に応じて同じ応答をするならば同じ実装である必要はない。すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンパイラオプション、ハードウェアかソフトウェアか、などが異なっていてもよい。サーバには、ＰｏｓｔｇｒｅＳＱＬなどのフリーソフトウェアやＯｒａｃｌｅなどの市販のソフトウェア、独自開発のソフトウェア、いずれを使ってもよい。また、それらが混在していてもよい。例えば、サーバ１００ａのＤＢＭＳ１２０ａはＰｏｓｔｇｒｅＳＱＬで、サーバ１００ｂのＤＢＭＳ１２０ｂはＯｒａｃｌｅでも良い。

また、上記実施の形態では、サーバはパソコン上のソフトウェアで実現しているが、ハードウェアで実装しても良い。

さらに、上記実施の形態では、仮想サーバ４００に含まれる仲介装置２００は１台のみであったが、複数台設けて冗長性を持たせることにより、より可用性の高い構成とすることも可能である。仲介装置を多重化させる技術については、例えば本願出願人による特開２００３−３４５６７９号公報に記載されたものなどを用いればよい。

多重化データベースシステムの構成図 データベースサーバの構成図 順序制御が必要なＳＱＬを説明する図 テーブルロック管理表の一例を説明する図 行ロック管理表の一例を説明する図 ＣＯＭＭＩＴ実行管理表の一例を説明する図 クエリ完了情報の一例を説明する図 テーブルロック管理部の動作を説明する図 テーブルロック管理部の動作を説明する図 テーブルロック管理部の動作を説明する図 テーブルロック管理部の動作を説明する図 テーブルロック管理部の動作を説明する図 テーブルロック管理部の動作を説明する図 行ロック管理部の動作を説明する図 行ロック管理部の動作を説明する図 ＣＯＭＭＩＴ実行管理部の動作を説明する図 ＣＯＭＭＩＴ実行管理部の動作を説明する図 ＣＯＭＭＩＴ実行管理部の動作を説明する図 ＣＯＭＭＩＴ実行管理部の動作を説明する図 ＣＯＭＭＩＴ実行管理部の動作を説明する図 クエリ実行管理部の動作を説明する図 従来のデータベース同期化システムの構成図 データベースのテーブルの一例 処理順序が問題となるトランザクションの一例 処理順序が問題となるトランザクションの一例

符号の説明

１００…データベースサーバ、１１０…実行順序制御部、１１１…クエリ並べ替え部、１１２…テーブルロック管理部、１１３…行ロック管理部、１１４…ＣＯＭＭＩＴ実行管理部、１１５…クエリ実行管理部、１１６…クエリ完了情報、１２０…ＤＢＭＳ、２００…仲介装置、３００…クライアント。

Claims (9)

1. 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおいて、各データベースサーバを同期化する方法であって、
   各データベースサーバは、仲介装置から受信した処理要求の実行順序を制御する実行順序制御手段と、実行順序制御手段で順序制御された処理要求を実行するデータベース管理システムとを備え、
   仲介装置が、クライアントから受信した処理要求に順序番号を付して各データベースサーバに転送するステップと、
   各データベースサーバの実行順序制御手段が、
   （ａ）仲介装置から受信した処理要求を該処理要求に付された順序番号にしたがって並べ替えるステップと、
   （ｂ）並び替えられた処理要求について、順序番号順に、（イ）処理要求の実行によりデータベース管理システムにおいてロック競合が生じる可能性があるか否かを判定し、（ロ）ロック競合が生じる可能性がある場合には該処理要求を所定の記憶手段に記憶し、（ハ）ロック競合が生じる可能性がない場合にはデータベース管理システムに転送するステップと、
   （ｃ）前記記憶手段に記憶されている処理要求がロック競合を起こす可能性がなくなると該処理要求をデータベース管理システムに転送するステップとを備えた
   ことを特徴とする多重化データベースシステムにおける同期化方法。
2. 各データベースサーバの実行順序制御手段が、
   （ｄ）並び替えられた処理要求について、順序番号順に、（イ）第１の処理要求と該第１の処理要求より新しい順序番号を有する第２の処理要求との間で各処理要求の実行順序の先後により処理結果が異なる可能性があるか否かを判定し、（ロ）処理結果が異なる可能性がない場合には各処理要求をデータベース管理システムに転送し、（ハ）処理結果が異なる可能性がある場合には前記第１の処理要求をデータベース管理システムに転送するとともに、前記第２の処理要求を所定の記憶手段に記憶するステップと、
   （ｅ）前記記憶手段に記憶されている第２の処理要求に対応する第１の処理要求の実行がデータベース管理システムにおいて完了すると、該第２の処理要求をデータベース管理システムに転送するステップとを備えた
   ことを特徴とする請求項１記載の多重化データベースシステムにおける同期化方法。
3. 前記（ｂ）の（イ）のステップは、テーブルロックが生じる可能性を判定するステップと、行レベルロックが生じる可能性を判定するステップを含む
   ことを特徴とする請求項１記載の多重化データベースシステムにおける同期化方法。
4. 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおいて、
   各データベースサーバは、仲介装置から受信した処理要求の実行順序を制御する実行順序制御手段と、実行順序制御手段で順序制御された処理要求を実行するデータベース管理システムとを備え、
   仲介装置は、クライアントから受信した処理要求に順序番号を付して各データベースサーバに転送する制御手段を備え、
   各データベースサーバの実行順序制御手段は、
   （ａ）仲介装置から受信した処理要求を該処理要求に付された順序番号にしたがって並べ替える手段と、
   （ｂ）並び替えられた処理要求について、順序番号順に、（イ）処理要求の実行によりデータベース管理システムにおいてロック競合が生じる可能性があるか否かを判定し、（ロ）ロック競合が生じる可能性がある場合には該処理要求を所定の記憶手段に記憶し、（ハ）ロック競合が生じる可能性がない場合にはデータベース管理システムに転送する手段と、
   （ｃ）前記記憶手段に記憶されている処理要求がロック競合を起こす可能性がなくなると該処理要求をデータベース管理システムに転送する手段とを備えた
   ことを特徴とする多重化データベースシステム。
5. 各データベースサーバの実行順序制御手段は、
   （ｄ）並び替えられた処理要求について、順序番号順に、（イ）第１の処理要求と該第１の処理要求より新しい順序番号を有する第２の処理要求との間で各処理要求の実行順序の先後により処理結果が異なる可能性があるか否かを判定し、（ロ）処理結果が異なる可能性がない場合には各処理要求をデータベース管理システムに転送し、（ハ）処理結果が異なる可能性がある場合には前記第１の処理要求をデータベース管理システムに転送するとともに、前記第２の処理要求を所定の記憶手段に記憶する手段と、
   （ｅ）前記記憶手段に記憶されている第２の処理要求に対応する第１の処理要求の実行がデータベース管理システムにおいて完了すると、該第２の処理要求をデータベース管理システムに転送する手段とを備えた
   ことを特徴とする請求項４記載の多重化データベースシステム。
6. 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおけるデータベースサーバであって、
   仲介装置から受信した処理要求の実行順序を制御する実行順序制御手段と、
   実行順序制御手段で順序制御された処理要求を実行するデータベース管理システムとを備え、
   前記実行順序制御手段は、
   （ａ）仲介装置から受信した処理要求を、仲介装置によって該処理要求に付された順序番号にしたがって並べ替える手段と、
   （ｂ）並び替えられた処理要求について、順序番号順に、（イ）処理要求の実行によりデータベース管理システムにおいてロック競合が生じる可能性があるか否かを判定し、（ロ）ロック競合が生じる可能性がある場合には該処理要求を所定の記憶手段に記憶し、（ハ）ロック競合が生じる可能性がない場合にはデータベース管理システムに転送する手段と、
   （ｃ）前記記憶手段に記憶されている処理要求がロック競合を起こす可能性がなくなると該処理要求をデータベース管理システムに転送する手段とを備えた
   ことを特徴とするデータベースサーバ。
7. 前記実行順序制御手段は、
   （ｄ）並び替えられた処理要求について、順序番号順に、（イ）第１の処理要求と該第１の処理要求より新しい順序番号を有する第２の処理要求との間で各処理要求の実行順序の先後により処理結果が異なる可能性があるか否かを判定し、（ロ）処理結果が異なる可能性がない場合には各処理要求をデータベース管理システムに転送し、（ハ）処理結果が異なる可能性がある場合には前記第１の処理要求をデータベース管理システムに転送するとともに、前記第２の処理要求を所定の記憶手段に記憶する手段と、
   （ｅ）前記記憶手段に記憶されている第２の処理要求に対応する第１の処理要求の実行がデータベース管理システムにおいて完了すると、該第２の処理要求をデータベース管理システムに転送する手段とを備えた
   ことを特徴とする請求項６記載のデータベースサーバ。
8. 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正当な応答の１つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおけるデータベースサーバを実現するプログラムであって、
   コンピュータを、
   （ａ）仲介装置から受信した処理要求を、仲介装置によって該処理要求に付された順序番号にしたがって並べ替え、
   （ｂ）並び替えられた処理要求について、順序番号順に、（イ）処理要求の実行によりデータベース管理システムにおいてロック競合が生じる可能性があるか否かを判定し、（ロ）ロック競合が生じる可能性がある場合には該処理要求を所定の記憶手段に記憶し、（ハ）ロック競合が生じる可能性がない場合にはデータベース管理システムに転送し、
   （ｃ）前記記憶手段に記憶されている処理要求がロック競合を起こす可能性がなくなると該処理要求をデータベース管理システムに転送する実行順序制御手段と、
   実行順序制御手段で順序制御された処理要求を実行するデータベース管理システムとして機能させる
   ことを特徴とするデータベースサーバプログラム。
9. 前記実行順序制御手段は、
   （ｄ）並び替えられた処理要求について、順序番号順に、（イ）第１の処理要求と該第１の処理要求より新しい順序番号を有する第２処理要求との間で各処理要求の実行順序の先後により処理結果が異なる可能性があるか否かを判定し、（ロ）処理結果が異なる可能性がない場合には各処理要求をデータベース管理システムに転送し、（ハ）処理結果が異なる可能性がある場合には前記第１の処理要求をデータベース管理システムに転送するとともに、前記第２の処理要求を所定の記憶手段に記憶し、
   （ｅ）前記記憶手段に記憶されている第２の処理要求に対応する第１の処理要求の実行がデータベース管理システムにおいて完了すると、該第２の処理要求をデータベース管理システムに転送する手段を備える
   ことを特徴とする請求項８記載のデータベースサーバプログラム。
   

Images