JP2009505281A - データベースフラグメントのクローン化および管理 - Google Patents

Abstract

データベースフラグメントのクローン化および管理に対するメカニズムおよび技術を与える。テーブルまたはインデックスのようなデータベースオブジェクトをフラグメントに分割する。それぞれのフラグメントをクローン化して、互いに動作上は同一であるクローンフラグメントを生成する。１つまたは複数のクローンフラグメントを、データベース操作を実施するプライマリクローンフラグメントとして、またはバックアップの役割を果たすセカンダリクローンフラグメントとして指定することができる。それぞれのフラグメントに対する更新をプライマリクローンフラグメント上で実施し、次いでプライマリクローンフラグメントから対応するセカンダリクローンフラグメントに前記更新を伝達する。クローンフラグメントはオフラインになり、更新不能となることができる。クローンフラグメントがオンラインに戻るとき、クローンフラグメントをプライマリクローンフラグメントに含まれるデータでリフレッシュする。リフレッシュしている間、クローンフラグメントを更新することができる。リフレッシュプロセスが完了したとき、クローンフラグメントはプライマリクローンフラグメントとして指定される資格を有する。

Description

データベースシステムは一般に、アクセシビリティを目的として編成した情報を効率的に管理するために使用される。確実に利用できるように、システムはプライマリコピーを破損または紛失した場合に備えてデータベースのバックアップコピーを含むことができる。データベースバックアップに関する一般的技術の１つは、データベース全体をコンピュータ読取可能媒体に定期的にコピーすることである。例えば、情報システム管理者はデータベースを毎週末にディスクまたはテープにコピーすることができる。データベースのコピーをこのように保存することができるが、データベース全体のコピーには時間がかかり、他の手段で追跡しない場合はバックアップインターバル間のアクティビティは失われる。

データベースバックアップの別の技術として、同じデータベースを別のコンピューティングマシン上に維持することがある。データベースの１つが使用不能となった場合、別のコンピューティングマシンにあるデータベースの別のコピーにアクセスすることができる。この種のフェールオーババックアップによりデータベースを確実に利用することができる。しかしながら、別のマシンにあるデータベース全体の複数のコピーをリアルタイムに同期することは、複雑でコストが高いプロセスである。

データの過度な複雑性または不必要な損失無しにデータベースの利用可能性を保証する効率的な方法は、当業界の技術者にまだ知られていない。

以下で、読者に基本的な理解を与えるために本開示を簡潔に要約する。本要約は本開示の広範囲の概要ではなく、本発明の主要／重要な要素を特定せず、または本発明の範囲を詳述するものではない。本要約の唯一の目的は、本明細書で開示した幾つかの概念を簡潔な形で、後述のより詳細な説明に対する前段として提示することである。

本例はデータベースフラグメントのクローン化および管理に関するメカニズムおよび技術を与える。テーブル、行セット、インデックス、あるいはテーブルまたはインデックスのパーティションのようなデータベースオブジェクトをフラグメントに分割する。行セットはテーブル内の行の集合またはインデックス内のエントリの集合と考えられることに留意されたい。行およびレコードという用語は実質的に同一であると考えられる。したがって、行セットはレコードセットと等価でもある。それぞれのフラグメントをクローン化してクローンフラグメントを生成する。クローンフラグメントは、動作上は互いに実質的には同一である。クローンフラグメントの１つを、データベース操作を実施するプライマリクローンフラグメントとして指定することができ、１つまたは複数のクローンフラグメントを、プライマリフラグメントクローンに対するバックアップの役割を果たす目的でセカンダリクローンフラグメントとして指定することができる。それぞれのフラグメントに対する更新をプライマリクローンフラグメント上で実施し、次いでプライマリクローンフラグメントから対応するセカンダリクローンフラグメントに伝達する。

クローンフラグメントはオフラインになり、更新不能となる可能性がある。上記のクローンフラグメント内のデータは対応するプライマリクローンフラグメントに対してトランザクション的に最新でないので、上記のオフラインで利用不能なクローンフラグメントは陳腐化のクローンフラグメント（ｓｔａｌｅ ｃｌｏｎｅｄ ｆｒａｇｍｅｎｔ）であると定義する。陳腐化のクローンフラグメントがオンラインに戻るとき、クローンフラグメントをプライマリクローンフラグメントに含まれるデータでリフレッシュする。リフレッシュする間、クローンフラグメントを更新し続ける。リフレッシュプロセスが完了したとき、クローンフラグメントは即座にプライマリクローンフラグメントの指定候補の資格を得る。

多数の付随する特徴は、付属図面と関連させて考慮すると以下の詳細な説明を参照することで、より容易に理解でき、より良く理解できるであろう。

本説明は付属図面と照らし合わせて以下の詳細説明を読むことでより良く理解できるであろう。

付属図面において、同一の参照番号は同じ部分を指すよう使用する。

以下で付属図面に関連させて与えた詳細な説明は本例を説明するものとして意図しており、本例を構築または利用可能な唯一の形態を表すようには意図していない。本説明は、本例の機能、および本例を構築および操作するためのステップの列を説明する。ただし、同じまたは等価な機能および列を異なる例により実現してもよい。

本明細書ではデータベースフラグメントのクローン化および管理システムにおいて実施されるとして本例を説明および図示するが、説明したシステムは限定ではなく例として与えてある。当業界の技術者が理解できるように、本例は多種の異なるタイプのデータベースフラグメントクローン化および管理システムにおけるアプリケーションに対して適切である。

図１は、データベースシステムにより管理されるデータベースオブジェクト１０５をクローン化するデータ構造１００の例を示す。データベースは、データベース内の所望のデータ片が迅速に選択および／または更新可能であるように編成した情報の集合である。データベースオブジェクトはデータベースの全体または任意の部分であることができる。例えば、データベースオブジェクト１０５はテーブル全体、インデックス、行の集合（例えば、行セット）、等であることができる。

データベースオブジェクト１０５をパーティション１１１−１１３に分割することができる。一般に、データベースオブジェクト１０５を便宜上または性能上の理由で分割する。例えば、データベースオブジェクト１０５は複数の年に関連付けたデータを含むことができる。データベースオブジェクト１０５を、それぞれのパーティションを特定の年度に関連付けたパーティション１１１−１１３に分割することができる。データベースオブジェクト１０５を分割することは任意のステップであり、実際の実装では実施してもしなくともよい。

データベースオブジェクト１０５のそれぞれのパーティション１１１−１１３（またはデータベース全体、未分割のオブジェクト１０５）を一般に、フラグメント１２１−１２４のようなフラグメントに分割する。フラグメント１２１−１２４は、データベースシステムにより操作ベースで分割したデータベースオブジェクト１０５の部分である。例えば、フラグメント１２１−１２４を異なるコンピューティング装置に割り当てて、データベースオブジェクト１０５に関連付けた問合わせをフラグメント１２１−１２４に対して、並列に動作するコンピューティング装置により実施することができる。

データベースオブジェクト１０５内のフラグメントをさらにクローン化してクローンフラグメントを生成することができる。図１に示すように、論理的に分割したフラグメント１２１−１２４の各々をクローン化して、クローンフラグメントの例１３１、１４０−１４６を生成する。一般に、データベースオブジェクトのフラグメント（またはデータベースオブジェクトのパーティションのフラグメント）を、上記オブジェクトを（テーブルに対する）行または（インデックスに対する）インデックスエントリの離散集合に分割することで、生成する。上記分割を実現する１つの基盤として、テーブルまたはインデックスのキー上でのハッシングがある。行の集合を、行セットまたはレコードの集合と称することもある。クローンフラグメントを図２に関連させてより詳細に説明する。簡潔に述べると、正しく更新すれば、データベースオブジェクト１０５の特定のフラグメントに関連付けたクローンフラグメントは動作上は同一であり、その結果、データベースシステムは容易にクローンフラグメントを使用することができる。クローンフラグメントの使用により、特定フラグメントの二つまたは複数のコピーを使用することができ、例えば高レベルのデータ可用性を維持すること、問合せおよび他のデータベース操作を高速にすること、負荷分散を実施すること、等が可能になる。例えば、高レベルのデータ可用性を維持するため、少なくとも１つのクローンフラグメントが、データベース操作に使用される別のクローンフラグメントのバックアップの役割を果たすことができる。検索を高速にするため、複数の動作上同一なクローンフラグメントをデータベース問合せに並行に使用することができる。負荷分散を実施するために、異なるが動作上は同一であるクローンフラグメントのコピーを作業負荷状況に基づいて起動することができる。

図２はデータベースオブジェクトのクローンフラグメントの例１３１−１３９を示す。図に示すように、クローンフラグメント１３１−１３９を３つのグループ１５１−１５３と見ることができる。クローンフラグメントのそれぞれのグループはデータベースオブジェクトの特定のフラグメントに関連する。それぞれのグループ内部のクローンフラグメントを、互いに動作上同一なものとして生成する。したがって、正しく更新すると、クローンフラグメントの１３１−１３９の各々を、対応するフラグメント１５１−１５３に適用可能なデータベース操作に対して使用することができる。

１つの実施形態において、クローンフラグメント１３１−１３９を構成して高レベルのデータ可用性を与えることができる。本実施形態において、グループ１５１−１５３の各々からのクローンフラグメントを、データベース操作に対するプライマリクローンフラグメントとして指定することができる。グループ内の他のクローンフラグメントは、容易に利用可能なバックアップとしての役割を果たすセカンダリクローンフラグメントである。図２において、クローンフラグメント１３１、１３５および１３９をプライマリクローンフラグメントとして示し、残りのクローンフラグメントをセカンダリクローンフラグメントとして指定してある。

高レベルのデータ可用性を与えるため、装置の１つが故障した場合に別の装置内のセカンダリクローンフラグメントで前記の故障した装置内のクローンフラグメントを迅速に置換してプライマリクローンフラグメントとすることができるように、グループ内のクローンフラグメントの各々を異なる装置に含めることができる。例えば、プライマリクローンフラグメント１３１が含まれる装置が故障した場合にセカンダリクローンフラグメント１３２−１３３のいずれかをプライマリとして指定できるように、クローンフラグメント１３１−１３３の各々を別々の装置に含めることができる。

