JP6711884B2 - ソースデータベースの負荷を最小化したデータ整合性検証方法およびシステム - Google Patents

Description

本発明は、同一の複数のデータベースを運営するデータベース運営システムにおいて、ソースデータベースと複製データベースのデータとが一致するかを検証するためのデータ整合性検証方法およびシステムに関するものであって、さらに詳細には、ソースデータベースのデータ変化のパターンを収集後に分析し、データ変更カラムの時間値または数字値の範囲で区分した後にグループ化して比較することによってソースデータベースの負荷を最小化しつつも効率的に大容量のデータを検証できる、データ整合性検証方法およびシステムに関するものである。

情報化時代に入るにつれて、電子商取引、インターネット金融、インターネットショッピングモールなどの多様な分野で大容量のデータが発生しており、それに伴う多様なデータベースの使用とデータベース間のデータ複製またはマイグレーション作業などにより、同一データが各種のデータベースで業務的に使われている。このような過程において、データの複製とマイグレーション作業中にデータ漏れまたは損傷が発生し得るため、データの信頼性を保証するための効率的な運営方法が必要である。

ソースデータベースとターゲットデータベース間のデータ複製またはマイグレーション時のデータ整合性の信頼性を保証するために、通常はソースデータベースとターゲットデータベースのデータを全体または一部を持ち込んだ後、行（ＲＯＷ）単位でデータ全体を比較してデータ整合性をチェックして維持している。

ところが、このようなＲＯＷ単位のデータ整合性検証方式は、ＯＬＴＰ特性のソースデータベースで多くの負荷を発生するようになるため業務処理システムが遅くなる問題点があり、したがって、実際の運営環境ではデータ整合性に対する検証がきちんと行われておらず、その結果、ターゲットデータベースで業務を進行する時にデータ整合性の問題で正確な業務が行われない場合が発生する。

特許文献１は、企業業務統合を利用したデータ整合性管理方法およびシステムに関するものであり、特許文献２は、ログに基づいてデータ整合性を維持する分散保存システムおよび方法に関するものであって、障害が発生したノードが遂行できない演算に対するログを生成し、生成したログに基づいて演算を遂行することによってデータの整合性を維持するものである。

韓国公開特許第１０−２００９−０００１９５５号公報 韓国登録特許第１０−１５５３７１２号公報

本発明の目的は、データベース複製またはマイグレーション中に発生し得るデータ不一致の問題を解決するために、ソースデータベースの負荷を最小化しながらも大容量のデータを早い時間内に効率的に整合性検証できる方法およびシステムを提供することである。

本発明の一見地に係るシステムは、クライアントとソースデータベースを運営する運営サーバーとの間のパケットを抽出するか、トランザクションログやトリガー情報から変更データを抽出する変更データ抽出手段と、前記変更データ抽出手段によって抽出した変更データをパターン分析して変更情報が保存されたＤＭＬ変更パターンビットセットデータを生成するパターン分析器と、前記ＤＭＬ変更パターンビットセットデータから規則を探して整合性プロファイルを生成するルールエンジンモジュールと、前記ルールエンジンモジュールの整合性プロファイルに従って整合性検証を実行する整合性実行モジュールと、を含む。

前記変更データ抽出手段は、ネットワーク環境のスイッチまたはタップ設備からパケットデータをコピーしてＳＱＬ変更データを抽出するスニッフィングモジュール、ネットワークパケットを中継しつつ、ＳＱＬ変更データを抽出するプロキシモジュール、第１運営サーバーのＤＢＭＳで復旧のために生成したトランザクションログを持ち込んで変更データを抽出するトランザクションログモジュール、変更データ履歴情報を残すことができるトリガー機能で変更データを抽出するトリガーモジュールのうちいずれか一つである。

前記パターン分析器は、分析対象テーブル目録を持ち込んだ後、キュー保存所から変更データを持ち込んでＤＭＬ変更パターンビットセットデータを生成した後、リポジトリに保存するものである。

