JP2002318718A - データベースレプリケーション方法、そのプログラム及び記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 異種スキーマ構造を持つデータベース間で、
双方のデータベースのスキーマ及びアリプリケーション
の改造なしにリプリケーションを実現する。 【解決手段】 プライマリ・サイト１００とレプリケー
ト・サイト２００の間に、プライマリ・サイトと同一ス
キーマ構造のプライマリ側中間サイト３０１及びレプリ
ケート・サイトと同一スキーマ構造のレプリケート側中
間サイト３０２の中間サイト３００を設置し、プライマ
リ・サイト１００のデータをプライマリ側中間サイト３
０１にレプリケーションし、プライマリ側中間サイト３
０１とレプリケート側中間サイト３０２の間でデータ変
換し、レプリケート側中間サイト３０２のデータをレプ
リケート・サイト２００にレプリケーションする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、異種スキーマ構造
を持つ複数のデータベース間におけるデータベースレプ
リケーション技術に関するものである。

【０００２】

【従来の技術】従来、いくつかの汎用的なデータベース
レプリケーション技術では、図１３および図１４のよう
にプライマリ・サイトとレプリケート・サイトの構成が
階層状構成や放射状構成を取ることや、図１５のように
特定条件に一致したデータのみレプリケーションするマ
スタ／ディテール関係を実装している機能を持つが、最
低限レプリケーション対象テーブルのスキーマ構造が一
致していなければレプリケーションを行うことはできな
かった。図１３および図１４は、プライマリ・サイトの
データベーススキーマＰと各リプリケート・サイトのデ
ータベーススキーマＲｎ（ｎ≧１）が一致していること
を示し、図１５はプライマリ・サイトとレプリケートサ
イトのリプリケーション対象テーブルＡ、Ｂのスキーマ
構造が一致していることを示している。

【０００３】

【発明が解決しようとする課題】このように、従来技術
においては、データベースレプリケーションを実現する
ためには、データ流通を行うシステム間で共通のスキー
マを構築してレプリケーションを行う必要があった。

【０００４】そのため、異なるスキーマ構造を持つシス
テム間でレプリケーションを実現する場合、スキーマ構
造を一致させるために、プライマリ・サイトもしくはレ
プリケート・サイト、または双方のスキーマ構造を修正
する必要があった。この場合、スキーマ構造の修正に伴
い、該当データベースにアクセスする全ての既存アプリ
ケーションを、共通スキーマにアクセスしてデータを取
得できるように改造する必要があった。

【０００５】つまり、従来の手法では、異なるスキーマ
構造を持つシステム間でのレプリケーションを実現する
ためには、データベース側のスキーマ変更とアプリケー
ション側の変更を必要とする問題があった。

【０００６】本発明の目的は、上記従来の問題を解決す
べく、プライマリ・サイトとレプリケート・サイトの間
のスキーマ構造が異なっていても、双方のデータベース
のスキーマ改造及び双方のアプリケーションの改造なし
にデータベースレプリケーションを実現することにあ
る。

【０００７】

【課題を解決するための手段】本発明は、上記目的を達
成するために、プライマリ・サイトとレプリケート・サ
イトの間にプライマリ側中間サイト及びレプリケート側
中間サイトの中間サイトを設置し、プライマリ側中間サ
イトにはプライマリ・サイトと同一のスキーマ構造（以
下、スキーマＰ）を持たせ、レプリケート側中間サイト
にはレプリケート・サイトと同一のスキーマ構造（以
下、スキーマＲ）を持たせ、プライマリ・サイトにて出
力されたデータを、プライマリ側中間サイトにレプリケ
ーションし、該プライマリ側中間サイトのデータをスキ
ーマＰからスキーマＲにデータ変換してレプリケート側
中間サイトに反映させ、該レプリケート側中間サイトの
データをレプリケート・サイトにレプリケーションする
ことをもっとも主要な特徴とする。