クローンフラグメントを管理するデータベースシステムはクローンフラグメント上で様々な操作を実施することができる。これらの操作は一般に、データ操作言語（ＤＭＬ）のステートメントまたは他の構造化問合せ言語（ＳＱＬ）のステートメントのような標準的なデータベース操作を用いて実施する。クローンフラグメントを更新およびリフレッシュする操作の例を、図３および４に関連させてより詳細に説明する。１つの実施例において、操作は以下を含むことができる。

１．クローンフラグメントの生成
クローンフラグメントを、データベース内の通常のテーブルまたはインデックス行セットから区別不能なように生成することができる。

２．クローンフラグメントの削除
ちょうどデータベース内の行セットのようにクローンを削除することができる。

３．クローンフラグメントのデータの完全な初期化
クローンフラグメントを完全に初期化し、クローンフラグメントにロードした新規の行セットを最初から含めることができる。

４．データ変更のクローンフラグメントへの伝達
プライマリクローンフラグメントへの変更を１つまたは複数のセカンダリクローンフラグメントに伝達する。伝達は、プライマリクローンフラグメントへの更新と同じトランザクションコンテクスト内で行う。

５．陳腐化のクローンフラグメントのリフレッシュ
クローンフラグメントがオフラインであるかまたはプライマリクローンフラグメントから更新のトランザクション伝達を受け取っていないとき、そのクローンフラグメントは陳腐化のクローンフラグメントであると定義する。陳腐化のクローンフラグメントを無効フラグメントクローンと記述することもできる。陳腐化クローンをプライマリフラグメントクローンとトランザクション的に一貫するように戻すプロセスはリフレッシュと呼ばれる。

６．クローンフラグメントの読み取り
ちょうど通常のテーブルまたはインデックスを読み出し、アクセスするように、クローンフラグメントをデータ抽出（テーブルアクセス）の目的で読み出すことができ、または参照（インデックスアクセス）するために読み出すことができる。本実施において、プライマリクローンフラグメントから読み出すことだけがユーザの作業負荷である。本制限を、システムにおける不必要なデッドロックを回避するためのメカニズムを簡略化する目的で使用することができる。しかしながら、デッドロックが問題ではないかまたは所与のシステムにおける他の手段を通して回避されるかのいずれかである場合、本制限を緩和することができる。

７．クローンフラグメントの更新
ユーザの作業負荷はプライマリクローンフラグメントを更新することであり、データベースシステムがこれらの変更を、同一トランザクション内のプライマリフラグメントに対応するセカンダリクローンに伝達および適用する。変更を伝達することは、プライマリクローンに適用した実質的には同一のＤＭＬ操作をセカンダリクローンに適用することを意味する。

図３はデータベースオブジェクトのクローンフラグメント１３１−１３９を更新する操作の例３００を示す。データベースの更新は、データの追加、削除および変更といった任意の種類の修正を含むことができる。データベースオブジェクトに関連付けた変更が判定されると、更新する必要があるデータベースオブジェクト内のフラグメントが識別される。識別したフラグメントに対応するプライマリクローンフラグメントを更新する。図に示すように、操作３０１−３０３はそれぞれ、プライマリクローンフラグメント１３１、１３５および１３９を更新するための操作である。プライマリクローンフラグメント１３１、１３５および１３９を更新した後、前記更新を対応するセカンダリクローンフラグメントに伝達する。図３において、操作３１１−３１３は、更新したプライマリクローンフラグメントに対応するセカンダリクローンフラグメントを更新するための操作である。

一般に、操作３０１−３０３および３１１−３１３は、ＤＭＬステートメントのセマンティクスを実施する挿入、更新および削除から成る標準的なデータベース操作を通して実施する。一貫性を実現するため、プライマリクローンフラグメントの更新操作とプライマリクローンフラグメントに対応するセカンダリフラグメントの更新操作とを、原子的な操作集合として構成することができる。

図４は、データベースオブジェクトに関連付けた陳腐化のクローンフラグメント１３３のリフレッシュ操作の例４００を示す。クローンフラグメントは、陳腐化フラグメントに対応するデータベースオブジェクトに関連付けた伝達更新操作を実行できない場合、陳腐である。例えば、クローンフラグメント１３３は、装置の故障、接続性の損失、システムの更新、等のような様々な理由により、更新不能である可能性がある。実用的であるためには、セカンダリクローンフラグメント１３３を、リフレッシュプロセスを通してプライマリクローンフラグメント１３１とトランザクション的に一貫するように戻さなければならないであろう。

クローンフラグメント１３３がオンラインに戻り、更新操作を実行可能になると、現在および過去の更新の全てを含む現在のプライマリクローンフラグメントに含まれるデータに基づいてクローンフラグメント１３３をリフレッシュする。例えば図４において、クローンリフレッシュ操作４１３を実行して、プライマリクローンフラグメント１３１内に含まれるデータでクローンフラグメント１３３をリフレッシュする。このように、クローンフラグメント１３３を、クローンフラグメント１３３が利用不能であった間に発生した更新でリフレッシュする。効率性のため、クローンリフレッシュ操作４１３を、陳腐化した行を削除するＳＱＬ削除操作と、プライマリからコピーされた新規の行を追加するＳＱＬ挿入動作とを通して実施することができる。上記の実施により、余分なプロセスを追加せずに、データベースシステムにおける通常のＳＱＬステートメントの実行が用いるものと同様な実行経路を経由してリフレッシュ操作を管理することができる。

プライマリクローンフラグメント１３１に対する更新操作４０１は、データベースオブジェクトに対する更新がプライマリクローンフラグメント１３１に対応するオブジェクト部分に影響するときに行う。更新を次いで、プライマリクローンフラグメント１３１に関連付けたセカンダリクローンフラグメントに伝達する。図４に示すように、セカンダリクローンフラグメント１３２をプライマリクローンフラグメント１３１に関連付けた操作４１１により更新する。クローンフラグメントを更新する必要性は、クローンフラグメントをリフレッシュしている間に生ずる可能性がある。例えば、クローンフラグメント１３３に対する更新は、クローンリフレッシュ操作４１３の実行中に生ずる可能性がある。更新操作４１２を、クローンリフレッシュ操作４１３の実行中にクローンフラグメント１３３上で実施することができる。一般に、ユーザの更新操作４１２はクローンリフレッシュ操作４１３よりも高優先度のデータベース操作である。更新操作４１２およびクローンリフレッシュ操作４１３を様々な方法で、および互いに対して様々なタイミングで実施することができる。例えば、更新が必要なとき、クローンフラグメント１３３上の更新操作４１２をクローンリフレッシュ４１３が継続する前に完了することができる。さらに、任意の所与の更新操作４１２に対するロックを原因とする任意の遅延の頻度および期間の両方を最小化するように、クローンリフレッシュ４１３を設計する。クローンリフレッシュは、短いインターバル時間だけロックを取得および保持する一連の小規模なトランザクションバッチとして実行することで、それを実現する。操作４１２は、操作４１３により既にリフレッシュした陳腐化クローン内の行またはエントリ、または陳腐化クローンがオフラインであった間にプライマリ内で不変であった行またはエントリのみを更新する。すなわち、陳腐化クローン内の無効な行を操作４１２が更新することを防ぐ。伝達した更新操作は、陳腐化クローン内の矛盾した行を最新と見せかけることはできない。行全体を更新４１２で伝達する実施においては、本制限を緩和することができる。しかしながら性能上の理由により、少数の列の値のみが変化したか否かに関わらず、全てのＤＭＬ操作に対して行全体を伝達する上記操作４１２は妨げられる傾向にある。新しい、最新の行を陳腐化クローンに導入することはクローンリフレッシュ操作４１３の責任である。

図４に示す陳腐化のクローンフラグメントをリフレッシュする操作４００により、データベースシステムは陳腐化のクローンフラグメントを、標準的なデータベース操作を用いてそのプライマリのオンライン状態を維持しつつ、対応するプライマリフラグメントとトランザクション的に一貫するように戻すことができる。ＤＭＬステートメントを表現するもののような標準的なデータベース操作を用いることでクローンリフレッシュを、データベースシステム上の余分だが標準的なＳＱＬステートメントの負荷として特別なプロセスを必要とせずに管理することができる。操作４００により、フラグメント全体を排他的にロックする必要なしに、およびリフレッシュプロセス中に発生しうる更新をキャッチアップする必要性によりリフレッシュプロセスを伸ばす必要なしに、陳腐化のクローンフラグメントのリフレッシュを可能とすることもできる。なぜならば、リフレッシュ操作４１３が進む間にこれらの更新が適用され続けるからである。操作４００によりさらに、陳腐化のセカンダリクローンフラグメントを効率的に更新してプライマリクローンフラグメントになる資格を迅速に与えうることが重要である。

１つの実施例において、クローンリフレッシュ操作４１３にはリフレッシュ操作から成る複数の小規模バッチが含まれる。小規模なリフレッシュ操作のバッチを用いることで、並行なユーザ作業負荷を長時間ブロックアウトすることを回避する。したがってリフレッシュプロセスをインクリメンタル形式で実施し、それによりプロセスはユーザの作業負荷とオンラインで共存することができる。

図４に示すクローンリフレッシュ操作４１３の複数インスタンスを、任意のデータベースオブジェクトの同一または異なるフラグメント内部の、異なる陳腐化のクローンフラグメントに対して並行に実行することができる。すなわち、上記リフレッシュ操作は互いに独立である。

