JP2015064777A - データベースシステム、データベース更新方法及びデータベース更新プログラム - Google Patents

Abstract

【課題】データベースサーバ間のデータ整合処理において、最適化された条件及び整合実施順序により、差分データの整合を最適化することができるようにする。【解決手段】本発明は、データ更新が行なわれている第１のデータベースサーバと、データ更新がなされていない第２のデータベースサーバとの間のデータ差分の整合を行う際、基準日時情報以降に、第１のデータベースサーバにおいて更新されたデータのうち、所定の差分抽出条件情報に基づいて、削除差分、更新差分及び追加差分を抽出する差分抽出手段と、抽出されたデータ差分に基づき、第２のデータベースサーバに対して、削除整合処理、更新整合処理、追加整合処理の順でデータ更新を行ないデータ整合処理手段とを備える。【選択図】 図１

Description

本発明は、データベースシステム、データベース更新方法及びデータベース更新プログラムに関し、例えば、冗長化されたデータベースサーバにおいて発生した差分データを整合するデータベースシステム、データベース更新方法及びデータベースプログラムに適用し得るものである。

従来、データベース分散トランザクション環境下において、分散されたデータベース間のデータ整合性を保つために、データベースサーバとデータベースクライントとの間で二相コミットプロトコルに従ったデータ更新が行なわれる場合がある。

しかし、二相コミットは、全てのデータベースサーバがコミット可能な状態であることが必要となる。そのため、一部のデータベースサーバが停止している場合には、二相コミットによるデータ更新を実行することができない事態が生じ得る。

特許文献１には、二相コミットによるデータ更新を実行できない場合に、一相コミットプロトコルに従って更新されたデータを、冗長化された他のデータベースに整合することが開示されている。

特開２００９−１２２９３５号公報

しかしながら、上述した特許文献１の記載技術は、冗長化された複数のデータベースサーバ間でデータの差分が生じている場合にデータの整合性を図る詳細な方式や手順については明らかでない。

例えば、更新時刻情報に基づいて、あるデータベースサーバ（以下、ＤＢサーバ）上のデータを、他方のＤＢサーバに整合する場合、差分データの整合を無条件で実施すると、エラーの発生や冗長な処理で整合に時間が掛かるため、非効率な処理で実施する可能性が生じ得る。

そのため、データベースサーバ間のデータ整合処理において、最適化された条件及び整合実施順序により、差分データの整合を最適化することができるデータベースシステム、データベース更新方法及びデータベース更新プログラムが求められている。

かかる課題を解決するために、第１の本発明は、継続的にデータ更新が行なわれている第１のデータベースサーバと、データ更新がなされていない第２のデータベースサーバとの間のデータ差分の整合を行うデータベースシステムにおいて、（１）データ差分が生じ得る基準日時情報以降に、第１のデータベースサーバにおいて更新されたデータのうち、所定の差分抽出条件情報に基づいて、削除差分、更新差分及び追加差分を抽出する差分抽出手段と、（２）差分抽出手段により抽出されたデータ差分に基づき、第２のデータベースサーバに対して、削除整合処理、更新整合処理、追加整合処理の順でデータ更新を行ない、第２のデータベースサーバに記録されるデータを第１のデータベースサーバに記録されるデータと一致させるデータ整合処理手段とを備えることを特徴とするデータベースシステムである。

第２の本発明は、継続的にデータ更新が行なわれている第１のデータベースサーバと、データ更新がなされていない第２のデータベースサーバとの間のデータ差分の整合を行うデータベース更新方法において、（１）差分抽出手段が、データ差分が生じ得る基準日時情報以降に、第１のデータベースサーバにおいて更新されたデータのうち、所定の差分抽出条件情報に基づいて、削除差分、更新差分及び追加差分を抽出する差分抽出工程と、（２）データ整合処理手段が、上記差分抽出手段により抽出されたデータ差分に基づき、第２のデータベースサーバに対して、削除整合処理、更新整合処理、追加整合処理の順でデータ更新を行ない、第２のデータベースサーバに記録されるデータを第１のデータベースサーバに記録されるデータと一致させるデータ整合処理工程とを有することを特徴とするデータベース更新方法である。

第３の本発明は、継続的にデータ更新が行なわれている第１のデータベースサーバと、データ更新がなされていない第２のデータベースサーバとの間のデータ差分の整合を行うデータベース更新プログラムにおいて、コンピュータを、（１）データ差分が生じ得る基準日時情報以降に、第１のデータベースサーバにおいて更新されたデータのうち、所定の差分抽出条件情報に基づいて、削除差分、更新差分及び追加差分を抽出する差分抽出手段と、（２）差分抽出手段により抽出されたデータ差分に基づき、第２のデータベースサーバに対して、削除整合処理、更新整合処理、追加整合処理の順でデータ更新を行ない、第２のデータベースサーバに記録されるデータを第１のデータベースサーバに記録されるデータと一致させるデータ整合処理手段として機能させることを特徴とするデータベース更新プログラムである。

本発明によれば、データベースサーバ間のデータ整合処理において、最適化された条件及び整合実施順序により、差分データの整合を最適化することができる。