【０００８】また、本発明は、プライマリ・サイトから
プライマリ側中間サイトの間、プライマリ側中間サイト
からレプリケート側中間サイトの間、及びレプリケート
側中間サイトからレプリケート・サイトの間におけるデ
ータベーストランザクションを保証することによって、
各サイト間の通信回線断や各サイト上のハードウェア／
ソフトウェアトラブルが発生した場合にも、各サイトに
おけるデータベース上のデータの一貫性を保証すること
も特徴とする。

【０００９】更に、本発明は、各サイト間のレプリケー
ションまたは中間サイト上でのデータ変換において、プ
ライマリキーの衝突やプラットフォームに依存した漢字
コード体系の違い等によって、レプリケーション処理や
データ変換処理を行うことが出来なかった場合、処理が
失敗した原因と該当データに関する情報をデータベース
中のログ管理テーブルに書き出し、またオペレーション
システム上にログファイルとして書き出すことで、シス
テム管理者が障害の原因を把握するための情報を提供す
ることも特徴とする。

【００１０】このように本発明では、プライマリ・サイ
トとレプリケート・サイトの間のスキーマ構造の差異を
中間サイトにて吸収することにより、プライマリ・サイ
ト及びレプリケート・サイトのデータベーススキーマ構
造に対する変更を必要とせず、また、データベーススキ
ーマ構造の変更が入らないことからアプリケーションの
変更も必要としない。

【００１１】一実施例では、プライマリ・サイト上のテ
ーブルから、プライマリ側中間サイト上のスキーマＰを
持つテーブル（以下、テーブルＰ）に一定時間ごとにデ
ータのレプリケーションを行う。この時、前回プライマ
リ側中間サイトに取得したデータより後に発生した更新
・挿入・削除等の変更データ（以下、差分データ）を対
象として、１テーブル単位のレプリケーションを１トラ
ンザクションとしてレプリケーションする。ここで、複
数のトランザクションをまとめて１つのトランザクショ
ンにすることも可能とする。このとき、プライマリ・サ
イトと中間サイトのプラットフォームの違い、漢字コー
ド体系の違い等によってレプリケーションに失敗した場
合、データベース中のログ管理テーブル及びオペレーシ
ョンシステム上のログファイルに対して、処理が失敗し
た原因と該当データに関する情報を書き出す。全てのテ
ーブルのレプリケーションが成功した場合、次の処理に
移る。

【００１２】プライマリ側中間サイト上のテーブルＰか
ら、レプリケート側中間サイトのスキーマＲを持つテー
ブル（以下、テーブルＲ）に一定時間ごとに差分データ
のデータ変換を行う。ここで、テーブルＰとテーブルＲ
は多対多に以下のパターンで関連付けられる。 (ｉ) 無条件に特定のテーブルＰから特定のテーブルＲ
へのデータ変換を行うパターン（１対１対応） (ii) 特定のテーブルＰの特定カラムの値が、特定条件
を満たす場合のみ特定のテーブルＲへのデータ変換を行
うパターン（テーブルの対応事体は１対多だが、データ
の対応は１対１対応） (iii) 特定のテーブルＰの特定カラムのみ特定のテーブ
ルＲへのデータ変換を行うパターン（特定のテーブルＰ
が非正規化構造になっており、特定のテーブルＲに正規
化を行いつつデータ変換する場合を含む）（１対多対
応） (iv) 上記パターンの任意の複合 テーブルＰから見てテーブルＲの対応は常に１対１もし
くは１対多だが、テーブルＲは複数のテーブルＰと関連
しうるため、テーブルＰとテーブルＲは多対多に関連す
る。

【００１３】また、テーブルＰ上の特定カラムにレプリ
ケート側中間サイト上のどのデータベースに差分データ
を反映させれば良いかの情報が含まれていれば、その情
報を使用してデータ変換した差分データを反映させる先
のデータベースを決定する。

【００１４】よって、プライマリ側中間サイト上のデー
タベース数とレプリケート側中間サイト上のデータベー
ス数は一致しなくても良い。