図５はクローンフラグメント５００を識別するためのデータ構造の例５１１−５１４を示す。データ構造５００を用いて、データオブジェクトに対応するクローンフラグメントを識別する。本例では前記データ構造は、データベースに関連付けたテーブルに対応するクローンフラグメント５００を識別する。図５に示すように、クローンフラグメント５００に対する識別子はテーブル識別子５１１、パーティション識別子５１２、フラグメント識別子５１３およびクローン識別子５１４を含むことができる。テーブル識別子５１１により、クローンフラグメント５００が対応するデータベースオブジェクト（この場合、テーブル）を識別する。データベースオブジェクトをパーティションに分割して、便宜上または性能上の理由でデータを分離することができる。パーティション識別子５１２により、クローンフラグメント５００が対応するパーティションを識別する。

データベースオブジェクトを管理するデータベースシステムを構成してデータベースオブジェクトをフラグメントに自動的に分離し、フラグメントをクローン化する。フラグメント識別子５１３により、クローンフラグメント５００が対応するデータベースオブジェクトの特定のフラグメントを識別する。クローン識別子５１４により、データベースオブジェクトの特定のフラグメントに関連付けた複数のクローンフラグメントの中からクローンフラグメント５００を識別する。

図６はデータオブジェクトのクローンフラグメントにおけるレコード６００を特定するデータ構造の例６１１−６１２を示す。クローンフラグメントはデータベースのレコード（またはインデックスエントリ）を含むことができる。例えば、クローンフラグメントは、データベースに関連付けたテーブルの一部における行として具体化されるレコードを含むことができる。レコード６００内のデータ構造６１１−６１２により、クローンフラグメント内のレコード６００およびレコードの更新状態を識別することができる。

図６に示すようにレコード６００はクローンレコード識別子６１１およびクローン更新識別子６１２を含むことができる。クローンレコード識別子６１１により、対応するテーブルまたはインデックス内部でレコード６００を一意に識別する。インデックスレコード内のクローンレコード識別子は、対応するクローンデータフラグメントからの更新により伝達される。ユーザ定義の一意なキーをクローンレコード識別子として使用したり、またはクローンレコード識別子としての役割を果たすのに十分な程度に複合キーが一意であるようにシステム定義の一意なキーを追加（またはユーザ定義のキーを補完）することができる、例えば、更なる一意性を与える目的でフラグメント識別子をキーに追加することができる。クローン更新識別子によりレコード６００の更新状態を識別する。本実施例において、クローンレコード識別子６１１は所与のテーブルのコンテクスト内部で一意（特有）であるべきである。クローン更新識別子６１２により、所与のデータベースオブジェクトに対して長時間、同一のクローンレコード識別子６１１を有する他レコードの更新状態と比較したレコードの更新状態だけを一意に識別する。

1つの実施形態において、データベースシステムにはプライマリクローンフラグメントとセカンダリクローンフラグメントが含まれ、クローンフラグメントには行が含まれる。クローンレコード識別子６１１およびクローン更新識別子６１２の両方をクローンフラグメントの行における列として含めることができる。クローンレコード識別子６１１およびクローン更新識別子６１２の列をセカンダリクローンフラグメントに含めることができ、セカンダリクローンフラグメントがトランザクション的に一貫しているとき（矛盾がないとき）、クローンレコード識別子６１１およびクローン更新識別子６１２の列はプライマリクローンフラグメントの場合と同一の値を含むことができる。したがってクローンレコード識別子６１１によりプライマリおよびセカンダリクローンフラグメントの間の行をマッピングすることができ、クローン更新識別子６１２により行に矛盾がないか否かを検証することができる。

陳腐化のクローンフラグメントに対するリフレッシュプロセスは、クローンレコード識別子（ＣＲＩＤ）とクローン更新識別子（ＣＵＩＤ）とを使用してクローンフラグメント内の特定のレコードをリフレッシュするべき否かを判定する。例えば、陳腐化のクローンフラグメント内のレコードはＣＲＩＤ＝ｘかつＣＵＩＤ＝ｙを含むことができる。陳腐化のクローンフラグメントに関連付けたプライマリクローンフラグメント内の対応するレコードは、ＣＲＩＤ＝ｘかつＣＵＩＤ＝ｚを含むことができる。リフレッシュプロセスはＣＲＩＤを使用して陳腐化のクローンフラグメント内のそれぞれのレコードを識別し、存在すればプライマリクローンフラグメント内の対応するレコードを発見する。リフレッシュプロセスは次いで、陳腐化のクローンフラグメント内のそれぞれの上記レコードを、存在すればプライマリクローンフラグメント内の対応するレコードと比較して陳腐化のクローンフラグメント内のレコードを更新すべきか否かを判定する。

データベースオブジェクトのフラグメントはデータフラグメント、インデックスフラグメント、等のような任意のフラグメントであることができる。インデックスフラグメントに対し、インデックス内のそれぞれの行はそのデータフラグメント識別子をインデックスのキーの一部として記憶することで、行がどこから来たかを指定する。インデックス自体はベーステーブルフラグメントのどのクローンが現在プライマリであるかを知る必要はない。所与のフラグメントに対し1つのプライマリクローンフラグメントが存在するので、インデックスレコードを任意の所与の時点でアクセスの目的で指定フラグメントにマップすることができる。したがってインデックスフラグメントは、異なるテーブルフラグメントを参照する互いに素なセカンダリ行セット（またはインデックスエントリ）の共存集合を含むことができる。それぞれの上記セカンダリ行セットを同一インデックスフラグメントにおいて他のものから別々に扱う限り、上で概観した仮定および技術を継続して適用する。実施に関して、任意の特定のベーステーブルフラグメントに対応するインデックスフラグメント内の行をロックすることで、（そのベーステーブルフラグメントに対応しない）インデックスフラグメント内の他の行に対するロックを発生させるべきではない。

インデックスフラグメントをデータフラグメントと同様にクローン化することができる。更新を伝達させる目的で、クローンインデックスフラグメントを同一のベーステーブルフラグメント集合上の追加インデックスとして扱う。すなわち、全てのクローンインデックスフラグメントに対する更新を、クローンインデックスフラグメントの構築基盤であるベーステーブルのプライマリクローンデータフラグメントから直接伝達する。或るインデックスフラグメントから別のものへ更新を伝達することが可能である一方、本プロセスは追加の待機ステップを導入することができる。所与のデータフラグメント内のレコードに対応する所与のインデックスフラグメント内のインデックスエントリ集合をセカンダリ行セットとして扱う場合、対応するプライマリ行セットはベーステーブルフラグメントと実質的には同一である。インデックスフラグメントのクローンにおけるそれぞれのセカンダリ行セットはしたがって、更新を伝達する目的で同一のクローン内部の他のセカンダリ行セットすべてから独立である。

図７はクローンインデックスフラグメントとクローンデータフラグメントとを更新するためのプロセスの例を示す。上述のようにデータフラグメントの最新（または現在）のセカンダリクローンフラグメントは所与のデータフラグメントに対してプライマリクローンフラグメントと実質的には同一である。同様に、インデックスフラグメントの最新のセカンダリクローンフラグメントはそのインデックスフラグメントに対してプライマリクローンフラグメントと実質的には同一である。クローンインデックスフラグメントは、複数のデータフラグメント内のレコードを参照するインデックスエントリを含むことができる。したがって、クローンインデックスフラグメントは伝達した更新を、複数のクローンデータフラグメントから受け取ることができる。

図７における例はインデックスフラグメントＩ１を示す。インデックスフラグメントＩ１は、二つの異なるデータフラグメントＤ１およびＤ２内のレコードを参照するインデックスエントリを含む。本例では、プライマリクローンインデックスフラグメントＩ１．ａ７０５とセカンダリクローンインデックスフラグメントＩ１．ｂ７０６との両方は、伝達した更新を、プライマリクローンデータフラグメントＤ１．ａ７０２とプライマリクローンデータフラグメントＤ２．ａ７０３との両方から直接受け取る。

データフラグメントとインデックスフラグメントの間のマッピングは、物理データベース設計と呼ばれる標準的なデータベース操作の結果を表す。テーブルの任意の所与のインデックス列に対して、列の値をインデックスのパーティション定義およびフラグメント定義に基づいて１つまたは複数のインデックスフラグメントに離散的にマップすることができる。テーブルおよびインデックスに対するパーティション定義は、例えば値の範囲、値のハッシュ、またはラウンドロビン割当てによりレコードを集合に分割する任意の従来のデータベース方法を指定することができる。システムが定義したフラグメント定義を、テーブルまたはインデックスのキー上でのハッシュにより実現することができる。しかしながら、ハッシュベースのフラグメント化が、非常に不均一にデータが偏在するようにフラグメントに対して行（またはインデックスエントリ）を埋める場合、フラグメントに対する行のラウンドロビン割当てを使用することができる。

クローンインデックスフラグメントが陳腐化し、リフレッシュする必要があるとき、リフレッシュを実現する２つの可能な方法がある。プライマリクローンインデックスフラグメントが存在する場合、陳腐化セカンダリクローンインデックスフラグメントをプライマリクローンインデックスフラグメントから直接リフレッシュすることができる。または陳腐化セカンダリクローンインデックスフラグメントを、インデックステーブルのプライマリクローンデータフラグメントの集合から直接リフレッシュすることができる。後者の場合、キー値がリフレッシュされているインデックスフラグメントにマップするような、プライマリクローンデータフラグメント内のレコードのみをリフレッシュにおいて使用する。

実施例において、クローン更新識別子（ＣＵＩＤ）値をテーブル毎ベースで維持することができる。すなわち、所与のプライマリクローンフラグメントを更新するＤＭＬステートメントに対してＣＵＩＤ値をそのフラグメントテーブルに固有なメタデータから読み出す。そのステートメントにより更新されるレコードにそのＣＵＩＤ値を割り当てる。これらレコードに対する更新をセカンダリクローンフラグメントに伝達するとき、割り当てた新規のＣＵＩＤ値も伝達する。

