JP4880668B2 - 冗長データストアにおける非同期データを識別するための、およびそれを再同期させるための装置および方法 - Google Patents

Description

発明の簡単な説明
本発明は、一般に、電子データストレージに関する。特に、本発明は、同一のデータを維持することになっている２つの異なるコンピュータネットワーク位置における非同期データを識別するための技術に関する。さらに、本発明は、識別された非同期データを再同期させることに関する。

発明の背景
多くの企業が、２以上の位置に同じ電子データを格納する。その理由には、停電によるコンピュータの停止、故障、または災害の場合におけるこの情報のセキュリティおよび可用性と同様に、多数のエンティティおよびアプリケーションが独立して同じ情報を管理する能力を向上させることが含まれる。結果として、１つのデータソースにおいてデータが変更された場合には、それを、データ複製を始めとする様々な可能な機構を介して、１つまたは複数の２次データソースにコピーする必要があることが多い。データ複製に関連する多くの難問がある。たとえば、複製機構が正確であることを独立して検証できることが重要である。すなわち、ある位置から別の位置にコピーされるべきデータが実際にコピーされたことを確認することが重要である。データソースが同期外れ（out of synchronization）（すなわち非同期）である場合には、それらをできる限り効率的に再同期させることが重要である。これらの比較および再同期アクティビティは、次の制約がある状況で実行する必要がある。すなわち、データソースにおける変更の高アクティビティ／レート、静的な比較を実行するためにアプリケーションまたはデータベースをターンオフする機会がない動的環境、およびデータソース間の限られた帯域幅を伴う地理的分離である。

前述のことを考慮すると、データ比較および再同期動作のための技術の改善をもたらすことが、非常に望ましいであろう。

発明の概要
本発明には、データベースを比較するための実行可能命令を備えたコンピュータ可読媒体が含まれる。実行可能命令は、最初に条件同期外れ状態を確立するために、第１のデータベースのセグメントが、第２のデータベースの対応するセグメントと条件同期外れである場合を識別するように構成されている。実行可能命令は、この最初の時の後、第１のデータベースおよび第２のデータベースに変更がなされる待ち時間（latency period）を割り当てる。実行可能命令はまた、待ち時間の後に、第１のデータベースのセグメントが、第２のデータベースの対応するセグメントと同期しているかどうかを決定する。

制限のある帯域幅をサポートする接続部かつ／または自身を介して移送されるデータ量が非常に大きい接続部を通じて、構造的に類似または異なる表を比較するための効率的な機構が、本発明によって提供される。本発明によって、経時的にデータベースのセグメントまたはサブセットの処理が促進される。本発明はまた、非同期状態を確認するために、待ち時間を用いることによって効率的に「インフライト（in flight）」表データに対応する。

本発明によって、高速、高容量で、様々な環境にわたるデータ移動、データ管理およびデータ統合を可能にする、企業インフラストラクチャ・ソフトウェア・プラットホームが提供される。本発明は、銀行業、金融サービス、医療、電報、電話、公共部門および航空宇宙産業に関連して成功裏に用いられる。

本発明は、添付の図面と共に書かれた以下の詳細な説明に関連して、より完全に理解される。

同様の参照数字は、図面のいくつかの図全体にわたって、対応する部分を指す。

発明の詳細な説明
図１は、本発明のある実施形態に従って構成されたコンピュータネットワーク１００を示す。ネットワーク１００には、第１のコンピュータ１０２、第２のコンピュータ１０４および第３のコンピュータ１０６が含まれる。コンピュータ１０２、１０４および１０６は、伝送媒体１０８によって連結されているが、この伝送媒体１０８は、任意の有線または無線ネットワークであってもよい。

コンピュータ１０４には、バス１１４によって接続されたネットワーク接続回路１１０および中央処理装置１１２を始めとする標準コンピュータコンポーネントが含まれる。また、メモリが、バス１１４に接続されている。メモリは、第１のデータベース（ＤＢ１）１１８を格納する。また、ハッシュモジュール１２０がメモリ１１６に格納されているが、ハッシュモジュール１２０は、以下でさらに説明するように、データベース１１８のセグメントにハッシュ演算を実行する実行可能命令セットとして構成されている。ハッシュモジュール１２０は、ハッシュデータ１２２を生成する。ハッシュモジュール１２０は、ハッシュデータ１２２をコンピュータ１０２に伝える。

コンピュータ１０６にもまた、バス１３４によって接続されたネットワーク接続回路１３０および中央処理装置１３２を始めとする標準コンピュータコンポーネントが含まれる。メモリ１３６は、第２のデータベース（ＤＢ２）１３８を格納する。メモリ１３６はまた、実行可能なハッシュモジュール１４０を格納するが、ハッシュモジュール１４０は、第２のデータベース１３８におけるデータセグメントからハッシュデータ１４２を生成する。第２のデータベース１３８におけるデータセグメントは、ハッシュデータ１２２の第１のセットを生成するように処理された、第１のデータベース１１８におけるデータセグメントに対応する。ハッシュモジュール１４０には、第２のハッシュデータ１４２をコンピュータ１０２に伝える実行可能命令が含まれる。したがって、コンピュータ１０２は、コンピュータ１０４で実行された第１のハッシュ演算の結果、およびコンピュータ１０６で実行された第２のハッシュ演算の結果を受信する。第１のデータベース１１８および第２のデータベース１３８の対応する部分が処理されたので、２つのデータベースセグメントの内容が同一の場合には、ハッシュデータは一致するはずである。セグメントが異なる場合には、ハッシュが異なる可能性が非常に高い。ハッシュデータの伝送がネットワークトラフィックを著しく低減し、その他の点では、データベースの内容を比較するための迅速な技術を促進することに注目されたい。

コンピュータ１０２には、中央処理装置１５０、ネットワーク接続回路１５２およびシステムバス１５４の標準コンポーネントが含まれる。コンピュータ１０２はまたメモリ１５６を有するが、メモリ１５６は、本発明の動作を実行するように構成された実行可能プログラムを格納する。本発明の一実施形態において、メモリ１５６は、条件同期チェックモジュール１５８を格納する。このモジュール１５８は、第１のハッシュデータ１２２を第２のハッシュデータ１４２と比較する。ハッシュデータが等しくない場合には、条件同期外れ状態が存在する。次に、条件同期チェックモジュール１５８は、条件同期外れ状態の識別後に、待ち時間を割り当てるために休止する。待ち時間によって、データベースは、既存の同期機構を介して、ことによると同期することが可能になる。待ち時間後に、ハッシュモジュール１２０および１４０は、ハッシュデータ１２２および１４２をコンピュータ１０２に供給し、同期再チェックモジュール１６０が呼び出される。このモジュール１６０は、最も最近受信されたハッシュデータ１２２および１４２を比較する。ハッシュ値が同一である場合には、データベースは、もはや条件同期外れであるとは見なされない。他方で、ハッシュの結果が一致しない場合には、データベースは、同期外れであると見なされる。この時点で、同期再チェックモジュール１６０は、データベースセグメントに関する情報を、同期外れキュー１６２にロードする。次に、再同期モジュール１６４が、様々な処理動作を実行してデータベース間に同期を確立するが、その詳細は以下で説明する。

図２は、本発明のある実施形態に関連する処理動作を示す。図２の第１の処理動作は、データベースが条件同期外れかどうかを決定することである（２００）。前述のように、条件同期チェックモジュール１５８を用いて、この動作を実行してもよい。データベースが同期外れでない場合には、処理はブロック２００に戻る。データベースが条件同期外れである場合には、休止または待ち時間が呼び出される（２０２）。その後、データベースがまだ同期外れであるかどうかが決定される（ブロック２０４）。そうでなければ、処理は、ブロック２００に戻る。そうならば、データベースセグメントに関する情報が、同期外れキューにロードされる（２０６）。同期再チェックモジュール１６０が、これらの動作を実行してもよい。次に、再同期モジュール１６４を呼び出して、同期外れキュー内の内容を再同期させてもよい（２０８）。

図２の処理の多くの変形を、本発明の実施形態に従って利用可能である。たとえば、処理が一行ずつ実行される場合には、データベースにより多くのデータベースセグメントまたは行があるかどうかを、最初にブロック２００で決定する。あるならば、データベースセグメントが同期外れであるかどうかを確かめる決定がなされる。同期外れならば、休止する（２０２）。同期の欠如が継続する場合には（２０４）、そのセグメントは、キューにロードされる（２０６）。この時点で、次の行がフェッチされ、処理はブロック２００に戻る。

本発明のある実施形態に関連する主な処理を説明した。ここで、本発明の様々な実施形態のより詳細な説明に注目する。本発明の全ての説明が、本発明の性質を開示するためにあり、したがって、開示される特定の実施形態に本発明を限定するものとして解釈されるべきでないことを理解されたい。たとえば、図１のネットワーク構成は、例示的である。データベースおよび実行可能モジュールは、ネットワーク環境において、いくつものやり方で分散してもよい。重要なのは本発明の動作であり、それらの動作がどこで実行されるかではない。

本発明の技術は、様々なデータストレージ機構に適用可能である。しかしながら、例として、本発明は、データベースの文脈で開示される。すなわち、本発明は、表内の行を、そしてデータベース内の表を比較および同期させるために用いられる技術の文脈で開示される。行、表およびデータベースなる用語は、関連情報を格納するための一般的な方法を説明するために用いられる。データベースの一般的な例は、リレーショナルデータベースである。本発明はまた、階層型データベース（たとえばＩＢＭ（登録商標）ＩＭＳ）またはキーベースのデータベース（たとえばＨＰ（登録商標）エンスクライブ（Ｅｎｓｃｒｉｂｅ））などの他のタイプのデータベースに適用可能である。これらのタイプのデータベースに関して、行はレコードと、列はフィールドと呼ばれることが多い。

さらに、表はまた、拡張マークアップ言語（ＸＭＬ）文書もしくはさらにＸＭＬ文書内のセクション、または「行」、「列」および「表」を描写する（delineate）一貫した方法を提供する類似の「半構造」データと見なしてもよい。これにはまた、スプレッドシートならびに他の文書およびファイルタイプを含むことが可能である。表はまた、ＳＱＬビューなどの関連データまたはデータサブセットの論理的結合と見なすことができる。