実施形態に係るデータベースシステムの全体構成を示すブロック図である。 実施形態に係るデータベースクライアント１０、データベースサーバに対する状態ポーリング動作示すシーケンス図である。 実施形態に係るデータベースシステムにおいて、二相コミットの実施ができない場合のトランザクション処理の動作を示すシーケンス図である。 実施形態に係るデータベースシステムにおけるデータ整合の対象とするデータ差分の種類を説明する説明図である。 実施形態に係るデータベースシステムにおけるデータ整合処理を示すフローチャートである。 実施形態に係るデータベースシステムにおけるデータ差分抽出条件を説明する説明図である。 実施形態に係る削除整合処理のＳＱＬ表記のイメージである。 実施形態に係るデータ差分抽出条件の変形例を説明する説明図である。 実施形態に係る更新整合処理のＳＱＬ表記のイメージである。 実施形態に係る追加整合処理のＳＱＬ表記のイメージである。 実施形態に係るデータベースシステム１においてデータ整合処理の際の各データベースサーバ上のレコード状態を説明する説明図である。 実施形態に係るデータベースシステム１において削除整合処理の際の各データベースサーバ上のレコード状態を説明する説明図である。 実施形態に係るデータベースシステム１において更新整合処理の際の各データベースサーバ上のレコード状態を説明する説明図である。 実施形態に係るデータベースシステム１において追加整合処理の際の各データベースサーバ上のレコード状態を説明する説明図である。

（Ａ）主たる実施形態
以下、本発明のデータベースシステム、データベース更新方法及びデータベース更新プログラムの実施形態を、図面を参照しながら詳細に説明する。

（Ａ−１）実施形態の構成
図１は、この実施形態に係るデータベースシステム１の全体構成を示すブロック図である。

図１において、この実施形態に係るデータベースサーバ１は、ネットワークＮに接続可能な、データベースクライアント１０、２台のデータベースサーバ２０（２０−１、２０−２）を有する。

なお、以下では、必要に応じて、データベースサーバ２０−１をＤＢサーバ＃１、データベースサーバ２０−２をＤＢサーバ＃２と表記して説明する。

データベースシステム１は、データベースクライアント１０から、データベースサーバ２０−１、２０−２にデータベースのデータ更新や参照などのトランザクションが与えられ、処理が行われる分散トランザクション環境である。

データベースクライアント１０は、データベースサーバ２０−１、２０−２にデータベースに係るトランザクションを与えるものである。図１では、データベースクライアント１０が１個の構成となっているが、その数は限定されないものである。データベースクライアント１０は、パーソナルコンピュータ等の情報処理装置（１台に限定されず、複数台を分散処理し得るようにしたものであっても良い。）上に、実施形態のデータベースクライアントプログラム（固定データを含む）をインストールすることにより、構築されるものである。

データベースサーバ２０（２０−１、２０−２）は、データベースクライアント１０から与えられたトランザクションの処理を行うものであり、ＤＢＭＳ２１（２１−１、２１−２）、データベースファイルシステム２２（２２−１、２２−２）を有している。データベースサーバ２０−１、２０−２は、パーソナルコンピュータなどの情報処理装置（１台に限定されず、複数台を分散処理し得るようにしたものであっても良い。）上に、実施形態のデータベース提供プログラム（固定データを含む）やデータベース更新プログラムをインストールすることにより、構築されるものであるが、機能的には図１のように表すことができる。

ＤＢＭＳ２１−１、２１−２は、データベース管理システム（Ｄａｔａ Ｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）の機能を担っており、例えば、データベースクライアント１０からトランザクションを受け取り、データベースファイルシステム２２−１、２２−２を制御するなどして受け取ったトランザクションの処理を行うものである。

データベースファイルシステム２２（２２−１、２２−２）は、データベースサーバ２０（２０−１、２０−２）において、データベースのデータを記憶する機能などを担っており、例えば、ＤＢＭＳ２１（２１−１、２１−２）の制御に基づいて記憶しているデータの更新を行うものである。また、データベースファイルシステム２２（２２−１、２２−２）は、データ記憶部２２１（２２１−１、２２１−２）、フラグ管理部２２２（２２２−１、２２２−２）、データ整合部５１（５１−１、５１−２）を有している。

データ記憶部２２１−１、２２１−２は、データベースサーバ２０−１、２０−２において、データベースサービスに利用するデータを格納する機能を担っており、メモリデータベースやキャッシュメモリを使用している場合はそれが該当する。

フラグ管理部２２２（２２２−１、２２２−２）は、データベースのデータ更新において、二相コミットにより行われるか否かについて管理するものであり、二相コミットフラグ２２３（２２３−１、２２３−２）を有している。

フラグ管理部２２２−１、２２２−２は、当該データベースサーバ２０−１、２０−２において、データベースのデータ更新が、二相コミットにより行われるか否かを示す二相コミットフラグ２２３−１、２２３−２を管理するものである。例えば、二相コミットフラグ２２３−１、２２３−２の内容が「ＯＮ」に設定されていた場合には、通常通りデータベースのデータ更新が二相コミットプロトコルに従って行われ、「ＯＦＦ」に設定されていた場合には、二相コミットプロトコルではなく一相コミットプロトコルに従ってデータ更新が行われることを示している。