本実施例において、ＣＵＩＤ値は長時間所与のテーブルに対し一意である。現在のＣＵＩＤ値は、所与のテーブルを記述するメタデータ内でトランザクション的に存続する。
ＣＵＩＤ値が最大値から最小値に巻き込む点に達する時点で、様々な技術を使用してＣＵＩＤ値を一貫した最小値にリセットすることができる。ＣＵＩＤ値のバイト範囲（例えば、６バイト）が与えられると、この場合が時系列で生じる可能性がある。ＣＵＩＤ値をリセットするための１つの単純な技術はテーブル上で排他的ロックを行い、そのテーブルのプライマリクローンフラグメントにおける全レコードのＣＵＩＤ値を最小のＣＵＩＤ値にリセットすることである。次いで、通常の更新伝達メカニズムがセカンダリクローンフラグメント内のＣＵＩＤ値を効率的にリセットする。

テーブルに対するＣＵＩＤ値はテーブルのフラグメントがオフラインになる度に増加する。本実施は図１２と関連させて後述する。

他のＣＵＩＤ割当てポリシーが可能であるが、それぞれはクローンリフレッシュに対する基本的技術に影響を及ぼす可能性を有する。例えばトランザクションＩＤをＣＵＩＤ値のベースとして使用できるが、更新の伝達とクローンリフレッシュの正確な相互作用とを保証するために、幾分か有利でないクローンリフレッシュ技術が必要である。具体的には、伝達待機ステップ（後述）において、基本クローンリフレッシュ技術は、全ての現在のＤＭＬステートメントの完了を単に待機するのではなく、現在アクティブなトランザクションの全ての完了を待機しなければならない。

一般にＣＵＩＤ値の管理技術を、その技術が以下の要件を満たす場合に実施することができる。

ａ）フラグメント内部で用いる所与のＣＲＩＤ値に対して、トランザクション的に一貫したセカンダリクローンフラグメント内のＣＲＩＤ値により特定（識別）される全てのレコードが、プライマリクローンフラグメント内のそのＣＲＩＤ値により特定されるレコード内のＣＵＩＤ値と同じであるＣＵＩＤ値を有さなければならない。

ｂ）所与のフラグメントに対し、陳腐化のセカンダリクローンフラグメント（リフレッシュ前）内およびプライマリクローンフラグメント内にＣＲＩＤが発見される場合、前記ＣＵＩＤ値はセカンダリクローンフラグメントが陳腐化してから行がプライマリクローンフラグメント内で更新されていない場合にのみ同一であることができる。

クローンフラグメントを更新するＤＭＬステートメントの例を以下で示す。ＤＭＬステートメントの例には、ＣＵＩＤ値３を用いて更新されるＳａｌｅｓ．２００４．１．ａ（クローンレコード識別子（ＣＲＩＤ）：５＆３）内の２つのレコードが含まれる。

ｓａｌｅｓ．２００４．１．ａプライマリクローンフラグメントの例を表１に示す。

プライマリクローンフラグメントＳａｌｅｓ．２００４．１．ａを更新した後、これらの更新を表２に示すようにセカンダリクローンフラグメントＳａｌｅｓ．２００４．１．ｂに伝達および適用する。

所与の時点で、利用可能なフラグメントは１つのプライマリクローンフラグメント（潜在的なクローンリフレッシュ源）と、Ｎ個のセカンダリクローン（潜在的なリフレッシュ対象）とを有する。行がプライマリクローンフラグメント内の対応する行とトランザクション的に一貫しないセカンダリクローンフラグメントは、無効または陳腐化したクローンフラグメントである。陳腐化のクローンフラグメント内部の行（レコードまたはインデックスエントリ）は、以下の状態例の一つにあることができる。プライマリ行という用語はプライマリクローンフラグメント内の行を指す。陳腐化のクローンフラグメント内部の行は以下であることができる。

１．矛盾がない
陳腐化のセカンダリクローンフラグメントがオフラインである間、プライマリ行は変化しない。または、リフレッシュプロセスが既に、陳腐化のセカンダリクローンフラグメント内の行を対応するプライマリ行と一貫するように更新している。セカンダリクローンフラグメント内の一貫した行は、同一のＣＲＩＤ値およびＣＵＩＤ値を有するプライマリクローンフラグメント内の行に対応する。

２．矛盾している
陳腐化のセカンダリクローンフラグメントがオフラインである間にプライマリ行が更新される。陳腐化のセカンダリクローンフラグメント内の矛盾した行は、同一のＣＲＩＤ値と異なるＣＵＩＤ値とを有するプライマリクローンフラグメント内の行に対応する。

３．紛失している
陳腐化のセカンダリクローンフラグメントがオフラインである間に新しいプライマリ行が生成される。陳腐化のセカンダリクローンフラグメント内の紛失行は、同じＣＲＩＤ値を有する対応行が陳腐化のセカンダリクローンフラグメント内に存在しないようなＣＲＩＤ値を有するプライマリ行が存在する場合を示す。

４．エキストラ
陳腐化のセカンダリクローンフラグメントがオフラインである間にプライマリ行が削除される。陳腐化のセカンダリクローンフラグメント内のエキストラ行は、同じＣＲＩＤ値を有する対応行がプライマリローンフラグメント内に存在しないようなＣＲＩＤ値を有する行が陳腐化のセカンダリクローンフラグメント内に存在する場合を示す。

一貫していない陳腐化クローンの行のＣＲＩＤを、リフレッシュ技術の初期段階で一時ファイル（ＳｔａｌｅＣｌｏｎｅＣＲＩＤｓ）に捕捉する。その一時ファイルは、リフレッシュが必要なレコード、例えば矛盾したレコード、紛失したレコード、またはエキストラレコードを識別する値を有する列Ｓｔａｌｅ＿ＣＵＩＤを有する。一時ファイル（ＳｔａｌｅＣｌｏｎｅＣＲＩＤｓ）の１つの実施において、Ｂａｔｃｈ＿ＩＤ列を追加して、ＳｔａｌｅＣｌｏｎｅＣＲＩＤｓ内部の離散的な行集合のアクセス処理を多数の小規模でインクリメンタルなバッチ操作に簡略化する値で初期化することができる。

図８は、陳腐化のクローンフラグメントをリフレッシュする際の状態の推移を示す。図８に示すように、セカンダリクローンフラグメント８０５はオフライン状態からリフレッシュ前状態に進む。陳腐化クローンがリフレッシュ前状態にある間に、リフレッシュ操作の性能を最適化する目的で、操作を陳腐化クローンに適用することができる。次に、セカンダリクローンフラグメント８０５をオンラインと見なし、リフレッシュ中状態に置く。リフレッシュしている間、陳腐化のクローンフラグメントはリフレッシュ中状態に留まる。本状態において、セカンダリクローンフラグメント８０５をプライマリクローンフラグメント８０３から伝達した変更により更新することができる。

リフレッシュプロセスを実施した後、セカンダリクローンフラグメント８０５はカレント状態に入る。セカンダリクローンフラグメント８０５がカレント状態に入ると、セカンダリクローンフラグメント８０５はプライマリになる資格を得る。

図１１はデータベースオブジェクトの陳腐化のクローンフラグメントをリフレッシュするリフレッシュプロセスの例１１００を示す。
０．陳腐化クローンのオンライン化 １１５０：
ブロック１１０２で、陳腐化クローンをクローンリフレッシュの対象とするとき（例えば、オフラインであった後に陳腐化クローンがシステムに対してアクセス可能となるとき）、陳腐化クローンをリフレッシュ前状態に置く。次に、ブロック１１０４で、クローンフラグメントがリフレッシュ前状態にある間にプリパス最適化を実行することができる。上記最適化を、残りのリフレッシュプロセス１１００の性能を最適化するように設計する。

１．更新の伝達を有効化 １１６０：
ブロック１１０６で、陳腐化のクローンフラグメントをリフレッシュ中状態にあるとしてマークを付ける。次いでブロック１１０８で、プライマリクローンフラグメントから陳腐化のクローンフラグメントへの更新の伝達が可能となる。更新の伝達を陳腐化のクローンフラグメントに選択的に適用することができる。例えば、更新の伝達を、既にリフレッシュしたレコードまたはリフレッシュが不必要と判定できるレコードに対してのみ実施する。すなわち、更新の伝達を、所与のＣＲＩＤ値に対するＣＵＩＤ値がプライマリクローンフラグメント内の対応レコードのものとマッチするレコードに対してのみ適用する。別の実施例において、全体の行の値を更新により伝達する場合、クローンフラグメントをリフレッシュしている間に更新を陳腐化のクローンフラグメントの任意のレコードに伝達および適用することができる。

２．伝達を待機 １１１０：
次のブロック１１１０で、リフレッシュプロセス１１００は、プライマリクローンフラグメント上の全てのアクティブなＤＭＬステートメントが更新を陳腐化のクローンフラグメントに伝達開始するまで待機する（または、プライマリに対する全ての後続のＤＭＬが一貫して陳腐化のクローンフラグメントに伝達されることを保証する等価なメカニズムを使用する）。リフレッシュ中状態にある陳腐化のクローンフラグメントを含む全てのオンラインなクローンフラグメントに更新が伝達されることを任意の新規に起動したＤＭＬステートメントは保証されるので、全ての現在実行中のＤＭＬステートメントが完了することを待機することでブロック１１１０を実現することができる。