表１および２は、製品および注文をそれぞれ特定するデータベース表の例である。

各表における「ユニークキー」（ＵＫ）は、表内の各行を一意に識別するために用いられる、表内の列のセットである。たとえば、ＰＲＯＤＵＣＴ表において、製品番号は、表において繰り返し現われることが決してないので、ユニークキーである。ＯＲＤＥＲ表において、注文番号は、繰り返し現われるので（値１が２度現われる）、一意ではない。しかしながら、注文番号および製品番号の組み合わせは、ユニークキーを構成する（（１、１００）、（１、２００）、（２、２００）、（５、１００）に繰り返しはない）。

アクセス方式によって、データベース内の表からデータを検索する方法が提供される。検索オプションには、データベースからの全ての行、キーに基づいた特定の行、特定の列、ならびに行および列サブセットに関する計算値を検索するための方法が含まれる。例示的なアクセス方式には、ＳＱＬ、ＯＤＢＣ、ＩＳＡＭ、Ｏｒａｃｌｅ ＯＣＩ、ストアドプロシージャ、および他に多くのものが含まれる。アクセス方式はまた、データベースと同じいくつかの特性を有する文書（ＸＭＬ文書およびスプレッドシートなど）からデータを検索する方法と見なすことができる。

本明細書で用いるように、ソースおよびターゲットなる用語は、あるデータベースから別のデータベースへの、またはある表から別の表への冗長データのデータフローの方向を説明するために用いられる。多くの場合、これは、予め定義された一方向のフローである。たとえば、データベースＰＲＩＭＡＲＹからデータベースＢＡＣＫＵＰへデータを移動するために複製が用いられている場合には、データベースＰＲＩＭＡＲＹおよびその中の表は「ソース」と見なされ、ＢＡＣＫＵＰおよびその中の表は「ターゲット」と見なされる。

さらに、ソースとターゲットとの間のデータフローは、他の方法で指定してもよい。たとえば、
− 行の特定のサブセット（ユニークキーによって定義されるような）が、ＴＡＢＬＥ１において「ソース」と指定され、ＴＡＢＬＥ２において「ターゲット」と指定される一方で、行の別のサブセットが、ＴＡＢＬＥ２において「ソース」として指定され、ＴＡＢＬＥ１において「ターゲット」と指定される
− どちらの表も、任意の行を修正することができ、次に、その行は、他のシステムにコピーされる
などである。

表の比較には、２つの表を要する。２つの表は、以下の条件が真である場合には、同期されている（すなわち「同期状態にある」）。
− 一方の表における全ての行が、ユニークキーによって識別されて（対応する行として）、もう一方の表で見つけることができる
− 各行内の全ての列が、もう一方の表における対応する行における全ての列と一致する

この定義は、同じ構造および行内容を有する表をカバーする。以下の表を考察する。

この例において、２つの表は、同期外れである。
１．ＰＲＯＤＵＣＴ１における行１および２は、ＰＲＯＤＵＣＴ２における行１および３に一致する（ユニークキー「製品番号」はそれぞれにおいて一致し、他の列も同様に一致する）
２．ＰＲＯＤＵＣＴ１の行４のための対応するエントリが、ＰＲＯＤＵＣＴ２内にはなく、その結果、行は同期外れである（製品番号４００は、ＰＲＯＤＵＣＴ２では見つけることができない）
３．ＰＲＯＤＵＣＴ２の行２のための対応するエントリが、ＰＲＯＤＵＣＴ１内にはない（製品番号１５０は見つけられない）−その行は同期外れである
４．製品番号３００は、両方の表で見つけられる（ＰＲＯＤＵＣＴ１行３、ＰＲＯＤＵＣＴ２行４）−しかし車輪数が異なる−その行は同期外れである

ここで、「同様に構造化された」かまたは「重複している」表のいくつかの例に注目する。これらのタイプの表において、たとえデータが正確には同じでなくても、選択されたデータ（列および／または行）は表間を流れて、重複データが適切に同期した状態で維持されるように保証する。

以下の例を考察するが、この例は、重複列のケースに関する。この例では、同じ列もあれば、異なる列もある。

この例において、２つの表は、正確には同じではないが、同期していると見なすことが可能である。なぜなら、「重複」列（製品番号および車輪数／車輪総数）が同期しているからである。これらのタイプのケースでは、すべてが正確に同じである上記の明白なケースとは異なり、どの列が重複しているかは、表のユーザによって定義される。

ここで、重複行を考察する。重複している行セットは、同期していると見なすことができる。

このケースで、ＢＡＳＥＢＡＬＬ＿ＴＥＡＭＳ表におけるチームのサブセット（地域が「西」である行）が、チームタイプが「野球」であるＷＥＳＴ＿ＴＥＡＭＳ表における行と比較される。この例では、１つの行だけが同期外れであろう（（ドジャーズ、６３）、（ドジャーズ、６０）。行２および４は、ＢＡＳＥＢＡＬＬ＿ＴＥＡＭＳのために返される行セットから除外される。なぜなら、対応する行情報が、ＷＥＳＴ＿ＴＥＡＭＳ表にあると予想されないからである。同様に、ＷＥＳＴ＿ＴＥＡＭＳにおける行３は、それがバスケットボールチームであるので、ＢＡＳＥＢＡＬＬ＿ＴＥＡＭＳ表にエントリがあるとは予想されない。さらに、列のサブセットが用いられる（地域は、ＷＥＳＴ＿ＴＥＡＭＳの一部ではなく、チームタイプは、ＢＡＳＥＢＡＬＬ＿ＴＥＡＭＳの一部ではない）。重複列および重複行の組み合わせも、同様に比較できることに留意されたい。

ここで、マップされたデータのケースを考察する。以下の例は、同じものを意味する異なるデータ値を示す。これは、あるシステムから別のシステムへデータが流れるので、「データマッピング」として知られている。上記の例を拡張すると、ＮＡＴＩＯＮＡＬ＿ＬＥＡＧＵＥ表は、以下のように見えるであろう。

このケースにおいて、ＡＬＬ＿ＴＥＡＭＳにおける地域は、たとえ正確な値が異なっても、ＮＡＴＩＯＮＡＬ＿ＬＥＡＧＵＥにおける短縮式地域に等しい。

本発明は、異種データストアと共に用いてもよい。異種データストアは、まさに同じ情報を別の仕方で格納する場合がある。たとえば、

これらの表のそれぞれにおいて、データ値は、実際には同じであるが、別の仕方で表現されている。

本発明の一態様は、行ハッシュ技術を用いて表を比較することである。比較される表データが、データベース１（ＤＢ１）およびデータベース２（ＤＢ２）に存在する状況を考察する。Ｃｏｍｐａｒｅ Ｃｌｉｅｎｔ（ＣＣ）プロセス（たとえば、条件同期チェックモジュール１５８として実行される）が、比較すべき各表のためにそれぞれある２つのホストサーバ（ＨＳ）プロセス（たとえばコンピュータ１０４および１０６における）への接続を確立する。一ホストサーバプロセスを用いて、比較すべきそれぞれの表のための表データを検索する。最高の効率のために、ＨＳとＤＢとの間の接続は、通常、同じシステムにあるかまたは非常に高速のネットワーク上にある。なぜなら、潜在的に多量のデータが、各ＨＳとＤＢとの間に流れているからである。

ＨＳプロセスおよびＣＣプロセスは、（互いに同じシステムにあること、いくつかが同じシステムにあること、または全てが異なるシステムにあることを始めとして）ネットワークのどこに位置してもよい。また、システムの１つにおけるＣＣおよびＨＳコンポーネントは、同じプロセスにおいて（異なるスレッドとしてかまたは同じスレッド内で）走行することが可能である。

次に、各ＨＳプロセスは、ユニークキー順に格納された各行を、その対応する表から検索する。検索された各行は、（データベース自体によってか、またはユーザが供給するメタデータを介して定義されるような）１つまたは複数のデータ列からなる。行検索は、データベースのタイプおよびそれが提供するアクセス方式（例として、ＳＱＬ、ＯＤＢＣ、Ｏｒａｃｌｅ ＯＣＩ、ＩＳＡＭ等が含まれる）に依存して、様々な方法で遂行される。

次に、ＨＳは、各行のための次のデータをメモリバッファに「パック」する。すなわち、ＨＳは、行のためにユニークキーを構成する全ての列をパックし、また、行における残りの列の「行ハッシュ」をパックする。

本明細書において、ハッシュは次のように定義される。すなわち、（特定の順序の）あるバイトセットに対して常に同じであるが、異なるバイトセット（たとえば、バイトセット「ＡＢ」は、バイトセット「１２３」、「ＢＡ」、「ＡＢＣ」のどれとも異なると見なされる）に対して同じである可能性が非常に低い、バイトセットに関する数値計算値として定義される。この場合に、バイトセットは、各列のデータであり、ここで各列は、列のデータ型のための標準フォーマットに変換される。ハッシュは、２つの行の比較を行なうために転送する必要のあるデータ量を低減するために、用いられる。

ハッシュ計算値の一例は、巡回冗長検査（ＣＲＣ）である。たとえば、５００バイトの行データに関して、３２ビットのＣＲＣを計算して、その行のために転送されるデータ量を、５００バイトから４バイトに低減することが可能である。かかるシナリオでは、５００バイトではなく、各行のための４バイトを比較して、２つの行が同期しているかどうかを決定することができる。これによって、転送される全体のデータ量は、効果的に劇的に縮小され、また所定の期間に所定のネットワークを通じて比較できるデータ量が、比例的に拡大される。

さらに、ＨＳは、個別の行情報−ユニークキーおよびハッシュ−をより大きな行ブロックにパックし、今度はこれらのブロックが圧縮され、ネットワークを通じて、より大きなメッセージでＣＣへ返送される。圧縮技術には、とりわけ、Ｚｉｖ／Ｌｅｍｐｅｌアルゴリズムなどの広く利用可能なアルゴリズムが含まれる。圧縮およびより大きなメッセージへの小さな行のブロック化は、ネットワークを通じて転送する必要があるデータ量を著しく低減する効果があり、また比較すべきデータ容量を比例的に拡大させる。