【００１５】データ変換は、以下のパターンで行われ
る。 ・文字列操作 ・データ型変換 ・四則演算 ・特定カラムの値による条件分岐 ・固定値の挿入 ・特定カラムの値を引数とした関数呼び出し ・上記パターンの任意の複合

【００１６】テーブルＰからテーブルＲへのデータ変換
は、前回データ変換したデータより後に発生した差分デ
ータのみを対象として、１つのテーブルＰから１つのデ
ータベース上の１つのテーブルＲへのデータ変換を１ト
ランザクションとして処理する。ここで、複数のトラン
ザクションをまとめて１つのトランザクションにするこ
とも可能とする。このデータ変換において何らかの問題
が発生した場合、データベース中のログ管理テーブル及
びオペレーションシステム上のログファイルに対して、
処理が失敗した原因と該当データに関する情報を書き出
す。全てのテーブルの変換が成功した場合、次の処理に
移る。

【００１７】レプリケート中間サイトのテーブルＲか
ら、レプリケート・サイト上のテーブルに一定時間ごと
に差分データのレプリケーションを行う。この時も、前
回レプリケート・サイト側に取得したデータより後に発
生した差分データのみを対象として、１テーブル単位の
レプリケーションを１トランザクションとしてレプリケ
ーションする。ここで、複数のトランザクションをまと
めて１つのトランザクションにすることも可能とする。
このレプリケーションにおいて、中間サイトとレプリケ
ート・サイトのプラットフォームの違い、漢字コード体
系の違い等によってレプリケーションに失敗した場合、
データベース中のログ管理テーブル及びオペレーション
システム上のログファイルに対して、処理が失敗した原
因と該当データに関する情報を書き出す。

【００１８】

【発明の実施の形態】以下、本発明の実施形態について
図面により具体的に説明する。

【００１９】［システム構成］図１は本発明のデータベ
ースレプリケーション方法を実施するハードイメージの
システム構成図である。図１において、１００はプライ
マリ・サイト側サーバ（以下、プライマリ・サイト）、
２００はリプリケート・サイト側サーバ（以下、レプリ
ケート・サイト）、３００は中間サイトサーバ（以下、
中間サイト）であり、それぞれネットワーク４００を介
して接続されている。一般にレプリケート・サイト２０
０は、プライマリ・サイト１００に対して複数存在する
が（例えば図１３や図１４）、便宜上、図１では１台の
み示したものである。

【００２０】プライマリ・サイト１００は制御部１１０
とデータベース１２０を具備する。同様に、レプリケー
ト・サイト２００も制御部２１０とデータベース２２０
を具備する。これらプライマリ・サイト１００とレプリ
ケート・サイト２００の構成は従来と同じであり、制御
部１１０、２１０はレプリケーション機能を備えてい
る。ここで、プライマリ・サイト１００におけるデータ
ベース１２０のスキーマ構造をスキーマＰ、レプリケー
ト・サイト２００におけるデータベース２２０のスキー
マ構造をスキーマＲとし、スキーマＰとスキーマＲは異
なるとする。

【００２１】中間サイト３００は制御部３１０とデータ
ベース３２０、３３０を具備する。ここで、データベー
ス３２０のスキーマ構造はスキーマＰとし、データベー
ス３３０のスキーマ構造はスキーマＲとする。制御部３
１０はレプリケーション機能に加えて、データのスキー
マＰからスキーマＲへの変換機能（データ変換機能）を
備えている。つまり、中間サイト３００は論理的には、
プライマリ側中間サイト３０１とレプリケート側中間サ
イト３０２で構成されていると見做すことができる。

【００２２】［実施例１］図２は本実施例における動作
説明図であり、図３は全体の処理フローチャートを示し
たものである。また、図４は、プライマリ・サイト１０
０上のスキーマＰ（＝プライマリ側中間サイト３０１上
のスキーマＰ）とレプリケート・サイト２００上のスキ
ーマＲ（＝プライマリ側中間サイト３０２上のスキーマ
Ｒ）、及び両者間におけるカラム対応とデータ変換方法
を表した図である。