また、本発明の他の見地に係る方法は、クライアントとソースデータベースを運営する運営サーバーとの間のパケットを抽出するか、トランザクションログやトリガー情報から変更データを抽出する第１段階と、前記第１段階で抽出した変更データをパターン分析して変更情報が保存されたＤＭＬ変更パターンビットセットデータを生成する第２段階と、前記ＤＭＬ変更パターンビットセットデータから規則を探して整合性プロファイルを生成する第３段階と、前記ルールエンジンモジュールの整合性プロファイルに従って整合性検証を実行する第４段階と、を含む。

前記第４段階は、対象テーブル情報と整合性プロファイルを持ち込んでソースおよびターゲットデータベースの予想実行時間と現在の負荷測定値に基づいてデータ抽出モジュールであるダンプモジュールの実行並列度を設定した後、ダンプモジュールを実行してソースおよびターゲットデータベースから該当比較検証対象データを抽出した後、整合性プロファイルのＧＲＣＡアルゴリズムに基づいて整合性グループチェックサム（ｇｒｏｕｐ ｃｈｅｃｋｓｕｍ）データを生成してデータ整合性をチェックし、不一致が検出されると、ダンプデータに基づいてリカバリーモジュールを実行してデータ同期化復旧作業を遂行するものである。

本発明によると、原本データベースのデータ変化のパターンを収集後に分析し、データ変更コラムの時間値または数字値の範囲で区分した後にグループ化して比較することによってソースデータベースの負荷を最小化すると効率的に大容量のデータ整合性を検証できる効果がある。

また、本発明によると、ターゲットデータベースで業務を進行する時にもソースデータベースと同一にデータ整合性を維持することによって正確な業務を速かに処理できる長所がある。

本実施例に係る整合性検証システムの全体構成ブロック図。 本実施例のシステムによる整合性検証手続きを図示した全体フローチャート。 本実施例に係るスニッフィングモジュールの動作フローチャート。 本実施例に係るプロキシモジュールの動作フローチャート。 本実施例に係るトランザクションログモジュールの動作フローチャート。 本実施例に係るトリガーモジュールの動作フローチャート。 本実施例に係るパターン分析器モジュールの動作フローチャート。 本実施例に係るルールエンジンモジュールの動作フローチャート。 本実施例に用いられるＧＲＣＡアルゴリズムのフローチャート。 本実施例に係る整合性実行モジュールの動作フローチャート。 本実施例に係るダンプモジュールの動作フローチャート。 本実施例に係る比較モジュールの動作フローチャート。 本実施例に係るリカバリーモジュールの動作フローチャート。

本発明と本発明の実施によって達成される技術的課題は、下記において説明する本発明の好ましい実施例によってより明確となるはずである。下記の実施例は単に本発明を説明するために例示されたものに過ぎず、本発明の範囲を制限するためのものではない。

図１は本実施例に係る整合性検証システムの全体構成ブロック図であり、図２は本実施例のシステムによる整合性検証手続きを図示したフローチャートである。

本実施例に係るデータ整合性検証システムは、図１に図示された通り、クライアント１０、ソースデータベース２２を運営する第１運営サーバー２０と、ターゲットデータベース３２を運営する第２運営サーバー３０と、ソースデータベース２２とターゲットデータベース３２との間のデータ整合性を検証する整合性検証サーバー１００と、で構成される。クライアント１０は第１運営サーバー２０に直接接続してＳＱＬパケットを送受信し、プロキシモジュール１１４を介して第１運営サーバー２０に接続してＳＱＬパケットを送受信することができ、第１運営サーバー２０は運営中にＤＢＭＳトランザクションログ２４を生成している。

整合性検証サーバー１００は、図１に図示された通り、各種データを保存するためのリポジトリ１０２と、スニッフィングモジュール１１２と、プロキシモジュール１１４と、トランザクションログモジュール１１６と、トリガーモジュール１１８と、パターン分析器モジュール１２０と、ルールエンジンモジュール１３０と、整合性実行モジュール１４０と、ダンプモジュール１５０と、比較モジュール１６０と、リカバリーモジュール１７０と、を含んでいる。リポジトリ１０２には多数のキューが備えられ得る。ここで、スニッフィングモジュール１１２と、プロキシモジュール１１４と、トランザクションログモジュール１１６と、トリガーモジュール１１８は、変更データ抽出モジュール１１０に該当する。