ＣＣは、圧縮された行ハッシュブロックを受信すると、そのブロックを復元して、メッセージを個別の行へ非ブロック化する。ＣＣは、各ＨＳプロセスのための全ての通信および非ブロック化アクティビティを、別個の処理スレッドで実行して、比較の並列度およびスループットを最大化してもよい（多数のプロセッサに、複数の比較タスクへ同時に取り組ませる）。ＤＢ１およびＤＢ２の両方からの行は、ユニークキー順にソートされる。

次に、ＣＣ内の行比較スレッドは、表１からの行を表２における行と比較する。表１は、「ソース表」（ＳＴ）と呼ばれ、表２は、「ターゲット表」（ＴＴ）と呼ばれる。比較は、以下のように進む。
− 同期外れ行が、「同期外れ可能性キュー（maybe out of sync queue）」（ＭＯＯＳＱ）に順に蓄積される
○ 比較される行のキーおよびハッシュが格納される
○ 比較がいつ実行されたかのタイムスタンプが格納される
○ ＭＯＯＳＱは、行が同期外れだと分かったときに、行比較データを格納するためのメモリキュー、ファイルまたは等価な機構とすることができる
− 最初に、ＳＴおよびＴＴの両方から行が検索される
− 次に、ＳＴからもＴＴからも利用可能な行がなくなるまで、比較は、以下のループを実行する
○ 現在行は、ｒｏｗ（ＳＴ）またはｒｏｗ（ＴＴ）と表される
○ 次行（現在の次）は、ｎｅｘｔ ｒｏｗ（ＳＴ）またはｎｅｘｔ ｒｏｗ（ＴＴ）である
○ 現在行のユニークキーは、ｋｅｙ（ＳＴ）またはｋｅｙ（ＴＴ）である
○ 現在行のハッシュは、ｈａｓｈ（ＳＴ）またはｈａｓｈ（ＴＴ）である
○ ｋｅｙ（ＳＴ）がｋｅｙ（ＴＴ）より小さいか、またはＴＴからの利用可能な行がこれ以上ない場合には
■ 「欠落挿入（missing insert）」動作としてｒｏｗ（ＳＴ）をＭＯＯＳＱへキューイングする（以下を参照）−これは、表を同期させるために、ｒｏｗ（ＳＴ）がＴＴに挿入されなければならないことを意味する
■ ｒｏｗ（ＳＴ）はｎｅｘｔ ｒｏｗ（ＳＴ）になる
○ ｋｅｙ（ＳＴ）がｋｅｙ（ＴＴ）より大きいか、またはＳＴからの利用可能な行がこれ以上ない場合には
■ 「欠落削除（missing delete）」動作としてｒｏｗ（ＴＴ）をＭＯＯＳＱへキューイングする−表を同期させるために、ｒｏｗ（ＴＴ）が削除されなければならない
■ ｒｏｗ（ＴＴ）はｎｅｘｔ ｒｏｗ（ＴＴ）になる
○ ｋｅｙ（ＳＴ）がｋｅｙ（ＴＴ）に等しい場合には
■ ｈａｓｈ（ＳＴ）がｈａｓｈ（ＴＴ）と異なる場合には、
● 「欠落更新（missing update）」動作としてｒｏｗ（ＳＴ）をＭＯＯＳＱへキューイングする−表を同期させるために、ｒｏｗ（ＳＴ）がｒｏｗ（ＴＴ）に取って替わらなければならない
■ ｈａｓｈ（ＳＴ）がｈａｓｈ（ＴＴ）に等しい場合には
● 何も行なわない、行は同期している
■ 両方のケースで、ｒｏｗ（ＳＴ）はｎｅｘｔ ｒｏｗ（ＳＴ）になり、ｒｏｗ（ＴＴ）はｎｅｘｔ ｒｏｗ（ＴＴ）になる

比較の後、ＭＯＯＳＱは、同期外れと分かった全ての行に対するキーを保持する。次に、これらのキーのそれぞれを用いてデータベースから完全な行イメージを選択し、同期外れの行のリストを作成することができる。

以下の例を考察するが、この例は、表１２のソース表（ＳＴ）および表１３のターゲット表（ＴＴ）に依拠する。

上記の行ハッシュ技術は、
− 重複列のケース
− 重複行のケース
− マップされたデータのケース
− 異種データストア
を始めとする前述の重複表シナリオに適用することができる。

重複列およびマップされたデータのケースでは、システムのユーザが重複列リストを供給し、このリストが、比較フィルタの役割をする。別の代替として、列リストはまた、表で用いられるインデックスまたは表のビューから自動的に導き出すことが可能である。重複列リストにおける各列は、各表に（同期行のための）同じ情報を有しており、行ハッシュ計算をそれらの列のみに制限して、異なる列をフィルタ除去する。

前述の重複列のケースを考察する。重複列リストは、以下のようになるであろう。

車輪数および車輪総数は、たとえ名前が異なっていても、同じ情報を表現することに留意されたい。さらに、在庫有がＰＲＯＤ表のリストから省略されたのは、それが、ＰＲＯＤＵＣＴにおけるどの列とも重複しないからであり、品目がＰＲＯＤＵＣＴ表のリストから省略されるのは、それが、ＰＲＯＤに重複列を有しないからである。

重複行のケースでは、システムのユーザが、比較のために返される行セットにフィルタ定義を適用する。これは、ＳＱＬ文のＷＨＥＲＥ節、表内の物理的もしくは論理的パーティションの名前を特定する識別子、または比較において表から特定の行サブセットを検索および提示するために用いられる他のタイプの機構とすることができる。

前に示した重複行の例を用いると、以下のフィルタが適用されるであろう。
− ＢＡＳＥＢＡＬＬ＿ＴＥＡＭＳ表では、地域が「西」に等しい行だけを選択する
− ＷＥＳＴ＿ＴＥＡＭＳ表では、チームタイプが野球に等しい行だけを選択する

さらに、チーム名および勝利列だけが重複する。比較のために結果として得られる行セットは、以下の通りであろう。

（行２および４は、地域が「西」に等しくないのでフィルタ除去され、地域列は、重複しないのでフィルタ除去された）

（行３は、チームタイプが「野球」に等しくないのでフィルタ除去され、チームタイプ列は、重複しないのでフィルタ除去された）

異種データストアに関して、各列は、ハッシュ計算の実行前に、その基本的「タイプ」のための標準表現に変換されなければならない。さもなければ、同じことを意味するが別の仕方で表現された列データは、対応する行に対して等しくないハッシュ値を結果としてもたらす。

前に提示した例において、数および日付は、標準フォーマットに変換される。標準フォーマットは、広く変更できるが、最低限、以下のデータ型に対して定義される必要がある。
− 数
− 日付
− 後続スペースを有する文字列

選択された標準が両方の表に一貫して（consistently）適用され、したがって、そのデータが両方の表に対して一貫して表現されている限り、正確なハッシュ計算および比較を行なうことができる。

数表現のための１つの例示的なフォーマットは、以下の通りである。
− 先行ゼロを切り捨てる
− 小数点の右まで末尾のゼロを切り捨てる

日付表現のための例示的なフォーマットは、以下の通りである。
− ４桁の年、続く２桁の月、続く２桁の日にち（ＹＹＹＹＭＭＤＤ）

異種データストアの例を用いると、データは、ＯＲＡＣＬＥ＿ＯＲＤＥＲおよびＳＹＢＡＳＥ＿ＯＲＤＥＲ表の両方に対して、以下の通りに標準化される。

いくつかのケースでは、多くのディスクドライブにわたって広げられた多数の行を備えた表（分割表）は、比較プロセスが多数の断片に分割され、そのそれぞれが１つまたは複数の表パーティションに集中する場合には、より迅速に処理することができる。これは、分割表に対して多数の論理比較を生成し、そのそれぞれが所定のデータ範囲を担当することによって、行うことができる。この方法は、重複行のケースと同様であり、フィルタが、各比較のために用いられる。たとえば、以下の通りである。

この表における比較は、２つの比較に分割することが可能である。
− 比較１：姓が「Ａ」と「Ｍ」との間にある行をＳＴおよびＴＴの両方から選択する
− 比較２：姓が「Ｎ」と「Ｚ」との間にある行をＳＴおよびＴＴの両方から選択する
「分割比較」が同時に実行される場合には、行範囲「Ａ」〜「Ｍ」および「Ｎ」〜「Ｚ」の検索は、分割比較によって異なるディスクドライブがアクセスされるので、並行して行なうことができる。分割比較を実行するためには、パーティションは同一である必要がないことに留意されたい。

行ハッシュ技術は、同期外れ行を決定するための効率的な方法を示す。しかしながら、基礎となる表が変化している間に行ハッシュ技術が適用される場合には、この技術は、不確かな結果をもたらす可能性がある。それは、次の事実のゆえである。すなわち、比較が行なわれている間に、基礎となる行値が変化し、したがって、比較が、実際には比較中に同期した行を同期外れとして識別する可能性があるという事実である。表を同期に維持するために用いられるどんな基礎となる複製機構も、ソース行が変化する時刻と、その変化がターゲット表に適用される時刻との間に、遅延（待ち時間）をもたらす可能性がある。

本発明に関連する一技術は、行ハッシュ技術を補足し、変化している環境において正確な結果をもたらすために用いられる。これは、「同期外れ確認（Confirm Out of Sync）」処理（ＣＯＯＳ）として知られているが、この処理は、同期再チェックモジュール１６０で実行してもよい。この処理の目標は、以下のフォーマット（これらに限定するわけではないが）のいずれかにおいて、ある期間後に同期外れのままである行を明らかにすることである。
− ユーザによって検討されるレポート
− 行ごとに表を再同期させるプログラムなどの別の機構によって処理できる、同期外れ行および同期外れの可能性がある行のリストを含むキューまたはファイル（同期外れ確認キュー、すなわちＣＯＯＳＱ）
○ また、ＣＯＯＳＱを別のＣＯＯＳプロセスへの入力として用いて、どの行が、別の期間後かまたは再同期化ステップが適用された後で、同期外れのままであるかを確かめることができる。