３．陳腐化クローンのＣＲＩＤの構築 １１１２：
ブロック１１１２で、コミット済み読み込みモードでＳｔａｌｅＣｌｏｎｅＣＲＩＤｓ一時テーブルを生成および初期化する。ＳｔａｌｅＣｌｏｎｅＣＲＩＤｓは陳腐化のクローンフラグメント内の最新でない行（矛盾行、紛失行およびエキストラ行）の全てを網羅することを保証されるが、コミット済み読み込み隔離モードで実行されるため、ＳｔａｌｅＣｌｏｎｅＣＲＩＤｓは実際には一貫しているＣＲＩＤｓの行を含むことがありうる。ＳｔａｌｅＣｌｏｎｅＣＲＩＤｓ一時テーブルを埋める１つの実施において、プライマリおよび陳腐化のクローンフラグメントの対応クローンレコード識別子（ｃｒｉｄ）列の上でＳＱＬ外部結合操作を使用することができる。この場合、対応するクローン更新識別子（ｃｕｉｄ）列の値はマッチしないかまたはヌルである。以下の擬似コードは上記の外部結合の１つの例を与える。本例では、Ｂａｔｃｈ＿Ｉｄ列をＳｔａｌｅＣｌｏｎｅＣＲＩＤｓテーブルに追加して、所与のサイズのリフレッシュバッチを生成するために使用しうる基盤の例を与えることに留意されたい。
SELECT
(case when (p.crid is not null) then p.crid else c.crid end) as crid,
IDENTITY(int, 1, 1) AS Batch_Id
Into
StaleCloneCRIDs
FROM
(select crid, cuid from primary_fragment_clone) as p
FULL OUTER JOIN
(select crid, cuid from stale_fragment_clone) as c
ON (p.crid = c.crid)
Where
p.cuid <> c.cuid OR
(p.crid is null) OR
(c.crid is null)

４．カレント化 １１７０：
図１７は陳腐化クローンをカレントにするプロセスの例１１７０を示す。プロセス１１７０は図１１に示すリフレッシュプロセスの例１１００の一部である。

ＳｔａｌｅＣｌｏｎｅＣＲＩＤｓ一時テーブルからのＳｔａｌｅ＿ＣＲＩＤｓの第１の小規模バッチ（ＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓ）をブロック１１１４で初期化する。ブロック１１１４の１例においてＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓを、Ｂａｔｃｈ＿Ｉｄ列の値がパラメータ値＠ｓｔａｒｔ＿Ｉｄおよび＠ｅｎｄ＿Ｉｄの間にあるＳｔａｌｅＣｌｏｎｅＣＲＩＤｓ一時テーブル内の行のＣＲＩＤｓであると定義する。実際の＠ｓｔａｒｔ＿Ｉｄの初期値を、ＳｔａｌｅＣｌｏｎｅＣＲＩＤｓ一時テーブルにおける最小のＢａｔｃｈ＿Ｉｄ列の値のものに設定する（例えば、Ｂａｔｃｈ＿ＩｄをＩＤＥＮＴＩＴＹ関数によりシード値１に初期化する）。実際の＠ｅｎｄ＿Ｉｄの初期値を次いで所望のＢａｔｃｈＳｉｚｅの値に設定する。ＢａｔｃｈＳｉｚｅの値を変化させて異なるリフレッシュ目標を実現することができる。小さい値のＢａｔｃｈＳｉｚｅにより、進行中のユーザ作業負荷に更なる並列性を与えることができる。ＢａｔｃｈＳｉｚｅに大きい値を与えると、より良好なリフレッシュ性能が得られる可能性がある。判定ブロック１１１６で、ＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓが空か否かを判定するチェックを行う。ＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓが空の場合、リフレッシュプロセス１１００はブロック１１１８に進み、リフレッシュしたクローンフラグメントにカレント状態にあるとしてマークを付ける。カレント状態にあるセカンダリクローンフラグメントは、プライマリクローンフラグメントになる資格を有する。次いで、プロセス１１００はブロック１１２０で終了する。

判定ブロック１１１６で、ＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓが空でないと分かった場合、
ａ．ブロック１１１２で、新規トランザクションを反復読み取りモードで開始する。
ｂ．ブロック１１２４で、読取りロックをＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓにより識別されるプライマリクローンフラグメント内の行に設定する。本ステップは機能的には必要でないが、更新の伝達による潜在的デッドロックを回避する目的に対しては重要である。
ｃ．ブロック１１２６で、ＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓ内のＣＲＩＤｓにより識別される陳腐化のクローンフラグメント内の行を削除する。以下の擬似コードは、旧式の行を陳腐化のクローンフラグメントから削除する１つの実施例を示す。実際の＠ｓｔａｒｔ＿Ｉｄおよび＠ｅｎｄ＿Ｉｄの値は（ブロック１１１４またはブロック１１３２での）カレント化プロセス１１７０において前に設定したものである。
delete from stale_fragment_clone
where exists (select * from StaleCloneCRIDs as s
where stale_fragment_clone.crid = s.crid and
(s.Batch_Id between @start_Id and @end_Id))
ｄ．ブロック１１２８で、ＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓにより識別される行がプライマリクローンから陳腐化クローンに挿入される。新規行をプライマリフラグメントから陳腐化のクローンフラグメントに挿入する１つの実施例の擬似コードの記述例は以下の通りである。実際の＠ｓｔａｒｔ＿Ｉｄおよび＠ｅｎｄ＿Ｉｄの値は（ブロック１１１４またはブロック１１３２での）カレント化プロセス１１７０において前に設定したものである。
insert into stale_fragment_clone
select * from primary_fragment_clone as p
where exists
(select * from StaleCloneCRIDs as s
Where p.crid = s.crid and
(s.Batch_Id between @start_Id and @end_Id))
ｅ．ブロック１１３０で、トランザクションをコミットする。
ｆ．ブロック１１３２で、ＳｔａｌｅＣｌｏｎｅＣＲＩＤｓ一時テーブルからのＣＲＩＤｓの次のバッチを次のＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓとして識別する。＠ｓｔａｒｔ＿Ｉｄおよび＠ｅｎｄ＿Ｉｄに使用される実際の値はそれぞれ、所望のＢａｔｃｈＳｉｚｅの値だけ増加する。
ｇ．リフレッシュプロセス１１００は次いでブロック１１１６に戻る。
ＢａｔｃｈＯｆＳｔａｌｅＣＲＩＤｓの処理中にエラーが発生する場合、トランザクションを中断し、リフレッシュプロセス１１００は終了する。
リフレッシュプロセス１１００が無事に完了しない場合、陳腐化のクローンフラグメントはリフレッシュ前状態に移動する（または、陳腐化のクローンフラグメントへのアクセスが完全に失われた場合は、オフライン状態に戻る）。

クローンフラグメントリフレッシュ技術の例は、既存の作業負荷との衝突を小規模な短いトランザクションを通して最小化しつつ継続して前進する。上で議論したクローンリフレッシュ技術を、ちょうどそれをクローンデータフラグメントに適用するように、クローンインデックスフラグメントに適用することもできる。１つの実施例において、陳腐化セカンダリクローンインデックスフラグメントを対応するプライマリクローンインデックスフラグメントからリフレッシュすることができる。

ベーステーブルフラグメントに対するクローンデータフラグメントの全てがオフラインになる場合、そのフラグメントに対応する全てのインデックスフラグメント内の行も同様に効率的にオフラインになる。ベーステーブルプライマリクローンフラグメントがオフラインに戻ると、リフレッシュ技術は任意の陳腐化テーブルクローンデータフラグメントおよび任意の陳腐化クローンインデックスフラグメントに影響を及ぼす。その時点で、リフレッシュされている陳腐化セカンダリクローンインデックスとデータフラグメントとに更新動作を伝達する。同様に、インデックスフラグメントに対する全てのクローンフラグメントがオフラインになる場合、そのインデックスフラグメントを用いるインデックスアクセスパスはオフラインになる。陳腐化クローンインデックスフラグメントを、それが再度アクセス可能になるときに、クローンリフレッシュを通して復元する。１つの実施例において、陳腐化クローンインデックスフラグメントをベーステーブルフラグメントの行を用いて直接リフレッシュする。しかしながら、陳腐化したセカンダリクローンインデックスフラグメントを、対応するプライマリクローンインデックスフラグメントからリフレッシュすることもできる。

上述したデータベースフラグメントのクローン化および管理メカニズムの性能を、後述する最適化の例により向上させることができる。

ａ）クローンリフレッシュのリフレッシュ前ステップ
クローンリフレッシュ技術を実行する前に、（図１１のプロセス１１００で説明した）完全にコミット済み読み込みモードで同じリフレッシュ技術を実行することができる（例えば、リフレッシュ前ステップ中に実行されると、プロセス１１００のブロック１１２２はコミット済み読み込みモードでトランザクションを開始する）。多数の並列更新がない場合、このプリパスによりクローンフラグメント内の大多数の行を除去する。その際、少数の矛盾が残り、もう少し多くの矛盾が導入される可能性がある。プリパスを行った後に、反復読み取り可能モードでの厳密なリフレッシュ段階（図１７のプロセス１１７０）がより高速に動作することがその狙いである。（バッチが少ないので）全体の短い期間に対しロックされる行は殆ど無く、したがってシステムにおける並行性が向上する。

プライマリクローンフラグメントがリフレッシュを必要とする複数のセカンダリクローンフラグメントを有するとき、全てのセカンダリクローンフラグメント上のリフレッシュパスを互いに独立に実行することができる。並列度の程度を、クローンフラグメントがオンラインに戻る速度に基づいて制御することができ、システムに課すべき並行性の量とトレードオフすることができる。

ｂ）セカンダリクローンフラグメントの障害に対するトランザクション弾力性
セカンダリクローンフラグメントに対する更新の伝達がシステム上の理由で失敗するとき、そのクローンフラグメントをオフラインとしてマーク付けする。進行中トランザクションの影響をプライマリクローンフラグメントの行に直接保存する。以前のトランザクションの影響を保存する目的に対し、保留中作業の待ち行列を追加する必要はない。エラー処理の便宜上、更新が伝達されていたステートメントをロールバックすることができる。しかしながら、故障したセカンダリクローンフラグメントに対する更新の伝達の失敗がステートメントの実行に対してその他の副作用を及ぼさない場合は、これは必要ではない。そのステートメントに対する更新はプライマリクローンフラグメントに対して既に適用され、プライマリクローンフラグメントに既に保存されているであろう。