本実施例のシステムは、図２に図示された通り、変更データ抽出モジュール１１０から変更データを抽出してキューに保存する変更データ抽出過程（Ｓ１）と、キューから変更データを持ち込んで分析して、ＤＭＬ変更パターンビットセットデータを生成してリポジトリ１０２に保存するＤＭＬ変更パターンビットセットデータ生成過程（Ｓ２）と、テーブル単位でグループロウチェックサムアルゴリズム（ＧＲＣＡ：Ｇｒｏｕｐ Ｒｏｗ Ｃｈｅｃｋｓｕｍ Ａｌｇｏｒｉｔｈｍ）を適用して整合性プロファイルを生成する整合性プロファイル生成過程（Ｓ３）と、整合性プロファイルに従って実際に整合性を実行する整合性実行過程（Ｓ４）を順次実行する。

図２を参照すると、変更データ抽出過程（Ｓ１）では、スニッフィングモジュール１１２を開始し、プロキシモジュール１１４を開始し、トランザクションログ１１６を開始し、トリガーモジュール１１８を開始した後、変更データを抽出してキューに保存する。

ＤＭＬ変更パターンビットセットデータ生成過程（Ｓ２）では、パターン分析器モジュール１２０を実行してキューの保存領域から変更データを持ち込んで分析した後、ＤＭＬ変更パターンビットセットデータを生成してリポジトリ１０２に保存する。

整合性プロファイル生成過程（Ｓ３）では、ルールエンジンモジュール１３０を開始してテーブル単位のビットマスクデータを持ち込んで、テーブル単位でＧＲＣＡを適用して整合性プロファイルを生成および保存する。

整合性実行過程（Ｓ４）では、ダンプモジュール１５０を開始し、ソースおよびターゲットデータベースからデータを抽出して整合性データを生成した後、比較モジュール１６０を開始してデータ整合性チェックを実行する。引き続き、リカバリーモジュール１７０で、復旧データがある場合、データ同期化復旧を遂行する。

図１を参照すると、スニッフィングモジュール１１２は、ネットワーク環境のスイッチ（Ｓｗｉｔｃｈ）またはタップ（Ｔａｐ）設備からパケットデータをコピーするモジュールであって、ＤＢＭＳパケットを分析して変更データを抽出した後、整合性に必要な情報をパターン分析器モジュール１２０に提供する役割を担当する。スニッフィングモジュール１１２は、図３に図示された通り、スニッフィング初期化を実行した後にネットワークパケットを収集し、収集したパケットからＳＱＬ変更データを抽出した後、抽出したデータをキューに保存する（Ｓ１０１〜Ｓ１０４）。

プロキシ（ｐｒｏｘｙ）モジュール１１４は、基本的にはネットワークパケットを中継する役割をするが、本実施例において、プロキシモジュール１１４は、ＤＢＭＳのパケットを中継する過程で整合性検証時に必要な変更データ情報をパターン分析器モジュール１２０に提供する役割を担当する。プロキシモジュール１１４は、図４に図示された通り、初期化を実行してからサーバーソケットを生成し、クライアント接続があるまで待機する（Ｓ１１１〜Ｓ１１３）。引き続き、接続されたクライアントからＤＢＭＳに送るパケットを収集し、収集したパケットからＳＱＬ変更データを抽出した後、抽出したデータをキューに保存する（Ｓ１１４〜Ｓ１１６）。

トランザクションログ（Ｔｒａｎｓａｃｔｉｏｎ Ｌｏｇ）モジュール１１６は、第１運営サーバー２０のＤＢＭＳで復旧のために生成したトランザクションログ（Ｔｒａｎｓａｃｔｉｏｎ ｌｏｇ）を持ち込んで分析した後、整合性に必要な変更データ（ＤＭＬ）情報をパターン分析器モジュール１２０に提供する役割を担当する。ここで、変更データ情報（ＤＭＬ：Ｄａｔａ Ｍａｎｉｐｕｌａｔｉｏｎ Ｌａｎｇｕａｇｅ）は、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥなどである。トランザクションログモジュール１１６は、図５に図示された通り、接続ＤＢＭＳ情報および最終処理トランザクションログを持ち込む初期化を実行した後、トランザクションログ２４から変更データ情報を抽出する（Ｓ１２１、Ｓ１２２）。引き続き、抽出した変更データをデータキューに保存する（Ｓ１２３）。