本発明の一実施形態において、ＣＯＯＳステップで処理された行には３つの可能な状態がある。すなわち、
− 「永続的な同期外れ」−行は、行ハッシュ比較が行なわれて以来更新されず、したがって、同期外れであると考えられ得ることを意味する
− 「インフライト」−行ハッシュステップで同期外れだった行が、その後更新されたこと、したがって、複製または他の機構により、この行に対して作業が実行されたが、しかし、それらの行が同期したことは確認されなかったことを意味する
− 「同期」−ソース行が、複製機構を介してターゲットに適用されたことを意味する

たとえ「同期」状態であっても、基礎となる表が継続的に変化している場合には、行が現在同期していることを保証しない。しかし、それは、行を同期に維持する複製または他の関連処理が働いていることを示す。

ＣＯＯＳ処理は、以下のことを仮定する。
− 行を同期に維持するための別のアクティブな機構があること（たとえばデータベース複製）−一般的には「複製機構」として知られている
− 複製機構が、（「複製待ち時間」として周知の）ある時間窓内で、一方の表における変更の適用例をもう一方の表に適用する高い確率があること
○ この待ち時間は、複製機構からの待ち時間統計を検討することによってプログラムで、または機構がない状態ではユーザが手動で、決定することができる

一実施形態において、ＣＯＯＳ処理は、以下のように働く。
− 処理すべきＭＯＯＳＱレコードが残されている間
○ ＭＯＯＳＱから次のレコードを得る
○ 同期外れ動作タイプ（ｏｐｔｙｐｅ）が
■ 「欠落削除」の場合
● ｋｅｙ（ＴＴ）を用いて、ＴＴから完全なｒｏｗ（ＴＴ）を選択する
● ｒｏｗ（ＴＴ）が見つからない場合には、状態は「同期」になり、そうでなければ、ｒｏｗ（ＴＴ）は、「永続的な同期外れ」である
■ 「欠落挿入」の場合
● ｋｅｙ（ＳＴ）を用いて、ＴＴから完全なｒｏｗ（ＴＴ）を選択する
● ｒｏｗ（ＴＴ）が見つからない場合には、状態は「永続的な同期外れ」になり
● ｒｏｗ（ＴＴ）が見つかった場合には、ｈａｓｈ（ＴＴ）を計算する
○ ｈａｓｈ（ＴＴ）がｈａｓｈ（ＳＴ）と同じである場合には、状態は「同期」になる
○ ｈａｓｈ（ＴＴ）がｈａｓｈ（ＳＴ）と異なる場合には、状態は「インフライト」になる
■ 「欠落更新」の場合
● ｈａｓｈ（ＴＴ）を計算する
● ｈａｓｈ（ＳＴ）がｈａｓｈ（ＴＴ）に等しい場合には、状態は「同期」になる
● ｈａｓｈ（ＳＴ）がｈａｓｈ（ＴＴ）に等しくない場合には
○ 古いｈａｓｈ（ＴＴ）を新しいｈａｓｈ（ＴＴ）と比較する
■ 同じ場合には、状態は「永続的な同期外れ」になる
■ 異なる場合には、状態は「インフライト」になる（ハッシュが変化した場合には、それは、ターゲット行値が変化したこと、およびデータベース複製機構（もしあれば）が、行を更新し、作動しているらしいが、データが同じである点は確認されていないことを意味する）
○ 永続的な同期外れである行、そしてオプションとしてインフライトである行に対しては
■ ＣＯＯＳは、ｋｅｙ（ＴＴ）を用いて、ｒｏｗ（ＴＴ）のための全ての対応する列値を探索し、ｋｅｙ（ＳＴ）を用いて、ｒｏｗ（ＳＴ）のための全ての対応する列値を探索することができる
● ＭＯＯＳＱではキーおよびハッシュだけが利用可能だったので、全体の行イメージを見るために、これは必要なステップである
● 探索は、ＳＱＬ ＳＥＬＥＣＴ．．．ＷＨＥＲＥなどの標準データベースアクセス方式を用いて行なわれる

この時点で、ＣＯＯＳＱおよび／またはＣＯＯＳレポートは、永続的な同期外れである全ての行、および必要に応じて、インフライトである行の内容を含むかまたは表示する。

複製待ち時間が終了した後まで、ＣＯＯＳ処理が各行の確認ステップの実行を待つ限り、ＣＯＯＳ処理は、行ハッシュまたは他の最初の比較技術と同時に行うことができる。たとえば、複製待ち時間が６０秒で、最初の比較が、９：３０に同期外れ行を明らかにした場合には、その行のための確認ステップは、９：３１まで実行されない（たとえ、表における全ての行のための最初の比較が、９：３３まで完了しない場合であっても）。

以下の例を考察する。予想待ち時間は、ユーザによって６０秒に設定される。

ＣＯＯＳアクティビティの説明
− ＭＯＯＳＱレコード１を検索する
○ 現在時間（８：３３：３３）が、比較時間＋待ち時間（８：３３：３２＋６０）を超えるまで待って、動作を施す機会を複製に与える
○ １５０のターゲット行キー値を用いて、ターゲット表への探索を実行する
○ ターゲットレコードが見つからないので、削除が適用されたと仮定する
○ 今は「同期」として動作をマークする
− ＭＯＯＳＱレコード２を検索する
○ 現在時間（８：３５：１１）が、比較時間＋待ち時間（８：３４：１０＋６０）を超えるまで待って、動作を施す機会を複製に与える
○ ３００のターゲット行キー値を用いて、ターゲット表への探索を実行する
○ ターゲットレコードを見つける。ターゲット表で行ハッシュ（新ハッシュ）を計算する
○ ソース行のハッシュを、ターゲット行の新ハッシュと比較する。それらは同じである
○ 今は「同期」として動作をマークする
− ＭＯＯＳＱレコード３を検索する
○ 現在時間（８：３８：５９）が、比較時間＋待ち時間（８：３８：５８＋６０）を超えるまで待って、動作を施す機会を複製に与える
○ ４００のソース行キー値を用いて、ターゲット表への探索を実行する
○ ターゲットレコードが見つからないので、欠落挿入が適用されなかったと仮定する
○ 「永続的な同期外れ」として動作をマークする
− ＭＯＯＳＱレコード４を検索する
○ 現在時間（８：４０：０１）が、比較時間＋待ち時間（８：３９：００＋６０）を超えるまで待って、動作を施す機会を複製に与える
○ ５００のターゲット行キー値を用いて、ターゲット表への探索を実行する
○ ターゲットレコードを見つける。ターゲット表で行ハッシュ（新ハッシュ）を計算する
○ ソース行のハッシュを、ターゲット行の新ハッシュと比較する。それらは異なっているが、しかし新ハッシュは、最初の比較以来、ターゲット行において変化したので、行は、最初の比較以来、変化したはずであり、その結果として、動作は「インフライト」とマークされる

説明したように、ＣＯＯＳ処理技術は、行ハッシュ技術からのＭＯＯＳＱ出力を入力として用いて、実行することができる。ＣＯＯＳ処理は、行ハッシュ技術によって生成される行キー、ハッシュおよび関連情報を用いて、どの行が同期外れの可能性があるかを決定し、次に、その情報を用いて、確かな複製待ち時間が終了した後で、詳細な行データを探索する。

しかしながら、ＣＯＯＳ処理は、行ハッシュ技術の入力に限定されない。ＣＯＯＳ処理は、ソース表にのみ発見される行（欠落挿入）またはターゲット表にのみ発見される行（欠落削除）のために、同期外れデータのキーが供給される任意の入力に適用することができる。両方の表にあるが、非キー列において異なる値を有する行について、非キー列のデータは、行ハッシュである必要がない。それは、列値自体を始めとして、それらの列の値を表わす何であってもよい。データがソースおよびターゲットにおいて一貫して表現される限り、このことは、確認処理を行なうためには十分である。

本発明の代替実施形態において、表は、バッチハッシュ技術を用いて比較される。一実施形態において、バッチハッシュ技術は、説明のために２段階に分割される（それらは同時に実行してもよい）。
１．不良バッチ決定
２．行詳細フェッチおよび比較
一旦これらの段階が完了すれば、ＭＯＯＳＱは、（行ハッシュ技術と同様に）「同期外れ可能性」の行セットを保持する。そこから、前述の同期外れ確認（ＣＯＯＳ）ステップを実行して、基礎となるデータベースが変化し続ける間であっても、永続的に同期外れのままである行セットを決定する。

不良バッチ決定は、次のように実行してもよい。行ハッシュ技術と同様に、ホストサーバプロセスが、ソースおよびターゲット表から行を検索する。前に示したように、各行の列データは、異種なケースを考慮して、選択後に標準化される。さらに、行および列の重複を有効にする機構が、バッチハッシュ技術に同様に適用される。特定の行および列サブセットを、各表から選択することができる。

この技術の目標は、行ハッシュよりさらにネットワークトラフィックを低減することである。バッチハッシュにおいて、データフローは、以下のように生じる。ソースおよびターゲット表から（理想的には並行して）検索された行は、各ＨＳプロセスにおいて行読み出しバッファにロードされる。
− 行ハッシュ技術と同様に、行は、ユニークキー順にソース表から検索される
− 理想的には、ソースおよびターゲット表からの行検索は、ＨＳ１（たとえばＤＢ１・１１８）およびＨＳ２（たとえばＤＢ２・１３８）において並行して行われる。

検索された行を用いて、ＨＳ１は、引き続いて行情報のバッチを構成してＨＳ２へ送る
− 「ソースバッチサイズ」のために定数Ｎ（たとえば１０行）が選択される
− ＨＳ１の行読み出しバッファにおける最初のＮ行が、以下の方法で「バッチ行レコード」にパックされる
○ 開始キー列値（行１）
○ 終了キー列値（行Ｎ）
○ 行ハッシュ技術において示したハッシュ技術（たとえばＣＲＣ）を用い、Ｎ行における全ての列（または選択された列）に関して計算されたハッシュ
− バッチ行レコードが、バッチハッシュブロックへキューイングされる
− これが、行Ｎ＋１〜２Ｎ、２Ｎ＋１〜３Ｎ等に対して繰り返される
○ 最後のバッチは特別なケースであり、また最終ソースバッチ行レコードは、「エンドオブファイル」と示された終了キー値を有する
− バッチハッシュブロックが満杯のときはいつでも、またはローカル行読み出しバッファが一杯もしくはほぼ一杯のときには、バッチハッシュブロックは、ＨＳ２プロセスに送られる
○ 満杯、またはいつ行読み取りバッファが一杯もしくはほぼ一杯になるかは、設定可能であり、典型的には、ネットワークにおいてデータの最大スループットを達成するように、最適化される
○ ブロックは、さらなる効率のために圧縮してもよい