なお、二相コミットフラグ２２３−１、２２３−２に登録される内容は、クライアントライブラリ１１が、二相コミットを実施出来ないことを認識できれば良く、例えば、プログラムのメモリ上のフラグやロックファイル、データベース内への状態書き込みなどを用いても良い。また、二相コミットフラグ２２３−１、２２３−２の内容は、クライアントライブラリ１１が、二相コミットを実施できないことを認識できれば良いので、「ＯＮ／ＯＦＦ」などのフラグによる表示ではなく、例えば、「二相コミットプロトコル／一相コミットプロトコル」などの表示であっても良く、その表示方式は限定されないものである。

また、二相コミットフラグ２２３−１、２２３−２の内容は、データベースクライアント１０のクライアントライブラリ１１により読み込まれ、クライアントライブラリ１１では、データベースのデータ更新に関するトランザクションについて、二相コミットフラグ２２３−１、２２３−２の内容に応じて、データベースファイルシステム２２−１、２２−２へ送信するトランザクションの内容を変化させる。

データ整合部５１−１、５１−２は、データベースサーバ間でデータ差分が生じ得る所定の基点時刻情報（基準日時情報とも呼ぶ。）ｔを設定し、その基点時刻情報ｔを基点として、データベースサーバ間で生じ得る、その種類に応じてデータ差分を抽出し、所定の手順に従ってデータ整合を行うものである。つまり、データ整合部５１−１、５１−２は、差分抽出機能とデータ整合機能とを有する。なお、データ整合部５２−１、５２−２による差分抽出方法及びデータ整合方法については、動作の項で詳細に説明する。

ここで、基点時刻情報ｔは、データベースサーバ間で差分データが発生し得る時刻とすることができる。例えば、二相コミットから一相コミットに移行した時点の時刻とすることができる。また例えば、基点時刻情報ｔは、いずれかのデータベースサーバにおいて障害やメンテナンス等により停止する場合に、その障害発生時の時刻としたり、メンテナンスによる停止時の時刻等としたりすることができる。

クライアントライブラリ１１では、二相コミットプロトコルによりデータ更新ができなくなり、いずれかのデータベースサーバ２０の二相コミットフラグ２２３がＯＦＦに設定された場合には、全てのデータベースサーバ２０から二相コミットフラグ２２３の読み込みを試行し、二相コミットフラグ２２３がＯＦＦに設定されたデータベースサーバにだけデータ更新のトランザクションを送信して一相コミットによりデータ更新を行うようにしても良い。

例えば、データベースサーバ２０−２が保守作業などにより停止中に、データベースサーバ２０−１において、二相コミットフラグ２２３−２の内容が「ＯＦＦ」に設定されていた場合には、クライアントライブラリ１１は、二相コミットフラグ２２３−１の内容を読み込むと、データベースサーバ２０−１にだけデータベース更新のトランザクションを送信し、データベースサーバ２０−１ではそのトランザクションによりデータベースのデータ更新を行う。

クライアントライブラリ１１が、二相コミットフラグ２２３−１、２２３−２の内容を読み込む契機としては、例えば、クライアントライブラリ１１が、データベースサーバ２０−１、２０−２にデータベース接続（ＤＢＭＳ２１−１、２１−２と接続）する際に読み込むようにしても良いし、また例えば、定期的又はトランザクションの発生ごとに読み込むようにしても良いし、さらに例えば、二相コミットできなかった場合に読み込むようにしても良い。また、クライアントライブラリ１１が、それぞれのデータベースサーバ２０−１、２０−２に動作の正常性について問い合わせ（以下、「状態ポーリング」という）を行う際に読み込んでも良い。状態ポーリングについては、後述する動作説明において詳述する。

二相コミットフラグ２２３−１、２２３−２内容については、例えば、保守運用作業者などのオペレータが手動で書き換えを行っても良いし、図１において図示は省略しているが、データベースサーバ２０−１、２０−２の内部又は外部に配置された監視装置により、データベースサーバの動作状況を監視し、データベースサーバの動作状況に応じて、フラグ管理部２２２−１、フラグ管理部２２２−２が書き換えるようにしても良い。例えば、データベースサーバ２０−２が故障などにより停止した場合に、監視装置により検知し、監視装置がその旨をデータベースサーバ２０−１のフラグ管理部２２２−１に通知し、フラグ管理部２２２−１が二相コミットフラグ２２３−１の内容を「ＯＦＦ」に書き換えるようにしても良い。また例えば、クライアントライブラリ１１が、データベースサーバ２０−１、２０−２の動作状況を監視し、その動作状態に応じて、フラグ管理部２２２−１、２２２−２に、二相コミットフラグ２２３−１、２２３−２の内容更新を要求するようにしても良い。

（Ａ−２）第１の実施形態の動作
次に、以上のような構成を有する第１の実施形態のデータベースシステム１におけるデータ更新の動作を説明する。

