(57)【要約】【課題】本発明は、独自のレプリケーション機能を使用することにより、複雑な抽出条件を設定や内部構造のカスタマイズを可能とし、マスタサーバのディスク容量の負担が軽いレプリケーションシステム及びレプリケーションシステム用プログラムを提供することを目的とする。【解決手段】本発明のレプリケーションシステムは、各レプリカデータベースに登録するデータをマスタデータベースから抽出するための抽出条件を記憶保持する抽出条件データベースと、マスタデータベースの登録データが変更されると、抽出条件データベースに記憶保持された抽出条件に基づき、各レプリカデータベースに登録すべき変更データを抽出する抽出手段と、各レプリカ端末からの要求に応じ、変更データを各レプリカ端末に伝送する変更データ伝送手段とを備える。【選択図】        図１
2004302919.tif 000002
【特許請求の範囲】
【請求項１】
マスタデータベースが接続されたマスタサーバと、このマスタサーバにネットワークを通じて接続され、マスタデータベースの登録データと同一のデータを登録する複数のレプリカデータベースが接続されたレプリカ端末とを備える関係データベースシステムに用いられるレプリケーションシステムであって、
各レプリカデータベースに登録するデータをマスタデータベースから抽出するための抽出条件を記憶保持する抽出条件データベースと、
マスタデータベースの登録データが変更されると、前記抽出条件データベースに記憶保持された抽出条件に基づき、各レプリカデータベースに登録すべき変更データを抽出する抽出手段と、
各レプリカ端末からの要求に応じ、前記変更データを各レプリカ端末に伝送する変更データ伝送手段とを備えるレプリケーションシステム。
【請求項２】
前記抽出手段によって抽出された変更データの削除処理をレプリカ端末から受けると、当該変更データをマスタサーバ側で削除する変更データ削除手段をさらに備えることを特徴とする請求項１に記載のレプリケーションシステム。
【請求項３】
各変更データには端末ＩＤ及びデータ識別番号が付されており、前記変更データ削除手段は、端末ＩＤ及びデータ識別番号で特定した変更データを削除することを特徴とする請求項２に記載のレプリケーションシステム。
【請求項４】
マスタデータベースへの登録データの変更が削除処理、挿入処理または更新処理のいずれの処理によって行われたかに基づき、レプリカデータベースへの変更データの登録処理方法である変更モードを判定する変更モード判定手段をさらに備えることを特徴とする請求項１ないし３のいずれか一項に記載のレプリケーションシステム。
【請求項５】
前記変更モード判定手段は、当該変更データの変更モードが挿入処理であると判定した場合は、レプリカデータベース内に同一のキーを有するデータがあるか否かを判定し、同一キーのデータがないと判定した場合は変更モードを挿入処理とし、同一キーのデータがあると判定した場合は、変更モードを更新処理とすることを特徴とする請求項４に記載のレプリケーションシステム。
【請求項６】
前記変更モード判定手段は、当該変更データの変更モードが更新処理であると判定した場合は、レプリカデータベース内に同一のキーを有するデータがあるか否かを判定し、同一キーのデータがあると判定した場合は変更モードを更新処理とし、同一キーのデータがないと判定した場合は、変更モードを挿入処理とすることを特徴とする請求項４に記載のレプリケーションシステム。
【請求項７】
マスタデータベースが接続されたマスタサーバと、このマスタサーバにネットワークを通じて接続され、マスタデータベースの登録データと同一のデータを登録する複数のレプリカデータベースが接続されたレプリカ端末とを備える関係データベースシステムに用いられるレプリケーションシステム用プログラムであって、コンピュータに、
マスタデータベースの登録データが変更されると、各レプリカデータベースに登録するデータをマスタデータベースから抽出するための抽出条件を記憶保持する抽出条件データベースに記憶保持された抽出条件に基づき、各レプリカデータベースに登録すべき変更データを抽出する抽出手段、及び、
各レプリカ端末からの要求に応じ、前記変更データを各レプリカ端末に伝送する変更データ伝送手段
として機能させるためのレプリケーションシステム用プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａｂａｓｅ  Ｓｙｓｔｅｍ：関係データベースシステム）に用いるレプリケーションシステム及びレプリケーションシステム用プログラムに関する。
【０００２】
【従来の技術】
図７は、従来のレプリケーションシステムのハードウェア構成及びデータの流れを概略的に示す図である。ここでは、ＲＤＢＭＳの一製品であるＯｒａｃｌｅ（登録商標）のレプリケーションシステムで用いられているレプリケーション機能（スナップショット）について説明する。
【０００３】
図７に示すように、マスタサーバ１とスナップショット端末２〜４はネットワーク（図示せず）で接続されている。マスタサーバ１とスナップショット端末２〜４にはマスタＤａｔａ  Ｂａｓｅ１Ａ（以下、ＤＢと略す）とスナップショットＤＢ２Ａ〜４Ａがそれぞれ配設され、マスタサーバ１でデータが変更されると、データの変更分がスナップショット端末２〜４に伝送され、スナップショットＤＢ２Ａ〜４Ａの登録内容が変更される。
【０００４】
具体的には、マスタサーバ１は、データの変更分で構成されるスナップショットログ１ａを生成する。スナップショットログ１ａは各スナップショット端末２〜４にスナップショット２ａ〜４ａ（２ａ、３ａ、４ａ）として伝送される。
マスタサーバ１はマスタＤＢ１Ａのデータ内容を変更する度に、変更データをスナップショットログ１ａとして出力する。スナップショット端末２〜４は、定期的にマスタサーバ１のスナップショットログ１ａを読み込んでスナップショット２ａ〜４ａを変更（リフレッシュ）する（例えば特許文献１参照。）。
【０００５】
【特許文献１】
特開２００２−１１６９３９号公報（第３−第６頁、第１図）
【０００６】
【発明が解決しようとする課題】
しかしながら、従来のレプリケーションシステムには下記のような課題があった。
各スナップショット端末２〜４はそれぞれ異なるデータを有している場合が多い。このような場合において、スナップショット２ａ〜４ａの抽出条件をある程度設定することはできるが、複雑な抽出条件を設定することはできなかった。このため、スナップショット２ａ〜４ａはマスタＤＢ１Ａの単純なコピーとなっていた。
【０００７】
また、上述したようにスナップショットログ１ａはマスタサーバ一つにつき一種類であるため、各スナップショット端末２〜４は不要なデータまで取り込まなければならず、リフレッシュ時間が長くなっていた。これは、特に低速な回線を使用した場合に顕著であった。
【０００８】
スナップショットログ１ａは全スナップショット端末２〜４でのリフレッシュが行われない限り削除されることはない。このため、リフレッシュを定期的に行わないスナップショット端末２〜４があると、マスタサーバ１のスナップショットログ１ａが保持される期間が長くなり、マスタサーバ１のディスク容量が圧迫されていた。
【０００９】
本発明は、以上のような課題を解決するためになされたもので、特に、Ｏｒａｃｌｅが持つレプリケーション機能を使用せずに、独自のレプリケーション機能を使用することにより、複雑な抽出条件の設定や内部構造のカスタマイズを可能とし、マスタサーバのディスク容量の負担が軽いレプリケーションシステム及びレプリケーションシステム用プログラムを提供することを目的とする。
【００１０】
【課題を解決するための手段】
本発明のレプリケーションシステムは、マスタデータベースが接続されたマスタサーバと、このマスタサーバにネットワークを通じて接続され、マスタデータベースの登録データと同一のデータを登録する複数のレプリカデータベースが接続されたレプリカ端末とを備える関係データベースシステムに用いられるレプリケーションシステムであって、各レプリカデータベースに登録するデータをマスタデータベースから抽出するための抽出条件を記憶保持する抽出条件データベースと、マスタデータベースの登録データが変更されると、前記抽出条件データベースに記憶保持された抽出条件に基づき、各レプリカデータベースに登録すべき変更データを抽出する抽出手段と、各レプリカ端末からの要求に応じ、前記変更データを各レプリカ端末に伝送する変更データ伝送手段とを備える。
【００１１】
また、前記抽出手段によって抽出された変更データの削除処理をレプリカ端末から受けると、当該変更データをマスタサーバ側で削除する変更データ削除手段をさらに備える。
【００１２】
また、各変更データには端末ＩＤ及びデータ識別番号が付されており、前記変更データ削除手段は、端末ＩＤ及びデータ識別番号で特定した変更データを削除する。
【００１３】
また、マスタデータベースへの登録データの変更が削除処理、挿入処理または更新処理のいずれの処理によって行われたかに基づき、レプリカデータベースへの変更データの登録処理方法である変更モードを判定する変更モード判定手段をさらに備える。
【００１４】
また、前記変更モード判定手段は、当該変更データの変更モードが挿入処理であると判定した場合は、レプリカデータベース内に同一のキーを有するデータがあるか否かを判定し、同一キーのデータがないと判定した場合は変更モードを挿入処理とし、同一キーのデータがあると判定した場合は、変更モードを更新処理とする。
【００１５】
また、前記変更モード判定手段は、当該変更データの変更モードが更新処理であると判定した場合は、レプリカデータベース内に同一のキーを有するデータがあるか否かを判定し、同一キーのデータがあると判定した場合は変更モードを更新処理とし、同一キーのデータがないと判定した場合は、変更モードを挿入処理とする。
【００１６】
本発明のレプリケーションシステム用プログラムは、マスタデータベースが接続されたマスタサーバと、このマスタサーバにネットワークを通じて接続され、マスタデータベースの登録データと同一のデータを登録する複数のレプリカデータベースが接続されたレプリカ端末とを備える関係データベースシステムに用いられるレプリケーションシステム用プログラムであって、コンピュータに、マスタデータベースの登録データが変更されると、各レプリカデータベースに登録するデータをマスタデータベースから抽出するための抽出条件を記憶保持する抽出条件データベースに記憶保持された抽出条件に基づき、各レプリカデータベースに登録すべき変更データを抽出する抽出手段、及び、各レプリカ端末からの要求に応じ、前記変更データを各レプリカ端末に伝送する変更データ伝送手段として機能させるプログラムである。
【００１７】
【発明の実施の形態】
以下、図面と共に本発明によるレプリケーションシステム及びレプリケーションシステム用プログラムをＯｒａｃｌｅのＲＤＢＭＳに適用した好適な実施の形態について詳細に説明する。
図１は、本発明のレプリケーションシステムのハードウェア構成及びデータの流れを概略的に示す図である。
【００１８】
図１に示すように、マスタサーバ１１は図示しないネットワークを通じてレプリカ端末１２〜１４と接続されている。マスタサーバ１１は、マスタＤＢ１１Ａ及び抽出条件ＤＢ１１Ｂを備え、各レプリカ端末１２〜１４は、レプリカＤＢ１２Ａ〜１４Ａを備える。
各レプリカＤＢ１２Ａ〜１４Ａに登録されているデータはそれぞれ異なるが、マスタＤＢ１１Ａには、レプリカＤＢ１２Ａ〜１４Ａに登録されている全てのデータと同一のデータが登録されている。
【００１９】
また、抽出条件ＤＢ１１Ｂには、マスタＤＢ１１Ａ内の登録データから、各レプリカＤＢ１２Ａ〜１４Ａ内に登録されているデータを抽出するための抽出条件が予め登録されている。この抽出条件は、複数の検索条件（ＳＥＬＥＣＴ文）の組み合わせや条件文等の判断ロジックによって構成されている。
レプリカＤＢ１２Ａ〜１４Ａのデータ内容は、それぞれの抽出条件に基づき、マスタＤＢ１１Ａのデータ内容の変更に合わせて変更（このレプリカＤＢの登録データの「変更」のことを「リフレッシュ」と称する）される。
【００２０】
本発明のレプリケーションシステムにおいて、マスタＤＢ１１Ａのデータ内容が変更されると、マスタＤＢ１１Ａの登録内容が変更された場合に、マスタサーバ１１は、データベーストリガ機能を利用し、抽出条件ＤＢ１１Ｂから各レプリカ端末１２〜１４用の抽出条件を読み出し、読み出した抽出条件に基づいてマスタＤＢ１１Ａから変更されたデータを抽出することにより変更データであるレプリカログ１１ａ〜１１ｃを生成する。この抽出・生成処理はマスタサーバ１１の抽出手段としての機能によって行われる。
各レプリカログ１１ａ〜１１ｃは、各レプリカ端末１２〜１４に対応した識別子である端末ＩＤを有している。
【００２１】
マスタサーバ１１は、各レプリカ端末１２〜１４からの要求に応じてレプリカログ１１ａ〜１１ｃを伝送する。これはマスタサーバ１１の変更データ送信手段としての機能によって実行される。レプリカログ１１ａ〜１１ｃを取り込んだレプリカ端末１２〜１４は、それぞれ予め設定されたタイミングでレプリカＤＢ１２Ａ〜１４Ａのデータ内容をリフレッシュし、リフレッシュ後にマスタサーバ１１のレプリカログ１１ａ〜１１ｃを削除する。
【００２２】
図２は、本発明のレプリケーションシステムで用いるレプリカログのテーブル構成を示す図である。
図２に示すように、レプリカログは、端末ＩＤ、変更モード、マスタテーブルレイアウト、変更時刻及びＳＥＱで構成されるテーブル（このテーブルを以下では、レプリカログテーブルと称する）を備える。
【００２３】
端末ＩＤとは、変更されたレコードを参照するレプリカ端末を識別するための識別子である。変更モードとは、Ｉｎｓｅｒｔ（挿入）によるマスタデータの変更（Ｉと略す）、Ｕｐｄａｔｅ（更新）によるマスタデータの変更（Ｕと略す）、Ｄｅｌｅｔｅ（削除）によるマスタデータの変更（Ｄと略す）のいずれかを指す。この変更モードは、マスタサーバ１１の変更モード判定手段としての機能によって判定され、マスタＤＢ１１Ａの登録データ（マスタデータ）が、挿入、更新または削除のいずれの処理によって変更されたかによって決定される。
【００２４】
マスタテーブルレイアウトとは、マスタＤＢ１１Ａで変更されたデータ（変更分）を格納する領域である。この領域には、変更データの他に後述するマスタのプライマリキーも格納される。変更時刻とは、変更処理が行われた日付と時刻である。また、ＳＥＱとは、レプリカログテーブルにデータが出力される毎にインクリメントされ、過去のログ・レコードも含めて絶対に重複しないように時系列的に採番される番号（データ識別番号）である。
【００２５】
このような構造を有するレプリカログ１１ａ〜１１ｃには、各レプリカ端末１２〜１４毎にマスタＤＢ１１Ａの変更分が時系列的に格納される。このとき、「端末ＩＤ＋マスタデータのプライマリキー」をプライマリとして変更されたレコードの最後の状態のみを格納する。
【００２６】
本発明のレプリケーションシステムにおける変更処理を基本的変更処理と例外的変更処理に分けて説明する。この変更処理は、上述したレプリカログ１１ａ〜１１ｃを用いてレプリカＤＢ１２Ａ〜１４Ａのデータ内容に挿入（Ｉｎｓｅｒｔ）、更新（Ｕｐｄａｔｅ）または削除（Ｄｅｌｅｔｅ）のいずれかを行う処理によって構成される。
【００２７】
基本的変更処理は、レプリカログ１１ａ〜１１ｃのテーブル（レプリカログテーブル）の変更モードに従い、レプリカＤＢ１２Ａ〜１４Ａの登録内容に対して、以下のＩ、ＵまたはＤの変更処理を行う処理である。
Ｉ：マスタテーブルレイアウトの値でレプリカテーブルに挿入する。
Ｕ：マスタテーブルレイアウトの値でレプリカテーブルを更新する。
Ｄ：マスタテーブルのプライマリキーでレプリカテーブルを削除する。
【００２８】
変更処理は、原則としてレプリカログテーブルの変更モードに従って処理されるが、マスタＤＢ１１ＡとレプリカＤＢ１２Ａ〜１４Ａとのデータ内容の整合性を保持する為に、例外として下記の例外的変更処理を行う。
なお、例外的変更処理の説明では、マスタサーバ１１とレプリカ端末１２との間における処理を例として挙げるが、マスタサーバ１１とレプリカ端末１３との間、及び、マスタサーバ１１とレプリカ端末１４との間における処理も同様である。
【００２９】
第１例外的変更処理
変更モードが”Ｉ”でもレプリカＤＢ１２Ａ内に同一のプライマリキーのレコードが存在する場合は更新処理に切り替えて処理を行う。
第２例外的変更処理
変更モードが”Ｕ”でもレプリカＤＢ１２Ａ内に同一のプライマリキーのレコードが存在しなければ挿入処理に切り替えて処理を行う。
【００３０】
上述のような例外的変更処理は障害対策ではなく、定常的に発生する問題に対応するためのものである。
具体的には図３に示す以下のような例で発生する。
図３（ａ）は、第１例外的変更処理を行う場合におけるレプリカログテーブルの構成を示す図である。
【００３１】
図３（ａ）において、「キーＡ」と示すものがプライマリキーである。
マスタサーバ１１は、同一のプライマリキーのレコードに対して常に最新の変更分のレプリカログテーブルのデータ内容（ログ）しか残さない。このため、マスタサーバ１１が▲１▼のレプリカログテーブルを抽出し、レプリカ端末１２がレプリカログ１１ａを取り込まないうちに次の▲２▼のレプリカログテーブルを抽出した場合は、レプリカ端末１２は▲１▼のレプリカログテーブルの内容をレプリカＤＢ１２Ａに反映しないうちに▲２▼のレプリカログテーブルのデータ内容（ログ）によってリフレッシュされてしまい、▲１▼のレプリカログテーブルのデータ内容がレプリカログとして残らない。
【００３２】
このとき、▲２▼のレプリカログテーブルに従って挿入処理を行うと、レプリカＤＢ１２Ａ内には▲１▼のレプリカログテーブルによる削除処理が行われないまま（すなわち、削除処理が行われずにデータが残ったまま）のプライマリキーが「キーＡ」のレコードが存在しているので、挿入処理を行うことができず、一意制約でエラーとなってしまう。このため、このような場合はリフレッシュの変更モードを更新処理に切り替えて行う。これが第１例外的変更処理である。
【００３３】
図３（ｂ）は、第２例外的変更処理を行う場合におけるレプリカログテーブルの構成を示す図である。
上述したように、マスタサーバ１１は、同一のプライマリキーのレコードに対して常に最新の変更分のレプリカログテーブルのデータ内容（ログ）しか残さない。このため、マスタサーバ１１が▲１▼のレプリカログテーブルを抽出し、レプリカ端末１２がレプリカログ１１ａを取り込まないうちに次の▲２▼のレプリカログテーブルを抽出した場合は、レプリカ端末１２は▲１▼のレプリカログテーブルの内容をレプリカＤＢ１２Ａに反映しないうちに▲２▼のレプリカログテーブルのデータ内容（ログ）によってリフレッシュされてしまい、▲１▼のレプリカログテーブルのデータ内容がレプリカログとして残らない。
【００３４】
このとき、▲２▼のレプリカログテーブルのデータ内容（ログ）に従って更新処理を行うと、レプリカＤＢ１２Ａには▲１▼のレプリカログテーブルによる挿入処理が行われないまま▲２▼のレプリカログテーブルにより更新処理が行われることになる。レプリカＤＢ１２Ａ内にはプライマリキーが「キーＡ」のレコードは存在しないので、処理内容は０件の更新処理となってしまう。従って、このような場合は更新処理に代えて挿入処理を行うこととする。これが第２例外的変更処理である。
【００３５】
図４は、本発明のレプリケーションシステムにおけるログ削除処理を行う場合におけるマスタＤＢ側のレプリカログの構成を示す図である。
マスタＤＢ１１Ａ内のログテーブルは、レプリカ端末１２側におけるリフレッシュの完了後に削除される。ログテーブルの削除は、リフレッシュが終了したレプリカ端末１２から削除要求を受けることによって行われる。これはマスタサーバ１１の変更データ削除手段としての機能により実行される処理である。
基本的に、リフレッシュを行ったレプリカ端末１２の端末ＩＤのログテーブルを削除するが、端末ＩＤのみで特定したログテーブルを削除するのではなく、「端末ＩＤ」と「ＳＥＱ」の双方を用いて特定したログテーブルを削除する。
【００３６】
このように、「端末ＩＤ」と「ＳＥＱ」の双方を用いて削除処理を行い、最終的にリフレッシュが行われたログテーブルのＳＥＱ以下のＳＥＱを有するログテーブル（図４では▲１▼のログテーブル）のみを削除し、▲２▼のログテーブルは次回のリフレッシュ時にレプリカＤＢ１２Ａに反映させることにより、リフレッシュの開始時点でマスタサーバ１１側に▲１▼のログテーブルのみが存在し、リフレッシュの途中あるいはリフレッシュの完了からログテーブルの削除処理までの間に▲２▼のログテーブルが発生した場合に、リフレッシュの完了後に端末ＩＤだけで特定したログテーブルを特定して削除処理を行ってしまうことにより、▲２▼のログテーブルのデータ内容（ログ）がレプリカＤＢ１２Ａに反映されないまま▲２▼のログテーブルが削除され、マスタＤＢ１１ＡとレプリカＤＢ１２Ａ〜１４Ａとのデータ内容に不整合が生じることを防止することができる。
【００３７】
以上のような機能を有する本発明のレプリケーションシステムにおけるマスタサーバ側及びレプリカ端末側における処理手順は以下の通りである。
図５は、本発明のレプリケーションシステムにおけるマスタサーバ側における処理手順を示すフローチャートである。この処理手順は、本発明のレプリケーションシステムに用いるプログラムによって実行されるものである。
【００３８】
図５に示すように、まず、Ｏｒａｃｌｅのデータベーストリガ機能が起動することにより、マスタサーバ１１における処理がスタートする。
ステップＳ１において、マスタＤＢ１１Ａで変更されたデータ（変更分）の出力先を特定する端末ＩＤを特定する。これはレプリカログテーブルの出力を要求してきたレプリカ端末（１２〜１４のうちのいずれか）の端末ＩＤとなる。
ステップＳ２では、変更モードが削除処理（Ｄ）、挿入処理（Ｉ）または更新処理（Ｕ）のいずれであるかを判定する。これは、マスタＤＢ１１Ａにおけるレプリカログ１１ａ〜１１ｃの変更モードに基づく判定となる。
【００３９】
ステップＳ２において、削除処理（Ｄ）であると判定した場合は、フローはステップＳ３に進行し、レプリカログテーブルに削除処理を実行するためのデータ内容（ログ）をステップＳ１で特定した端末ＩＤによって表されるレプリカ端末１２〜１４のいずれかに出力する。これでステップＳ３は終了する。
【００４０】
ステップＳ２において、挿入処理（Ｉ）であると判定した場合は、フローはステップＳ４に進行し、レプリカＤＢ１２Ａ内に同一のプライマリキーのレコードが存在するか否かを判定する。
ステップＳ４において、レプリカＤＢ１２Ａ内に同一のプライマリキーのレコードが存在すると判定した場合は、フローはステップＳ５に進行し、レプリカログテーブルに挿入処理を実行するためのデータ内容（ログ）をステップＳ１で特定した端末ＩＤによって表されるレプリカ端末１２〜１４のいずれかに出力する。これでステップＳ５は終了する。
【００４１】
一方、ステップＳ４において、レプリカＤＢ１２Ａ内に同一のプライマリキーのレコードが存在しないと判定した場合は、フローは後述するステップＳ７に進行し、更新処理を行う。こうして第１例外的変更処理が行われる。
【００４２】
ステップＳ２において、更新処理（Ｕ）であると判定した場合は、フローはステップＳ６に進行し、レプリカＤＢ１２Ａ内に同一のプライマリキーのレコードが存在するか否かを判定する。
ステップＳ６において、レプリカＤＢ１２Ａ内に同一のプライマリキーのレコードが存在すると判定した場合は、フローはステップＳ７に進行し、レプリカログテーブルに更新処理を実行するためのデータ内容（ログ）をステップＳ１で特定した端末ＩＤによって表されるレプリカ端末１２〜１４のいずれかに出力する。これでステップＳ７は終了する。
【００４３】
一方、ステップＳ６において、レプリカＤＢ１２Ａ内に同一のプライマリキーのレコードが存在しないと判定した場合は、フローは前述したステップＳ５に進行し、挿入処理を行う。こうして第２例外的変更処理が行われる。
以上でマスタサーバ１１側における処理は終了する。
【００４４】
図６は、本発明のレプリケーションシステムにおけるレプリカ端末側における処理手順を示すフローチャートである。この処理手順は、本発明のレプリケーションシステムに用いるプログラムによって実行されるものである。
【００４５】
図６において、レプリカ端末側で予め設定された時間、または、任意の時間において起動の指令を受けた際にレプリカ端末側における処理がスタートする。
まず、ステップＳ１１において、マスタサーバ１１にアクセスし、マスタＤＢ１１Ａ内に自端末の端末ＩＤを有するレプリカログテーブルが存在するか否かを判定する。
【００４６】
自端末の端末ＩＤを有するレプリカログテーブルが存在すると判定した場合は、フローはステップＳ１２に進行し、そのレプリカログテーブルに含まれる変更モードが削除処理（Ｄ）、挿入処理（Ｉ）または更新処理（Ｕ）のいずれであるかを判定する。
【００４７】
ステップＳ１２において、変更モードが削除処理（Ｄ）であると判定した場合は、フローはステップＳ１３に進行し、自端末のレプリカＤＢ内のログテーブルのレコードを削除する。これにより、削除処理によるリフレッシュが完了する。ログテーブルのレコードの削除処理が終了すると、フローはステップＳ１６に進行し、マスタサーバ１１にアクセスし、この処理に対応するレプリカログを削除する。
ステップＳ１６が終了すると、フローが終了する。
【００４８】
ステップＳ１２において、変更モードが挿入処理（Ｉ）であると判定した場合は、フローはステップＳ１４に進行し、自端末のレプリカＤＢ内のログテーブルのレコードを挿入する。
ログテーブルのレコードの挿入処理が終了すると、フローはステップＳ１６に進行し、マスタサーバ１１にアクセスし、この処理に対応するレプリカログを削除する。
ステップＳ１６が終了すると、フローが終了する。
【００４９】
ステップＳ１２において、変更モードが更新処理（Ｕ）であると判定した場合は、フローはステップＳ１５に進行し、自端末のレプリカＤＢ内のログテーブルのレコードを更新する。
ログテーブルのレコードの更新処理が終了すると、フローはステップＳ１６に進行し、マスタサーバ１１にアクセスし、この処理に対応するレプリカログを削除する。
ステップＳ１６が終了すると、フローが終了する。
【００５０】
なお、以上の説明では、本発明のレプリケーションシステム及びレプリケーションシステム用プログラムをＯｒａｃｌｅのＲＢＤＭＳに適用した場合について説明したが、本発明のレプリケーションシステム及びレプリケーションシステム用プログラムは、Ｏｒａｃｌｅ以外のＲＢＤＭＳにも適用できるものである。
【００５１】
以上、本発明のレプリケーションシステム及びこれに用いるプログラムによれば、レプリカ端末毎に複雑なレプリカ抽出条件を設定することができる。このため、各レプリカ端末は、自端末のレプリカログのみを取り込めばよいので、従来のように不要なデータまで含まれたログを読み込む必要が無くなり、リフレッシュ時間を大幅に短縮できる。
【００５２】
また、変更データをマスタサーバ側で削除する変更データ削除手段を備え、レプリカ端末毎にレプリカログを作成し、各レプリカ端末がリフレッシュを行えば、そのレプリカログを削除するので、従来のようにリフレッシュを行わない端末が一つだけあるために長期にわたって膨大な容量を有するログをメインサーバ側で保持する必要が無くなり、メインサーバ側におけるディスク容量を節約できる。また、マスタサーバに対する最後の変更内容のみが出力されることによってもディスク容量を節約できる。
【００５３】
また、各端末ＩＤ及びデータ識別番号で特定した変更データを削除するので、マスタＤＢ１１ＡとレプリカＤＢ１２Ａ〜１４Ａとのデータ内容に不整合が生じることを防止することができる。
【００５４】
また、マスタデータベースへの登録データの変更が削除処理、挿入処理または更新処理のいずれの処理によって行われたかに基づき、レプリカデータベースへの変更データの登録処理方法である変更モードを判定する変更モード判定手段をさらに備えるので、マスタＤＢとレプリカＤＢ間におけるデータの不整合を抑制したレプリケーションシステムを提供することができる。
【００５５】
また、前記変更モード判定手段は、当該変更データの変更モードが挿入処理であると判定した場合は、レプリカデータベース内に同一のキーを有するデータがあるか否かを判定し、同一キーのデータがないと判定した場合は変更モードを挿入処理とし、同一キーのデータがあると判定した場合は、変更モードを更新処理とするので、マスタＤＢとレプリカＤＢ間におけるデータの不整合を抑制したレプリケーションシステムを提供することができる。
【００５６】
また、前記変更モード判定手段は、当該変更データの変更モードが更新処理であると判定した場合は、レプリカデータベース内に同一のキーを有するデータがあるか否かを判定し、同一キーのデータがあると判定した場合は変更モードを更新処理とし、同一キーのデータがないと判定した場合は、変更モードを挿入処理とするので、リフレッシュが行われる前にレプリカログの内容が変わった場合でも、マスタＤＢとレプリカＤＢ間におけるデータの不整合を抑制したレプリケーションシステムを提供することができる。
【００５７】
また、本発明のレプリケーションシステム用プログラムは、マスタデータベースが接続されたマスタサーバと、このマスタサーバにネットワークを通じて接続され、マスタデータベースの登録データと同一のデータを登録する複数のレプリカデータベースが接続されたレプリカ端末とを備える関係データベースシステムに用いられるレプリケーションシステム用プログラムであって、コンピュータに、マスタデータベースの登録データが変更されると、各レプリカデータベースに登録するデータをマスタデータベースから抽出するための抽出条件を記憶保持する抽出条件データベースに記憶保持された抽出条件に基づき、各レプリカデータベースに登録すべき変更データを抽出する抽出手段、及び、各レプリカ端末からの要求に応じ、前記変更データを各レプリカ端末に伝送する変更データ伝送手段として機能させるためのプログラムであるので、レプリカ端末毎に複雑なレプリカ抽出条件を設定することができ、また、各レプリカ端末は、自端末のレプリカログのみを取り込めばよいので、従来のように不要なデータまで含まれたログを読み込む必要が無くなり、リフレッシュ時間を大幅に短縮できるレプリケーションシステム用プログラムを提供することができる。
【００５８】
【発明の効果】
本発明のレプリケーションシステムは、マスタデータベースが接続されたマスタサーバと、このマスタサーバにネットワークを通じて接続され、マスタデータベースの登録データと同一のデータを登録する複数のレプリカデータベースが接続されたレプリカ端末とを備える関係データベースシステムに用いられるレプリケーションシステムであって、各レプリカデータベースに登録するデータをマスタデータベースから抽出するための抽出条件を記憶保持する抽出条件データベースと、マスタデータベースの登録データが変更されると、前記抽出条件データベースに記憶保持された抽出条件に基づき、各レプリカデータベースに登録すべき変更データを抽出する抽出手段と、各レプリカ端末からの要求に応じ、前記変更データを各レプリカ端末に伝送する変更データ伝送手段とを備えるので、レプリカ端末毎に複雑なレプリカ抽出条件を設定することができる。このため、各レプリカ端末は、自端末のレプリカログのみを取り込めばよいので、従来のように不要なデータまで含まれたログを読み込む必要が無くなり、リフレッシュ時間を大幅に短縮できる。
【図面の簡単な説明】
【図１】本発明のレプリケーションシステムのハードウェア構成及びデータの流れを概略的に示す図である。
【図２】本発明のレプリケーションシステムで用いるレプリカログのテーブル構成を示す図である。
【図３】本発明のレプリカエーションシステムにおける第１例外的変更処理及び第２例外的変更処理を行う場合におけるレプリカログテーブルの構成を示す図である。
【図４】本発明のレプリケーションシステムにおけるログ削除処理を行う場合におけるレプリカＤＢ内のログテーブルの構成を示す図である。
【図５】本発明のレプリケーションシステムにおけるマスタサーバ側における処理手順を示すフローチャートである。
【図６】本発明のレプリケーションシステムにおけるレプリカ端末側における処理手順を示すフローチャートである。
【図７】従来のレプリケーションシステムのハードウェア構成及びデータの流れを概略的に示す図である。
【符号の説明】
１１  マスタサーバ、１１Ａ  マスタＤＢ、１１ａ、１１ｂ、１１ｃ  レプリカログ、１１Ｂ  抽出条件ＤＢ、１２、１３、１４  レプリカ端末、１２Ａ、１３Ａ、１４Ａ  レプリカＤＢ。
【図１】
2004302919.tif 000003
【図２】
2004302919.tif 000004
【図３】
2004302919.tif 000005
【図４】
2004302919.tif 000006
【図５】
2004302919.tif 000007
【図６】
2004302919.tif 000008
【図７】
2004302919.tif 000009