ＨＳ２は、バッチ行レコードを読み出して、（ターゲット表の）それ自身の行と比較する
− ＨＳ２は、ターゲット表のための行データをユニークキー順に読み出す
− 各バッチ行レコードは、ＨＳ１からの着信メッセージから、非ブロック化される
− ＨＳ１から来る各バッチ行レコードに対して
○ ＨＳ２は、バッチ行比較の境界、すなわちソースバッチ行レコードと一致する必要のある、ＨＳ２における行セットを決定する
■ ターゲットバッチ行レコードの開始行は、ターゲット表（ＴＴ）からの最初の利用可能な行である
■ ターゲットバッチ行レコードの終了行は、ソースバッチ行レコードの最後の行より小さいかまたは等しいキーを備えた行である
■ ＨＳ２はまた、その行セットにおける全ての行に関してハッシュを計算する
○ 次に、ＨＳ２は、ソースバッチ行レコードのハッシュを、ターゲットバッチ行レコードのハッシュと比較する
○ それらが異なっている場合には、バッチは「不良」と宣言される−これは、基礎となる行セットの少なくとも１つ、おそらくはより多くの行が同期外れであることを意味する。次に、不良バッチレコードが作成されるが、このレコードは、以下のものからなる。
■ ソースおよびターゲットバッチ行レコードを開始するキーの「小さいほう」−開始不良バッチ値
■ ソースおよびターゲットバッチ行レコードを終了するキーの「大きいほう」−終了不良バッチ値（これは、常に、ソースバッチ行レコードの終了キー値と同じでなければならないことに留意されたい）
■ ソースバッチ行レコードが、終了キー値として「エンドオブファイル」を示す場合には、ターゲットバッチ行レコードもまた、その終了キー値として「エンドオブファイル」を示さなければならない
○ 不良バッチレコードは、ＣＣプロセスに送られる（または送信のためにバッファされる）

今度はＣＣプロセスが、不良バッチレコードを同期外れ可能性キュー（ＭＯＯＳＱ）に書き込む。ＭＯＯＳＱは、同期外れであるバッチのための境界を保持する。これは、バッチ当たり少なくとも１つの、おそらくはより多くの行が同期外れだったことを意味する。

この時点で、第２のステップが行われ、同期外れである行セットを正確に決定する。このステップは、「行詳細フェッチ」として知られている。このステップは、全ての不良バッチを決定した後かまたはそのプロセス中に、実行することができる。各不良バッチを決定した後に同期外れである行を決定することは、行ハッシュ技術と同じロジックの多くに従う。この処理は、以下のように行なわれる。
− 不良バッチが、ＣＣによって検索される
− ＣＣは、ソース（ＨＳ１）およびターゲット（ＨＳ２）の両方に、基礎となる行詳細（各行の列）を要求する
− 各ＨＳプロセスは、不良バッチレコードの範囲にある各行を返すための問い合わせを定式化する。たとえば、不良バッチレコードが、キー「Ｂ」を備えた開始レコードおよびキー「Ｅ」を備えた終了レコードを有する場合には、これらのキー値間（これらのキー値を含む）の全てが返される（たとえばＢ、Ｃ、Ｄ、Ｅ）
○ 代替として、同じＨＳプロセスが、バッチ検索ステップおよび行詳細フェッチステップの両方で用いられる場合には、ＨＳプロセスは、詳細が要求される可能性があることを予想して、バッチ検索中に詳細な行データをキャッシュすることができる
− 行は、ＣＣに返される
− ＣＣは、行ハッシュステップにおけるように、各行を比較する。行が一致しない場合には、ＣＣは、不良行値をＭＯＯＳＱへ出力する

その時点で、ＭＯＯＳＱには、（行ハッシュ技術におけるように）「同期外れ可能性」の行が含まれる。そこから、基礎となる表が継続的に更新されている場合には、前述のように、「連続的に変化する表に対して同期外れ状態を評価する」ための技術を、設定可能な待ち時間の後で、適用することができる。

バッチ行技術は、以下の例に関連して、より完全に理解される。以下のことを考慮する。
バッチサイズ＝３
ブロック化＝１不良バッチレコード（簡略化のため）

ＨＳ１は、ＳＴから最初の３つのレコード−キー＝Ａ、Ｂ、Ｃ−を抽出し、これらの３つのレコードに関してハッシュを計算する。バッチ行レコードには、以下のものが含まれる。
− 開始キー列値−Ａ
− 終了キー列値−Ｃ
− ｈａｓｈ（１、２、３）

ＨＳ１は、バッチ行レコードをＨＳ２に送る。ＨＳ２は、以下の処理を実行する。
− ＴＴから第１の行（キー＝Ａ）を読み出し、それを、ＨＳ２からの不良バッチ行の終了キー値（Ｃ）と比較する−それが終了キーＣ以下であるので、その行は、ターゲットのための現在のバッチに含まれる
− ＴＴから第２の行（キー＝Ｃ）を読み出す−それが終了キーＣ以下であるので、この行がまた含まれる
− ＴＴから第３の行（キー＝Ｄ）を読み出す−これを、次のバッチ比較のために保存する
− レコードＡ、Ｃに関してハッシュを計算する−これ（ｈａｓｈ（１、３））は、ソースバッチ行レコードハッシュと異なる。なぜなら、ソースに存在した行（キー＝Ｂ）が、ターゲットバッチでは欠けているからである
− Ａ、Ｃを含むバッチ行レコードが、不良バッチキュー（ＢＢＱ）に出力される

次に、ＨＳ１は、ＳＴにおける次の３行から次のバッチレコードを構成する。
− 開始キー＝Ｄ
− 終了キー＝Ｇ
− ｈａｓｈ（４、５、６）

ＨＳ１は、バッチ行レコードをＨＳ２に送る。ＨＳ２は、以下の処理を実行する。
− 前のバッチに入らなかった、ＴＴからの残りの行（キー＝Ｄ）を用いる
− ＨＳ２がソースバッチレコードからの終了キーを超える行（キー＝Ｈ）を見つけるまで、行を蓄積する。ターゲットバッチ行レコードにおけるＧまで（Ｇを含む）の全ての行が含まれる
− ソースバッチ行レコードハッシュと一致するターゲット行ハッシュ−ｈａｓｈ（４、５、６）−を計算し、このバッチが「良」であると決定する

ＨＳ１は、最後のバッチを構成して、ＨＳ２へ送る。バッチには、以下のものが含まれる。
− 開始キー＝Ｈ
− 終了キー＝ＥＯＦ
− ｈａｓｈ（７）

ＨＳ２には、そのバッチ行レコード計算における全ての残りの行が含まれる。なぜなら、ソースバッチ行レコードからの終了キーが、ＥＯＦだからである。これらのレコードは、ターゲットバッチ行ハッシュがｈａｓｈ（７、８）であるので、一致しない。このレコードは、ＢＢＱに入れられる。

行詳細フェッチステップにおいて、各不良バッチレコードが、ＣＣによってＢＢＱから検索される。ＣＣは、開始および終了キー値によって境界を定められて暗黙のうちに示された行セットのために、行詳細をＨＳ１およびＨＳ２のそれぞれから検索する。一旦行が検索されると、行は、検索された順に比較される。

この時点でのＭＯＯＳＱには、同期外れの可能性がある行が含まれる。続く比較は、上記の行ハッシュに続いて説明したように、待ち時間の後に実行されて、同期外れのままである（かつ複製または同様の機構によって同期にされなかった）行を識別することができる。

比較技術は、同期すべきだが同期していない、２つの表における行を識別するための方法を示す。これらの技術はまた、基礎となるデータが絶えず変化している場合に、識別するための方法を確認する。

一旦２つの表が同期外れであると識別されると、それらを同期へ戻すことがしばしば要求される。これには、以下のことが含まれる。
− どの行を同期させるべきかを決定すること（データ駆動規則を用いて行ごとにか、または全行）−「再同期行セット」として知られている
− 再同期行セットにおける各行のために、どちらの表が変更情報の真のソースかを決定すること（これは、行ごとにか、データ駆動の規則でか、または一方向に流れる全行に基づいて行なってもよい）
− 変更情報をソースからターゲットへ実際に移動させるか、または個別の行を同期させながら移動をトリガすること

本発明の一実施形態において、同期外れキュー（ＯＯＳＱ）が、再同期プロセスへの入力として用いられる。ＯＯＳＱは、おそらく再同期可能な行のための、各行キーおよび動作タイプを始めとして最低限必要な属性を供給する。上記のＭＯＯＳＱおよびＣＯＯＳＱキューを生成する比較プロセスを始めとして、多くの異なるタイプのプロセスによりＯＯＳＱを生成してもよい。

同期させるために再同期行セットおよび方向性データフローを決定することが、表を同期へ戻す第１のステップである。再同期させるべき最終的な行セットは、「再同期キュー」（ＲＱ）として知られている。これは、ファイルおよびキューを始めとして多くの形状を取ることができるが、必要な行の再同期化プロセスに影響を与えるために必要な不可欠な情報を含む。ＲＱおよびＯＯＳＱは、同じファイルにすることさえできる。変更の適用が、各変更を適用すべきかどうか、どのように適用すべきかの決定に基づいて直ちになされる場合には、ＲＱはまた、論理概念と見なすことができる。

再同期キューの内容の決定は、次の方法で行なうことができる。デフォルトアクションが、１つのアプローチである。比較プロセス中に、一方の表がソースとして指定され、もう一方の表が、ターゲットとして指定される。デフォルトアクションは、再同期行セットにおけるすべての行を、ソースからターゲットへ流すことである。別のアプローチは、手動の検査および決定のために、ユーザに行を提示することである。この方法では、システムは、上記のＯＯＳＱからシステムのユーザへデータを提示する。動作が欠落挿入である場合には、ソース行が表示される。欠落削除のためには、ターゲット行が表示され、欠落更新のためには、ソースおよびターゲット行の両方が表示され、１つのオプションとして、ユーザの注意のために、同期外れ列を強調表示する。