（Ａ−２−１）状態ポーリングについて
まず、データベースクライアント１０が、データベースサーバ２０−１、２０−２の状態について問い合わせを行う状態ポーリングの動作の例について説明する。

図２は、データベースクライアント１０が、データベースサーバ２０−２に対して状態ポーリングを行った動作の例について示したシーケンス図である。

図２では、データベースクライアント１０が、データベースサーバ２０−２に状態ポーリングを行った場合について示しているが、データベースサーバ２０−１であっても同様であるので説明を省略する。

まず、データベースクライアント１０のクライアントライブラリ１１から、データベースサーバ２０−２に対して、ネットワーク上での疎通確認（例えば、ＰＩＮＧ）が実施される（Ｓ１０１）。例えば、データベースクライアント１０から、データベースサーバ２０−２に対して、ネットワーク上での疎通確認をするための信号が送信され、その応答がデータベースサーバ２０−２からあった場合には通信可と判定される（Ｓ１０２）。

上述のステップＳ１０１によりデータベースサーバ２０−２との疎通が確認された場合には、データベースクライアント１０（クライアントライブラリ１１）から、データベースサーバ２０−２のＤＢＭＳ２１−２にデータベース接続が実施され（Ｓ１０３）、ＤＢＭＳ２１−２から接続応答があると（Ｓ１０４）データベースサーバ２０−２においてデータベース機能が正常に動作していることが確認される（Ｓ１０４）。

上述のステップＳ１０２によりデータベースサーバ２０−２のデータベースとしての正常性が確認された場合は、データベースクライアント１０（クライアントライブラリ１１）は、データベースファイルシステム２２−２へのアクセスの正常性と判断し、データベースファイルシステム２２−２にアクセスする（Ｓ１０５）。そして、データベースファイルシステム２２−２は、アクセス結果をデータベースクライアント１０（クライアントライブラリ１１）に送信し、二相コミットフラグ２２３−２の内容が読込まれる（Ｓ１０６）。

（Ａ−２−２）トランザクション（データベース更新）処理
図１の構成では、通常であればデータベースクライアント１０（クライアントライブラリ１１）から、データベースサービスにおけるデータ更新の要求が、データベースサーバ２０−１、２０−２に対して送信され、二相コミットプロトコルにより、データベースファイルシステム２２−１、２２−２のデータが更新される。

次に、データベースシステム１において、二相コミットの実施ができない場合のトランザクション処理の動作について説明する。

図３は、データベースシステム１において、二相コミットの実施ができない場合のトランザクション処理の動作について説明したシーケンス図である。また、図３においては、データベースサーバ２０−２が、例えば、障害発生等により停止しており、データベースサーバ２０−１の二相コミットフラグ２２３−１には「ＯＦＦ」が設定されているものとする。

まず、データベースクライアント１０のクライアントライブラリ１１により、データベースサーバ２０−１に対して上述の図２に示す状態ポーリングの問い合わせが実施される。ここでは、上述の通りデータベースサーバ２０−２は停止しているので、ネットワーク上の疎通も取ることができず、上述のステップＳ１０１及びＳ１０２の時点で終了し、クライアントライブラリ１１では、データベースサーバ２０−２との接続は不可であったという結果となる（Ｓ２０１）。

クライアントライブラリ１１では、データベースサーバ２０−１に対しても、上述の図２に示す状態ポーリングの問い合わせが実施され、二相コミットフラグ２２３−１の内容が読込まれる（Ｓ２０２）。

二相コミットフラグ２２３−１の内容が読込まれると、データベースクライアント１０では、データベースサーバ２０−１の二相コミットフラグ２２３−１の内容が「ＯＦＦ」となっているため、データベースのデータ更新は、データベースサーバ２０−１に対して一相コミットプロトコルにより行うと決定される（Ｓ２０３）。

そして、データベースクライアント１０からは、データベースサーバ２０−２へのコミットは要求されず、データベースサーバ２０−１に対してのみコミットが要求され（Ｓ２０４）、データベースサーバ２０−１においてデータが更新される（Ｓ２０５）。

（Ａ−２−３）差分データの整合処理
次に、この実施形態に係るデータベースシステム１におけるデータベースサーバ間で生じる差分データの整合処理について図面を参照しながら詳細に説明する。

ここでは、データベースサーバ２０−２に障害が発生して動作が停止した場合を例示する。

データベースサーバ２０−２が一旦停止してしまうと、データベースサーバ２０−１とデータベースサーバ２０−２との間で差分データが生じることになるため、停止状態にあるデータベースサーバ２０−２をそのまま起動させて復帰させることができない。

このとき、データベースサーバ２０−２に障害が発生した場合に、データベース更新のコミットプロトコルを二相コミットから一相コミットに変更し、データベースサーバ２０−１に対してのみデータ更新を行うようにする。

そして、データベースサーバ２０−２が運転を停止し、その後、データベースサーバ２０−２が運転を再開した後に、データベースサーバ２０−１とデータベースサーバ２０−２との間でデータ整合を行う必要がある。