一方、すべてのＤＢＭＳは変更データ履歴情報を残すことができるトリガー（Ｔｒｉｇｇｅｒ）機能を提供するが、本実施例でＤＢＭＳトリガーモジュール１１８は、トリガー機能による変更データ情報をパターン分析器モジュール１２０に提供する役割を担当する。トリガーモジュール１１８は、図６に図示された通り、接続ＤＢＭＳ情報、トリガー抽出対象持ち込みのような初期化を実行した後、既存に生成したトリガーがなければトリガーを生成し、周期的に生成したトリガー情報を抽出し、処理したデータは削除する（Ｓ１３１〜Ｓ１３３）。この時、トリガー生成は、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ時に変更コラム情報が１、０でトリガーテーブルに保存されるようにすることである。

パターン分析器モジュール１２０は、スニッフィングモジュール１１２、プロキシ（Ｐｒｏｘｙ）モジュール１１４、ＤＢＭＳトランザクションログ（Ｔｒａｎｓａｃｔｉｏｎ ｌｏｇ）モジュール１１６、ＤＢＭＳトリガー（Ｔｒｉｇｇｅｒ）モジュール１１８のうち少なくとも一つで収集された変更データ情報を分析して、ＤＭＬ変更パターンビットセットデータを生成してリポジトリ１０２に保存する。このようなパターン分析器モジュール１２０は、図７に図示された通り、分析対象テーブル目録から分析対象テーブル目録を持ち込んだ後、キューの保存領域から変更データを持ち込む（Ｓ２０１、Ｓ２０２）。引き続き、変更データであって、ＤＭＬであり、分析対象テーブルであれば、ＩＮＳＥＲＴあるいはＵＰＤＡＴＥであるかを判断してパターン分析ビットマスクデータを生成した後、リポジトリ１０２にＤＭＬ変更パターンビットセットデータを保存する（Ｓ２０３〜Ｓ２０８）。

ここでＤＭＬ変更パターンビットセットデータの属性値は下記の表１の通りである。

前記表１のバイナリーデータを一つのパターンＲＯＷで保存するために、ＢＡＳＥ ６４エンコーディングされた文字列の形態で保存して分析資料として活用する。

ルールエンジン（Ｒｕｌｅ Ｅｎｇｉｎｅ）モジュール１３０は、パターン分析器モジュール１２０で収集されて保存されたＤＭＬ変更パターンビットセットデータを分析して、テーブル（Ｔａｂｌｅ）単位で最終整合性実行プロファイル（Ｐｒｏｆｉｌｅ）を生成してリポジトリ１０２に保存する。そして、各Ｔａｂｌｅ単位、日単位、時間単位でデータの発生量を測定し、全体のデータ発生量を測定してソースデータベースの負荷発生情報を生成してリポジトリ１０２に保存する。ここで、ＧＲＣＡ（ｇｒｏｕｐ ｒｏｗ ｃｈｅｃｋｓｕｍ ａｌｇｏｒｉｔｈｍ）ソースデータベースの負荷を最小化した方法を提示し、ＧＲＣＡアルゴリズムで実行される場合、ソースデータベースの整列負荷を除外するデータ抽出方法で負荷を最小化し、データ整合性検証時に比較機能を単純化することによって速やかに動作可能であるようにする。

図８を参照すると、ルールエンジンモジュール１３０は、分析対象テーブルから分析対象テーブル目録を持ち込むと共に、全体のデータ件数を把握した後、分析対象テーブル単位で分析対象ＤＭＬ変更パターンビットセットデータを持ち込む（Ｓ３０１、Ｓ３０２）。引き続き、ＧＲＣＡアルゴリズムでデータ整合性プロファイルを生成し、生成したデータ整合性プロファイルをリポジトリ１０２に保存する（Ｓ３０３、Ｓ３０４）。ここで、ＧＲＣＡアルゴリズムによってデータ整合性プロファイルを生成する手続きは、図９に図示された通りである。