ユーザは、各行を検査するときに、１）その行を再同期させるかどうか、および２）どの方向にその行を送る（すなわち「真の」ソースを決定する）かを決定することができる。比較のためにソースおよびターゲットが仮定されても、手動の検査プロセスは、ケースバイケースでこの関係を逆にできることに留意されたい。システムは、これらの設定をＲＱ（おそらくはＯＯＳＱ自体または新しいファイル／メモリキュー）に格納し、その行を後で同期させることができるようにする。代替として、システムは、方向性情報を格納せずに、検討が完了した後に直接これらの変更を実行することができる。

行を適用すべきかどうか、およびどの方向に適用すべきかを決定する別の方法は、データ駆動規則を用いることである。このシナリオでは、システムは、ユーザが、ＯＯＳＱ内の適用すべき行サブセットを特定できるようにする機構を提供する。この機能を可能にするシンタックスを実現するための、またはこの情報の入力を要求するユーザインタフェースを提供するための、多くのオプションがある。

以下の例を考察する。同期している場合、ＡＬＬ＿ＣＩＴＩＥＳ＿ＥＡＳＴおよびＡＬＬ＿ＣＩＴＩＥＳ＿ＷＥＳＴは、同じデータを有するはずである。ＡＬＬ＿ＣＩＴＩＥＳ＿ＥＡＳＴがソース表に指定され、ＡＬＬ＿ＣＩＴＩＥＳ＿ＷＥＳＴがターゲットに指示されたと仮定する。また、所定の都市に関するデータは、常に、その地域のための表のコピーに由来する（たとえば、ニューヨークのデータは、常にＡＬＬ＿ＣＩＴＩＥＳ＿ＥＡＳＴで生じる）と仮定する。

表３０の＃４および＃５以外の全てのケースで、データは、指定されたソースからターゲットへの方向に流れていることに留意されたい。しかしながら、＃４のケースでは、シアトルは西地域にあるので、行をＡＬＬ−ＣＩＴＩＥＳ−ＷＥＳＴから削除するのではなく、そのデータは、ＡＬＬ＿ＣＩＴＩＥＳ＿ＥＡＳＴへ挿入されるべきである。ケース＃５は、どちらの方向にもデータを適用したくない場合があるケースを示すために用いられる。したがって、方向性データフローを決定するための自動規則は、以下の通りであろう。
− ＯＯＳＱにおける各レコードに対して
○ 地域が東の場合には、変更の方向は、ＡＬＬ＿ＣＩＴＩＥＳ＿ＥＡＳＴからＡＬＬ＿ＣＩＴＩＥＳ＿ＷＥＳＴへである
○ 地域が西の場合には、変更の方向は、ＡＬＬ＿ＣＩＴＩＥＳ＿ＷＥＳＴからＡＬＬ＿ＣＩＴＩＥＳ＿ＥＡＳＴへである
○ 地域が他の場合には、どの方向にも変更を適用しない

表データ、動作タイプ、比較タイムスタンプおよび他の情報の組み合わせに基づくブール論理を含み、行セットの再同期化を可能または不能にし、それらの行の方向性フローを決定する規則を、システムは、可能にすることができる。より精巧な規則例は、以下の通りである。
− 地域が東かつＯＯＳＱ動作が欠落削除でないか、または都市がニューヨークである場合には、ＡＬＬ＿ＣＩＴＩＥＳ＿ＷＥＳＴに変更を適用する

１．規則ベースおよび手動検査技術の組み合わせ
システムはまた、規則自体によって決定されない行のために手動検査および決定を可能にする、規則明細特性（the rules specification capabilities）を拡張するオプションを提供することができる。上記の例を用いると、規則は、以下のように指定し得る。
− ＯＯＳＱにおける各レコードに対して
○ 地域が東の場合には、変更の方向は、ＡＬＬ＿ＣＩＴＩＥＳ＿ＥＡＳＴからＡＬＬ＿ＣＩＴＩＥＳ＿ＷＥＳＴへである
○ 地域が西の場合には、変更の方向は、ＡＬＬ＿ＣＩＴＩＥＳ＿ＷＥＳＴからＡＬＬ＿ＣＩＴＩＥＳ＿ＥＡＳＴへである
○ 地域が他の場合には、手動で決定する

行はまた、直接適用技術によって再同期させてもよい。一実施形態において、この技術には、以下のことが含まれる。
− 各意図した変更のためにＲＱを読み出す
− 列値、キー情報および動作タイプを用い、そのデータベース用に利用可能な固有の方法を用いて、ソースまたはターゲット表を更新する

これは、ＳＱＬデータベースの場合、以下のステップを含む。
− 欠落挿入のために、以下のシンタックスを構成する
○ ｉｎｓｅｒｔ ｉｎｔｏ ＜ｔａｂｌｅ＞（＜ｃｏｌｕｎｍ１＞［，＜ｃｏｌｕｍｎ２＞．．．］）ｖａｌｕｅｓ（＜ｃｏｌｕｍｎ ｖａｌｕｅ１＞［，＜ｃｏｌｕｍｎ ｖａｌｕｅ２＞．．．］）
○ 例：ｉｎｓｅｒｔ ｉｎｔｏ ＰＲＯＤＵＣＴ（名前、価格） ｖａｌｕｅｓ（’自動車’、３２０００）
− 欠落更新のために、以下のシンタックスを構成する
○ ｕｐｄａｔｅ ＜ｔａｂｌｅ＞ ｓｅｔ ＜ｃｏｌｕｍｎ１＞＝＜ｃｏｌｕｍｎ ｖａｌｕｅ１＞［，＜ｃｏｌｕｍｎ２＞＝＜ｃｏｌｕｍｎ ｖａｌｕｅ２＞］ ｗｈｅｒｅ ＜ｋｅｙ ｃｏｌｕｍｎ１＞＝＜ｋｅｙ ｃｏｌｕｍｎ１ ｖａｌｕｅ＞［ａｎｄ＜ｋｅｙ ｃｏｌｕｍｎ２＞＝＜ｋｅｙ ｃｏｌｕｍｎ２ ｖａｌｕｅ＞
○ 例：ｕｐｄａｔｅ ＰＲＯＤＵＣＴ ｓｅｔ 価格＝３２０００ ｗｈｅｒｅ 名前＝’自動車’
− 欠落削除のために、以下のシンタックスを構成する
○ ｄｅｌｅｔｅ ｆｒｏｍ ＜ｔａｂｌｅ＞ ｗｈｅｒｅ ＜ｋｅｙ ｃｏｌｕｍｎ１＞＝＜ｋｅｙ ｃｏｌｕｍｎ１ ｖａｌｕｅ＞［ａｎｄ＜ｋｅｙ ｃｏｌｕｍｎ２＞＝＜ｋｅｙ ｃｏｌｕｍｎ２ ｖａｌｕｅ＞
○ 例：ｄｅｌｅｔｅ ｆｒｏｍ ＰＲＯＤＵＣＴ 名前＝’自動車’
＜ｃｏｌｕｎｍ １＞．．．＜ｃｏｌｕｎｍ ｎ＞は、（それらの値が、最初の比較ステップで利用可能であった）、表における列のリストである。＜ｃｏｌｕｎｍ ｖａｌｕｅ １＞．．．＜ｃｏｌｕｎｍｎ ｖａｌｕｅ ｎ＞は、対応する列値である。
＜ｋｅｙ ｃｏｌｕｍｎ １＞．．．＜ｋｅｙ ｃｏｌｕｍｎ ｎ＞は、比較において用いられるユニークキーを含む列のリストである。＜ｋｅｙ ｖａｌｕｅ １＞．．．＜ｋｅｙ ｖａｌｕｅ ｎ＞は、対応する列値である。

一実施形態において、行は、以下によって再同期される。
− ＳＱＬ文シンタックスを構成する
− ＳＱＬ文をデータベースのＳＱＬエグゼキュータ（SQL executor）へ送る
− 独立にかまたは動作のより大きなグループの一部として各動作をコミットする

他のデータベースが、特定の行を削除、挿入および更新するための、ＳＱＬと同様の機能をサポートする。これらには、様々なＩＳＡＭ方法および異なるデータベースＡＰＩが含まれる。行変更を適用するための同じ一般的方法が、これらのタイプの表に適用される。特定の列またはフィールドを設定し、かつこれらのタイプのデータベースを更新するための方法が、一般に知られており、利用可能である。

多くの普通の環境およびアーキテクチャにおいて、２つのデータベースが、データベース複製方法を用いて、任意の所定の時間にしっかりと同期しているように維持される。これらのタイプのシナリオにおいて、行変更がデータソースで適用された場合には、それは、典型的には、ある遅延（ミリ秒から複数日に及ぶ）後に、ターゲットにおいて複製機構によって適用される。

このように適用されるデータは、再同期機構にとって難題を呈する。以下のイベントセットを考察する。

この例において、比較プロセスは、時間３（複製は、まだ、自動車からトラックへの変更をターゲット行に適用していない）において、同期外れ状態を正確に検出する。時間４において、時間２におけるソース行の更新が、ターゲットに最終的に適用される。続くアクティビティが、ソース行値を更新し（時間５）、複製が、時間６においてデータの新しい（正確な）バージョンを適用する。

しかしながら、時間７で、再同期化ステップは、古くなった変更をターゲットに適用し、レコードの最新のバージョンをより古いバージョンで誤って上書きする。これは、少なくとも次の比較および再同期化が行なわれるまでか、または比較および再同期アクティビティを邪魔することなく行が再び更新されて複製されるまで、ターゲット行におけるデータ誤りを確実にする。

本発明の一態様は、複製環境において順序だった変更適用を保証する。データベース複製が、所定の行への新しい情報の更新を邪魔する可能性があるので、システムは、異常を防ぐために再同期アクティビティを連係させる必要がある。これを達成するための不可欠な機構は、複製システムに変更自体を検出および適用させることである。

複製機構は、典型的には、動作がソースデータベースにおいて実行される順序で動作を検出し、これらの変更をターゲットデータベースにおいて同じ順序で適用する。これによって、ターゲット行が、（最終的には複製待ち時間が過ぎた後で）正確な情報を含むことが保証される。