図４は、この実施形態に係るデータベースシステム１におけるデータ整合の対象とするデータ差分の種類を説明する説明図である。なお、図４では、説明を容易にするために、データベースサーバ２０−２が停止しており、データベースサーバ２０−１が一相コミットによるデータ更新がなされている場合を想定したものである。

図４に示すように、データ整合対象となるデータ差分は、大別して、「追加差分」、「更新差分」、「削除差分」がある。

「追加差分」とは、一相コミットによるデータ更新を行うデータベースサーバ（ここでは、データベースサーバ２０−１）に新たにレコードが追加されたときに生じ得る差分をいう。ここでは、レコードの追加態様に応じて、「追加差分」を「追加差分Ａ」と「追加差分Ｂ」とに分別する。「追加差分Ａ」は、データベースサーバ２０−１に追加されたレコードであって、停止状態のデータベースサーバ２０−２に存在しないキーで、データベースサーバ２０−１側に登録されたレコードが追加された差分をいう。「追加差分Ｂ」は、データベースサーバ２０−１に追加されたレコードであって、データベースサーバ２０−２にも存在するキーで、登録されたレコードの差分をいう。例えば、データベースサーバ２０−１側で一旦削除され、同一キーで登録された新たなレコードが追加されたものである。

「更新差分」とは、一相コミットによるデータ更新を行うデータベースサーバ（ここでは、データベースサーバ２０−１）が更新したレコードの差分をいう。例えば、両方のデータベースサーバ２０−１及び２０−２にレコードが存在し、データベースサーバ２０−１で任意のカラムに更新されているレコードの差分である。

「削除差分」とは、一相コミットによるデータ更新を行うデータベースサーバ（ここでは、データベースサーバ２０−１）が削除したレコードの差分をいう。例えば、データベースサーバ２０−１上で削除されたことにより、データベースサーバ２０−１に存在しないレコードで、かつ、データベースサーバ２０−２に存在するレコードの差分である。

図５は、この実施形態に係るデータベースシステム１におけるデータ整合処理を示すフローチャートである。

まず、データベースサーバ２０−１において、データ整合部５１−１は、基点時刻情報ｔを設定する（Ｓ３０１）。

この実施形態では、二相コミットから一相コミットに移行した時点からデータ差分が発生し得るため、二相コミットから一相コミットに移行した時点を基点時刻情報ｔとするものとする。

ここで、データベースサーバ２０−１、２０−２に記憶されるレコードには、日時情報が付される。この日時情報は、レコードが生成（すなわち、登録）された日時情報（以下、生成日時情報とも呼ぶ。）と、レコードが更新された事項情報（以下、更新日時情報とも呼ぶ。）を有する。なお、新規登録されたレコードには、同一の日時を示す生成日時情報及び更新日時情報が設定される。また、既に登録されているレコードが更新されたときには、その更新された日時が更新日時情報として設定される。

データベースサーバ２０−１では、基点時刻情報ｔが保持されているため、データ整合部５１−１、５１−２は、データ差分を抽出基点時刻情報ｔと、レコードの生成日時情報及び更新日時情報とを比較することにより、所定のデータ差分抽出条件に従って、データベースサーバ２０−１内に記憶されるデータの中からデータ差分の抽出し、整合カテゴリを決定する（Ｓ３０２）。

図６は、この実施形態に係るデータベースシステム１におけるデータ差分抽出条件を説明する説明図である。

図６に示すように、データ差分抽出条件は差分の種類毎に定義されており、データ整合部５１−１、５１−２は、データ差分抽出条件に合致するデータ差分を検索する。これにより、データ差分の種類に応じたデータ差分を抽出することができる。また、図６のデータ差分抽出条件には、各条件に合致するデータ差分に対して、どのように整合するかを示す整合カテゴリが定義されている。

「追加差分Ａ」については、データベースサーバ２０−２に同一キーのレコードが存在せず、かつ、データサーバ２０−１の更新日時情報が基点時刻情報ｔ以降のレコードとする。例えば、レコードの追加時は、生成日時情報＝更新日時情報＞基点時刻情報ｔであり、またレコードの追加後に更新されたレコードは、更新日時情報＞生成日時情報＞ｔであるため、いずれの日時情報が条件に入っているものとする。データ整合部５１−１、５１−２は、この条件に合致するデータ差分を、整合カテゴリ「追加整合」とする。

「追加差分Ｂ」については、データベースサーバ２０−１、データベースサーバ２０−２共に、同一キーのレコードが存在し、かつ、データベースサーバ２０−１の生成日時情報／更新日時情報がｔ以降のレコードとする。データ整合部５１−１、５１−２は、この条件に合致するデータ差分を、整合カテゴリ「更新整合」とする。

「更新差分」については、データベース２０−１、データベースサーバ２０−２条に生成日時情報が一致している同一キーのレコードが存在し、かつ、データベースサーバ２０−１の更新日時情報がｔ以降のレコードとする。データ整合部５１−１、５１−２は、この条件に合致するデータ差分を、整合カテゴリ「更新整合」とする。