【００２３】以下、図３のフローチャートに従って本実
施例１の動作を説明する。ユーザ等が定めたプライマリ
・サイトと中間サイト間のレプリケーション時間間隔
で、既存のレプリケーション機能を用いて、プライマリ
・サイト１００の特定データベースの特定テーブルのデ
ータを、中間サイト３００のプライマリ側中間サイト３
０１の特定データベースの特定テーブルに１対１対応で
レプリケーションを実施する（ステップＳ１、Ｓ２）。
次に、中間サイト３００において、プライマリ側中間サ
イト３０１のスキーマＰからレプリケート側中間サイト
３０２のスキーマＲに、図４に示したような変換ルール
を用いて、文字列変換やデータ型変換、四則演算、関数
呼び出しなどを行ってデータ変換し（ステップＳ３）、
レプリケート側中間サイト３０２の複数データベースの
複数テーブルに反映させる（ステップＳ４）。最後に、
同様に、ユーザ等が定めた中間サイトとレプリケートサ
イト間のレプリケーション時間間隔で、既存のレプリケ
ーション機能を用いて、中間サイト３００のレプリケー
ト側中間サイト３０２の特定データベースの特定テーブ
ルのデータを、レプリケート・サイト２００の特定デー
タベースの特定テーブルに１対１対応でレプリケーショ
ンを実施する（ステップＳ５、Ｓ６）。

【００２４】このように、プライマリ・サイト１００と
レプリケート・サイト２００のスキーマが異なっていて
も、中間サイト３００のプライマリ側中間サイト３０１
とレプリケート側中間サイト３０２の間でスキーマの差
異を吸収させることで、従来は実現できなかった異種ス
キーマ構造を持つ複数のデータベース間におけるデータ
ベースレプリケーションを実現することができる。

【００２５】［実施例２］これは、中間サイトを論理的
に３つ用意する（以下、中間サイト１、中間サイト２、
中間サイト３）ことによって、中間サイト上にプライマ
リ・サイトやレプリケート・サイト上の全てのデータを
格納せず、前回レプリケーションした以降にプライマリ
・サイトで変更（更新、挿入、削除）のあったデータ
（差分データ）のみを流通させることで、中間サイトに
必要とされるハードディスク容量等を極力抑えるもので
ある。また、本実施例では、各サイト間のレプリケーシ
ョンまたは中間サイト上でのデータ変換において、プラ
イマリキーの衝突やプラットフォームに依存した漢字コ
ード体系の違い等によって、レプリケーション処理やデ
ータ変換処理を行うことが出来なかった場合、処理が失
敗した原因と該当データに関する情報をデータベース中
のログ管理テーブルに書き出し、またオペレーションシ
ステム上にログファイルとして書き出すことで、システ
ム管理者が障害の原因を把握するための情報を提供する
こともできるようにしたものである。

【００２６】図５は本実施例の動作説明図であり、図６
乃至図９は全体の処理フローチャートを示したものであ
る。図１０はプライマリ・サイト１００上のテーブル５
０５のスキーマ、レプリケート・サイト２００上のテー
ブル５１１のスキーマ及び中間サイト３上におけるレプ
リケートサイト上のテーブル５１１にアクセスするため
のプロキシテーブル５１０（以下、プロキシテーブル
Ｒ）のスキーマであり、図１１はプライマリ・サイト１
００上の差分テーブル５０６のスキーマ、中間サイト１
上におけるプライマリ・サイト上の差分テーブル５０６
にアクセスするための差分プロキシテーブル５０７（以
下、差分プロキシテーブルＰ）のスキーマ、及び中間サ
イト１上の実テーブル５０８（以下、中間側差分テーブ
ルＰ）のスキーマであり、図１２は中間サイト２上の実
テーブル５０９（以下、中間側差分テーブルＲ）のスキ
ーマである。