図９を参照すると、対象テーブルの過去パターン分析統計情報を持ち込み、対象テーブルのメタ情報とインデックス情報を持ち込む（Ｓ３１１、Ｓ３１２）。引き続き、分析していないＤＭＬ変更パターンビットセットを分析して統計情報を生成し、生成した統計情報と過去の統計情報に基づいて新しい統計情報を生成する（Ｓ３１３、Ｓ３１４）。生成した新しい統計情報から日単位で最も値が高頻度に変更されるカラム情報を抽出する（Ｓ３１５）。この時、条件としては、少なくとも１つ以上、できる限りカラム種類が異なる３つを選択する。

そして、統計情報とインデックス情報からグループ単位条件となり得るカラム情報を探す（Ｓ３１６）。ここで、カラム情報は、日付またはシーケンスや数字や文字のうち継続して増加する値、範囲値等となり得る。引き続き、グループとして使用される値が存在するかを判断して、日付またはシーケンス範囲に合わせてデータを抽出できる条件節のプロファイルを生成する（Ｓ３１７〜Ｓ３１９）。

そして、パターン適用カラムが存在するかを判断し、日付タイプ、整数タイプ、実数タイプであれば、整数値に変換してチェックサム値すなわちプラス演算をする（Ｓ３２０〜Ｓ３２２）。文字タイプであれば、文字列を２バイトで整列させ、さらに整数に変換した後に曜日の数字で割った余りの値を求める（Ｓ３２３、Ｓ３２４）。その後、日単位、時間単位の最終グループ単位でデータを抽出できるデータ抽出条件とグループ単位のＲＯＷのコラムに対してチェックサム値を求めるプロファイルを生成する（Ｓ３２５）。

再び図１を参照すると、整合性実行モジュール１４０は、整合性実行要請時にルールエンジン（Ｒｕｌｅ Ｅｎｇｉｎｅ）モジュール１３０で生成したＧＲＣＡアルゴリズムとプロファイル（Ｐｒｏｆｉｌｅ）に基づいて、実際の整合性動作を実行し管掌する。整合性実行は、ルールエンジン（Ｒｕｌｅ Ｅｎｇｉｎｅ）モジュール１３０で収集されたソースデータベースの負荷値を求めて、負荷が最小化される時点でダンプ（Ｄｕｍｐ）モジュール１５０が開始されるようにする。これは、ソースデータベースの負荷を最小化するための事前作業である。

このような整合性実行モジュール１４０は、図１０に図示された通り、テーブル情報とメタ情報のような対象テーブル情報を持ち込み、実行計画（ｐｒｏｆｉｌｅ）情報を持ち込んだ後、ソースデータベースの負荷を測定して実行可能の可否を確認する（Ｓ４０１〜Ｓ４０３）。引き続き、ダンプモジュール１５０の並列処理の判断をし、ダンプモジュール１５０の並列度を設定した後、ダンプモジュール１５０を実行する（Ｓ４０４〜Ｓ４０６）。そして、比較モジュール１６０を実行した後、リカバリーモジュール１７０を実行して結果を処理する（Ｓ４０７〜Ｓ４０９）。

ダンプ（Ｄｕｍｐ）モジュール１５０は、整合性対象テーブル（ｔａｂｌｅ）のデータを常識ルールエンジン（Ｒｕｌｅ Ｅｎｇｉｎｅ）モジュール１３０で生成したプロファイル（Ｐｒｏｆｉｌｅ）情報に基づいて動作する。まず、ソースおよびターゲットデータベースから該当ＲＯＷデータを抽出し、引き続きＧＲＣＡアルゴリズムを適用してチェックサム値（ｃｈｅｃｋｓｕｍ）を生成および保存した後、復旧用として抽出したＲＯＷデータをＧＲＣＡアルゴリズムでＧＲＯＵＰ処理して保存し、検索のためのＩＮＤＥＸファイルを生成する。復旧用に、ＧＲＣＡアルゴリズムによってＧＲＯＵＰ単位でソースデータを保存することによって、復旧時に早い検索機能を提供する。このようなダンプモジュール１５０は、図１１に図示された通り、並列度入力値により並列処理あるいは単一処理を決定し、該当テーブルのＧＲＣＡアルゴリズムのプロファイルに基づいてグループ単位データを抽出する（Ｓ４１１、Ｓ４１２）。抽出したソースデータを保存してインデックスファイルを生成する（Ｓ４１３）。そして、抽出したソースデータにＧＲＣＡアルゴリズムを適用してグループＲＯＷデータ単位でチェックサム値を生成する（Ｓ４１４）。