変更の順序だった適用を可能にする一機構は、ソース行更新技術である。かかる技術は、以下のように実現可能である。
− 同期外れである行のキーをＲＱから得る
− キー値を用いて、その行における全ての列を、それら自身へ更新する
− これによって、データベースは、現在の行値をデータベーストランザクションログまたは類似の機構（トリガによって維持される変更ログなど）にログするようにトリガされる
− 続いて、複製システムは、変更のイベントを読み出して解釈し、変更をターゲットデータベースに複製する

以下の例を考察する。

直接適用技術とは対照的に、ここでは、複製が行の正確なバージョンを見つけて適用したので、行の正確なバージョンが適用されることに留意されたい。また、複製機構が、以下の追加機能を有しなければならないことに留意されたい。
− 再同期イベントは、常に、（値をそれら自身へ設定する）行に対する更新である。したがって、複製機構は、行がターゲットに実際に存在するか否かを検出し、かつそれがターゲットに存在しない場合には、挿入として行を適用できなければならない。

本発明の一実施形態は、ソース行マーカ技術を用いる。この技術が用いられるのは、ソース行更新技術が以下のように制限されているからである。
− 欠落削除レコードは、ソース行の更新によっては再作成することができない−したがって、削除の実施および処理のためには別の機構が必要である
− 行の更新は、データベーストリガなどの他の意図しないイベントを引き起こす場合がある
− 再同期機構によって引き起こされたアクティビティと、ソースエンドにおける適用によってかまたはターゲットにおける複製による適用によって引き起こされたアクティビティとの間で線引きする容易な方法がない

ソース行マーカ技術は、これらの制限に対処する。この技術はまた、複製と共に働いて、適切な順序で変更が適用されるように保証する。この技術は、以下のように働く。
− 同期外れの行のためのキーを（ＲＱから）得る
− 動作タイプが、欠落挿入または欠落更新である場合には
○ ソース行をロックしている間に、キー値を用いて、そのソース行から列の全てを選択する（例として、ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥまたはＲＥＡＤ ＷＩＴＨ ＬＯＣＫを用いる）
○ 最低限、表名および動作タイプと共に列値をＲＥＳＹＮＣ＿ＭＡＲＫＥＲ表に記録する
− 動作が欠落削除である場合には
○ ソース行をロックしている間に、キー値を用いて、そのソース行から列の全てを選択する（例として、ＳＥＬＥＣＴ ＦＯＲ ＵＰＤＡＴＥまたはＲＥＡＤ ＷＩＴＨ ＬＯＣＫを用いる）
○ 行が存在する場合には、何もしない
○ 行が存在しない場合には、最低限、表名、動作タイプまたは現在時刻と共にキー列値をＲＥＳＹＮＣ＿ＭＡＲＫＥＲ表に記録する
− （個別にかまたは再同期動作のグループで）データベーストランザクションをコミットする
− 選択されたか、又はロックしたまま読み出された任意の行をアンロックする

本発明は、以下の特徴を備えたＲＥＳＹＮＣ＿ＭＡＲＫＥＲ表で実現してもよい。
− 表内に作成された行は、データベーストランザクションログまたは均等物（複製変更データソース）にログされなければならない−トランザクションログは、基礎となるソース表によって用いられるトランザクションログと同じでなければならない
− この表は、異なる表構造のためのデータを格納することができる−それは、ソース表の列値を１つの大きな列につなぎ合わせるなど、何らかの方法でソース表の列値を格納できる限り、基礎となる１つまたは複数のソース表と同じ構造である必要がない

複製機構のための追加的な要件として、
− それは、ＲＥＳＹＮＣ＿ＭＡＲＫＥＲ表になされた変更を追跡しなければならない
− それは、ＲＥＳＹＮＣ＿ＭＡＲＫＥＲ表の目的を知り、この表の内容を、他の表を解釈するのとは異なって、解釈しなければならない−すなわち、それは、各ＲＥＳＹＮＣ＿ＭＡＲＫＥＲ行（たいがい、単一列への多数の列のパッキング）の内容を、適切なソース表フォーマットに翻訳する（意図された多数の列に単一列をアンパックする）
− それは、各ＲＥＳＹＮＣ＿ＭＡＲＫＥＲ行の内容を理解し、対応する行／列値および等価の変更レコードを内部で再構成できなければならない
− それは、ＲＥＳＹＮＣ＿ＭＡＲＫＥＲ表における削除行を処理する必要がない

この処理が特定の行に対して行なわれた後で、複製機構は、それが基礎となる行のための正常な変更レコードであるかのように、データを処理することができる。

最後に、ＲＥＳＹＮＣ＿ＭＡＲＫＥＲ行は、複製がそれらを処理してしまうまで必要なだけであるので、複製機構は、もはや必要でないＲＥＳＹＮＣ＿ＭＡＲＫＥＲ行を周期ベースで定期的に削除することができる。

この例において、時間８におけるソース行更新が、ＲＥＳＹＮＣ＿ＭＡＲＫＥＲ行がデータベースログに記録されることを保証するために、時間６で設定されたソース行読み出し用のロックが解除されるのを待たなければならなかったことに留意されたい。これによって、時間９および１０におけるステップは、正確な順序で実行されることが保証される。

前述の考察は、表比較が同期外れ行を明らかにする場合に、複製機構を用いて、データベースの進行中の同期化およびそれらのデータベースの再同期化の両方を促進する技術を説明する。複製機構がまた、前述の異種で重複するケースのために同期化をサポートできることを仮定し、さらにこの機構が、上記のソース行マーカ技術をサポートすることを仮定すると、この機構を用いて、異種表および／または重複行／列セットを同期させることもできる。これは、次の事実による。すなわち、一旦複製システムが、ソース行マーカデータを正確に解釈すると、続く動作は、まるでそれらが基礎となるソース表自体に生じたかのように、複製システムには見えるということである。したがって、複製機構によって既に対応された任意の異種で重複するデータ差異は、結合された再同期／複製機構に透過的に拡張される。

また、複製機構を用いて、再同期プロセスによって作成された行に対して、変更の監査証跡（audit trail）を作成することができる。これによって、再同期機構のユーザは、再同期化によって作成された行と、複製または外部アプリケーションによって作成された行との間で線引きすることが可能になる。

複製機構によって実行される以下のステップによって、特定の行のために、ターゲットデータベーストランザクションログに監査レコードが確立される。
− ＲＥＳＹＮＣ＿ＭＡＲＫＥＲ行がフェッチされる
− 行データが解釈され、基礎となるソース行に似るように変換される
− ターゲット行が、更新される
− 同じデータベーストランザクションの文脈内で、ＲＥＳＹＮＣ＿ＡＰＰＬＹ＿ＭＡＲＫＥＲ行が、ターゲットデータベースに作成される（その唯一の目的は、再同期アクティビティによってもたらされたものとして、トランザクションを識別することである）

一旦、レコードが、ターゲットデータベーストランザクションログに作成されると、ユーザがデータにアクセスする２つの方法がある。
１．ＲＥＳＹＮＣ＿ＡＰＰＬＹ＿ＭＡＲＫＥＲ表自体を見ることによって
２．ターゲットデータベーストランザクションログからトランザクションデータを調べることによって。ＲＥＳＹＮＣ＿ＡＰＰＬＹ＿ＭＡＲＫＥＲ表に対する動作はトランザクションに現われるので、トランザクションにおける全ての他の動作は、再同期アクティビティによって生成されたに違いないと仮定することができる

上記の第２のステップにはまた、列情報のための冗長記憶を必要としないという利点がある。なぜなら、それは、（ターゲットデータベースにその行を適用することによって）トランザクションログレコードに含まれているからである。

本発明のある実施形態は、様々なコンピュータ実行動作を実行するために、コンピュータコードを記録したコンピュータ可読媒体を備えたコンピュータストレージ製品に関する。媒体およびコンピュータコードは、本発明のために特に設計および構成されたものでもよく、またはそれらは、コンピュータソフトウェア技術分野の当業者に周知で入手可能な種類であってもよい。コンピュータ可読媒体の例には、限定するわけではないが、次のものが含まれる。すなわち、ハードディスク、フロッピー（登録商標）ディスクおよび磁気テープなどの磁気媒体と、ＣＤ−ＲＯＭおよびホログラフィック装置などの光学媒体と、光フロッピー（登録商標）ディスクなどの光磁気媒体と、特定用途向け集積回路（「ＡＳＩＣ」）、プログラム可能論理デバイス（「ＰＬＤ」）ならびにＲＯＭおよびＲＡＭデバイスなどの、プログラムコードを格納および実行するように特に構成されたハードウェアデバイスと、である。コンピュータコードの例には、コンパイラによって作成されるような機械コード、およびインタープリタを用いてコンピュータによって実行されるより高いレベルのコードを含むファイルが含まれる。たとえば、本発明のある実施形態は、Ｊａｖａ（登録商標）、Ｃ＋＋または他のオブジェクト指向プログラミング言語および開発ツールを用いて実現してもよい。本発明の別の実施形態は、マシン実行可能なソフトウェア命令の代わりに、またはそれらの命令と組み合わせて、配線回路で実現してもよい。

説明のための前述の記載は、本発明の完全な理解を提供するために特定の専門用語を用いた。しかしながら、本発明を実施するために具体的な詳細が必要とされてはいないことは、当業者には明らかであろう。したがって、本発明の特定の実施形態の前述の記載は、例証および説明のために提示されている。それらは、網羅的であるようにも、本発明を開示された形状に正確に限定するようにも意図されていない。上記の教示に鑑みて、多くの修正および変形が可能であることは、明らかである。実施形態は、本発明の原理およびその実際的な適用を最も良く説明するために、選択され記載された。その結果、それらによって、当業者は、本発明および意図された特定の用途に適した種々の修正を備えた様々な実施形態を最も良く利用することが可能になる。添付の請求項およびそれらの均等物が本発明の範囲を定義することが意図されている。

本発明のある実施形態を実行するネットワークを示す。 本発明のある実施形態に関連する処理動作を示す。

Claims (18)