【００２７】以下、図６乃至図９のフローチャートに従
って本実施例の動作を説明する。なお、図５のカウンタ
番号管理テーブル５０１、５０３は前回までのレプリケ
ーションやデータ変換を実施したデータの最大のカウン
タ番号（通番）を管理しており、ここでは「１００」と
する（図１１、図１２）。

【００２８】プライマリ・サイト１００の実テーブル５
０５でデータの更新、挿入、削除が発生すると（ステッ
プＳ１１）、該データをプライマリ・サイト１００上の
差分テーブル５０６上にトリガを用いて格納し（ステッ
プＳ１２）、差分テーブル５０６の現カウンタ番号＋１
を当該データのカウンタ番号（通番）として格納する。
この動作は、プライマリ・サイト１００の実テーブル５
０５において、データの変更（更新、挿入、削除）が発
生する毎に繰り返される。

【００２９】一方、ユーザ等が定めたプライマリ・サイ
ト１００と中間サイト１間のレプリケーション時間間隔
で（ステップＳ１３）、以下のようにしてレプリケート
・サイト１００と中間サイト１（プライマリ側中間サイ
ト）間でのレプリケーションを実施する（ステップＳ１
４）。プライマリ・サイト１００から中間サイト１への
レプリケーション対象テーブル（差分テーブル５０６）
を選択し（ステップ１４１）、プライマリ・サイト１０
０のカウンタ番号管理テーブルＰ５０１の該レプリケー
ション対象テーブルのカウンタ番号を参照することによ
り（ステップＳ１４２）、その番号より大きなカウンタ
番号を持つデータを、差分プロキシテーブルＰ５０７を
参照することで、プライマリ・サイト１００上の差分テ
ーブル１０６から中間サイト１の中間側差分テーブルＰ
５０８にレプリケーションする（ステップＳ１４３）。
ここでは、差分テーブルＰ５０６の「１００」より大き
なカウンタ番号（通番）を持つデータ（差分データ）が
中間側差分テーブルＰ５０８にレプリケーションされ
る。このレプリケーションデータ中の最大のカウンタ番
号を、例えば「１２０」とする。また、この時１テーブ
ルのレプリケーションを１トランザクションとする。次
に、このレプリケーションが成功したかチエックし（ス
テップＳ１４４）、漢字コード体系の違いによってレプ
リケーション処理を行うことが出来なかった場合、ログ
管理テーブルＰ５０２及びオペレーションシステム上の
ログファイルに対して、処理が失敗した原因と該当デー
タに関する情報を書き出し（ステップＳ１４５）、レプ
リケーションを終了する。レプリケーションが成功した
場合には、レプリケーションしたデータ中の最大のカウ
ンタ番号（例では「１２０」）をカウンタ番号管理テー
ブルＰ５０１に格納する（ステップＳ１４６）。次に、
プライマリ・サイト１００の差分テーブルＰ５０６上で
最小のカウンタ番号を参照し、そのカウンタ番号より小
さなカウンタ番号（例では「１００」未満）を持つ中間
側差分テーブルＰ５０８のデータを削除する（ステップ
Ｓ１４７）。つまり、中間側差分テーブルＰ５０８上の
前回までのレプリケーションデータを削除する。次に、
プライマリ・サイト１００の差分テーブルＰ５０６上の
データに対して、カウンタ番号管理テーブルＰ５０１の
カウンタ番号を参照して、そのカウンタ番号（例では
「１２０」）より小さなデータを削除する（ステップＳ
１４８）。つまり、プライマリ・サイト１００の差分テ
ーブルＰ５０６上の今回レプリケーション済みのデータ
を削除する（ステップＳ１４９）。

【００３０】上記ステップＳ１４１〜Ｓ１４８の処理を
繰り返し、全てのレプリケーション対象テーブルのレプ
リケーションが成功した場合、次の処理に移る（ステッ
プＳ１４９）。

