計算機、及びデータベース管理プログラム
【課題】共有ディスク装置を使用しない安価なハードウェア構成を前提として、単純な構成を有する多重化データベース制御システムを構築する。
【解決手段】ノード２は、自己が保有するデータベースの自己更新情報としての自ノード用ｒｅｄｏログ１２０と、自己が保有するデータベース以外の他の更新情報としての他ノード用ｒｅｄｏログ１３０と、を各データベース毎に分けて保有し、ノード２が自ノード用ｒｅｄｏログ１２０を更新する際に、他ノード用ｒｅｄｏログ１３０を参照することで、自己が保有するデータベースの更新と自己が保有する以外のデータベースの更新とで競合が発生しているか否かを判定することを特徴とする。
【解決手段】ノード２は、自己が保有するデータベースの自己更新情報としての自ノード用ｒｅｄｏログ１２０と、自己が保有するデータベース以外の他の更新情報としての他ノード用ｒｅｄｏログ１３０と、を各データベース毎に分けて保有し、ノード２が自ノード用ｒｅｄｏログ１２０を更新する際に、他ノード用ｒｅｄｏログ１３０を参照することで、自己が保有するデータベースの更新と自己が保有する以外のデータベースの更新とで競合が発生しているか否かを判定することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多重化されたデータベースのうち少なくとも一つを備える計算機、及びデータベース管理プログラムに関する。
【背景技術】
【０００２】
従来の多重化データベースにおいては、各ノードにデータそのものを格納するためのＤＢファイルと、更新履歴情報を逐次書き込むためのｒｅｄｏログとを持っている。
図１１（ａ）に示すように、多重化データベースは、データベースの可用性を向上するためにノードを２重化する。ノードの２重化を行う方法の一つに、分散トランザクションの機能を用いる方法がある。
【０００３】
この方法では、更新を行う際に、クライアントから、両ノードに対して同一の内容の更新要求を行い、２フェーズコミット方式により、両ノード間のＤＢファイルの内容の整合を保障する。すなわち、この方法は、コミット要求時に、両ノードにコミット準備指示を行い、両ノードから準備完了応答を得られてから、両ノードに対してコミット指示を行う。なお、分散トランザクションの機能を用いる方法の詳細は、例えば、特許文献１に記載がある。
【０００４】
また、別の方法として、共有ディスクによる２重化の方法がある。図１１（ｂ）に示すように、ｒｅｄｏログとＤＢファイルとを共有ディスクに格納し、両ノードに接続することによって、データベースを２重化する。ｒｅｄｏログは、各ノード用に一つずつ用意されるが、ＤＢファイルは、物理的に同じものを共有する。なお、共有ディスクを用いる方法の詳細は、例えば、非特許文献１に記載がある。
【０００５】
この方法では、一つのディスク装置を共有してＤＢを構成しているため、片方のノードで実行された操作は、即時他ノードにも反映されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平６−１１９２２７号公報（段落０００２〜０００６、図２等）
【非特許文献】
【０００７】
【非特許文献１】Barb Lundhild，Peter Sechser、“Oracle RAC 10g”、[online]、２００５年９月、Oracle Corporation、[平成２１年９月１６日検索]、インターネット<URL:http://otndnld.oracle.co.jp/products/database/oracle10g/clustering/pdf/TWP_RAC10g.pdf >
【発明の概要】
【発明が解決しようとする課題】
【０００８】
このように、分散トランザクションの機能を用いるデータベースの多重化方法は、更新操作に対する競合があれば、その時点で待ちが発生し、また、コミット動作中に障害が発生すると、自動的にロックを解除できなくなり、制御が複雑であるという問題がある。
また、共有ディスク装置を用いるデータベースの多重化方法では、共有ディスク装置が高価であり、両ノードを地理的に分散させた配置とすることができないという欠点がある。
【０００９】
本発明は前記問題に鑑みてなされたものであり、データベースを地理的に分散させた状態であっても、データベースの更新における競合を判定することができる、計算機、及びデータベース管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
前記目的を達成するために、本発明に係る計算機は、複数の同じ内容のデータベースに通信可能に接続されて多重化されたデータベースのうち少なくとも１つを備える計算機であって、自己が保有するデータベースの自己更新情報と、自己が保有するデータベース以外のデータベースの他の更新情報とを各データベース毎に分けて保有する記憶部と、前記自己更新情報を更新する際に、前記他の更新情報を参照することで、前記多重化されたデータベースの更新における競合を判定する競合判定部と、を備えることを特徴とする。
【００１１】
前記目的を達成するために、本発明に係るデータベース管理プログラムは、複数の同じ内容のデータベースに通信可能に接続されて多重化されたデータベースのうち少なくとも１つを備える計算機の制御装置に実行させるデータベース管理プログラムであって、前記自己の計算機が保有するデータベースの自己更新情報と、前記自己が保有するデータベース以外のデータベースの他の更新情報とを各データベース毎に分けて記憶部に保有させる機能と、前記自己情報を更新する際に、前記他の更新情報を参照することで、前記多重化されたデータベースの更新における競合を判定する機能と、を前記制御装置に実現させることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、データベースを地理的に分散させた状態であっても、データベースの更新における競合を判定することができる。このため、共有ディスク装置を使用しない安価なハードウェア構成を前提として、分散トランザクション方式によるデータベース制御システムよりも単純な構成にすることができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１実施形態に係るデータベース制御システムの構成図である。
【図２】本発明の第１実施形態に係るデータベース制御システムを構成するノードの機能構成図である。
【図３】本発明の第１実施形態に係るノードが備えるｒｅｄｏログの一例を示す図である。
【図４】本発明の第１実施形態に係るノードが相互に送信しあうｒｅｄｏログ情報の一例を示す図である。
【図５】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）を説明する動作説明図である。
【図６Ａ】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）の各ステップ後のｒｅｄｏログの状態を示す図である。
【図６Ｂ】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）の各ステップ後のｒｅｄｏログの状態を示す図である。
【図７】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）を説明する動作説明図である。
【図８】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の各ステップ後のｒｅｄｏログの状態を示す図である。
【図９】本発明の第２実施形態に係るデータベース制御システムを構成するノードの機能構成図である。
【図１０】本発明の第２実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）を説明する動作説明図である。
【図１１】（ａ）従来の構成要素（分散トランザクション）、（ｂ）従来の構成要素（共有ディスク）を示す構成図である。
【発明を実施するための形態】
【００１４】
≪第１実施形態に係るデータベース制御システムの構成≫
＜概要＞
図１は、第１実施形態に係るデータベース制御システムの構成図である。
データベース制御システム１は、ノード２Ａ，２Ｂ（以下、まとめてノード２と呼ぶときがある），クライアント８Ａ，８Ｂ，・・８Ｘ（以下、まとめてクライアント８と呼ぶときがある），及びネットワーク９を備えて構成される。データベース制御システム１は、クライアント８がネットワーク９を介してノード２が備える記憶装置２００Ａ，２００Ｂ（以下、まとめて記憶装置２００と呼ぶときがある）内に記憶されているデータベース（ＤＢ）２２０Ａ，２２０Ｂ（以下、まとめてデータベース（ＤＢ）２２０と呼ぶときがある）を更新する。データベース２２０の更新は、制御装置１００に記憶されるｒｅｄｏログ１２０，１３０（図２参照）を使って行われる。データベース２２０の更新処理についての詳細は後述する。
【００１５】
ここで、データベース２２０Ａ，及びデータベース２２０Ｂは同じ内容である。データベース制御システム１では、データベース２２０の更新に際し、クライアント８はノード２Ａ，又はノード２Ｂのどちらかにアクセスし、一方のデータベース２２０Ａ，又はデータベース２２０Ｂを更新する。更新したデータベース２２０を備える一方のノード２は、他方のノード２に更新情報を送信し、更新情報を受信した他方のノード２は、受信した更新情報を基に自己のデータベース２２０を更新する。このように、第１実施形態に係るデータベース制御システム１では、ノード２が相互に自己のデータベース２２０の更新情報を送信しあうことで、データベース２２０の内容の同一性を図っている。
【００１６】
図１に示すデータベース制御システム１は、データベース２２０を２重化する構成としているが、より多数のノード２を接続してデータベース２２０を３重，４重又はそれ以上の多重に構成してもよい。その場合、更新したデータベース２２０を備えるノード２は、多重化されたデータベース２２０を備えるすべてのノード２に対して、自己のデータベース２２０の更新情報を送信することになる。
【００１７】
また、データベース制御システム１は、ノード２Ａをあるローカルネットワークに接続し、ノード２Ｂをノード２Ａが属するローカルネットワークとは異なるローカルネットワークに接続し、それぞれのローカルネットワークをグローバルネットワークに接続するようにしてもよい。このような構成にすれば、ノード２を地理的に離した場所に設置することが可能となる。
以下、データベース制御システム１の各構成装置について説明する。
【００１８】
＜ノード＞
ノード２は、ネットワークに接続され、データベースを備えるディスク装置である。例えば、３層アーキテクチャのクライアントサーバシステムにおけるデータアクセス層の処理を行うサーバ，集中処理システムにおけるホストコンピュータ等を含む広い概念である。
ノード２の構成は、装置の種類によって異なるが、クライアントサーバシステムにおけるサーバの場合には、例えば、制御装置１００，記憶装置２００，入力装置３，表示装置４，通信装置５，タイマ６で構成される。
【００１９】
（制御装置）
制御装置１００は、ＣＰＵ，メモリ（記憶部），及びこれらの周辺回路等（いずれも図示せず）から構成される。制御装置１００は、記憶装置２００に記憶されるＤＢＭＳ（DataBase Management System：データベース管理システム（データベース管理プログラム））２１０，及びＯＳ（Operating System）２３０をメモリにロードし実行することで、様々な機能を実現する。制御装置１００が備える機能については後記する。
【００２０】
（記憶装置）
記憶装置２００は、ＨＤＤ（Hard Disk Drive）等で構成され、ＤＢＭＳ２１０，ＤＢ２２０，及びＯＳ２３０を記憶する。ＤＢＭＳ２１０は、データベースとして蓄えた情報を制御し、活用するためのソフトウェアである。ＤＢ２２０は、ＤＢＭＳ２１０の管理下で記憶装置２００に記憶されているデータである。ＯＳ２３０は、ノード２のコンピュータシステムを管理し、基本的なユーザ操作環境を提供するソフトウェアである。
ＤＢ２２０は、複数のファイルにより構成されている。ＤＢ２２０を構成するファイルについては後記する。
【００２１】
（入力装置，表示装置，通信装置，タイマ）
入力装置３は、キーボード，マウス等の操作入力用デバイスを含み、ノード２の操作者の入力操作を受け入れて、制御装置１００に対して出力する。
表示装置４は、ＬＣＤ，ＣＲＴ等であって、制御装置１００から渡される出力画像等を表示する。
通信装置５は、ＬＡＮ用のアダプタ装置，ＩＳＤＮ通信回線用のＴＡ，又はモデム等であって、制御装置１００の指示に従って動作し、ネットワーク９を介してノード２又はクライアント８とデータの送受信を行う。
タイマ６は、ノード２の時計であり、ＲＴＣ（Real Time Clock）等で構成される。タイマ６は、制御装置１００に時刻をデータとして提供する。
【００２２】
＜クライアント＞
クライアント８は、ネットワーク９を介してノード２が備えるＤＢ２２０の更新を要求する装置である。クライアント８は、ＰＣ（Personal Computer），携帯端末等で構成される。
【００２３】
＜ネットワーク＞
ネットワーク９は、ＬＡＮ（Local Area Network），ＷＡＮ（Wide Area Network）等であり、有線，無線のどちらか一方，又は両方で構成され、データ通信を実現する。
有線の例としては、光ファイバ，一般電話回線，専用線等が挙げられ、無線の例としては、赤外線等の電波が挙げられる。
【００２４】
≪第１実施形態に係るデータベース制御システムを構成するノードの機能及び使用するフォーマット≫
＜ノードが備える機能＞
（概要）
図２は、第１実施形態に係るデータベース制御システムを構成するノードの機能構成図である。図２では、各機能を「○○部」と記載している。
ノード２は、第１実施形態に係るデータベース制御システム１を実現するために、図２に示す機能を有する。図２に記載される各部１１０，１１１，１１２，１１３，１１４は、ＤＢＭＳ２１０をメモリにロードし、ＣＰＵにより実行されることで実現される。通信部１４０は、ＯＳ２３０をメモリにロードし、ＣＰＵにより実行されることで実現される。また、ログ１２０，１３０はメモリ上に領域として確保される。
図２には、説明の便宜上、第１実施形態に係るデータベース制御システム１を説明するのに必要な機能以外の機能を図示していない。例えば、入力装置３，表示装置４，及びタイマ６を管理する機能等は図示していない。
【００２５】
（データベース（ＤＢ））
ＤＢ２２０は、ｒｅｄｏログファイル２２１，制御ファイル２２２，及びデータファイル２２３の３つのファイルで構成される。
ｒｅｄｏログファイル２２１は、データファイル２２３の更新情報を記憶しておくファイルである。制御ファイル２２２は、ｒｅｄｏログファイル２２１やデータファイル２２３のファイル名と保存場所を記録しておくファイルである。データファイル２２３は、実際のデータが入っているファイルである。
【００２６】
（ｒｅｄｏログ）
更新情報としてのｒｅｄｏログ１２０，１３０は、ＤＢ２２０の変更履歴データであり、その構成を図３に示す。ｒｅｄｏログ１２０，１３０の１エントリは、タイムスタンプ欄１２１，１３１、トランザクション番号欄１２２，１３２、ＤＢ操作コード欄１２３，１３３、ＤＢ操作アドレス欄１２４，１３４、ＤＢ操作パラメタ欄１２５，１３５で構成される。
ｒｅｄｏログ１２０，１３０は、ＤＢ２２０についての処理が行われるたびに、エントリが追加されていく。
なお、図２は、ノード２が２重化された場合の構成であり、仮にノード２が３重化，４重化された場合、各ノード２が備えるｒｅｄｏログの数は、ノード２の数分になり、３つ，４つとなる。
【００２７】
（ｒｅｄｏログ更新部）
図２に示す、ｒｅｄｏログ更新部１１１は、基本的にはｒｅｄｏログ１２０，１３０を更新する機能である。
以下、ｒｅｄｏログ更新部１１１の機能を自己のノード２でトランザクションが発生した場合と、他のノード２でトランザクションが発生した場合とに分けて説明する。
（１）自己のノードでトランザクションが発生した場合
ｒｅｄｏログ更新部１１１は、トランザクション（以下、「Ｔｘ」と称す場合がある）の開始時，ＤＢ２２０の更新操作（ｕｐｄａｔｅ，ｄｅｌｅｔｅ，ｉｎｓｅｒｔ）実行時，及びｃｏｍｍｉｔ（結果確定）実行時に、自ノード用ｒｅｄｏログ１２０にエントリを１行追加する。具体的には、以下の（ａ）〜（ｃ）の内容を設定したエントリを１行追加する。
【００２８】
（ａ）Ｔｘ開始時
ｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０のタイムスタンプ欄１２１に「時刻」を設定し、トランザクション番号欄１２２に「任意のＴｘ番号」を設定する。
（ｂ）ＤＢの更新操作実行時
ｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０のタイムスタンプ欄１２１に「時刻」を設定し、トランザクション番号欄１２２に「Ｔｘ開始時に設定したＴｘ番号」を設定し、ＤＢ操作コード欄１２３に「ｕｐｄａｔｅ」，「ｄｅｌｅｔｅ」，「ｉｎｓｅｒｔ」のうちのいずれかを設定し、ＤＢ操作アドレス欄１２４に「更新対象レコードのアドレス」を設定し、ＤＢ操作パラメタ欄１２５に「ＤＢの更新内容」を設定する。
ＤＢ操作コード欄１２３に「ｕｐｄａｔｅ」，「ｄｅｌｅｔｅ」，「ｉｎｓｅｒｔ」のうちのいずれかを設定するかは、更新対象レコードを更新するのか、削除するのか、それとも新たにレコードを追加するのかにより決定される。
【００２９】
（ｃ）ｃｏｍｍｉｔ（結果確定）実行時
ｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０のタイムスタンプ欄１２１に「時刻」を設定し、トランザクション番号欄１２２に「Ｔｘ開始時に設定したＴｘ番号」を設定し、ＤＢ操作コード欄１２３に「ｃｏｍｍｉｔ」又は「ｒｏｌｌｂａｃｋ」を設定する。
ＤＢ操作コード欄１２３に「ｃｏｍｍｉｔ」，「ｒｏｌｌｂａｃｋ」のどちらを設定するかは、後述する更新対象競合判定部１１２（図２参照）で更新対象レコードに競合がないと判定された場合は「ｃｏｍｍｉｔ」を設定し、更新対象レコードに競合があると判定された場合は「ｒｏｌｌｂａｃｋ」を設定する。
【００３０】
また、ｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０にエントリを追加するたびに、図４に示すｒｅｄｏログ情報３００を作成する。すなわち、ｒｅｄｏログ更新部１１１は、（ａ）Ｔｘ開始時，（ｂ）ＤＢの更新操作実行時，（ｃ）ｃｏｍｍｉｔ実行時のすべてのタイミングでｒｅｄｏログ情報３００を作成する。ｒｅｄｏログ情報３００の構成は、ｒｅｄｏログ１２０，１３０の１エントリの構成と同じである。ｒｅｄｏログ更新部１１１は、ｒｅｄｏログ情報３００の各欄に、自ノード用ｒｅｄｏログ１２０の同一欄名に設定した内容と同じ内容を設定する。
ｒｅｄｏログ更新部１１１は、作成したｒｅｄｏログ情報３００を、他のノード２に対して送信するように通信部１４０に指示する。通信部１４０（図２参照）は、ｒｅｄｏログ情報３００を、ＴＣＰ（Transmission Control Protocol），ＩＰ（Internet Protocol）等の通信規約に従ってパケット化し、通信装置５（図１参照）を介して他のノード２に送信する。
【００３１】
（２）他のノードでトランザクションが発生した場合
ｒｅｄｏログ更新部１１１は、他のノード２から受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０にエントリを追加する。具体的には、ｒｅｄｏログ更新部１１１は、他ノード用ｒｅｄｏログ１３０の各欄に、ｒｅｄｏログ情報３００の同一欄名に格納されている内容と同じ内容を設定し、エントリを追加する。これにより、一方のノード２の自ノード用ｒｅｄｏログ１２０の内容と、他方のノード２の他ノード用ｒｅｄｏログ１３０の内容は一致される。
【００３２】
（更新対象競合判定部）
図２に示す更新対象競合判定部１１２は、自己のノード２でトランザクションが発生し、かつ、ｃｏｍｍｉｔを行うときに、自己のノード２と他のノード２とで更新対象レコードが競合したか否かの判定を行う。更新対象競合判定部１１２は、更新対象レコードの競合の判定を、トランザクションの開始からｃｏｍｍｉｔを行うときまでの時間帯について、他ノード用ｒｅｄｏログ１３０の内容を調べることにより行う。
具体的には、更新対象競合判定部１１２は、自己のノード２でトランザクションが開始してからｃｏｍｍｉｔを行うときまでの時間帯において、自ノード用ｒｅｄｏログ１２０に追加したエントリのＤＢ操作アドレス欄１２４に設定したアドレスと、他ノード用ｒｅｄｏログ１３０に追加したエントリのＤＢ操作アドレス欄１３４に設定したアドレスとが一致し、かつ、他ノード用ｒｅｄｏログ１３０に、ＤＢ操作コード欄１３３に「ｃｏｍｍｉｔ」が設定されたエントリが追加されている場合に更新対象レコードが競合したと判定する。
【００３３】
仮に、自ノード用ｒｅｄｏログ１２０のＤＢ操作アドレス欄１２４と、他ノード用ｒｅｄｏログ１３０のＤＢ操作アドレス欄１３４とに設定したアドレスが一致しても、他ノード用ｒｅｄｏログ１３０に、ＤＢ操作コード欄１３３に「ｃｏｍｍｉｔ」が設定されたエントリが追加されていなければ更新対象レコードが競合したと判定しない。この場合には、他のノード２の更新対象競合判定部１１２が、更新対象レコードが競合したと判定することになる。すなわち、更新対象レコードが競合した場合に、先にｃｏｍｍｉｔが行われた更新処理を優先する。
【００３４】
（ｒｅｄｏログファイル更新部）
図２に示すｒｅｄｏログファイル更新部１１３は、自ノード用ｒｅｄｏログ１２０に、ＤＢ操作コード欄１２３に「ｃｏｍｍｉｔ」が設定されたエントリが追加されたときに、自ノード用ｒｅｄｏログ１２０の内容をｒｅｄｏログファイル２２１に書き出す。
また、ｒｅｄｏログファイル更新部１１３は、他ノード用ｒｅｄｏログ１３０に、ＤＢ操作コード欄１３３に「ｃｏｍｍｉｔ」が設定されたエントリが追加さたときに、他ノード用ｒｅｄｏログ１３０の内容をｒｅｄｏログファイル２２１に書き出す。
【００３５】
（データファイル更新部）
図２に示すデータファイル更新部１１４は、任意のタイミングでｒｅｄｏログファイル２２１の内容をデータファイル２２３に更新する。
【００３６】
≪第１実施形態に係るデータベース制御システムのデータベース更新動作≫
以下、図５から図９を参照して第１実施形態に係るデータベース制御システムのデータベース更新動作について説明する。
図５は、第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）の説明図である。
図５は、ノード２ＡでＴｘＡが、ノード２ＢでＴｘＢがほぼ同時に実行される場合の処理の流れを示している。ＴｘＡは、アドレス＃０００１のレコードを更新し、ＴｘＢは、アドレス＃０００２のレコードを更新するので、ＴｘＡとＴｘＢとでは更新対象レコードが競合しない。他ノード用ｒｅｄｏログ１３０上の白抜き矢印は、更新対象競合判定部１１２が競合判定を行う時間帯を表している。
【００３７】
なお、説明に際して、ｒｅｄｏログ１２０，１３０及びｒｅｄｏログ情報３００のデータの設定の記載については、一部省略する。
また、各ステップ後の、ノード２Ａの自ノード用ｒｅｄｏログ１２０Ａ，及びノード２Ｂの他ノード用ｒｅｄｏログ１３０Ｂの状態、さらに、ノード２Ｂの自ノード用ｒｅｄｏログ１２０Ｂ，及びノード２Ａの他ノード用ｒｅｄｏログ１３０Ａの状態を図６Ａ（ａ）〜（ｃ），及び図６Ｂ（ａ）〜（ｃ）に示す。
【００３８】
（ステップＳ００１Ａ）
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、ＴｘＡの開始とともに、トランザクション番号欄１２２Ａに「任意のＴｘ番号」を設定したエントリを自ノード用ｒｅｄｏログ１２０Ａに１行追加する。また、ｒｅｄｏログ更新部１１１Ａは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ｂに送信する。
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ｂにエントリを１行追加する。
【００３９】
（ステップＳ００１Ｂ）
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、ＴｘＢの開始とともに、トランザクション番号欄１２２Ｂに「任意のＴｘ番号」を設定したエントリを自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。
【００４０】
（ステップＳ００２Ａ）
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、ＤＢ操作コード欄１２３Ａに「ｕｐｄａｔｅ」を設定し、ＤＢ操作アドレス欄１２４Ａに「０００１」を設定し、ＤＢ操作パラメタ欄１２５Ａに「ＡＡＡＡＡ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ａに１行追加する。また、ｒｅｄｏログ更新部１１１Ａは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ｂに送信する。
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ｂにエントリを１行追加する。
【００４１】
（ステップＳ００２Ｂ）
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、ＤＢ操作コード欄１２３Ｂに「ｕｐｄａｔｅ」を設定し、ＤＢ操作アドレス欄１２４Ｂに「０００２」を設定し、ＤＢ操作パラメタ欄１２５Ｂに「ＢＢＢＢＢ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。
【００４２】
（ステップＳ００３Ａ）
ノード２Ａの更新対象競合判定部１１２Ａは、ｃｏｍｍｉｔを行うときに、ノード２Ａとノード２Ｂとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の時刻は「20090101010101005」とする。
更新対象競合判定部１１２Ａは、自ノード用ｒｅｄｏログ１２０Ａのタイムスタンプ欄１２１Ａを参照することで、ＴｘＡの開始が「20090101010101001」であることを把握し、他ノード用ｒｅｄｏログ１３０Ａのタイムスタンプ欄１３１Ａの日時が「20090101010101001」から「20090101010101005」までの間のエントリで自ノード用ｒｅｄｏログ１２０ＡのＤＢ操作アドレス欄１２４Ａの値と他ノード用ｒｅｄｏログ１３０ＡのＤＢ操作アドレス欄１３４Ａの値が一致するエントリがあるか否か調べるが、一致するエントリはないと分かる。その為、更新対象競合判定部１１２Ａは、更新対象レコードの競合はないと判定する。
【００４３】
次に、ノード２Ａのｒｅｄｏログ更新部１１１Ａは、更新対象レコードの競合はないと判定されたので、ＤＢ操作コード欄１２３Ａに「ｃｏｍｍｉｔ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ａに１行追加する。また、ｒｅｄｏログ更新部１１１Ａは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ｂに送信する。さらに、ｒｅｄｏログファイル更新部１１３Ａは、自ノード用ｒｅｄｏログ１２０Ａの内容をｒｅｄｏログファイル２２１Ａに書き出す。
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ｂにエントリを１行追加する。さらに、ｒｅｄｏログファイル更新部１１３Ｂは、他ノード用ｒｅｄｏログ１３０Ｂの内容をｒｅｄｏログファイル２２１Ｂに書き出す。
【００４４】
（ステップＳ００３Ｂ）
ノード２Ｂの更新対象競合判定部１１２Ｂは、ｃｏｍｍｉｔを行うときに、ノード２Ａとノード２Ｂとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の時刻は「20090101010101006」とする。
更新対象競合判定部１１２Ｂは、自ノード用ｒｅｄｏログ１２０Ｂのタイムスタンプ欄１２１Ｂを参照することで、ＴｘＢの開始が「20090101010101002」であることを把握し、他ノード用ｒｅｄｏログ１３０Ｂのタイムスタンプ欄１３１Ｂの日時が「20090101010101002」から「20090101010101006」までの間のエントリで自ノード用ｒｅｄｏログ１２０ＢのＤＢ操作アドレス欄１２４Ｂの値と他ノード用ｒｅｄｏログ１３０ＢのＤＢ操作アドレス欄１３４Ｂの値が一致するエントリがあるか否か調べるが、一致するエントリはないと分かる。その為、更新対象競合判定部１１２Ｂは、更新対象レコードの競合はないと判定する。
【００４５】
次に、ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、更新対象レコードの競合はないと判定されたので、ＤＢ操作コード欄１２３Ｂに「ｃｏｍｍｉｔ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。さらに、ｒｅｄｏログファイル更新部１１３Ｂは、自ノード用ｒｅｄｏログ１２０Ｂの内容をｒｅｄｏログファイル２２１Ｂに書き出す。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。さらに、ｒｅｄｏログファイル更新部１１３Ａは、他ノード用ｒｅｄｏログ１３０Ａの内容をｒｅｄｏログファイル２２１Ａに書き出す。
以上で、第１実施形態に係るデータベース制御システム１のデータベース更新動作（更新データの競合なし）の説明を終了する。
【００４６】
図７は、第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の説明図である。
図７は、ノード２ＡでＴｘＡが、ノード２ＢでＴｘＢがほぼ同時に実行される場合の処理の流れを示している。ＴｘＡ，ＴｘＢ共に、アドレス＃０００１のレコードを更新するので更新対象レコードが競合する。他ノード用ｒｅｄｏログ１３０上の白抜き矢印は、更新対象競合判定部１１２が競合判定を行う時間帯を表している。
【００４７】
なお、説明に際して、ｒｅｄｏログ１２０，１３０及びｒｅｄｏログ情報３００のデータの設定の記載については、一部省略する。
また、各ステップ後の、ノード２Ａの自ノード用ｒｅｄｏログ１２０Ａ，及びノード２Ｂの他ノード用ｒｅｄｏログ１３０Ｂの状態、さらに、ノード２Ｂの自ノード用ｒｅｄｏログ１２０Ｂ，及びノード２Ａの他ノード用ｒｅｄｏログ１３０Ａの状態を図６Ａ（ａ）〜（ｃ）及び図８（ａ）〜（ｃ）に示す。
【００４８】
（ステップＳ００１Ａ，Ｓ００１Ｂ，Ｓ００２Ａ）
ステップＳ００１Ａ，Ｓ００１Ｂ，Ｓ００２Ａの処理は、前記第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）の説明（図５参照）と同じなので説明を省略する。
【００４９】
（ステップＳ００２Ｂ）
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、ＤＢ操作コード欄１２３Ｂに「ｕｐｄａｔｅ」を設定し、ＤＢ操作アドレス欄１２４Ｂに「０００１」を設定し、ＤＢ操作パラメタ欄１２５Ｂに「ＢＢＢＢＢ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。
【００５０】
（ステップＳ００３Ａ）
ノード２Ａの更新対象競合判定部１１２Ａは、ｃｏｍｍｉｔを行うときに、ノード２Ａとノード２Ｂとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の時刻は「20090101010101005」とする。
更新対象競合判定部１１２Ａは、自ノード用ｒｅｄｏログ１２０Ａのタイムスタンプ欄１２１Ａを参照することで、ＴｘＡの開始が「20090101010101001」であることを把握し、他ノード用ｒｅｄｏログ１３０Ａのタイムスタンプ欄１３１Ａの日時が「20090101010101001」から「20090101010101005」までの間のエントリで、自ノード用ｒｅｄｏログ１２０ＡのＤＢ操作アドレス欄１２４Ａの値と他ノード用ｒｅｄｏログ１３０ＡのＤＢ操作アドレス欄１３４Ａの値とが一致するエントリがあるが、ＤＢ操作コード欄１３３Ａに「ｃｏｍｍｉｔ」が設定されたエントリがないと分かる。その為、更新対象競合判定部１１２Ａは、更新対象レコードの競合はないと判定する。
【００５１】
次に、ノード２Ａのｒｅｄｏログ更新部１１１Ａは、更新対象レコードの競合はないと判定されたので、ＤＢ操作コード欄１２３Ａに「ｃｏｍｍｉｔ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ａに１行追加する。また、ｒｅｄｏログ更新部１１１Ａは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ｂに送信する。さらに、ｒｅｄｏログファイル更新部１１３Ａは、自ノード用ｒｅｄｏログ１２０Ａの内容をｒｅｄｏログファイル２２１Ａに書き出す。
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ｂにエントリを１行追加する。さらに、ｒｅｄｏログファイル更新部１１３Ｂは、他ノード用ｒｅｄｏログ１３０Ｂの内容をｒｅｄｏログファイル２２１Ｂに書き出す。
【００５２】
（ステップＳ００３Ｂ）
ノード２Ｂの更新対象競合判定部１１２Ｂは、ｃｏｍｍｉｔを行うときに、ノード２Ａとノード２Ｂとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の時刻は「20090101010101006」とする。
更新対象競合判定部１１２Ｂは、自ノード用ｒｅｄｏログ１２０Ｂのタイムスタンプ欄１２１Ｂを参照することで、ＴｘＢの開始が「20090101010101002」であることを把握し、他ノード用ｒｅｄｏログ１３０Ｂのタイムスタンプ欄１３１Ｂの日時が「20090101010101002」から「20090101010101006」までの間のエントリで自ノード用ｒｅｄｏログ１２０ＢのＤＢ操作アドレス欄１２４Ｂの値と他ノード用ｒｅｄｏログ１３０ＢのＤＢ操作アドレス欄１３４Ｂの値とが一致するエントリがあり、かつ、ＤＢ操作コード欄１３３Ｂに「ｃｏｍｍｉｔ」が設定されたエントリもあると分かる。その為、更新対象競合判定部１１２Ｂは、更新対象レコードの競合があると判定する。
【００５３】
次に、ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、更新対象レコードの競合があると判定されたので、ＤＢ操作コード欄１２３Ｂに「ｒｏｌｌｂａｃｋ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。そして、ノード２Ｂは、ＴｘＢの実行を中止する。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。
以上で、第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の説明を終了する。このように、本実施形態に係るデータベース制御システムでは、更新操作において競合があっても、待ちが発生することがない。
【００５４】
≪第２実施形態に係るデータベース制御システムを構成するノードの機能及び使用するフォーマット≫
＜ノードが備える機能＞
（概要）
第１実施形態に係るノード２（図２参照）では、前記した通り、ノード２間で更新対象レコードが競合した場合に、先にｃｏｍｍｉｔした方を優先する。そして、自ノード用ｒｅｄｏログ１２０と他ノード用ｒｅｄｏログ１３０の情報を比較する際には、各ノード２で同期しているタイマ６（図１参照）に基づいてｒｅｄｏログ１２０，１３０のタイムスタンプ欄１２１，１３１に書き込まれる時刻の情報を利用して、参照するｒｅｄｏログ１２０，１３０の範囲を決定する。
【００５５】
実際には、ノード２間でのｒｅｄｏログ情報３００の送信には、ある程度時間がかかるため、ｃｏｍｍｉｔを行うときに、即時に更新対象レコードの競合を判定することができない。すなわち、自己のノードでｃｏｍｍｉｔを行うときに、自己のノードが備える他ノード用ｒｅｄｏログ１３０には他のノードのｃｏｍｍｉｔの情報が反映されていないが、実際には、他のノードでｃｏｍｍｉｔが行われており、ｒｅｄｏログ情報３００の伝送遅延により自己のノードが備える他ノード用ｒｅｄｏログ１３０に他のノードのｃｏｍｍｉｔの情報が反映されていない場合である。この場合、自己のノードは、ｃｏｍｍｉｔを行う時点では他のノードがｃｏｍｍｉｔを行っているのか否かを判定することができない。
【００５６】
そのため、第２実施形態に係るノードは、更新情報がない場合も定期的にタイムスタンプ欄以外はデータを設定しないｒｅｄｏログ情報（以下、空のｒｅｄｏログ情報と称す）を他ノードに送信し、空のｒｅｄｏログ情報を受信したノードは、受信した時刻と空のｒｅｄｏログ情報のタイムスタンプ欄に格納される時刻との差を更新対象レコードが競合したか否かの判定に利用する。
ここで、第２実施形態に係るデータベース制御システムの構成は、図１に示す第１実施形態に係るデータベース制御システム１と同じである。
以下、第２実施形態に係るノードについて説明する。
【００５７】
図９は、第２実施形態に係るデータベース制御システムを構成するノードの機能構成図である。図９では、各機能を「○○部」と記載している。
第２実施形態に係るノード２は、第１実施形態に係るノード２（図２参照）の機能に加えてさらに、ｒｅｄｏログ情報送信遅延演算部１１５を備える。また、ｒｅｄｏログ更新部１１１，及び更新対象競合判定部１１２の機能が異なる。それ以外のデータ構成等は第１実施形態と同様である。以下、説明する。
【００５８】
（ｒｅｄｏログ更新部）
ｒｅｄｏログ更新部１１１は、第１実施形態に係るｒｅｄｏログ更新部１１１の機能に加えて、以下の機能を備える。
本実施形態に係るｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０の更新をしておらず、本来ならば、他ノードに対してｒｅｄｏログ情報を送信する必要がない場合でも、図４に示すタイムスタンプ欄３０１に「時刻」を設定し、それ以外の欄にはデータを設定しない空のｒｅｄｏログ情報３００を、定期的に他のノード２に送信する機能を備える。
【００５９】
（ｒｅｄｏログ情報送信遅延演算部）
ｒｅｄｏログ情報送信遅延演算部１１５は、空のｒｅｄｏログ情報３００を受信したら、現在の時刻と、空のｒｅｄｏログ情報３００のタイムスタンプ欄３０１に設定される時刻との時間差をメモリ上に保存する。
ここで、メモリ上に保存する時間差は、現在の時刻と直近の空のｒｅｄｏログ情報３００に設定される時刻との単純な時間差だけでなく、現在の時刻と受信した複数個のｒｅｄｏログ情報３００に設定されている時刻との平均値との差としてもよい。また、メモリ上に保存される時間差には、上記以外にも種々の影響を考慮した値を設定することができる。
【００６０】
（更新対象競合判定部）
本実施形態に係る更新対象競合判定部１１２は、自己のノード２でトランザクションが発生し、かつ、ｃｏｍｍｉｔを行うときに、ｒｅｄｏログ情報送信遅延演算部１１５によりメモリ上に保存された時間差分だけ待って、自己のノード２（２Ａ）と他のノード２（２Ｂ）とで更新対象レコードが競合したか否かの判定を行う。
すなわち、更新対象競合判定部１１２は、トランザクションの開始からｃｏｍｍｉｔを行ったときからメモリ上に保存される時間差分加えた時間帯までの他ノード用ｒｅｄｏログ１３０の内容を調べることで更新対象レコードの競合を判定する。
【００６１】
≪第２実施形態に係るデータベース制御システムのデータベース更新動作≫
以下、図１０を参照して第２実施形態に係るデータベース制御システムのデータベース更新動作について説明する。
図１０は、第２実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の説明図である。
図１０は、ノード２ＡでＴｘＡが、ノード２ＢでＴｘＢがほぼ同時に実行される場合の処理の流れを示している。ＴｘＡ，ＴｘＢ共に、アドレス＃０００１のレコードを更新するので更新対象レコードが競合する。以下、ステップＳ００３Ｂを使って本実施形態の動作を説明する。
【００６２】
なお、説明に際して、ｒｅｄｏログ１２０，１３０及びｒｅｄｏログ情報３００のデータの設定の記載については、一部省略する。
また、ステップ後の、ノード２Ａの自ノード用ｒｅｄｏログ１２０Ａ，及びノード２Ｂの他ノード用ｒｅｄｏログ１３０Ｂの状態、さらに、ノード２Ｂの自ノード用ｒｅｄｏログ１２０Ｂ，及びノード２Ａの他ノード用ｒｅｄｏログ１３０Ａの状態は図８（ａ）〜（ｃ）と同じである。
【００６３】
（ステップＳ００３Ｂ）
ノード２Ｂの更新対象競合判定部１１２Ｂは、ｃｏｍｍｉｔを行う前に、自ノードと他ノードとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の日時は「20090101010101006」だとする。また、ノード２Ｂのｒｅｄｏログ情報送信遅延演算部１１５は、空のｒｅｄｏログ情報を受信して一定の時間差があることを把握し、この時間差をメモリ上に保存している。
【００６４】
更新対象競合判定部１１２Ｂは、現時点からメモリ上に保存した時間差後に更新対象レコードが競合したか否かの判定を行う。更新対象競合判定部１１２Ｂは、自ノード用ｒｅｄｏログ１２０Ｂのタイムスタンプ欄１２１Ｂを参照することで、ＴｘＢの開始が「20090101010101002」であることを把握し、他ノード用ｒｅｄｏログ１３０Ｂのタイムスタンプ欄１３１Ｂの日時が「20090101010101002」から「20090101010101006」までの間のエントリで自ノード用ｒｅｄｏログ１２０ＢのＤＢ操作アドレス欄１２４Ｂの値と他ノード用ｒｅｄｏログ１３０ＢのＤＢ操作アドレス欄１３４Ｂの値とが一致するエントリがあり、かつ、ＤＢ操作コード欄１３３Ｂに「ｃｏｍｍｉｔ」が設定されたエントリもあると分かる。その為、更新対象競合判定部１１２Ｂは、更新対象レコードの競合があると判定する。
【００６５】
仮に、更新対象競合判定部１１２Ｂが、現時点「20090101010101006」で競合を判定した場合を想定する。現時点では、ノード２Ａのｃｏｍｍｉｔ情報がノード２Ｂに届いていないので、更新対象競合判定部１１２Ｂは、実際は競合があるのに、競合なしと判定してしまう。
以上で、第２実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の説明を終了する。
【００６６】
なお、本実施形態に係るデータベース制御システムは、自己のノードでｃｏｍｍｉｔを行うときに、自己のノードが備える他ノード用ｒｅｄｏログ１３０には他のノードのｃｏｍｍｉｔの情報が反映されていないが、他のノードでｃｏｍｍｉｔが行われており、ｒｅｄｏログ情報３００の伝送遅延により自己のノードが備える他ノード用ｒｅｄｏログ１３０に他のノードのｃｏｍｍｉｔの情報が反映されていない場合に有効である。
【００６７】
（第２実施形態に係るデータベース制御システムの効果）
ノード間の伝送に遅延が生じても、更新対象レコードの競合の判定を行うことが可能になる。
【符号の説明】
【００６８】
１ データベース制御システム
２（２Ａ，２Ｂ） ノード（計算機）
６（６Ａ，６Ｂ） タイマ
１００（１００Ａ，１００Ｂ） 制御装置
１１０（１１０Ａ，１１０Ｂ） データベース管理部
１１１（１１１Ａ，１１１Ｂ） ｒｅｄｏログ更新部
１１２（１１２Ａ，１１２Ｂ） 更新対象競合判定部
１１５（１１５Ａ，１１５Ｂ） ｒｅｄｏログ情報送信遅延演算部
１２０（１２０Ａ，１２０Ｂ） 自ノード用ｒｅｄｏログ（自己更新情報）
１３０（１３０Ａ，１３０Ｂ） 他ノード用ｒｅｄｏログ（他の更新情報）
２００（２００Ａ，２００Ｂ） 記憶装置
２１０（２１０Ａ，２１０Ｂ） ＤＢＭＳ（データベース管理プログラム）
２２０（２２０Ａ，２２０Ｂ） ＤＢ（データベース）
３００ ｒｅｄｏログ情報（更新データ）
【技術分野】
【０００１】
本発明は、多重化されたデータベースのうち少なくとも一つを備える計算機、及びデータベース管理プログラムに関する。
【背景技術】
【０００２】
従来の多重化データベースにおいては、各ノードにデータそのものを格納するためのＤＢファイルと、更新履歴情報を逐次書き込むためのｒｅｄｏログとを持っている。
図１１（ａ）に示すように、多重化データベースは、データベースの可用性を向上するためにノードを２重化する。ノードの２重化を行う方法の一つに、分散トランザクションの機能を用いる方法がある。
【０００３】
この方法では、更新を行う際に、クライアントから、両ノードに対して同一の内容の更新要求を行い、２フェーズコミット方式により、両ノード間のＤＢファイルの内容の整合を保障する。すなわち、この方法は、コミット要求時に、両ノードにコミット準備指示を行い、両ノードから準備完了応答を得られてから、両ノードに対してコミット指示を行う。なお、分散トランザクションの機能を用いる方法の詳細は、例えば、特許文献１に記載がある。
【０００４】
また、別の方法として、共有ディスクによる２重化の方法がある。図１１（ｂ）に示すように、ｒｅｄｏログとＤＢファイルとを共有ディスクに格納し、両ノードに接続することによって、データベースを２重化する。ｒｅｄｏログは、各ノード用に一つずつ用意されるが、ＤＢファイルは、物理的に同じものを共有する。なお、共有ディスクを用いる方法の詳細は、例えば、非特許文献１に記載がある。
【０００５】
この方法では、一つのディスク装置を共有してＤＢを構成しているため、片方のノードで実行された操作は、即時他ノードにも反映されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平６−１１９２２７号公報（段落０００２〜０００６、図２等）
【非特許文献】
【０００７】
【非特許文献１】Barb Lundhild，Peter Sechser、“Oracle RAC 10g”、[online]、２００５年９月、Oracle Corporation、[平成２１年９月１６日検索]、インターネット<URL:http://otndnld.oracle.co.jp/products/database/oracle10g/clustering/pdf/TWP_RAC10g.pdf >
【発明の概要】
【発明が解決しようとする課題】
【０００８】
このように、分散トランザクションの機能を用いるデータベースの多重化方法は、更新操作に対する競合があれば、その時点で待ちが発生し、また、コミット動作中に障害が発生すると、自動的にロックを解除できなくなり、制御が複雑であるという問題がある。
また、共有ディスク装置を用いるデータベースの多重化方法では、共有ディスク装置が高価であり、両ノードを地理的に分散させた配置とすることができないという欠点がある。
【０００９】
本発明は前記問題に鑑みてなされたものであり、データベースを地理的に分散させた状態であっても、データベースの更新における競合を判定することができる、計算機、及びデータベース管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
前記目的を達成するために、本発明に係る計算機は、複数の同じ内容のデータベースに通信可能に接続されて多重化されたデータベースのうち少なくとも１つを備える計算機であって、自己が保有するデータベースの自己更新情報と、自己が保有するデータベース以外のデータベースの他の更新情報とを各データベース毎に分けて保有する記憶部と、前記自己更新情報を更新する際に、前記他の更新情報を参照することで、前記多重化されたデータベースの更新における競合を判定する競合判定部と、を備えることを特徴とする。
【００１１】
前記目的を達成するために、本発明に係るデータベース管理プログラムは、複数の同じ内容のデータベースに通信可能に接続されて多重化されたデータベースのうち少なくとも１つを備える計算機の制御装置に実行させるデータベース管理プログラムであって、前記自己の計算機が保有するデータベースの自己更新情報と、前記自己が保有するデータベース以外のデータベースの他の更新情報とを各データベース毎に分けて記憶部に保有させる機能と、前記自己情報を更新する際に、前記他の更新情報を参照することで、前記多重化されたデータベースの更新における競合を判定する機能と、を前記制御装置に実現させることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、データベースを地理的に分散させた状態であっても、データベースの更新における競合を判定することができる。このため、共有ディスク装置を使用しない安価なハードウェア構成を前提として、分散トランザクション方式によるデータベース制御システムよりも単純な構成にすることができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１実施形態に係るデータベース制御システムの構成図である。
【図２】本発明の第１実施形態に係るデータベース制御システムを構成するノードの機能構成図である。
【図３】本発明の第１実施形態に係るノードが備えるｒｅｄｏログの一例を示す図である。
【図４】本発明の第１実施形態に係るノードが相互に送信しあうｒｅｄｏログ情報の一例を示す図である。
【図５】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）を説明する動作説明図である。
【図６Ａ】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）の各ステップ後のｒｅｄｏログの状態を示す図である。
【図６Ｂ】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）の各ステップ後のｒｅｄｏログの状態を示す図である。
【図７】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）を説明する動作説明図である。
【図８】本発明の第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の各ステップ後のｒｅｄｏログの状態を示す図である。
【図９】本発明の第２実施形態に係るデータベース制御システムを構成するノードの機能構成図である。
【図１０】本発明の第２実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）を説明する動作説明図である。
【図１１】（ａ）従来の構成要素（分散トランザクション）、（ｂ）従来の構成要素（共有ディスク）を示す構成図である。
【発明を実施するための形態】
【００１４】
≪第１実施形態に係るデータベース制御システムの構成≫
＜概要＞
図１は、第１実施形態に係るデータベース制御システムの構成図である。
データベース制御システム１は、ノード２Ａ，２Ｂ（以下、まとめてノード２と呼ぶときがある），クライアント８Ａ，８Ｂ，・・８Ｘ（以下、まとめてクライアント８と呼ぶときがある），及びネットワーク９を備えて構成される。データベース制御システム１は、クライアント８がネットワーク９を介してノード２が備える記憶装置２００Ａ，２００Ｂ（以下、まとめて記憶装置２００と呼ぶときがある）内に記憶されているデータベース（ＤＢ）２２０Ａ，２２０Ｂ（以下、まとめてデータベース（ＤＢ）２２０と呼ぶときがある）を更新する。データベース２２０の更新は、制御装置１００に記憶されるｒｅｄｏログ１２０，１３０（図２参照）を使って行われる。データベース２２０の更新処理についての詳細は後述する。
【００１５】
ここで、データベース２２０Ａ，及びデータベース２２０Ｂは同じ内容である。データベース制御システム１では、データベース２２０の更新に際し、クライアント８はノード２Ａ，又はノード２Ｂのどちらかにアクセスし、一方のデータベース２２０Ａ，又はデータベース２２０Ｂを更新する。更新したデータベース２２０を備える一方のノード２は、他方のノード２に更新情報を送信し、更新情報を受信した他方のノード２は、受信した更新情報を基に自己のデータベース２２０を更新する。このように、第１実施形態に係るデータベース制御システム１では、ノード２が相互に自己のデータベース２２０の更新情報を送信しあうことで、データベース２２０の内容の同一性を図っている。
【００１６】
図１に示すデータベース制御システム１は、データベース２２０を２重化する構成としているが、より多数のノード２を接続してデータベース２２０を３重，４重又はそれ以上の多重に構成してもよい。その場合、更新したデータベース２２０を備えるノード２は、多重化されたデータベース２２０を備えるすべてのノード２に対して、自己のデータベース２２０の更新情報を送信することになる。
【００１７】
また、データベース制御システム１は、ノード２Ａをあるローカルネットワークに接続し、ノード２Ｂをノード２Ａが属するローカルネットワークとは異なるローカルネットワークに接続し、それぞれのローカルネットワークをグローバルネットワークに接続するようにしてもよい。このような構成にすれば、ノード２を地理的に離した場所に設置することが可能となる。
以下、データベース制御システム１の各構成装置について説明する。
【００１８】
＜ノード＞
ノード２は、ネットワークに接続され、データベースを備えるディスク装置である。例えば、３層アーキテクチャのクライアントサーバシステムにおけるデータアクセス層の処理を行うサーバ，集中処理システムにおけるホストコンピュータ等を含む広い概念である。
ノード２の構成は、装置の種類によって異なるが、クライアントサーバシステムにおけるサーバの場合には、例えば、制御装置１００，記憶装置２００，入力装置３，表示装置４，通信装置５，タイマ６で構成される。
【００１９】
（制御装置）
制御装置１００は、ＣＰＵ，メモリ（記憶部），及びこれらの周辺回路等（いずれも図示せず）から構成される。制御装置１００は、記憶装置２００に記憶されるＤＢＭＳ（DataBase Management System：データベース管理システム（データベース管理プログラム））２１０，及びＯＳ（Operating System）２３０をメモリにロードし実行することで、様々な機能を実現する。制御装置１００が備える機能については後記する。
【００２０】
（記憶装置）
記憶装置２００は、ＨＤＤ（Hard Disk Drive）等で構成され、ＤＢＭＳ２１０，ＤＢ２２０，及びＯＳ２３０を記憶する。ＤＢＭＳ２１０は、データベースとして蓄えた情報を制御し、活用するためのソフトウェアである。ＤＢ２２０は、ＤＢＭＳ２１０の管理下で記憶装置２００に記憶されているデータである。ＯＳ２３０は、ノード２のコンピュータシステムを管理し、基本的なユーザ操作環境を提供するソフトウェアである。
ＤＢ２２０は、複数のファイルにより構成されている。ＤＢ２２０を構成するファイルについては後記する。
【００２１】
（入力装置，表示装置，通信装置，タイマ）
入力装置３は、キーボード，マウス等の操作入力用デバイスを含み、ノード２の操作者の入力操作を受け入れて、制御装置１００に対して出力する。
表示装置４は、ＬＣＤ，ＣＲＴ等であって、制御装置１００から渡される出力画像等を表示する。
通信装置５は、ＬＡＮ用のアダプタ装置，ＩＳＤＮ通信回線用のＴＡ，又はモデム等であって、制御装置１００の指示に従って動作し、ネットワーク９を介してノード２又はクライアント８とデータの送受信を行う。
タイマ６は、ノード２の時計であり、ＲＴＣ（Real Time Clock）等で構成される。タイマ６は、制御装置１００に時刻をデータとして提供する。
【００２２】
＜クライアント＞
クライアント８は、ネットワーク９を介してノード２が備えるＤＢ２２０の更新を要求する装置である。クライアント８は、ＰＣ（Personal Computer），携帯端末等で構成される。
【００２３】
＜ネットワーク＞
ネットワーク９は、ＬＡＮ（Local Area Network），ＷＡＮ（Wide Area Network）等であり、有線，無線のどちらか一方，又は両方で構成され、データ通信を実現する。
有線の例としては、光ファイバ，一般電話回線，専用線等が挙げられ、無線の例としては、赤外線等の電波が挙げられる。
【００２４】
≪第１実施形態に係るデータベース制御システムを構成するノードの機能及び使用するフォーマット≫
＜ノードが備える機能＞
（概要）
図２は、第１実施形態に係るデータベース制御システムを構成するノードの機能構成図である。図２では、各機能を「○○部」と記載している。
ノード２は、第１実施形態に係るデータベース制御システム１を実現するために、図２に示す機能を有する。図２に記載される各部１１０，１１１，１１２，１１３，１１４は、ＤＢＭＳ２１０をメモリにロードし、ＣＰＵにより実行されることで実現される。通信部１４０は、ＯＳ２３０をメモリにロードし、ＣＰＵにより実行されることで実現される。また、ログ１２０，１３０はメモリ上に領域として確保される。
図２には、説明の便宜上、第１実施形態に係るデータベース制御システム１を説明するのに必要な機能以外の機能を図示していない。例えば、入力装置３，表示装置４，及びタイマ６を管理する機能等は図示していない。
【００２５】
（データベース（ＤＢ））
ＤＢ２２０は、ｒｅｄｏログファイル２２１，制御ファイル２２２，及びデータファイル２２３の３つのファイルで構成される。
ｒｅｄｏログファイル２２１は、データファイル２２３の更新情報を記憶しておくファイルである。制御ファイル２２２は、ｒｅｄｏログファイル２２１やデータファイル２２３のファイル名と保存場所を記録しておくファイルである。データファイル２２３は、実際のデータが入っているファイルである。
【００２６】
（ｒｅｄｏログ）
更新情報としてのｒｅｄｏログ１２０，１３０は、ＤＢ２２０の変更履歴データであり、その構成を図３に示す。ｒｅｄｏログ１２０，１３０の１エントリは、タイムスタンプ欄１２１，１３１、トランザクション番号欄１２２，１３２、ＤＢ操作コード欄１２３，１３３、ＤＢ操作アドレス欄１２４，１３４、ＤＢ操作パラメタ欄１２５，１３５で構成される。
ｒｅｄｏログ１２０，１３０は、ＤＢ２２０についての処理が行われるたびに、エントリが追加されていく。
なお、図２は、ノード２が２重化された場合の構成であり、仮にノード２が３重化，４重化された場合、各ノード２が備えるｒｅｄｏログの数は、ノード２の数分になり、３つ，４つとなる。
【００２７】
（ｒｅｄｏログ更新部）
図２に示す、ｒｅｄｏログ更新部１１１は、基本的にはｒｅｄｏログ１２０，１３０を更新する機能である。
以下、ｒｅｄｏログ更新部１１１の機能を自己のノード２でトランザクションが発生した場合と、他のノード２でトランザクションが発生した場合とに分けて説明する。
（１）自己のノードでトランザクションが発生した場合
ｒｅｄｏログ更新部１１１は、トランザクション（以下、「Ｔｘ」と称す場合がある）の開始時，ＤＢ２２０の更新操作（ｕｐｄａｔｅ，ｄｅｌｅｔｅ，ｉｎｓｅｒｔ）実行時，及びｃｏｍｍｉｔ（結果確定）実行時に、自ノード用ｒｅｄｏログ１２０にエントリを１行追加する。具体的には、以下の（ａ）〜（ｃ）の内容を設定したエントリを１行追加する。
【００２８】
（ａ）Ｔｘ開始時
ｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０のタイムスタンプ欄１２１に「時刻」を設定し、トランザクション番号欄１２２に「任意のＴｘ番号」を設定する。
（ｂ）ＤＢの更新操作実行時
ｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０のタイムスタンプ欄１２１に「時刻」を設定し、トランザクション番号欄１２２に「Ｔｘ開始時に設定したＴｘ番号」を設定し、ＤＢ操作コード欄１２３に「ｕｐｄａｔｅ」，「ｄｅｌｅｔｅ」，「ｉｎｓｅｒｔ」のうちのいずれかを設定し、ＤＢ操作アドレス欄１２４に「更新対象レコードのアドレス」を設定し、ＤＢ操作パラメタ欄１２５に「ＤＢの更新内容」を設定する。
ＤＢ操作コード欄１２３に「ｕｐｄａｔｅ」，「ｄｅｌｅｔｅ」，「ｉｎｓｅｒｔ」のうちのいずれかを設定するかは、更新対象レコードを更新するのか、削除するのか、それとも新たにレコードを追加するのかにより決定される。
【００２９】
（ｃ）ｃｏｍｍｉｔ（結果確定）実行時
ｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０のタイムスタンプ欄１２１に「時刻」を設定し、トランザクション番号欄１２２に「Ｔｘ開始時に設定したＴｘ番号」を設定し、ＤＢ操作コード欄１２３に「ｃｏｍｍｉｔ」又は「ｒｏｌｌｂａｃｋ」を設定する。
ＤＢ操作コード欄１２３に「ｃｏｍｍｉｔ」，「ｒｏｌｌｂａｃｋ」のどちらを設定するかは、後述する更新対象競合判定部１１２（図２参照）で更新対象レコードに競合がないと判定された場合は「ｃｏｍｍｉｔ」を設定し、更新対象レコードに競合があると判定された場合は「ｒｏｌｌｂａｃｋ」を設定する。
【００３０】
また、ｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０にエントリを追加するたびに、図４に示すｒｅｄｏログ情報３００を作成する。すなわち、ｒｅｄｏログ更新部１１１は、（ａ）Ｔｘ開始時，（ｂ）ＤＢの更新操作実行時，（ｃ）ｃｏｍｍｉｔ実行時のすべてのタイミングでｒｅｄｏログ情報３００を作成する。ｒｅｄｏログ情報３００の構成は、ｒｅｄｏログ１２０，１３０の１エントリの構成と同じである。ｒｅｄｏログ更新部１１１は、ｒｅｄｏログ情報３００の各欄に、自ノード用ｒｅｄｏログ１２０の同一欄名に設定した内容と同じ内容を設定する。
ｒｅｄｏログ更新部１１１は、作成したｒｅｄｏログ情報３００を、他のノード２に対して送信するように通信部１４０に指示する。通信部１４０（図２参照）は、ｒｅｄｏログ情報３００を、ＴＣＰ（Transmission Control Protocol），ＩＰ（Internet Protocol）等の通信規約に従ってパケット化し、通信装置５（図１参照）を介して他のノード２に送信する。
【００３１】
（２）他のノードでトランザクションが発生した場合
ｒｅｄｏログ更新部１１１は、他のノード２から受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０にエントリを追加する。具体的には、ｒｅｄｏログ更新部１１１は、他ノード用ｒｅｄｏログ１３０の各欄に、ｒｅｄｏログ情報３００の同一欄名に格納されている内容と同じ内容を設定し、エントリを追加する。これにより、一方のノード２の自ノード用ｒｅｄｏログ１２０の内容と、他方のノード２の他ノード用ｒｅｄｏログ１３０の内容は一致される。
【００３２】
（更新対象競合判定部）
図２に示す更新対象競合判定部１１２は、自己のノード２でトランザクションが発生し、かつ、ｃｏｍｍｉｔを行うときに、自己のノード２と他のノード２とで更新対象レコードが競合したか否かの判定を行う。更新対象競合判定部１１２は、更新対象レコードの競合の判定を、トランザクションの開始からｃｏｍｍｉｔを行うときまでの時間帯について、他ノード用ｒｅｄｏログ１３０の内容を調べることにより行う。
具体的には、更新対象競合判定部１１２は、自己のノード２でトランザクションが開始してからｃｏｍｍｉｔを行うときまでの時間帯において、自ノード用ｒｅｄｏログ１２０に追加したエントリのＤＢ操作アドレス欄１２４に設定したアドレスと、他ノード用ｒｅｄｏログ１３０に追加したエントリのＤＢ操作アドレス欄１３４に設定したアドレスとが一致し、かつ、他ノード用ｒｅｄｏログ１３０に、ＤＢ操作コード欄１３３に「ｃｏｍｍｉｔ」が設定されたエントリが追加されている場合に更新対象レコードが競合したと判定する。
【００３３】
仮に、自ノード用ｒｅｄｏログ１２０のＤＢ操作アドレス欄１２４と、他ノード用ｒｅｄｏログ１３０のＤＢ操作アドレス欄１３４とに設定したアドレスが一致しても、他ノード用ｒｅｄｏログ１３０に、ＤＢ操作コード欄１３３に「ｃｏｍｍｉｔ」が設定されたエントリが追加されていなければ更新対象レコードが競合したと判定しない。この場合には、他のノード２の更新対象競合判定部１１２が、更新対象レコードが競合したと判定することになる。すなわち、更新対象レコードが競合した場合に、先にｃｏｍｍｉｔが行われた更新処理を優先する。
【００３４】
（ｒｅｄｏログファイル更新部）
図２に示すｒｅｄｏログファイル更新部１１３は、自ノード用ｒｅｄｏログ１２０に、ＤＢ操作コード欄１２３に「ｃｏｍｍｉｔ」が設定されたエントリが追加されたときに、自ノード用ｒｅｄｏログ１２０の内容をｒｅｄｏログファイル２２１に書き出す。
また、ｒｅｄｏログファイル更新部１１３は、他ノード用ｒｅｄｏログ１３０に、ＤＢ操作コード欄１３３に「ｃｏｍｍｉｔ」が設定されたエントリが追加さたときに、他ノード用ｒｅｄｏログ１３０の内容をｒｅｄｏログファイル２２１に書き出す。
【００３５】
（データファイル更新部）
図２に示すデータファイル更新部１１４は、任意のタイミングでｒｅｄｏログファイル２２１の内容をデータファイル２２３に更新する。
【００３６】
≪第１実施形態に係るデータベース制御システムのデータベース更新動作≫
以下、図５から図９を参照して第１実施形態に係るデータベース制御システムのデータベース更新動作について説明する。
図５は、第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）の説明図である。
図５は、ノード２ＡでＴｘＡが、ノード２ＢでＴｘＢがほぼ同時に実行される場合の処理の流れを示している。ＴｘＡは、アドレス＃０００１のレコードを更新し、ＴｘＢは、アドレス＃０００２のレコードを更新するので、ＴｘＡとＴｘＢとでは更新対象レコードが競合しない。他ノード用ｒｅｄｏログ１３０上の白抜き矢印は、更新対象競合判定部１１２が競合判定を行う時間帯を表している。
【００３７】
なお、説明に際して、ｒｅｄｏログ１２０，１３０及びｒｅｄｏログ情報３００のデータの設定の記載については、一部省略する。
また、各ステップ後の、ノード２Ａの自ノード用ｒｅｄｏログ１２０Ａ，及びノード２Ｂの他ノード用ｒｅｄｏログ１３０Ｂの状態、さらに、ノード２Ｂの自ノード用ｒｅｄｏログ１２０Ｂ，及びノード２Ａの他ノード用ｒｅｄｏログ１３０Ａの状態を図６Ａ（ａ）〜（ｃ），及び図６Ｂ（ａ）〜（ｃ）に示す。
【００３８】
（ステップＳ００１Ａ）
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、ＴｘＡの開始とともに、トランザクション番号欄１２２Ａに「任意のＴｘ番号」を設定したエントリを自ノード用ｒｅｄｏログ１２０Ａに１行追加する。また、ｒｅｄｏログ更新部１１１Ａは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ｂに送信する。
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ｂにエントリを１行追加する。
【００３９】
（ステップＳ００１Ｂ）
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、ＴｘＢの開始とともに、トランザクション番号欄１２２Ｂに「任意のＴｘ番号」を設定したエントリを自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。
【００４０】
（ステップＳ００２Ａ）
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、ＤＢ操作コード欄１２３Ａに「ｕｐｄａｔｅ」を設定し、ＤＢ操作アドレス欄１２４Ａに「０００１」を設定し、ＤＢ操作パラメタ欄１２５Ａに「ＡＡＡＡＡ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ａに１行追加する。また、ｒｅｄｏログ更新部１１１Ａは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ｂに送信する。
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ｂにエントリを１行追加する。
【００４１】
（ステップＳ００２Ｂ）
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、ＤＢ操作コード欄１２３Ｂに「ｕｐｄａｔｅ」を設定し、ＤＢ操作アドレス欄１２４Ｂに「０００２」を設定し、ＤＢ操作パラメタ欄１２５Ｂに「ＢＢＢＢＢ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。
【００４２】
（ステップＳ００３Ａ）
ノード２Ａの更新対象競合判定部１１２Ａは、ｃｏｍｍｉｔを行うときに、ノード２Ａとノード２Ｂとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の時刻は「20090101010101005」とする。
更新対象競合判定部１１２Ａは、自ノード用ｒｅｄｏログ１２０Ａのタイムスタンプ欄１２１Ａを参照することで、ＴｘＡの開始が「20090101010101001」であることを把握し、他ノード用ｒｅｄｏログ１３０Ａのタイムスタンプ欄１３１Ａの日時が「20090101010101001」から「20090101010101005」までの間のエントリで自ノード用ｒｅｄｏログ１２０ＡのＤＢ操作アドレス欄１２４Ａの値と他ノード用ｒｅｄｏログ１３０ＡのＤＢ操作アドレス欄１３４Ａの値が一致するエントリがあるか否か調べるが、一致するエントリはないと分かる。その為、更新対象競合判定部１１２Ａは、更新対象レコードの競合はないと判定する。
【００４３】
次に、ノード２Ａのｒｅｄｏログ更新部１１１Ａは、更新対象レコードの競合はないと判定されたので、ＤＢ操作コード欄１２３Ａに「ｃｏｍｍｉｔ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ａに１行追加する。また、ｒｅｄｏログ更新部１１１Ａは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ｂに送信する。さらに、ｒｅｄｏログファイル更新部１１３Ａは、自ノード用ｒｅｄｏログ１２０Ａの内容をｒｅｄｏログファイル２２１Ａに書き出す。
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ｂにエントリを１行追加する。さらに、ｒｅｄｏログファイル更新部１１３Ｂは、他ノード用ｒｅｄｏログ１３０Ｂの内容をｒｅｄｏログファイル２２１Ｂに書き出す。
【００４４】
（ステップＳ００３Ｂ）
ノード２Ｂの更新対象競合判定部１１２Ｂは、ｃｏｍｍｉｔを行うときに、ノード２Ａとノード２Ｂとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の時刻は「20090101010101006」とする。
更新対象競合判定部１１２Ｂは、自ノード用ｒｅｄｏログ１２０Ｂのタイムスタンプ欄１２１Ｂを参照することで、ＴｘＢの開始が「20090101010101002」であることを把握し、他ノード用ｒｅｄｏログ１３０Ｂのタイムスタンプ欄１３１Ｂの日時が「20090101010101002」から「20090101010101006」までの間のエントリで自ノード用ｒｅｄｏログ１２０ＢのＤＢ操作アドレス欄１２４Ｂの値と他ノード用ｒｅｄｏログ１３０ＢのＤＢ操作アドレス欄１３４Ｂの値が一致するエントリがあるか否か調べるが、一致するエントリはないと分かる。その為、更新対象競合判定部１１２Ｂは、更新対象レコードの競合はないと判定する。
【００４５】
次に、ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、更新対象レコードの競合はないと判定されたので、ＤＢ操作コード欄１２３Ｂに「ｃｏｍｍｉｔ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。さらに、ｒｅｄｏログファイル更新部１１３Ｂは、自ノード用ｒｅｄｏログ１２０Ｂの内容をｒｅｄｏログファイル２２１Ｂに書き出す。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。さらに、ｒｅｄｏログファイル更新部１１３Ａは、他ノード用ｒｅｄｏログ１３０Ａの内容をｒｅｄｏログファイル２２１Ａに書き出す。
以上で、第１実施形態に係るデータベース制御システム１のデータベース更新動作（更新データの競合なし）の説明を終了する。
【００４６】
図７は、第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の説明図である。
図７は、ノード２ＡでＴｘＡが、ノード２ＢでＴｘＢがほぼ同時に実行される場合の処理の流れを示している。ＴｘＡ，ＴｘＢ共に、アドレス＃０００１のレコードを更新するので更新対象レコードが競合する。他ノード用ｒｅｄｏログ１３０上の白抜き矢印は、更新対象競合判定部１１２が競合判定を行う時間帯を表している。
【００４７】
なお、説明に際して、ｒｅｄｏログ１２０，１３０及びｒｅｄｏログ情報３００のデータの設定の記載については、一部省略する。
また、各ステップ後の、ノード２Ａの自ノード用ｒｅｄｏログ１２０Ａ，及びノード２Ｂの他ノード用ｒｅｄｏログ１３０Ｂの状態、さらに、ノード２Ｂの自ノード用ｒｅｄｏログ１２０Ｂ，及びノード２Ａの他ノード用ｒｅｄｏログ１３０Ａの状態を図６Ａ（ａ）〜（ｃ）及び図８（ａ）〜（ｃ）に示す。
【００４８】
（ステップＳ００１Ａ，Ｓ００１Ｂ，Ｓ００２Ａ）
ステップＳ００１Ａ，Ｓ００１Ｂ，Ｓ００２Ａの処理は、前記第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合なし）の説明（図５参照）と同じなので説明を省略する。
【００４９】
（ステップＳ００２Ｂ）
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、ＤＢ操作コード欄１２３Ｂに「ｕｐｄａｔｅ」を設定し、ＤＢ操作アドレス欄１２４Ｂに「０００１」を設定し、ＤＢ操作パラメタ欄１２５Ｂに「ＢＢＢＢＢ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。
【００５０】
（ステップＳ００３Ａ）
ノード２Ａの更新対象競合判定部１１２Ａは、ｃｏｍｍｉｔを行うときに、ノード２Ａとノード２Ｂとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の時刻は「20090101010101005」とする。
更新対象競合判定部１１２Ａは、自ノード用ｒｅｄｏログ１２０Ａのタイムスタンプ欄１２１Ａを参照することで、ＴｘＡの開始が「20090101010101001」であることを把握し、他ノード用ｒｅｄｏログ１３０Ａのタイムスタンプ欄１３１Ａの日時が「20090101010101001」から「20090101010101005」までの間のエントリで、自ノード用ｒｅｄｏログ１２０ＡのＤＢ操作アドレス欄１２４Ａの値と他ノード用ｒｅｄｏログ１３０ＡのＤＢ操作アドレス欄１３４Ａの値とが一致するエントリがあるが、ＤＢ操作コード欄１３３Ａに「ｃｏｍｍｉｔ」が設定されたエントリがないと分かる。その為、更新対象競合判定部１１２Ａは、更新対象レコードの競合はないと判定する。
【００５１】
次に、ノード２Ａのｒｅｄｏログ更新部１１１Ａは、更新対象レコードの競合はないと判定されたので、ＤＢ操作コード欄１２３Ａに「ｃｏｍｍｉｔ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ａに１行追加する。また、ｒｅｄｏログ更新部１１１Ａは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ｂに送信する。さらに、ｒｅｄｏログファイル更新部１１３Ａは、自ノード用ｒｅｄｏログ１２０Ａの内容をｒｅｄｏログファイル２２１Ａに書き出す。
ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ｂにエントリを１行追加する。さらに、ｒｅｄｏログファイル更新部１１３Ｂは、他ノード用ｒｅｄｏログ１３０Ｂの内容をｒｅｄｏログファイル２２１Ｂに書き出す。
【００５２】
（ステップＳ００３Ｂ）
ノード２Ｂの更新対象競合判定部１１２Ｂは、ｃｏｍｍｉｔを行うときに、ノード２Ａとノード２Ｂとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の時刻は「20090101010101006」とする。
更新対象競合判定部１１２Ｂは、自ノード用ｒｅｄｏログ１２０Ｂのタイムスタンプ欄１２１Ｂを参照することで、ＴｘＢの開始が「20090101010101002」であることを把握し、他ノード用ｒｅｄｏログ１３０Ｂのタイムスタンプ欄１３１Ｂの日時が「20090101010101002」から「20090101010101006」までの間のエントリで自ノード用ｒｅｄｏログ１２０ＢのＤＢ操作アドレス欄１２４Ｂの値と他ノード用ｒｅｄｏログ１３０ＢのＤＢ操作アドレス欄１３４Ｂの値とが一致するエントリがあり、かつ、ＤＢ操作コード欄１３３Ｂに「ｃｏｍｍｉｔ」が設定されたエントリもあると分かる。その為、更新対象競合判定部１１２Ｂは、更新対象レコードの競合があると判定する。
【００５３】
次に、ノード２Ｂのｒｅｄｏログ更新部１１１Ｂは、更新対象レコードの競合があると判定されたので、ＤＢ操作コード欄１２３Ｂに「ｒｏｌｌｂａｃｋ」を設定したエントリを、自ノード用ｒｅｄｏログ１２０Ｂに１行追加する。また、ｒｅｄｏログ更新部１１１Ｂは、追加したエントリと同じ内容でｒｅｄｏログ情報３００を作成し、このｒｅｄｏログ情報３００をノード２Ａに送信する。そして、ノード２Ｂは、ＴｘＢの実行を中止する。
ノード２Ａのｒｅｄｏログ更新部１１１Ａは、受信したｒｅｄｏログ情報３００を基に、他ノード用ｒｅｄｏログ１３０Ａにエントリを１行追加する。
以上で、第１実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の説明を終了する。このように、本実施形態に係るデータベース制御システムでは、更新操作において競合があっても、待ちが発生することがない。
【００５４】
≪第２実施形態に係るデータベース制御システムを構成するノードの機能及び使用するフォーマット≫
＜ノードが備える機能＞
（概要）
第１実施形態に係るノード２（図２参照）では、前記した通り、ノード２間で更新対象レコードが競合した場合に、先にｃｏｍｍｉｔした方を優先する。そして、自ノード用ｒｅｄｏログ１２０と他ノード用ｒｅｄｏログ１３０の情報を比較する際には、各ノード２で同期しているタイマ６（図１参照）に基づいてｒｅｄｏログ１２０，１３０のタイムスタンプ欄１２１，１３１に書き込まれる時刻の情報を利用して、参照するｒｅｄｏログ１２０，１３０の範囲を決定する。
【００５５】
実際には、ノード２間でのｒｅｄｏログ情報３００の送信には、ある程度時間がかかるため、ｃｏｍｍｉｔを行うときに、即時に更新対象レコードの競合を判定することができない。すなわち、自己のノードでｃｏｍｍｉｔを行うときに、自己のノードが備える他ノード用ｒｅｄｏログ１３０には他のノードのｃｏｍｍｉｔの情報が反映されていないが、実際には、他のノードでｃｏｍｍｉｔが行われており、ｒｅｄｏログ情報３００の伝送遅延により自己のノードが備える他ノード用ｒｅｄｏログ１３０に他のノードのｃｏｍｍｉｔの情報が反映されていない場合である。この場合、自己のノードは、ｃｏｍｍｉｔを行う時点では他のノードがｃｏｍｍｉｔを行っているのか否かを判定することができない。
【００５６】
そのため、第２実施形態に係るノードは、更新情報がない場合も定期的にタイムスタンプ欄以外はデータを設定しないｒｅｄｏログ情報（以下、空のｒｅｄｏログ情報と称す）を他ノードに送信し、空のｒｅｄｏログ情報を受信したノードは、受信した時刻と空のｒｅｄｏログ情報のタイムスタンプ欄に格納される時刻との差を更新対象レコードが競合したか否かの判定に利用する。
ここで、第２実施形態に係るデータベース制御システムの構成は、図１に示す第１実施形態に係るデータベース制御システム１と同じである。
以下、第２実施形態に係るノードについて説明する。
【００５７】
図９は、第２実施形態に係るデータベース制御システムを構成するノードの機能構成図である。図９では、各機能を「○○部」と記載している。
第２実施形態に係るノード２は、第１実施形態に係るノード２（図２参照）の機能に加えてさらに、ｒｅｄｏログ情報送信遅延演算部１１５を備える。また、ｒｅｄｏログ更新部１１１，及び更新対象競合判定部１１２の機能が異なる。それ以外のデータ構成等は第１実施形態と同様である。以下、説明する。
【００５８】
（ｒｅｄｏログ更新部）
ｒｅｄｏログ更新部１１１は、第１実施形態に係るｒｅｄｏログ更新部１１１の機能に加えて、以下の機能を備える。
本実施形態に係るｒｅｄｏログ更新部１１１は、自ノード用ｒｅｄｏログ１２０の更新をしておらず、本来ならば、他ノードに対してｒｅｄｏログ情報を送信する必要がない場合でも、図４に示すタイムスタンプ欄３０１に「時刻」を設定し、それ以外の欄にはデータを設定しない空のｒｅｄｏログ情報３００を、定期的に他のノード２に送信する機能を備える。
【００５９】
（ｒｅｄｏログ情報送信遅延演算部）
ｒｅｄｏログ情報送信遅延演算部１１５は、空のｒｅｄｏログ情報３００を受信したら、現在の時刻と、空のｒｅｄｏログ情報３００のタイムスタンプ欄３０１に設定される時刻との時間差をメモリ上に保存する。
ここで、メモリ上に保存する時間差は、現在の時刻と直近の空のｒｅｄｏログ情報３００に設定される時刻との単純な時間差だけでなく、現在の時刻と受信した複数個のｒｅｄｏログ情報３００に設定されている時刻との平均値との差としてもよい。また、メモリ上に保存される時間差には、上記以外にも種々の影響を考慮した値を設定することができる。
【００６０】
（更新対象競合判定部）
本実施形態に係る更新対象競合判定部１１２は、自己のノード２でトランザクションが発生し、かつ、ｃｏｍｍｉｔを行うときに、ｒｅｄｏログ情報送信遅延演算部１１５によりメモリ上に保存された時間差分だけ待って、自己のノード２（２Ａ）と他のノード２（２Ｂ）とで更新対象レコードが競合したか否かの判定を行う。
すなわち、更新対象競合判定部１１２は、トランザクションの開始からｃｏｍｍｉｔを行ったときからメモリ上に保存される時間差分加えた時間帯までの他ノード用ｒｅｄｏログ１３０の内容を調べることで更新対象レコードの競合を判定する。
【００６１】
≪第２実施形態に係るデータベース制御システムのデータベース更新動作≫
以下、図１０を参照して第２実施形態に係るデータベース制御システムのデータベース更新動作について説明する。
図１０は、第２実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の説明図である。
図１０は、ノード２ＡでＴｘＡが、ノード２ＢでＴｘＢがほぼ同時に実行される場合の処理の流れを示している。ＴｘＡ，ＴｘＢ共に、アドレス＃０００１のレコードを更新するので更新対象レコードが競合する。以下、ステップＳ００３Ｂを使って本実施形態の動作を説明する。
【００６２】
なお、説明に際して、ｒｅｄｏログ１２０，１３０及びｒｅｄｏログ情報３００のデータの設定の記載については、一部省略する。
また、ステップ後の、ノード２Ａの自ノード用ｒｅｄｏログ１２０Ａ，及びノード２Ｂの他ノード用ｒｅｄｏログ１３０Ｂの状態、さらに、ノード２Ｂの自ノード用ｒｅｄｏログ１２０Ｂ，及びノード２Ａの他ノード用ｒｅｄｏログ１３０Ａの状態は図８（ａ）〜（ｃ）と同じである。
【００６３】
（ステップＳ００３Ｂ）
ノード２Ｂの更新対象競合判定部１１２Ｂは、ｃｏｍｍｉｔを行う前に、自ノードと他ノードとで更新対象レコードが競合したか否かの判定を行う。ここで、現時点の日時は「20090101010101006」だとする。また、ノード２Ｂのｒｅｄｏログ情報送信遅延演算部１１５は、空のｒｅｄｏログ情報を受信して一定の時間差があることを把握し、この時間差をメモリ上に保存している。
【００６４】
更新対象競合判定部１１２Ｂは、現時点からメモリ上に保存した時間差後に更新対象レコードが競合したか否かの判定を行う。更新対象競合判定部１１２Ｂは、自ノード用ｒｅｄｏログ１２０Ｂのタイムスタンプ欄１２１Ｂを参照することで、ＴｘＢの開始が「20090101010101002」であることを把握し、他ノード用ｒｅｄｏログ１３０Ｂのタイムスタンプ欄１３１Ｂの日時が「20090101010101002」から「20090101010101006」までの間のエントリで自ノード用ｒｅｄｏログ１２０ＢのＤＢ操作アドレス欄１２４Ｂの値と他ノード用ｒｅｄｏログ１３０ＢのＤＢ操作アドレス欄１３４Ｂの値とが一致するエントリがあり、かつ、ＤＢ操作コード欄１３３Ｂに「ｃｏｍｍｉｔ」が設定されたエントリもあると分かる。その為、更新対象競合判定部１１２Ｂは、更新対象レコードの競合があると判定する。
【００６５】
仮に、更新対象競合判定部１１２Ｂが、現時点「20090101010101006」で競合を判定した場合を想定する。現時点では、ノード２Ａのｃｏｍｍｉｔ情報がノード２Ｂに届いていないので、更新対象競合判定部１１２Ｂは、実際は競合があるのに、競合なしと判定してしまう。
以上で、第２実施形態に係るデータベース制御システムのデータベース更新動作（更新データの競合あり）の説明を終了する。
【００６６】
なお、本実施形態に係るデータベース制御システムは、自己のノードでｃｏｍｍｉｔを行うときに、自己のノードが備える他ノード用ｒｅｄｏログ１３０には他のノードのｃｏｍｍｉｔの情報が反映されていないが、他のノードでｃｏｍｍｉｔが行われており、ｒｅｄｏログ情報３００の伝送遅延により自己のノードが備える他ノード用ｒｅｄｏログ１３０に他のノードのｃｏｍｍｉｔの情報が反映されていない場合に有効である。
【００６７】
（第２実施形態に係るデータベース制御システムの効果）
ノード間の伝送に遅延が生じても、更新対象レコードの競合の判定を行うことが可能になる。
【符号の説明】
【００６８】
１ データベース制御システム
２（２Ａ，２Ｂ） ノード（計算機）
６（６Ａ，６Ｂ） タイマ
１００（１００Ａ，１００Ｂ） 制御装置
１１０（１１０Ａ，１１０Ｂ） データベース管理部
１１１（１１１Ａ，１１１Ｂ） ｒｅｄｏログ更新部
１１２（１１２Ａ，１１２Ｂ） 更新対象競合判定部
１１５（１１５Ａ，１１５Ｂ） ｒｅｄｏログ情報送信遅延演算部
１２０（１２０Ａ，１２０Ｂ） 自ノード用ｒｅｄｏログ（自己更新情報）
１３０（１３０Ａ，１３０Ｂ） 他ノード用ｒｅｄｏログ（他の更新情報）
２００（２００Ａ，２００Ｂ） 記憶装置
２１０（２１０Ａ，２１０Ｂ） ＤＢＭＳ（データベース管理プログラム）
２２０（２２０Ａ，２２０Ｂ） ＤＢ（データベース）
３００ ｒｅｄｏログ情報（更新データ）
【特許請求の範囲】
【請求項１】
複数の同じ内容のデータベースに通信可能に接続されて多重化されたデータベースのうち少なくとも１つを備える計算機であって、
自己が保有するデータベースの自己更新情報と、自己が保有するデータベース以外のデータベースの他の更新情報とを各データベース毎に分けて保有する記憶部と、
前記自己更新情報を更新する際に、前記他の更新情報を参照することで、前記多重化されたデータベースの更新における競合を判定する競合判定部と、
を備えることを特徴とする計算機。
【請求項２】
前記他の更新情報は、自己以外の計算機が各々備えるデータベースの更新データを受信したときに前記記憶部に記憶される、
ことを特徴とする請求項１に記載の計算機。
【請求項３】
前記競合判定部は、前記自己更新情報の更新の開始から結果確定までの時間帯で、前記自己更新情報の更新対象レコードのアドレスと前記他の更新情報の更新対象レコードのアドレスとが一致し、かつ、他の更新情報の更新処理が結果確定している場合に前記多重化されたデータベースの更新が競合したと判定する、
ことを特徴とする請求項２に記載の計算機。
【請求項４】
自己以外の計算機が発信する発信時刻を記載したデータを受信する時刻と、この発信時刻との時間差を計算する遅延演算部をさらに備え、
前記競合判定部は、前記時間差だけ待って前記多重化されたデータベースの更新が競合したか否かの判定を行う、
ことを特徴とする請求項２又は請求項３に記載の計算機。
【請求項５】
前記発信する発信時刻を記載したデータは、前記更新データである、
ことを特徴とする請求項４に記載の計算機。
【請求項６】
複数の同じ内容のデータベースに通信可能に接続されて多重化されたデータベースのうち少なくとも１つを備える計算機の制御装置に実行させるデータベース管理プログラムであって、
前記自己の計算機が保有するデータベースの自己更新情報と、前記自己が保有するデータベース以外のデータベースの他の更新情報とを各データベース毎に分けて記憶部に保有させる機能と、
前記自己情報を更新する際に、前記他の更新情報を参照することで、前記多重化されたデータベースの更新における競合を判定する機能と、
を前記制御装置に実現させることを特徴とするデータベース管理プログラム。
【請求項１】
複数の同じ内容のデータベースに通信可能に接続されて多重化されたデータベースのうち少なくとも１つを備える計算機であって、
自己が保有するデータベースの自己更新情報と、自己が保有するデータベース以外のデータベースの他の更新情報とを各データベース毎に分けて保有する記憶部と、
前記自己更新情報を更新する際に、前記他の更新情報を参照することで、前記多重化されたデータベースの更新における競合を判定する競合判定部と、
を備えることを特徴とする計算機。
【請求項２】
前記他の更新情報は、自己以外の計算機が各々備えるデータベースの更新データを受信したときに前記記憶部に記憶される、
ことを特徴とする請求項１に記載の計算機。
【請求項３】
前記競合判定部は、前記自己更新情報の更新の開始から結果確定までの時間帯で、前記自己更新情報の更新対象レコードのアドレスと前記他の更新情報の更新対象レコードのアドレスとが一致し、かつ、他の更新情報の更新処理が結果確定している場合に前記多重化されたデータベースの更新が競合したと判定する、
ことを特徴とする請求項２に記載の計算機。
【請求項４】
自己以外の計算機が発信する発信時刻を記載したデータを受信する時刻と、この発信時刻との時間差を計算する遅延演算部をさらに備え、
前記競合判定部は、前記時間差だけ待って前記多重化されたデータベースの更新が競合したか否かの判定を行う、
ことを特徴とする請求項２又は請求項３に記載の計算機。
【請求項５】
前記発信する発信時刻を記載したデータは、前記更新データである、
ことを特徴とする請求項４に記載の計算機。
【請求項６】
複数の同じ内容のデータベースに通信可能に接続されて多重化されたデータベースのうち少なくとも１つを備える計算機の制御装置に実行させるデータベース管理プログラムであって、
前記自己の計算機が保有するデータベースの自己更新情報と、前記自己が保有するデータベース以外のデータベースの他の更新情報とを各データベース毎に分けて記憶部に保有させる機能と、
前記自己情報を更新する際に、前記他の更新情報を参照することで、前記多重化されたデータベースの更新における競合を判定する機能と、
を前記制御装置に実現させることを特徴とするデータベース管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１１−７６４８７（Ｐ２０１１−７６４８７Ａ）
【公開日】平成２３年４月１４日（２０１１．４．１４）
【国際特許分類】
【出願番号】特願２００９−２２８８６４（Ｐ２００９−２２８８６４）
【出願日】平成２１年９月３０日（２００９．９．３０）
【出願人】（３０８０３３７２２）株式会社ＯＫＩネットワークス (165)
【Ｆターム（参考）】
【公開日】平成２３年４月１４日（２０１１．４．１４）
【国際特許分類】
【出願日】平成２１年９月３０日（２００９．９．３０）
【出願人】（３０８０３３７２２）株式会社ＯＫＩネットワークス (165)
【Ｆターム（参考）】
[ Back to top ]