「削除差分」については、データベースサーバ２０−１にレコードが存在せず、かつ、データベースサーバ２０−２に同一キーのレコードが存在する。一相コミット条件下で、データベースサーバ２０−２のデータが全く操作されないのであれば、生成日時情報、更新日時情報の条件は不要となる。データ整合部５１−１、５１−２は、この条件に合致するデータ差分を、整合カテゴリ「削除整合」とする。

次に、データ整合部５１−１、５１−２は、整合カテゴリ「削除整合」に属するデータ差分についてデータ整合を行う（Ｓ３０３）。つまり、データ整合部５１−１、５１−２は、削除整合を行うことにより、データベースサーバ２０−２側の対象データを削除する。削除対象データの抽出は、図６のデータ差分抽出条件によって決定されたデータ差分に対して行なわれる。

削除整合を最初に実施する理由は、データベースサーバ２０−２側のデータ量を予め削減できる可能性がためである。データ量の削減は、追加差分のデータ整合時処理のフォーマンスに影響するからである。

削除整合の処理をＲＤＢＭＳ（リレーショナルデータベース管理システム）のＳＱＬで表記すると図７に示すような表記となる。図７は、削除整合処理のＳＱＬ表記のイメージである。

データ整合部５１−１及び５１−２は、図７（Ａ）のＳＱＬによって、抽出されたレコードに対して、図７（Ｂ）を繰り返すことで、削除対象データをデータベースサーバ２０−２から削除する。

次に、データ整合部５１−１、５１−２は、整合カテゴリ「更新整合」に属するデータ差分についてデータ整合を行う（Ｓ３０５）。更新差分の整合では、図６のデータ差分抽出条件に従って「更新整合」となっている「追加差分Ｂ」、及び、「更新差分」が対象データとするところが特徴的である。

これは、「追加差分Ｂ」は、両方のデータベースサーバ２０−１及び２０−２に同一キーのレコードが存在しているため、キーカラム以外の全カラムの整合を実施すればからである。また、「更新差分」は、元々、両方のデータベースサーバ２０−１及び２０−２に同一キーのレコードが存在しており、生成日時情報に変化はないが、キーカラム以外の全力ラムの整合、つまりデータベースサーバ２０−１上の情報でデータベースサーバ２０−２側のレコードを上書きすることに問題が発生しないからである。

データベースの性能については、一般的に、更新処理時間＜追加処理時間、および、更新処理時間＜削除処理時間が成り立つ。そのため、「追加差分Ｂ」を実際には更新差分として扱い、「追加差分Ｂ」を更新整合することにより、整合処理性能の向上に効果があると考えられる。

これにより、更新整合を行う際の実際のデータ抽出条件は、図８の通りに見直しすることができる。

図８は、実施形態に係るデータ差分抽出条件の変形例を説明する説明図である。図８では、「追加差分Ｂ」及び「更新差分」については、データベースサーバ２０−１、データベースサーバ２０−２共に、同一キーのレコードが存在し、かつ、データベースサーバ２０−１の更新日時情報がｔ以降のレコード、かつ、データベースサーバ２０−１の更新日時情報が、データベースサーバ２０−２の更新日時情報以降のレコードとするように見直している。データ整合部５１−１、５１−２は、この条件に合致するデータ差分を、整合カテゴリ「更新整合」とする。

また、更新整合処理が、削除整合の次の２番目の手順で実施される理由は、追加差分の整合により、データベースサーバ２０−２側のレコード件数を増加させないためである。更新差分の整合は、両データベースサーバ２０−１及び２０−２に存在するレコードが対象となるが、このレコードを検索する際のデータベースの全体量は少ない方がパフォーマンスは良いはずだからである。

更新整合の処理をＲＤＢＭＳのＳＱＬで表記すると図９に示すような表記となる。図９は、更新整合処理のＳＱＬ表記のイメージである。

データ整合部５１−２は、図９（Ａ）のＳＱＬによって、データベースサーバ２０−１側からキーカラム以外の全カラム情報を取得する。データベースサーバ２０−２において、データ整合部５１−２が、データベースサーバ２０−２のレコードに対して、図９（Ｂ）を繰り返すことで、更新対象データを更新する。

最後に、データ整合部５１−１、５１−２は、整合カテゴリ「追加整合」に属するデータ差分についてデータ整合を行う（Ｓ３０６）。追加差分の整合は、図６のデータ差分抽出条件により抽出した「追加差分Ａ」をデータ対象とする。

更新整合の処理をＲＤＢＭＳのＳＱＬで表記すると図１０に示すような表記となる。図１０は、追加整合処理のＳＱＬ表記のイメージである。

データ整合部５１−１及び５１−２は、図１０（Ａ）のＳＱＬによって、抽出されたレコードに対して、図１０（Ｂ）を繰り返すことで、追加対象データをデータベースサーバ２０−２に追加する。

次に、図１１〜図１４を用いて、具体的なデータ例を参照しながら、この実施形態に係るデータベースシステム１におけるデータ整合処理を説明する。