【００３１】中間サイト３００において、中間サイト１
のスキーマＰから中間サイト２のスキーマＲのデータ変
換を次のように実施する（ステップＳ１５）。中間サイ
ト１から中間サイト２へのデータ変換処理対象テーブル
を選定し（ステップＳ１５１）、カウンタ番号管理テー
ブルＭ５０３を参照して、中間側差分テーブルＲ５０９
上のカウンタ番号より大きなカウンタ番号（例では「１
００」以上）を持つデータを処理対象として、中間側差
分テーブルＰ５０８から中間側差分テーブルＲ５０９
に、文字列変換やデータ型変換、四則演算などを行って
データ変換する（ステップＳ１５２、Ｓ１５３）。この
時、１つの中間側差分テーブルＰからデータ変換処理対
象の複数の中間側差分テーブルＲへのデータ変換を１ト
ランザクションとする。次に、このデータ変換処理が成
功したかチエックし（ステップＳ１５４）、データ変換
処理時に何らかの問題が発生した場合、ログ管理テーブ
ルＭ５０４及びオペレーションシステム上のログファイ
ルに対して、処理が失敗した原因と該当データに関する
情報を書き出し（ステップＳ１５５）、データ変換処理
を終了する。データ変換処理が成功した場合には、中間
側差分テーブルＲ５０９上のデータに対して、中間側差
分テーブルＰ５０８上のカウンタ番号を参照して、その
最小のカウンタ番号より小さなカウンタ番号（例では
「１００」未満）のデータを削除する（ステップＳ１５
６）。つまり、中間側差分テーブルＲ５０９上の前回の
データ変換処理済みデータを削除する。

【００３２】上記ステップＳ１５１〜Ｓ１５６を繰り返
し、全てのデータ変換処理対象テーブルのデータ変換が
成功した場合、次の処理に移る（ステップＳ１５７）。

【００３３】中間サイト３００の中間サイト２から中間
サイト３を介し、レプリケート・サイト３００へのレプ
リケーションを次のように実施する（ステップＳ１
６）。中間サイト上３００のカウンタ番号管理テーブル
Ｍ５０３のレプリケーション対象テーブルのカウンタ番
号を参照することにより（ステップＳ１６１）、中間側
差分テーブルＲ５０９において、その番号より大きなカ
ウンタ番号（例では「１００」より大きな番号）を持つ
データを、プロキシテーブルＲ５１０を参照することで
レプリケート・サイト２００上のテーブルＲ５１１に１
レコードずつ反映させる（ステップＳ１６２、Ｓ１６
３）。ここで、ステップＳ１６２では、図１２に示すよ
うに中間側差分テーブルＲ５０９上のＤＢ名カラムの値
によって、レプリケート・サイト２００上のどのデータ
ベースにデータを反映させるか決定する。また、ステッ
プＳ１６３では、中間側差分テーブルＲ５０９中のデー
タにおいて処理内容が‘１’（更新）の場合、旧column
_Xをプライマリ・キーとして持つテーブルＲ５１１上の
レコードを、column_X、 column_Y、 column_Zに更新
し、中間側差分テーブルＲ５０９中のデータにおいて処
理内容が‘２’（挿入）の場合、テーブルＲ５１１上に
１レコード挿入し、中間側差分テーブルＲ５０９中のデ
ータにおいて処理内容が‘３’（削除）の場合、旧colu
mn_Xをプライマリ・キーとして持つテーブルＲ５１１上
のレコードを削除する。この時１テーブルのレプリケー
ションを１トランザクションとする。