1. 第１のデータベースの行バッチを含む前記第１のデータベースの領域を識別するステップと、
   前記第１のデータベースの前記行バッチを圧縮するステップと、
   前記第１のデータベースの圧縮された前記行バッチにおいて、非キーデータと、開始キー値および終了キー値を含むキーデータとを識別するステップと、
   第１のハッシュデータを作成するよう、識別された前記非キーデータにハッシュを実行するステップと、
   第２のデータベースの対応する領域を識別するよう、少なくとも識別された前記開始キー値と識別された前記終了キー値とを処理するステップと、
   第２のハッシュデータを作成するよう、前記第２のデータベースの識別された対応する前記領域の少なくとも一部にハッシュを実行するステップと、
   第１の時点での条件同期外れ状態を確認するために、作成された前記第１のハッシュデータが作成された前記第２のハッシュデータに対応していない場合を識別するように、作成された前記第１のハッシュデータと、作成された前記第２のハッシュデータとを比較するステップと、
   前記第１の時点の後に、前記第１のデータベースおよび前記第２のデータベースが既存の同期機構を介して同期するために、待ち時間を割り当てるステップと、
   前記待ち時間後に、前記第１のデータベースの識別された前記領域が、前記第２のデータベースの識別された対応する前記領域と同期しておらず、待ち時間後同期外れ状態を形成していると判断するステップと、
   前記待ち時間後同期外れ状態に応答して、前記第１のデータベースおよび前記第２のデータベースの動的な動作の間に、前記第１のデータベースの識別された前記領域を前記第２のデータベースの識別された対応する前記領域と再同期させるステップと、をコンピュータに実行させるためのプログラム。
2. 前記プログラムは、前記コンピュータに、前記第１のデータベースの前記領域と、前記第２のデータベースの対応する前記領域とのための共通フォーマットを確立させる、請求項１に記載のプログラム。
3. 前記プログラムは、前記コンピュータに、重複列、重複行、マップされたデータおよび異種データストアの少なくとも１つに対処する、前記第１のデータベースと前記第２のデータベースとの間の前記共通フォーマットを確立させ、前記第１または第２のデータベースの重複列の各々における各データは同じであり、前記重複行の各々における各データは同じであり、前記マップされたデータは前記第１および第２のデータベースの一方から検索され、前記異種データストアは互いに異なる態様で同じデータを格納する、請求項２に記載のプログラム。
4. 前記プログラムは、さらに、前記コンピュータに、作成された前記第１のハッシュデータとユーザ指定された非キーデータとをデータブロックに含めるために、作成された前記第１のハッシュデータを前記ユーザ指定された非キーデータで増強するステップを実行させる、請求項１に記載のプログラム。
5. 前記プログラムは、さらに、前記コンピュータに、前記第１のデータベースの前記領域が、前記第２のデータベースの対応する前記領域の対応する行または列と少なくとも部分的に重複する行または列を含むかどうかを確認するステップを実行させる、請求項１に記載のプログラム。
6. 前記プログラムは、さらに、前記コンピュータに、前記第１のデータベースの前記領域のうちの部分領域を、前記第２のデータベースの対応する部分領域と並行して比較するステップを実行させる、請求項１に記載のプログラム。
7. 前記プログラムは、さらに、前記コンピュータに、識別された前記開始キー値および識別された前記終了キー値を用い、前記第１のデータベースおよび前記第２のデータベース内で、前記第１の時点で条件同期外れ状態である前記第１のデータベースの識別された前記領域と、前記第２のデータベースの識別された前記領域とに対応する行セットを識別するステップを実行させる、請求項１に記載のプログラム。
8. 前記プログラムは、さらに、前記コンピュータに、前記行セットの個別行を比較して、条件同期外れである行を識別するステップを実行させる、請求項７に記載のプログラム。
9. 再同期化が、
   前記第１のデータベースの識別された前記領域から値を検索することと、
   前記第１のデータベースの識別された前記領域をロックすることと、
   前記第１のデータベースに関連するマーカ表に、前記第１のデータベースの識別された前記領域からの、検索された前記値を格納することとを含む、請求項１に記載のプログラム。
10. 前記プログラムは、さらに、前記コンピュータに、複製機構を用いて、前記マーカ表から前記第２のデータベースの識別された対応する前記領域へ、格納された検索された前記値を伝えるステップを実行させる、請求項９に記載のプログラム。
11. 前記プログラムは、さらに、前記コンピュータに、前記複製機構を用いて、前記第１のデータベースに対する変更を順序付けるステップを実行させる、請求項１０に記載のプログラム。
12. 前記再同期させるステップは、同期外れデータベース領域に関する情報を特定する同期外れキューにアクセスすることを含む、請求項１に記載のプログラム。
13. 前記再同期させるステップは、データ方向性フローを決定することを含む、請求項１２に記載のプログラム。
14. 前記再同期させるステップは、前記第１のデータベースまたは前記第２のデータベースのどちらかに関連する固有の方法に依存する直接適用技術を介して再同期させることを含み、前記直接適用技術は、
    各意図した変更のために再同期キュー（ＲＱ）を読み出すことと、
    列値、キー情報および動作タイプを用い、前記第１のデータベースまたは前記第２のデータベース用に利用可能な固有の方法を用いて、ソースまたはターゲット表を更新することとを含む、請求項１に記載のプログラム。
15. 前記再同期させるステップは、複製マーカを用いて再同期させることを含み、前記複製マーカは、
    同期外れの行のためのキーを再同期キュー（ＲＱ）から得るステップと、
    動作タイプが、欠落挿入または欠落更新である場合には、
    ソース行をロックしている間に、キー値を用いて、当該ソース行から列の全てを選択するステップ、および、
    最低限、表名および動作タイプと共に列値をＲＥＳＹＮＣ＿ＭＡＲＫＥＲ表に記録するステップと、
    前記動作タイプが欠落削除である場合に、
    ソース行をロックしている間に、キー値を用いて、当該ソース行から列の全てを選択するステップと、
    行が存在する場合には、何もせず、
    行が存在しない場合には、最低限、表名、動作タイプまたは現在時刻と共にキー列値をＲＥＳＹＮＣ＿ＭＡＲＫＥＲ表に記録するステップと、
    データベーストランザクションをコミットするステップと、
    選択されたか、又はロックしたまま読み出された任意の行をアンロックするステップとを含む、請求項１に記載のプログラム。
16. 前記再同期を行うステップは、ソース行更新技術を用いて再同期させることを含み、
    前記ソース行更新技術は、
    同期外れである行のキーを再同期キュー（ＲＱ）から得ることと、
    キー値を用いて、その行における全ての列を、それら自身へ更新することと、
    現在の行値をデータベーストランザクションログにログするようにデータベースをトリガすることと、
    続いて複製システムが、変更のイベントを読み出して解釈しすることと、
    変更をターゲットデータベースに複製することとを含む、請求項１に記載のプログラム。
17. コンピュータシステムにおいて、第１のデータベースの行バッチを含む前記第１のデータベースの領域を識別するステップと、
    前記第１のデータベースの前記行バッチを圧縮するステップと、
    前記第１のデータベースの圧縮された前記行バッチにおいて、非キーデータと、開始キー値および終了キー値を含むキーデータとを識別するステップと、
    第１のハッシュデータを作成するよう、前記非キーデータにハッシュを実行するステップと、
    第２のデータベースの対応する領域を識別するよう、少なくとも識別された前記開始キー値と識別された前記終了キー値とを処理するステップと、
    第２のハッシュデータを作成するよう、前記第２のデータベースの識別された対応する前記領域の少なくとも一部にハッシュを実行するステップと、
    第１の時点での条件同期外れ状態を確認するために、前記第１のデータベースの識別された前記領域が前記第２のデータベースの識別された対応する前記領域と条件同期外れであることを識別するように、作成された前記第１のハッシュデータを作成された前記第２のハッシュデータと比較するステップと、
    前記第１の時点の後に、前記第１のデータベースおよび前記第２のデータベースが既存の同期機構を介して同期するために、待ち時間を割り当てるステップと、
    前記待ち時間後に、前記第１のデータベースの識別された前記領域が、前記第２のデータベースの識別された対応する前記領域と同期しておらず、待ち時間後同期外れ状態を形成していると判断するステップと、
    前記待ち時間後同期外れ状態に応答して、前記第１のデータベースおよび前記第２のデータベースの動的な動作の間に、前記第１のデータベースの識別された前記領域を前記第２のデータベースの識別された対応する前記領域と再同期させるステップとを含む、方法。
18. プロセッサと、前記プロセッサと通信するメモリとを含むコンピュータシステムであって、前記メモリは、内部に前記コンピュータシステムによって実行可能なコンピュータコードを有しており、前記コンピュータコードは、
    第１のデータベースの行バッチを含む前記第１のデータベースの領域を識別するための実行可能命令と、
    前記第１のデータベースの前記行バッチを圧縮するための実行可能命令と、
    前記第１のデータベースの圧縮された前記行バッチにおいて、非キーデータと、開始キー値および終了キー値を含むキーデータとを識別するための実行可能命令と、
    第１のハッシュデータを作成するよう、識別された前記非キーデータにハッシュを実行するための実行可能命令と、
    第２のデータベースの対応する領域を識別するよう、少なくとも識別された前記開始キー値と識別された前記終了キー値とを処理するための実行可能命令と、
    第２のハッシュデータを作成するよう、前記第２のデータベースの識別された対応する前記領域の少なくとも一部にハッシュを実行するための実行可能命令と、
    第１の時点での条件同期外れ状態を確認するために、前記第１のデータベースの識別された前記領域が前記第２のデータベースの対応する前記領域と条件同期外れであることを識別するように、作成された前記第１のハッシュデータを作成された前記第２のハッシュデータと比較するための実行可能命令と、
    前記第１の時点の後の、前記第１のデータベースおよび前記第２のデータベースのための待ち時間により、既存の同期機構を介して同期することを可能にするための実行可能命令と、
    前記待ち時間後に、前記第１のデータベースの識別された前記領域が、前記第２のデータベースの識別された対応する前記領域と同期しておらず、待ち時間後同期外れ状態を形成していると判断するための実行可能命令と、
    前記待ち時間後同期外れ状態に応答して、前記第１のデータベースおよび前記第２のデータベースの動的な動作の間に、前記第１のデータベースの識別された前記領域を前記第２のデータベースの識別された対応する前記領域と再同期させるための実行可能命令とを含む、コンピュータシステム。

Images