比較モジュール１６０は、ダンプ（Ｄｕｍｐ）モジュール１５０で生成したソースデータベースのＧＲＣＡデータとターゲットデータベースのＧＲＣＡデータとを比較して整合性一致の有無を確認し、もし、ＧＲＣＡ整合データが一致しない場合は、ソースとターゲットデータファイルで該当不一致ＲＯＷを探してすべて復旧用データファイルとして保存する。この時、全体のデータの３０％以上、または対象テーブルのソースデータが１００万件以下の場合は、データ不一致が発生する場合、マイグレーション復旧モードで動作する。このような比較モジュール１６０は、図１２に図示された通り、ソースデータベースのグループＲＯＷチェックサム値とターゲットデータベースのグループＲＯＷチェックサム値を比較してデータ整合性検査をする（Ｓ４２１）。引き続き、不一致チェックサム値が存在するかを判断し、存在する場合、不一致チェックサム値に対するグループ情報を保存する（Ｓ４２２、Ｓ４２３）。

リカバリーモジュール１７０は、比較（Ｃｏｍｐａｒｅ）モジュール１６０でデータ復旧信号がある場合に動作し、ソースデータベースで該当復旧テーブル（Ｔａｂｌｅ）のＲＯＷに対してＬＯＣＫを実行した後、ソースデータベースから抽出したＲＯＷデータをターゲットデータベースシステムに同期化する。ＬＯＣＫは該当ＤＢＭＳ ＴＡＢＬＥまたはＲＯＷ単位のＬＯＣＫ機能を活用する。リカバリーモジュール１７０は、図１３に図示された通り、不一致情報ファイルから該当リカバリー対象グループ情報を持ち込み、グループ情報に基づいてソースデータファイルでＲＯＷ単位データを比較して不一致ＲＯＷを検出する（Ｓ４３１、Ｓ４３２）。検出したＲＯＷデータを復旧ファイルに保存する（Ｓ４３３）。このような動作を繰り返した後、それ以上不一致データがなければ、復旧ファイルからＲＯＷデータを持ち込むと共に、該当ＲＯＷデータをソースデータベースでＬＯＣＫをかけて再度持ち込む（Ｓ４３４〜Ｓ４３６）。引き続き、持ち込んだＲＯＷデータをターゲットデータベースに適用し、復旧ＲＯＷが存在すればこのような段階を繰り返す（Ｓ４３７、Ｓ４３８）。

以上、本発明は図面に図示された一実施例を参照して説明されたが、本技術分野の通常の知識を有する者であれば、これから多様な変形および均等な他の実施例が可能であることが理解できるはずである。

１０：クライアント
２０：第１運営サーバー
２２：ソースデータベース
２４：ＤＢＭＳトランザクションログ
３０：第２運営サーバー
３２：ターゲットデータベース
１００：整合性検証サーバー
１０２：リポジトリ
１１０：変化データ抽出モジュール
１２０：パターン分析器モジュール
１３０：ルールエンジンモジュール
１４０ : 整合性実行モジュール
１５０：ダンプモジュール
１６０：比較モジュール
１７０：リカバリーモジュール

Claims (3)