【００３４】次に、データ反映処理が成功したかチエッ
クし（ステップＳ１６４）、このレプリケーション時
に、差分データが挿入だった場合にレプリケート・サイ
ト２００でプライマリキーが衝突する場合や、差分デー
タが削除だった場合にレプリケート・サイト２００で該
当プライマリキーを持つデータが存在しない場合や、差
分データが更新だった場合にレプリケート・サイト２０
０で該当旧プライマリキー持つデータが存在しなかった
り該当新プライマリキーが衝突する場合、ログ管理テー
ブルＭ５０４及びオペレーションシステム上のログファ
イルに対して、処理が失敗した原因と該当データに関す
る情報を書き出し（ステップ１６５）、データ反映処理
を終了する。データ反映処理が成功した場合には、レプ
リケーションした最大のデータのカウンタ番号（例では
「１２０」の番号）を中間サイト３００のカウンタ番号
管理テーブルＭ５０３に格納し（ステップＳ１６６）、
処理終了となる。

【００３５】このように、実施例２では、中間サイトに
必要とされるハードディスク容量を極力抑えてスキーマ
の差異を吸収でき、更にはレプリケーション処理やデー
タ変換処理が成功しなかった場合、その原因や該当デー
タに関する情報をログ管理テーブルに書き出し、また、
オペレーションシステム上にログファイルとして書き出
すことで、システム管理者が障害の原因を把握するのに
役立つ。

【００３６】以上、本発明の実施例を説明したが、図３
や図６乃至図９に示したような処理フローを各サイトの
コンピュータに実行させるためのプログラムは、あらか
じめコンピュータ読み取り可能な記録媒体（ＦＤ、ＣＤ
−ＲＯＭ、ＭＯ等）に記録して提供することが可能であ
る。この記録媒体に記録されたプログラムを、必要に応
じ各サイトのコンピュータにインストールすることによ
り、各実施例で説明したようなレプリケーションが達成
される。なお、この種のプログラムは各サイトのコンピ
ュータにプレインストールされていてもよい。

【００３７】

【発明の効果】以上説明したように、本発明によれば、
中間サイトの中でプライマリ・サイトとレプリケート・
サイトの間のスキーマの差異を吸収させることで、プラ
イマリ・サイトのデータベーススキーマ構造と、レプリ
ケート・サイトのデータベーススキーマ構造が異なり、
テーブル間の関係やデータベース間の関係が多対多にな
っており、テーブル間のプライマリキーが異なっていて
も、プライマリ・サイト上のプライマリキーに対して何
らかの変換を行うことでレプリケート・サイト上のプラ
イマリキーに一意に結び付けることができる場合には、
プライマリ・サイトとレプリケート・サイトの間でレプ
リケーションを行うことができる。

【００３８】特に、大規模なデータベース間で新規にレ
プリケーションを行う必要性が生じた場合や、元々プラ
イマリ・サイトだったデータベースシステムに大規模な
改造が入りスキーマ構造が大きく変わってしまったよう
な場合に、本発明を適用した場合、全てのデータベース
スキーマの修正を必要とせず、またそれらデータベース
にアクセスしている全てのアプリケーションに対して修
正を必要としないことから、既存システムの資産を有効
活用できると共に関連するシステムの改造費用を抑える
ことができるメリットがある。

【図面の簡単な説明】

【図１】本発明の各実施例におけるシステム構成図であ
る。

【図２】本発明の第１の実施例の動作説明図である。

【図３】本発明の第１の実施例の処理フローチャートで
ある。

【図４】プライマリ・サイト上のスキーマとレプリケー
ト・サイト上のスキーマの関係を説明する図である。

【図５】本発明の第２の実施例の動作説明図である。

【図６】本発明の第２の実施例の処理フローチャートの
一部である。

【図７】図６の続きの処理フローチャートである。

【図８】図７の続きの処理フローチャートである。

【図９】図８の続きの処理フローチャートである。

【図１０】プライマリ・サイト上のスキーマ、レプリケ
ート・サイト上のスキーマ及び中間サイト３上のプロキ
シテーブルスキーマを説明する図である。

【図１１】プライマリ・サイト上の差分テーブル、中間
サイト１上のプロキシテーブル及び中間サイト１上の実
テーブルスキーマを説明する図である。