ｃ）プライマリクローンフラグメントの障害に対するトランザクション弾力性
プライマリクローンフラグメントに障害が発生するとき、新規のプライマリとして即座に指定可能なオンラインの一貫したセカンダリクローンフラグメントがある場合、そのクローンフラグメントにアクセスするユーザトランザクションを中断する必要はない。しかしながら、障害が発生したプライマリクローンフラグメントに現在アクセスする任意のステートメントはロールバックされるであろう。

ｄ）クローンリフレッシュ弾力性
セカンダリクローンフラグメントにおけるレコードに対するクローンリフレッシュ更新がシステム上の理由で失敗する場合、クローンリフレッシュパスは最初から再開することができ、現在アクティブなカレント化バッチを再試行するかまたはＳｔａｌｅＣｌｏｎｅＣＲＩＤｓのカレント化処理全体を繰り返すことができる。

図９は、クローンデータベースフラグメントを有するデータベースシステムの例９００である。データベースシステム９００は一般に、作業負荷を分散しデータオブジェクトのアクセスに対する信頼性のある可用性と負荷分散とを与える、複数のコンピューティング装置９１１−９１４を含む。データベース例の内部のオブジェクトをクローンフラグメントに分割する。クローンフラグメントはコンピューティング装置９１１−９１４の間で分割する。このように、コンピューティング装置９１１−９１４は、データベース例におけるオブジェクトの異なる部分上で並列に操作を実施することができる。コンピューティング装置９１１−９１４をＳＱＬサーバのような任意の種類のデータベースシステムで構成することができる。

図に示すように、コンピューティング装置９１１−９１４はプライマリクローンフラグメント９２３−９２６とセカンダリクローンフラグメント９３４−９３７を含むことができる。１つの実施形態において、プライマリクローンフラグメント９２３−９２６をコンピューティング装置９１１−９１４により使用して、データベースオブジェクト、問合せ、レポート、等の追加、削除、または修正といった生産性関連の作業を実施する。セカンダリクローンフラグメント９３４−９３７はプライマリクローンフラグメント９２３−９２６のバックアップとしての役割を果たす。

一般に、それぞれのコンピューティング装置内のプライマリクローンフラグメントは前記装置内のセカンダリクローンフラグメントに対応しない。コンピューティング装置９１１−９１４の１つに障害が発生した場合、別のコンピューティング装置が、障害が発生した装置が管理するプライマリフラグメントに対応するセカンダリクローンフラグメントを用いて動作を引き継ぐことができる。このように、データベースシステム９００は、データベースオブジェクトのフラグメントはそのフラグメントの少なくとも１つのクローンが利用可能である限りアクセス可能であることを、保証することができる。

別の実施形態において、コンピューティング装置９１１−９１４は重複したプライマリクローンフラグメントを含むことができる。このように、複数のコンピューティング装置は問合せのような操作をデータベースオブジェクトの同一部分上で実施することができる。

図１０は、データベースオブジェクトを更新するプロセスの例１０００を示す。データベースオブジェクトは、テーブル、インデックス等のようなデータベース全体のデータまたはデータベースの一部のデータを含むことができる。更新は、１つまたは複数のフラグメントの修正を含むことができる。ブロック１００１で、更新の影響を受けるデータベースオブジェクトのフラグメントを識別し、これらはプロセス１０００に対してローカルなデータ構造であるＳｅｔＯｆＦｒａｇｍｅｎｔｓという名前の集合を形成する。本集合内のそれぞれの要素に最初は未処理としてマークを付ける（これは実際のフラグメントを変更せず、ローカルデータ構造内の要素のみを変更する）。プロセス１０００は判定ブロック１００２に続き、ＳｅｔＯｆＦｒａｇｍｅｎｔｓ内に未処理の要素がまだあるか否かを判定する。未処理の要素がなければ、プロセス１０００は終了ブロック１０１２に続き、プロセスが終了する。

判定ブロック１００２に戻ると、集合ＳｅｔＯｆＦｒａｇｍｅｎｔｓ内に未処理の要素がまだある場合、プロセス１０００はブロック１００３に続き、未処理の要素を集合ＳｅｔＯｆＦｒａｇｍｅｎｔｓから取得し、この要素が次に更新すべきフラグメントを表す。ブロック１００４で、対応するプライマリクローンフラグメントを判定し、更新する必要があるプライマリクローンフラグメントのレコード集合を識別し、プロセス１０００に対してローカルなデータ構造であるＳｅｔＯｆＲｅｃｏｒｄｓという名前の集合を形成する。本集合内のそれぞれの要素に最初は未処理としてマークを付ける（これは実際のレコードを変更せず、ローカルデータ構造内の要素のみを変更する）。判定ブロック１００５で、集合ＳｅｔＯｆＲｅｃｏｒｄｓ内に未処理の要素がまだあるか否かを判定する。未処理の要素がなければ、プロセス１０００はブロック１００６に続き、集合ＳｅｔＯｆＦｒａｇｍｅｎｔｓ内のカレント要素に処理済としてマークを付ける（これは実際のフラグメントを変更せず、ローカルデータ構造内の要素のみを変更する）。プロセス１０００は次いで判定ブロック１００２に戻る。

判定ブロック１００５に戻ると、集合ＳｅｔＯｆＲｅｃｏｒｄｓ内に未処理の要素が残っている場合、プロセス１０００はブロック１００７に続き、未処理の要素を集合ＳｅｔＯｆＲｅｃｏｒｄｓから取得する。その要素が次に更新すべきレコードを表す。ブロック１００８で、前記レコードに対してＣＵＩＤを取得する（ＣＵＩＤ値の維持および割り当ては、図１２および１３のコンテクストで本文書の他所でさらに説明する）。

プロセス１０００はブロック１００９に続き、レコードを新規値と新規ＣＵＩＤで更新する。ブロック１０１０で、古いＣＵＩＤおよび（新規ＣＵＩＤを含む）更新レコードを全てのセカンダリクローンデータフラグメント、および本レコードのコピーを含む全てのクローンインデックスフラグメント（プライマリ、セカンダリ両方）に伝達する。図１６は本ブロックをさらに詳細に説明する。

更新を伝達および適用した後、プロセス１０００はブロック１０１１に続き、集合ＳｅｔＯｆＲｅｃｏｒｄｓ内のカレント要素に処理済としてマークを付ける（これは実際のレコードを変更せず、ローカルデータ構造内の要素のみを変更する）。プロセス１０００は次いで判定ブロック１００５に戻る。

図１２は、クローン更新識別子（ＣＵＩＤｓ）を修正するプロセスの例１２００を示す。プロセス１２００を、データベースのテーブルのようなそれぞれのデータベースオブジェクトに対し実施することができる。ブロック１２０３で、プロセス１２００はテーブルに関連付けたクローンフラグメントの構成に対する変化を待機する。判定ブロック１２０５で、クローンフラグメントが利用不能となったか否かの判定を行う。クローンフラグメントが全て利用可能である場合、プロセス１２００はブロック１２０３で待機状態に戻る。

判定ブロック１２０５に戻ると、クローンフラグメントが利用できなくなった場合、プロセス１２００はブロック１２０７に移動して、テーブルのＣＵＩＤ値が増加する。ブロック１２０９で、テーブルの新規ＣＵＩＤ値はトランザクション的に存続する。

図１３は、図１２に示すプロセス１２００にしたがって配分したプロセスにＣＵＩＤ値を割り当てるプロセスの例１３００を示す。データベースシステムを構成して、データベース上で動作するステートメントに対してプロセス１３００を実行することができる。ブロック１３０２で、プロセスはデータベースに対して新規のステートメントを実行する準備を行う。判定ブロック１３０４で、新規ステートメントがＤＭＬステートメントか否かを判定する。ＤＭＬステートメントには一般にデータベース内の項目の挿入、削除および修正のような操作が含まれる。ステートメントがＤＭＬステートメントでない場合、プロセス１３００はブロック１３２０に行き、非ＤＭＬステートメントをデータベースに対して実行する。次いで、プロセスはブロック１３０２に戻る。

判定ブロック１３０４に戻ると、ステートメントがＤＭＬステートメントである場合、プロセス１３００はブロック１３０６で継続し、更新されているデータベースのテーブルに対するＣＵＩＤ値を読み出す。ブロック１３０８で、ＣＵＩＤ値がＤＭＬステートメントと関連付けられる。ブロック１３１０で、ＣＵＩＤ値を、ＤＭＬステートメントにより更新した全てのプライマリクローンフラグメントの各行に記憶する。ブロック１３１２で、ＣＵＩＤ値を、ＤＭＬステートメントの更新の伝達により影響を受けたクローンフラグメント内のそれぞれの行またはインデックスエントリに記憶する。ＣＵＩＤ値を前記更新でクローンデータおよびインデックスフラグメントの両方に対して伝達することができる。ＣＵＩＤ値に対する伝達経路の例を図１４に関連させて説明する。ＣＵＩＤ値が伝達されると、プロセス１３００はブロック１３０２に戻る。

図１４は、ＣＵＩＤ値に対する伝達経路の例を示す。図１４において、プライマリクローンデータフラグメント１４０３はＤＭＬステートメントに含まれる更新を実施する。上述のように、ＤＭＬステートメントに関連付けたＣＵＩＤ値を、プライマリクローンデータフラグメント１４０３内のＤＭＬステートメントにより更新される各行に記憶する。プライマリクローンデータフラグメント１４０３はＣＵＩＤ値を更新とともに経路１４１１を通ってセカンダリクローンデータフラグメント１４０５に伝達することができる。特に、ＤＭＬステートメントに関連付けたＣＵＩＤ値を、更新の伝達により影響を受けたそれぞれの行に割り当てる。１つの実施において、ＣＵＩＤ値をプライマリクローンインデックスフラグメント１４０７およびセカンダリクローンインデックス１４０９に、それぞれ経路１４１２および１４１３を通してプライマリクローンデータフラグメントから伝達する。別の実施において、ＣＵＩＤ値を経路１４１３で伝達する代わりに、経路１４１５を通してＣＵＩＤ値をプライマリクローンインデックスフラグメント１４０７からセカンダリクローンインデックスフラグメント１４０９に伝達する。