図１１から図１４では、説明便宜上、「生成日時情報」を「生成日」と表記し、「更新日時情報」を「更新日」と表記している。また、二相エミットから一相エミットに移行した日時情報が「２０１３／６／３０」であり、基点時刻情報ｔが「２０１３／６／３０」とする。

図１１は、データベースサーバ２０−１において一相コミットが実施されて、データベースサーバ２０−１及び２０−２の間に差分データが発生した状態を示している。

図１１において、停止状態にあったデータベースサーバ２０−２には、「生成日：２０１３／６／１」及び「更新日：２０１３／６／１」のデータＡ、「生成日：２０１３／６／１」及び「更新日：２０１３／６／２０」のデータＢ、「生成日：２０１３／６／１」及び「更新日：２０１３／６／１」のデータＣ、「生成日：２０１３／６／１」及び「更新日：２０１３／６／１」のデータＤ、「生成日：２０１３／６／１」及び「更新日：２０１３／６／１」のデータＥが登録されている。

一方、一相コミットによりデータ更新が継続されていたデータベースサーバ２０−１には、「生成日：２０１３／６／１」及び「更新日：２０１３／６／１」のデータＡ、「生成日：２０１３／６／１」及び「更新日：２０１３／６／２０」のデータＢ、「生成日：２０１３／６／１」及び「更新日：２０１３／７／１」のデータＤ、「生成日：２０１３／７／２」及び「更新日：２０１３／７／２」のデータＥ、「生成日：２０１３／７／３」及び「更新日：２０１３／７／３」のデータＦが登録されている。そのため、図１１の例の場合、データＣ、Ｄ、Ｅ、Ｆが差分となる。

まず、削除差分の整合が実施される。このとき、図１１において、データベースサーバ２０−１にレコードが存在せず、かつ、データベースサーバ２０−２に同一キーのレコードとして「データＣ」が存在する。そのため、「データＣ」が「削除差分」として抽出される。

従って、データベースサーバ２０−２では、図１２に示すように、データ整合部５１−２が、「データＣ」をデータベースサーバ２０−２から削除する。

次に、更新差分の整合が実施される。図１１において、データベースサーバ２０−１、データベースサーバ２０−２共に、同一キーのレコードが存在し、かつ、データベースサーバ２０−１の生成日時情報／更新日時情報が基点時刻情報ｔ「２０１３／６／３０」以降のレコードとして「データＥ」がある。そのため、「データＥ」が「追加差分Ｂ」として抽出される。

また、図１１において、データベース２０−１、データベースサーバ２０−２条に生成日時情報が一致している同一キーのレコードが存在し、かつ、データベースサーバ２０−１の更新日時情報が基点時刻情報ｔ「２０１３／６／３０」以降のレコードとして「データＤ」がある。そのため、「データＤ」が「更新差分」として抽出される。

従って、データベースサーバ２０−２では、図１３に示すように、データ整合部５１−２が、「データＥ」及び「データＤ」について整合する。

最後に、追加差分のデータ整合が実施される。図１１において、データベースサーバ２０−２に同一キーのレコードが存在せず、かつ、データサーバ２０−１の更新日時情報が基点時刻情報ｔ「２０１３／６／３０」以降のレコードとして「データＦ」がある。そのため、「データＦ」が「追加差分Ａ」として抽出される。

従って、データベースサーバ２０−２では、図１４に示すように、データ整合部５１−２が、「データＦ」を追加する。

（Ａ−３）実施形態の効果
以上のように、この実施形態によれば、データベースサーバ間のデータ整合処理において、最適化された条件及び、整合実施順序により、最適なデータ整合を実現することができる。

また、例えば、「追加差分Ｂ」に該当するデータがある場合、実施順序が「追加整合」→「削除整合」とする場合に、データベースサーバ２０−２側に旧い同一キーのレコードが存在するため、二重登録エラーが発生する場合が生じ得る。このような処理は、整合処理中に発生したエラーについて、アプリケーションがエラー分析、リアクション決定等を実施すると、整合処理そのものに時間を要する事になるため、非効率といえる。

これに対して、この実施形態によれば、「追加差分Ｂ」に該当するデータがある場合、データベースサーバ２０−２側のレコードを「削除整合」で一旦削除した後、「追加整合」で再度登録する処理方式としている。この実施形態は、上記のようなデータ矛盾が発生しない順序により整合を実施しているため、動作説明においてもエラーが現れず、効率的なデータ整合を図ることができる。

（Ｂ）他の実施形態
上述した実施形態においても、本発明の種々の変形実施形態を言及したが、本発明は、以下の変形実施形態にも適用できる。

上述した実施形態では、冗長化されたデータベースサーバ、つまりＡＣＴ／ＡＣＴ運用の環境を例示した。しかし、ＡＣＴ／ＡＣＴ運用に限定されるものではなく、例えば、ＡＣＴ／ＳＢＹ環境において定期的に差分のデータのみを転送する機能としても利用できる。これは、例えばＡＣＴ系データベースサーバから、定期的に全データをｅｘｐｏｒｔ、ＳＢＹ系データベースにｉｍｐｏｒｔを実施し、データのバックアップを保守する作業については、毎回全データをｅｘｐｏｒｔするために要する時間は、差分のみを転送する時間よりも大きいと考えられるためである。