1. クライアントとソースデータベースを運営する運営サーバーとの間のパケットからＳＱＬ変更データを抽出するか、トランザクションログ又はトリガー情報からＳＱＬ変更データを抽出する変更データ抽出手段と、
   前記変更データ抽出手段によって抽出したＳＱＬ変更データを受信し、分析対象のテーブルに属し、データ操作言語(ＤＭＬ）に属している場合、テーブルオブジェクトナンバー、データ発生時間、ＤＭＬタイプ、変更されたコラムのビット単位の表現、日付、またはシーケンス番号で構成されるバイナリデータ形式のＤＭＬ変更パターンビットセットデータを生成するパターン分析器と、
   分析対象のテーブルの過去のパターン分析統計を取得し、前記ＤＭＬ変更パターンビットセットデータを分析して新しい統計情報を生成した後、生成された統計情報と過去の統計情報に基づいて、日単位で値が最も頻繁に変更されるカラム情報を抽出して、日付またはシーケンスの範囲に合わせてグループ単位でデータを抽出することができる条件節の整合性プロファイルを生成するルールエンジンモジュールと、
   ソースデータベースの負荷を測定して負荷が最小となった時点で、前記ルールエンジンモジュールの整合性プロファイルを実行する整合性実行モジュールと、
   前記整合性実行モジュールの制御に基づいて、 ソースデータベースとターゲットデータベースからグループ単位で対象のテーブルのデータを読み込み、該当行(ＲＯＷ）のコラムのチェックサム値を生成するダンプモジュールと、
   前記整合性実行モジュールの制御に基づいて、ソースデータベースのチェックサム値とターゲットデータベースのチェックサム値とを比較し、一致しない場合、データ復旧信号を生成する比較モジュールと、
   前記整合性実行モジュールの制御と、前記比較モジュールの復旧信号に応じて、ソースデータベースからの復旧テーブルの行（ＲＯＷ）についてロック（ＬＯＣＫ）した後、ソースデータベースから抽出した行（ＲＯＷ）データをターゲットデータベースにコピーして、ソースデータベースとターゲットデータベースを同期させるリカバリーモジュールと、
   を含む、ソースデータベースの負荷を最小化したデータ整合性検証システム。
2. 前記変更データ抽出手段は、
   ネットワーク環境のスイッチまたはタップ設備からパケットデータをコピーしてＳＱＬ変更データを抽出するスニッフィングモジュール、ネットワークパケットを中継しつつＳＱＬ変更データを抽出するプロキシモジュール、第１運営サーバーのＤＢＭＳで復旧のために生成したトランザクションログを持ち込んでＳＱＬ変更データを抽出するトランザクションログモジュール、変更データ履歴情報を残すことができるトリガー機能でＳＱＬ変更データを抽出するモジュール、のうちいずれか一つであることを特徴とする、請求項１に記載のソースデータベースの負荷を最小化したデータ整合性検証システム。
3. クライアントと接続され、ソースデータベースを運営する第１運用サーバーと、ターゲットデータベースを運営する第２運用サーバーと、により構成されるデータベースシステムにおいて、整合性検証サーバーによって、前記ソースデータベースとターゲットデータベースの整合性を検証するためのデータ整合性検証方法において、
   前記整合性検証サーバーがクライアントとソースデータベースを運営する運営サーバーとの間のパケットからＳＱＬ変更データを抽出するか、トランザクションログ又はトリガー情報からＳＱＬ変更データを抽出する第１段階と、
   前記整合性検証サーバーが前記第１段階で抽出したＳＱＬ変更データを受信し、分析対象のテーブルに属し、データ操作言語（ＤＭＬ）に属している場合、テーブルオブジェクトナンバー、データ発生時間、ＤＭＬタイプ、変更されたコラムのビット単位の表現、日付、またはシーケンス番号で構成されるバイナリデータ形式のＤＭＬ変更パターンビットセットデータを生成する第２段階と、
   前記整合性検証サーバーが分析対象のテーブルの過去のパターン分析統計を取得し、前記ＤＭＬ変更パターンビットセットデータを分析して新しい統計情報を生成した後、生成された統計情報と過去の統計情報に基づいて、日単位で値が最も頻繁に変更されるカラム情報を抽出して、日付またはシーケンスの範囲に合わせてグループ単位でデータを抽出することができる条件節の整合性プロファイルを生成する第３段階と、
   前記整合性検証サーバーがソースデータベースの負荷を測定して負荷が最小となった時点で、前記整合性プロファイルに従ってソースデータベースとターゲットデータベースから対象のテーブルのデータを読み込み、該当行（ＲＯＷ）のコラムのチェックサム値を求める第４段階と、
   前記整合性検証サーバーが、ソースデータベースのチェックサム値とターゲットデータベースのチェックサム値とを比較し、一致しない場合、データ復旧信号を生成する第５段階と、
   前記整合性検証サーバーが前記復旧信号に応じて、ソースデータベースからの復旧テーブルの行（ＲＯＷ）についてロック（ＬＯＣＫ）した後、ソースデータベースから抽出した行（ＲＯＷ）データをターゲットデータベースにコピーして、ソースデータベースとターゲットデータベースを同期させる第６段階と、
   を含む、ソースデータベースの負荷を最小化したデータ整合性検証方法。
   
   

Images