図１６は、更新レコードおよび古いＣＵＩＤ値をプライマリクローンフラグメントから全てのセカンダリクローンデータフラグメント、および本レコードのコピーを含む全てのクローンインデックスフラグメントに伝達および適用するプロセスの例１６００を示す。伝達した更新を受け取るこれらのクローンフラグメントはカレント状態にあることができるか、またはリフレッシュ中状態にあることができる。プロセス１６００は一般に大規模な更新プロセスで１つのステップを形成し、これを本文書の別の部分で説明する。ブロック１６０１で、全てのセカンダリクローンデータフラグメントと、本レコードのコピーを含む全てのクローンインデックスフラグメント（プライマリ、セカンダリ両方）とを識別する。これらのクローンフラグメントは、プロセス１６００に対してローカルなデータ構造であるＳｅｔＯｆＳｅｃｏｎｄａｒｉｅｓという名前の集合を形成する。本集合内のそれぞれの要素に最初は未処理としてマークを付ける（これは実際のフラグメントを変更せず、ローカルデータ構造内の要素のみを変更する）。プロセス１６００は判定ブロック１６０２に続き、集合ＳｅｔＯｆＳｅｃｏｎｄａｒｉｅｓ内に未処理の要素がまだあるか否かを判定する。未処理の要素がなければ、プロセス１６００は終了ブロック１６０３に続き、プロセスは終了して、プロセス１６００をステップとして備える任意の大規模なプロセスは、その大規模なプロセス内で次のステップに続く。

判定ブロック１６０２に戻ると、集合ＳｅｔＯｆＳｅｃｏｎｄａｒｉｅｓ内に未処理の要素がまだある場合、プロセス１６００はブロック１６０４に続き、未処理の要素を集合ＳｅｔＯｆＳｅｃｏｎｄａｒｉｅｓから取得する。その要素は、次に更新すべきセカンダリクローンフラグメントを表す。そのセカンダリクローンフラグメントはセカンダリクローンデータフラグメント、プライマリクローンインデックスフラグメント、またはセカンダリクローンインデックスフラグメントである可能性がある。判定ブロック１６０５で、セカンダリクローンフラグメント内に、プライマリクローンフラグメントからのレコードと同じＣＲＩＤを有し、ＣＵＩＤがプライマリクローンフラグメントからのレコードの古いＣＵＩＤ値とマッチするレコードが存在するか否かを判定する。存在する場合、プロセス１６００はブロック１６０６に続き、レコードが新規値および新規ＣＵＩＤで更新される。プロセス１６００は次いでブロック１６０９に続く。

判定ブロック１６０５に戻ると、マッチするレコードが見つからない場合、プロセス１６００は判定ブロック１６０７に続き、セカンダリクローンフラグメントがリフレッシュ中状態にあるか否かを判定する。リフレッシュ中状態でなければ、ブロック１６０８で、プライマリクローンフラグメントと一貫しないのでセカンダリクローンフラグメントにオフラインとしてマークを付ける。プロセス１６００は次いでブロック１６０９に続く。

判定ブロック１６０７に戻ると、セカンダリクローンフラグメントがリフレッシュ中状態にある場合、プロセス１６００はブロック１６０９に続き、集合ＳｅｔＯｆＳｅｃｏｎｄａｒｉｅｓ内のカレント要素に処理済としてマークを付ける（これは実際のフラグメントを変更せず、ローカルデータ構造内の要素のみを変更する）。プロセス１６００は次いで判定ブロック１６０２に戻る。

図１５は、説明したシステムおよび方法を実施するコンピュータ装置の例１５００を示す。その最も基本的な構成において、コンピューティング装置１５００には一般に少なくとも１つの中央演算装置（ＣＰＵ）１５０５およびメモリ１５１０が含まれる。

コンピューティング装置の正確な構成および種類に依存して、メモリ１５１０は揮発性（例えば、ＲＡＭ）、不揮発性（例えば、ＲＯＭ、フラッシュメモリ、等）、または前記２つの何らかの組み合わせであることができる。さらに、コンピューティング装置１５００は追加の特徴／機能性を有することもできる。例えば、コンピューティング装置１５００は複数のＣＰＵを含むことができる。説明した方法をコンピューティング装置１５００内の任意の演算装置により任意の方法で実行することができる。例えば、説明したプロセスを複数のＣＰＵにより並列に実行することができる。

コンピューティング装置１５００は追加の記憶装置（取り外し可能および／または取り外し不能）を含むこともできる。その記憶装置は、磁気または光ディスクあるいはテープを含むがこれらに限らない。上記の追加の記憶装置を図１５において記憶装置１５１５により示す。コンピュータ記憶媒体には、コンピュータ読取可能命令、データ構造、プログラムモジュールまたは他のデータといった情報を記憶するための任意の方法または技術で実施した揮発性および不揮発性、取り外し可能および取り外し不能媒体が含まれる。メモリ１５１０および記憶装置１５１５はコンピュータ記憶媒体の全ての例である。コンピュータ記憶媒体はＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶または他の磁気記憶装置、あるいは所望の情報を記憶するために使用可能でかつコンピューティング装置１５００によりアクセス可能な任意の他の媒体を含むがこれらに限らない。任意の上記コンピュータ記憶媒体はコンピューティング装置１５００の一部であることができる。

コンピューティング装置１５００は通信装置（複数）１５４０を含むこともできる。通信装置（複数）１５４０により、コンピューティング装置１５００は他の装置と通信することができる。通信装置（複数）１５４０は通信媒体の例である。通信媒体は一般に、コンピュータ読取可能命令、データ構造、プログラムモジュールまたは他のデータを、搬送波または他の伝送機構のような変調データ信号で具現化し、任意の情報配信媒体を含む。用語「変調データ信号」は、１つまたは複数の特性集合を有するかまたは情報を信号に符号化するように変化した信号を意味する。限定ではなく例として、通信媒体には有線ネットワークまたは直接配線接続のような有線媒体、ならびに音響、ＲＦ、赤外線および他の無線媒体のような無線媒体が含まれる。本明細書で用いるコンピュータ読取可能媒体または装置読取可能媒体という用語には、コンピュータ記憶媒体および通信媒体の両方が含まれる。説明した方法を任意のコンピュータ読取可能媒体において、データ、コンピュータ実行可能命令、等のような任意の形態で符号化することができる。

コンピューティング装置１５００は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置、等のような入力装置（複数）１５３５を有することもできる。ディスプレイ、スピーカ、プリンタ、等のような出力装置（複数）１５３０も含めることができる。これら装置の全ては当業界において公知であり、詳細に議論する必要はない。

当業界の技術者は、プログラム命令を記憶するために利用される記憶装置をネットワークに渡って分散できることを理解するであろう。例えば、リモートコンピュータは、説明したプロセスの例をソフトウェアとして記憶することができる。ローカルまたはターミナルコンピュータはリモートコンピュータにアクセスして、ソフトウェアの一部または全部をダウンロードしてプログラムを実行することができる。または、ローカルコンピュータは必要に応じて少量のソフトウェアをダウンロードすることができるか、または幾つかのソフトウェア命令をローカル端末で実行し、幾つかをリモートコンピュータ（またはコンピュータネットワーク）で実行することができる。当業界の技術者は、当業界の技術者に公知な従来技術を利用することで、ソフトウェア命令の全部または一部をＤＳＰ、プログラマブルロジックアレイのような専用回路により実行可能であることも理解するであろう。

データベースシステムにより管理されるデータベースオブジェクトをクローン化するデータ構造の例である。 データベースオブジェクトのクローンフラグメントの例である。 データベースオブジェクトのクローンフラグメントを更新する操作の例である。 データベースオブジェクトに関連付けた陳腐化のクローンフラグメントをリフレッシュする操作の例である。 クローンフラグメントを識別（特定）するデータ構造の例である。 データベースオブジェクトのクローンフラグメントにおけるレコードを識別（特定）するデータ構造の例である。 セカンダリクローンインデックスフラグメントおよびセカンダリクローンデータフラグメントを更新するプロセスの例である。 陳腐化のクローンフラグメントをリフレッシュする際の状態の推移を示す。 クローンデータベースフラグメントを有するデータベースシステムの例である。 データベースオブジェクトの更新プロセスの例を示す。 データベースオブジェクトの陳腐化のクローンフラグメントをリフレッシュするリフレッシュプロセスの例を示す。 クローン更新識別子（ＣＵＩＤ）の修正プロセスの例を示す。 図１２に示すプロセスに従って配分したＣＵＩＤ値の割り当てプロセスの例を示す。 ＣＵＩＤ値の伝達経路の例を示す。 記載したシステムおよび方法を実施するコンピュータ装置の例である。 更新をレコードに伝達および適用し、古いＣＵＩＤ値をプライマリクローンフラグメントから全てのセカンダリクローンデータフラグメント、および前記レコードのコピーを含む全てのクローンインデックスフラグメントに伝達するプロセスの例を示す。 図１１に示すリフレッシュプロセスの一部として陳腐化クローンをカレントとするプロセスの例である。

Claims (28)

1. データベースオブジェクトに関連付けたプライマリクローンフラグメントであって、前記データベースオブジェクトに関連付けたデータベース操作に関して選択されたプライマリクローンフラグメントを識別するステップと、
   前記プライマリクローンフラグメントに対応するセカンダリクローンフラグメントであって、前記プライマリクローンフラグメントに関して陳腐であるセカンダリクローンフラグメントを識別するステップと、
   データベース操作を実行することで、陳腐化の前記セカンダリクローンフラグメントを前記プライマリクローンフラグメント内のデータでリフレッシュするステップと
   を実行するための装置実行可能な命令を有することを特徴とする１つまたは複数の装置読取可能媒体。