上述した実施形態では、データベースシステムにおいて、２台のデータベースサーバが配置された場合について示したが、３台以上のデータベースサーバを配置しても良く、その台数は限定されないものである。

上述した実施形態においては、データベースシステムにおいて、通常時は二相コミットメントに従ってデータ更新を行い、いずれかのデータベースサーバの故障時には、一相コミットメントに従ったデータ更新をするようにしていたが、通常時は三相コミットメントによりデータ更新を行うデータベースシステムに適用しても良い。

上述した実施形態では、データ整合部が、データベースサーバに搭載される場合を例示したが、例えば、データベースクライアントやデータベースサーバを更に制御する他の制御装置に設けるようにしても良い。

１…データベースシステム、
１０…データベースクライアント、１１…クライアントライブラリ、
２０、２０−１、２０−２…データベースサーバ、２１、２１−１、２１−２…ＤＢＭＳ、２２、２２−１、２２−２…データベースファイルシステム、２２１、２２１−１、２２１−２…データ記憶部、２２２、２２２−１、２２２−２…フラグ管理部、２２３、２２３−１、２２３−２…二相コミットメントフラグ、５１−１、５１−２…データ整合部。

Claims (7)

1. 継続的にデータ更新が行なわれている第１のデータベースサーバと、データ更新がなされていない第２のデータベースサーバとの間のデータ差分の整合を行うデータベースシステムにおいて、
   データ差分が生じ得る基準日時情報以降に、上記第１のデータベースサーバにおいて更新されたデータのうち、所定の差分抽出条件情報に基づいて、削除差分、更新差分及び追加差分を抽出する差分抽出手段と、
   上記差分抽出手段により抽出されたデータ差分に基づき、第２のデータベースサーバに対して、削除整合処理、更新整合処理、追加整合処理の順でデータ更新を行ない、上記第２のデータベースサーバに記録されるデータを上記第１のデータベースサーバに記録されるデータと一致させるデータ整合処理手段と
   を備えることを特徴とするデータベースシステム。
2. 上記差分抽出手段は、追加差分について、少なくとも上記第１のデータベースサーバ及び上記第２のデータベースサーバに同一キーのレコードが存在しないレコードを第１の追加差分として抽出し、少なくとも上記第１のデータベースサーバ及び上記第２のデータベースサーバに同一キーのレコードが存在するレコードを第２の追加差分として抽出し、
   上記データ整合処理手段が、上記第１の追加差分に対して追加整合処理を行い、上記第２の追加差分に対して更新整合処理を行う
   ことを特徴とする請求項１に記載のデータベースシステム。
3. 上記差分抽出手段が、上記第２のデータベースサーバにおける障害発生時の日時情報を上記基準日時情報として設定するものであることを特徴とする請求項１又は２に記載のデータベースシステム。
4. 上記差分抽出手段が、上記第１のデータベースサーバ及び上記第２のデータベースサーバへのデータ更新に係るコミットプロトコルの移行時の日時情報を上記基準日時情報として設定するものであることを特徴とする請求項１又は２に記載のデータベースシステム。
5. 上記第１のデータベースサーバ及び上記第２のデータベースサーバに記録されるデータのレコードには、作成日時情報及び更新日時情報が付されることを特徴とする請求項１〜４のいずれかに記載のデータベースシステム。
6. 継続的にデータ更新が行なわれている第１のデータベースサーバと、データ更新がなされていない第２のデータベースサーバとの間のデータ差分の整合を行うデータベース更新方法において、
   差分抽出手段が、データ差分が生じ得る基準日時情報以降に、上記第１のデータベースサーバにおいて更新されたデータのうち、所定の差分抽出条件情報に基づいて、削除差分、更新差分及び追加差分を抽出する差分抽出工程と、
   データ整合処理手段が、上記差分抽出手段により抽出されたデータ差分に基づき、第２のデータベースサーバに対して、削除整合処理、更新整合処理、追加整合処理の順でデータ更新を行ない、上記第２のデータベースサーバに記録されるデータを上記第１のデータベースサーバに記録されるデータと一致させるデータ整合処理工程と
   を有することを特徴とするデータベース更新方法。
7. 継続的にデータ更新が行なわれている第１のデータベースサーバと、データ更新がなされていない第２のデータベースサーバとの間のデータ差分の整合を行うデータベース更新プログラムにおいて、
   コンピュータを、
   データ差分が生じ得る基準日時情報以降に、上記第１のデータベースサーバにおいて更新されたデータのうち、所定の差分抽出条件情報に基づいて、削除差分、更新差分及び追加差分を抽出する差分抽出手段と、
   上記差分抽出手段により抽出されたデータ差分に基づき、第２のデータベースサーバに対して、削除整合処理、更新整合処理、追加整合処理の順でデータ更新を行ない、上記第２のデータベースサーバに記録されるデータを上記第１のデータベースサーバに記録されるデータと一致させるデータ整合処理手段と
   して機能させることを特徴とするデータベース更新プログラム。

Images