【図１２】中間サイト２上の実テーブルスキーマを説明
する図である。

【図１３】従来の階層状構成システムのレプリケーショ
ンを説明する図である。

【図１４】従来の放射線状構成システムのレプリケーシ
ョンを説明する図である。

【図１５】従来のマスタ／ディテール関係を実装するシ
ステムにおいてレプリケーション動作を説明する図であ
る。

【符号の説明】

１００ プライマリ・サイト １２０ データベース（スキーマＰ） ２００ レプリケート・サイト ２２０ データベース（スキーマＲ） ３００ 中間サイト ３０１ プライマリ側中間サイト ３０２ レプリケート側中間サイト ３２０ データベース（スキーマＰ） ３３０ データベース（スキーマＲ） ４００ ネットワーク

───────────────────────────────────────────────────── フロントページの続き (72)発明者 国分 利直 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 Ｆターム(参考） 5B082 DE04 GA03 GA04 GA07 GB02

Claims (6)

【特許請求の範囲】
1. 【請求項１】 異種スキーマ構造を持つ複数のデータベ
   ース間におけるデータベースレプリケーション方法であ
   って、 レプリケーション元であるプライマリ・サイトとレプリ
   ケーション先であるレプリケート・サイトの間に、プラ
   イマリ側中間サイト及びレプリケート側中間サイトの中
   間サイトを設置し、 プライマリ側中間サイトにはプライマリ・サイトと同一
   のスキーマ構造を持たせ、レプリケート側中間サイトに
   はレプリケート・サイトと同一のスキーマ構造を持た
   せ、 プライマリ・サイトにて出力されたデータをプライマリ
   側中間サイトにレプリケーションし、 プライマリ側中間サイト上のデータをデータ変換してレ
   プリケート側中間サイトに反映させ、 レプリケート側中間サイト上のデータをレプリケート・
   サイトにレプリケーションする、 ことを特徴とするデータベースレプリケーション方法。
2. 【請求項２】 請求項１記載のデータベースレプリケー
   ション方法において、 プライマリ・サイトにて出力された特定データベースの
   特定テーブル上のデータを、プライマリ側中間サイト上
   の特定データベースの特定テーブル上に１対１対応でレ
   プリケーションし、 プライマリ側中間サイト上のデータをデータ変換すると
   共に、レプリケート側中間サイト上の複数のデータベー
   ス上の複数のテーブルに反映させ、 レプリケート側中間サイト上の特定データベースの特定
   テーブル上のデータをレプリケート・サイト上の特定デ
   ータベースの特定テーブルに１対１対応でレプリケーシ
   ョンする、 ことを特徴とするデータベースレプリケーション方法。
3. 【請求項３】 請求項１もしくは２記載のデータベース
   レプリケーション方法において、 前回のレプリケーション後に発生した変更データ（以
   下、差分データ）のみを対象として、プライマリ・サイ
   トにて出力された差分データをプライマリ側中間サイト
   にレプリケーションし、 プライマリ側中間サイト上の差分データをデータ変換
   し、レプリケート側中間サイトに反映させ、 レプリケート側中間サイト上の差分データをレプリケー
   ト・サイトにレプリケーションする、 ことを特徴とするデータベースレプリケーション方法。
4. 【請求項４】 請求項１乃至３記載のデータベースレプ
   リケーション方法において、各サイト間のレプリケーシ
   ョン処理もしくは中間サイトでのデータ変換処理に失敗
   した場合、該処理が失敗した原因と該当データに関する
   情報をログ管理テーブルに書き出し、また、オペレーシ
   ョンシステム上にログファイルとして書き出すことを特
   徴とするデータベースレプリケーション方法。
5. 【請求項５】 請求項１乃至４記載のデータベースレプ
   リケーション方法をコンピュータに実行させるためのプ
   ログラム。
6. 【請求項６】 請求項１乃至４記載のデータベースレプ
   リケーション方法をコンピュータに実行させるためのプ
   ログラムを記録した記録媒体。