2. 前記陳腐化のセカンダリクローンフラグメントをリフレッシュするためのデータベース操作は、前記陳腐化のセカンダリクローンフラグメントをインクリメンタルにリフレッシュするバッチ操作を含むことを特徴とする請求項１に記載の１つまたは複数の装置読取可能媒体。
3. 前記陳腐化のセカンダリクローンフラグメントをリフレッシュするバッチ操作は、構造化問合せ言語（ＳＱＬ）の操作であることを特徴とする請求項２に記載の１つまたは複数の装置読取可能媒体。
4. さらに、前記プライマリクローンフラグメントについて実行する更新に応じて、前記陳腐化のセカンダリクローンフラグメントをリフレッシュしている間に前記陳腐化のセカンダリクローンフラグメントを更新することを特徴とする請求項１に記載の１つまたは複数の装置読取可能媒体。
5. 前記更新するステップでは、さらに、前記陳腐化のセカンダリクローンフラグメントの最新行を更新するが前記陳腐化のセカンダリクローンフラグメントの最新でない行は更新しないことを特徴とする請求項４に記載の１つまたは複数の装置読取可能媒体。
6. 前記リフレッシュするステップでは、
   前記プライマリクローンフラグメントに含まれる第１のレコードに関連付けた第１の更新識別子を識別し、
   前記陳腐化のセカンダリクローンフラグメント内の、前記第１のレコードに対応する第２のレコードに関連付けた第２の更新識別子を識別し、および
   同一のクローンレコード識別子を有する前記第１のレコードおよび第２のレコードが矛盾がないか否かを、少なくとも部分的に、前記第１の更新識別子と前記第２の更新識別子とを比較することに基づいて判定する
   ことを特徴とする請求項１に記載の１つまたは複数の装置読取可能媒体。
7. 前記第１および第２のレコードが矛盾していると判定される場合、前記リフレッシュするステップでは、さらに、
   前記第２のレコードを前記第１のレコード内のデータでリフレッシュし、および
   前記第１の更新識別子の値を前記第２の更新識別子に割り当てる
   ことを特徴とする請求項６に記載の１つまたは複数の装置読取可能媒体。
8. 前記セカンダリクローンフラグメント内に含まれるレコードの各々について判定、リフレッシュ、および割り当てのステップを実行することを特徴とする請求項７に記載の１つまたは複数の装置読取可能媒体。
9. 前記リフレッシュスするテップでは、コミット済み読み込みモードでプレリフレッシュの動作を前記セカンダリクローンフラグメントについてで実行することを特徴とする請求項１に記載の１つまたは複数の装置読取可能媒体。
10. 前記プレリフレッシュの動作は、前記プライマリクローンフラグメントに対応する他のセカンダリクローンフラグメントについて並列に実行されることを特徴とする請求項９に記載の１つまたは複数の装置読取可能媒体。
11. 前記陳腐化のセカンダリクローンフラグメントが更新中にオフラインになることに応じて、更新を前記プライマリクローンフラグメントに保存するステップ、および
    前記陳腐化のセカンダリクローンフラグメントがオンラインに戻るとき、前記陳腐化のセカンダリクローンフラグメントを前記の保存した更新でリフレッシュするステップ
    をさらに実行することを特徴とする請求項１に記載の１つまたは複数の装置読取可能媒体。
12. 前記セカンダリクローンフラグメントをリフレッシュする前記データベース操作は、前記セカンダリクローン内のレコードを挿入、削除および更新するデータ操作言語（ＤＭＬ）の操作を含むことを特徴とする請求項１に記載の１つまたは複数の装置読取可能媒体。
13. 前記プライマリクローンフラグメントは、クローンデータフラグメントまたはクローンインデックスフラグメントのうち少なくとも１つであることを特徴とする請求項１に記載の１つまたは複数の装置読取可能媒体。
14. 前記陳腐化のセカンダリクローンフラグメントはクローンインデックスフラグメントであり、前記陳腐化のセカンダリクローンフラグメントを複数のクローンデータフラグメントによりリフレッシュし、それぞれは前記陳腐化のセカンダリクローンフラグメント内の少なくとも１つのエントリと関連付けたことを特徴とする請求項１に記載の１つまたは複数の装置読取可能媒体。
15. データベースオブジェクトのフラグメントを識別するステップ、
    対応するクローンフラグメントを前記の識別したフラグメントから生成するステップ、
    前記クローンフラグメントをコンピューティング装置のグループに分散するステップ、および
    前記クローンフラグメントの少なくとも１つを、前記データベースオブジェクトに関連付けた操作に対して使用するよう構成したプライマリクローンフラグメントとして指定するステップを
    を実行するための装置実行可能命令を有することを特徴とする１つまたは複数の装置読取可能媒体。
16. 前記データベースオブジェクトの識別したフラグメントに対する更新を判定するステップ、
    前記プライマリクローンフラグメントに対する前記更新を実行するステップ、および
    前記更新を他の対応するセカンダリクローンフラグメントに伝達および適用するステップ
    をさらに実行することを特徴とする請求項１５に記載の１つまたは複数の装置読取可能媒体。
17. 前記セカンダリクローンフラグメントの１つを、前記更新を含まない陳腐化のセカンダリクローンフラグメントとして識別するステップ、および
    前記の特定した陳腐化のセカンダリクローンフラグメントを、前記プライマリクローンフラグメント内のデータでリフレッシュするステップ
    をさらに実行することを特徴とする請求項１６に記載の１つまたは複数の装置読取可能媒体。
18. 前記リフレッシュステップを標準的なＳＱＬデータベース操作を用いて実行することを特徴とする請求項１７に記載の１つまたは複数の装置読取可能媒体。
19. 前記の識別したフラグメントに対する別の更新を判定するステップ、
    前記の他の更新を前記プライマリクローンフラグメント上で実行するステップ、および
    前記の他の更新の前に前記陳腐化のセカンダリクローンフラグメント内のレコードが前記プライマリクローンフラグメントの対応するレコードに対して最新であった場合に限り、前記の他の更新を前記陳腐化のクローンフラグメント上で選択的に実行するステップ、
    をさらに実行することを特徴とする請求項１７に記載の１つまたは複数の装置読取可能媒体。
20. 前記の選択的に実行するステップでは、リフレッシュした前記陳腐化のクローンフラグメントの一部分で前記の他の更新を実行することを特徴とする請求項１９に記載の１つまたは複数の装置読取可能媒体。
21. さらに、前記陳腐化のクローンフラグメントがリフレッシュされたと判定することに応じて、前記リフレッシュクローンフラグメントをプライマリクローンフラグメントである資格を有するとして即座に指定するステップを実行することを特徴とする請求項２０に記載の１つまたは複数の装置読取可能媒体。
22. 前記リフレッシュするステップを、少数のレコードを短期間ロックしかつ他のユーザの作業負荷と並行に実行する作業負荷として実行することを特徴とする請求項１７に記載の１つまたは複数の装置読取可能媒体。
23. 前記リフレッシュステップを、複数の陳腐化のセカンダリクローンフラグメント上で並列に実行することを特徴とする請求項１７に記載の１つまたは複数の装置読取可能媒体。
24. 前記複数の陳腐化のセカンダリクローンフラグメントは、共通プライマリクローンフラグメント、別のプライマリクローンフラグメント、または別のデータベースオブジェクトのうち少なくとも１つに対応することを特徴とする請求項１７に記載の１つまたは複数の装置読取可能媒体。
25. 前記クローンフラグメントを、データベース操作に対して十分に同一なように生成することを特徴とする請求項１５に記載の１つまたは複数の装置読取可能媒体。
26. 相互作用コンピューティング装置システムにおけるコンピューティング装置であって、前記コンピューティング装置はデータベースオブジェクトと関連付けたデータを含み、前記コンピューティング装置を
    前記データベースオブジェクトの一部分を更新用に識別するステップ、
    前記の特定したデータベースオブジェクト部分に関連付けたプライマリクローンフラグメントを第１のデータベース操作を用いて更新するステップ、
    前記プライマリクローンフラグメントに関連付けたセカンダリクローンフラグメントを特定するステップ、および
    前記セカンダリクローンフラグメントを、少なくとも部分的に前記プライマリクローンフラグメントに含まれるデータに基づいて、前記第１のデータベース操作に関連付けた第２のデータベース操作を用いて更新するステップ
    を実行するよう構成したことを特徴とするコンピューティング装置。
27. 前記セカンダリクローンフラグメントは前記プライマリクローンフラグメントと比べて陳腐化していることを判定するステップ、
    前記プライマリクローンフラグメント内のデータを用いて前記セカンダリクローンフラグメントをリフレッシュするステップ、および
    前記セカンダリクローンフラグメントがリフレッシュされているときに、前記セカンダリクローンフラグメントを選択的に更新するステップ
    を実行するよう前記コンピューティング装置をさらに構成したことを特徴とする請求項２６に記載のコンピューティング装置。
28. データベースオブジェクトに関連付けた、プライマリおよびセカンダリクローンフラグメントを含むクローンフラグメントを監視するステップ、
    前記クローンフラグメントの少なくとも１つが利用不能になったことを判定するステップ、
    前記データベースオブジェクトに関連付けた更新識別子を増加させるステップ、
    トランザクション的に前記更新識別子を存続させるステップ、
    前記データベースオブジェクトに関連付けた、前記データベースオブジェクトに対する更新を含むＤＭＬステートメントを識別するステップ、
    前記の存続させた更新識別子を前記ＤＭＬステートメントと関連付けるステップ、
    前記ＤＭＬステートメントにより影響を受けた前記プライマリクローンフラグメント上で前記更新を実行するステップ、
    前記ＤＭＬステートメントに関連付けた更新識別子を、前記更新により影響を受けた前記プライマリクローンフラグメント内の各行に記憶するステップ、
    前記更新および前記更新識別子を、前記の影響を受けたプライマリクローンフラグメントに関連付けた前記セカンダリクローンフラグメントに伝達するステップ、および
    前記セカンダリクローンフラグメント上に前記更新識別子を記憶するステップ
    を実行することを特徴とする装置実行可能な方法。

Images