JP2020503588A - コミットされていないトランザクションを有するデータベース・レコードのマルチバージョン同時制御 - Google Patents

Abstract

システム及び方法は、コミットされていないトランザクションを有するデータベース・レコードのマルチバージョン同時制御を提供する。システム及び方法はトランザクション・カウンタ番号に関するクエリを受信することを含む。データを識別するトランザクション・ヘッダが、割り当てられたトランザクション・カウンタ番号で更新される場合、更新されたトランザクション・ヘッダは、マルチバージョン同時制御情報のインスタンスとして、受信したクエリにより使用され得る。キー・ルックアップが実行され、キー・ルックアップが、トランザクション番号についてコミットされていない行に遭遇した場合、トランザクション番号がコミットされるか否かを判断するためにデータ・アレイ要素を識別するために、データを識別する対応するトランザクション・ヘッダにアクセスし、トランザクション番号がコミットされていない場合に、トランザクション・カウンタ番号を決定する。トランザクション・カウンタ番号は、行がコミットされると判断された場合に行バージョン・レコードでスタンプされ得る。

Description

データベース・システムに保存されるレコードは様々な識別子に基づいて互いから識別され得る。データベース・システムは、各々がデータベースにレコードを保存し得る複数のテナントをサポートしてもよい。トランザクション又はレコードのステータスは様々な時間に様々な場所で更新され得るので、データベース・システムは、異なる場所に保存されるデータベース・レコードの異なるバージョンを有し得る。典型的なデータベース・システムは、異なる場所に保存されるレコードの同時性（ｔｈｅ ｃｏｎｃｕｒｒｅｎｃｙ）を制御しようと試みることができ、そのため、システムに対するクエリが異なる場所から行われる場合に、データベース・システム経験が類似するようになる。しかしながら、ある場所に保存されるレコードは異なる場所に保存されるレコードよりも最新であるかもしれず、クエリがデータベース・システムに対して行われる場合に、不一致が生じ得る。

開示される対象事項の更なる理解を提供するように意図される添付図面は、本願に組み込まれ、本願の一部分を構成する。図面はまた、開示される対象事項の実現の原理を説明するのに役立つように、詳細な説明とともに開示される対象事項の実装を示す。開示される対象事項及び実現され得る様々な方法の基本的な理解にとって必要とされ得る以上に詳細に構造を示す試みは行われていない。

図１は開示される対象事項の実装に従ってトランザクション・カウンタ番号がマルチバージョン同時制御（ａ ｍｕｌｔｉｖｅｒｓｉｏｎ ｃｏｎｃｕｒｒｅｎｃｙ ｃｏｎｔｒｏｌ：ＭＶＣＣ）として使用され得るようにトランザクションをスタンピングする方法例を示す。

図２はトランザクションがビジブルでない及び／又は認識可能でない場合にレコードに対するトランザクションをコミットする開示される対象事項の実装による方法例を示す。

図３はトランザクションがビジブル及び／又は認識可能である場合にレコードに対するトランザクションをコミットする開示される対象事項の実装による方法例を示す。

図４Ａ−４Ｂは開示される対象事項の実装に従ってレコードにおけるトランザクションをルックアップする方法例を示す。 図４Ａ−４Ｂは開示される対象事項の実装に従ってレコードにおけるトランザクションをルックアップする方法例を示す。

図５は開示される対象事項の実装によるトランザクション・カウンタ番号割り当て（即ち、「スタンピング（ｓｔａｍｐｉｎｇ）」）に相応しいシステム例の基本ブロック図を示す。

図６は開示される対象事項の実装によるトランザクション・カウンタ番号割り当て（即ち、「スタンピング」）に相応しい構成例を示す。

図７は開示される対象事項の実装によるトランザクション番号割り当て（即ち、「スタンピング」）に相応しい構成例を示す。

図８Ａ及び８Ｂは開示される対象事項の実装によるトランザクション番号割り当て（即ち、「スタンピング」）に相応しい構成例を示す。 図８Ａ及び８Ｂは開示される対象事項の実装によるトランザクション番号割り当て（即ち、「スタンピング」）に相応しい構成例を示す。

図９は開示される対象事項の実装によるコンピュータを示す。

図９は開示される対象事項の実装によるネットワーク構成を示す。

ここで開示される実装において、トランザクション番号等のトランザクション識別子は、サーバー・システムに保存されるレコードのアップデート各々に関連付けられてよい。ここで使用されるように、トランザクション番号は、サーバー・システムにおいてトランザクションに対して指定される固有の番号を指すことができ、トランザクションはレコードの生成及び／又は更新であってもよい。トランザクション・ヘッダが、指定されたトランザクション・カウンタ番号で更新される場合、新たなクエリは、その指定されたトランザクション・カウンタ番号を、それらのマルチバージョン同時制御（ＭＶＣＣ）スナップショットとして使用し得る。開示される対象事項の実装において、行ルックアップ・オペレーションは、コミットされていない（アンコミットされている）ように見える行レコードに遭遇するかもしれず、なぜなら行レコードはそれらに指定されるトランザクション・カウンタ番号を有していないかもしれないからである（即ち、トランザクション・カウンタ番号がそれらにスタンプされていないかもしれない）。行レコードは、同時オペレーションにおいてスタンプされる（即ち、コミット済みとなるような）過程におけるものであり得る。

トランザクション番号について、コミットされていないように見える行に遭遇したキー・ルックアップは、そのトランザクション番号がコミットされるか否かを判断するために、対応するトランザクション・ヘッダにアクセスし得る。トランザクション番号がコミットされていると判断される場合、トランザクション・カウンタ番号が決定され得る。行がコミットされるべきであると判断される場合、ルックアップを実行する１つ以上のオペレーションは、行レコード・バーションにトランザクション・カウンタ番号を指定（即ち、スタンプ）することができる。

トランザクションについてコミット・タイム処理（ｔｈｅ ｃｏｍｍｉｔ−ｔｉｍｅ ｐｒｏｃｅｓｓｉｎｇ）を終了し得るシステムは、トランザクションにより影響を受ける行を訪れることができる。システムは、その行をトランザクション・カウンタ番号でスタンプすることができ（同時ルックアップがそうしていない場合）、任意の行のロックを解放することができる。即ち、トランザクション・ヘッダ・レコードに対するトランザクション・コミット番号の指定は、トランザクションをコミットすることができ、行のロックはトランザクションのコミットメントに基づいて解放される。コミットメントについての知識は、コミット・タイム処理のこの最終段階の間に行レコードに転送され得る。より大きなトランザクションは、コミット・タイム処理を終えるためにより長くかかり得るが、他のコミット・トランザクションの処理を妨げないであろう。更に、適切なＭＶＣＣスナップショットを有する同時トランザクションは、影響を受ける行にアクセスするために、コミット・タイム処理が完了まで待機する必要はないかもしれない。ここで開示されるシステム及び方法では、トランザクション・カウンタ番号にとって、キー・ルックアップにより又は進行中のコミット・タイム処理によりスタンプされることは十分であり得る。

典型的なデータベース・システムは、異なる場所に保存されるデータベース・レコードの異なるバージョンを有する。トランザクション又はレコードのステータスは様々な時間に様々な場所で更新される。典型的なデータベース・システムは、システムに対するクエリが異なる場所から行われる場合に、データベース・システム経験が類似するように、異なる場所に保存されるレコードの同時性を制御しようと試みるが、異なる場所に保存されるレコードに対する更新は周期的にしか実行されない。各々の場所は異なる時間に更新され得る。従って、ある場所に保存されるレコードは異なる場所に保存されるレコードよりも最新であるかもしれない。従って、異なる場所に保存されるレコードを調和させるための周期的な更新の間の時間等において、クエリがデータベース・システムに対して行われる場合に、特定の場所でどのデータが利用可能であるかに依存して、結果に不一致が生じる。

開示される対象事項の実装は、レコードの同時性を制御し、そして指定されたトランザクション・カウンタ番号を有する更新されたトランザクション・ヘッダを利用することにより、データベース・システムに対して為されたクエリに、より最新の情報を提供する。新たなクエリは、この指定されたトランザクション・カウンタ番号を、それらのＭＶＣＣスナップショットとして使用することができる。即ち、データベース・システムにとって、コミットされていないものとして見えるトランザクションは（なぜなら、トランザクションは、トランザクション・カウンタ番号でスタンプされていないからである）、これらのトランザクションがスタンプされる過程におけるものである場合（例えば、コミットされていないトランザクションではなく、レコード・バージョンとなるように処理される場合）、クエリに応答するために使用されてよい。これは、最新であるデータを、クエリに利用可能にするが、そうでなければ、データベース・システムがレコード・バージョンとしてコミットするまで時間を費やすであろう。コミット処理を実行するための時間は、トランザクションのサイズに依存して変わり得る（例えば、より大きなトランザクションは、比較的より小さなトランザクションよりも、システムがコミットするまで長時間を費やし得る）。

マルチテナントは、例えばユーザー、ユーザーのグループ、又は組織等であってもよい様々なテナントが、様々なテナントの間で共有され得るサーバー・システム上のソフトウェア・ツール又はインスタンスにより、サーバー・システム上の各自自身のレコードにアクセスすることを許容することができる。各テナントのレコードは、そのテナントに関するデータベースの一部分であってもよい。複数のテナントのレコードは、同じサーバー・システムの中に全て一緒に保存され得るが、各々のテナントは、そのテナントに帰属する又はそのテナントにより作成されたレコードにアクセスすることができるだけであってもよい。これは、各々のテナントのレコードを別々に、例えば個々のサーバー又はサーバー・システムに保存する必要無しに、サーバー・システムがマルチテナントを可能にすることを許容し得る。テナントのデータベースは、例えば、リレーショナル・データベース、階層データベース、又は適切な他の任意のデータベース・タイプであってもよい。サーバー・システムに保存される全てのレコードは、例えばＬＳＭ（ａ ｌｏｇ−ｓｔｒｕｃｔｕｒｅｄ ｍｅｒｇｅ）ツリーを含む適切な任意の構造に保存され得る。

ここで開示されるレコードは、マルチテナント・システムのインスタンスにおけるキー・バリュー・ペアにより識別され得る。バリュー（値）は、例えば、リレーショナル・データベースのテーブルの行の内容、リレーショナル・データベースのテーブルの行の識別子、又は適切な他の任意の値であってもよい。キーは、レコードに対する識別子であってもよく、そして例えば英数字シーケンス等の適切な任意の形式におけるものであってよい。キーの一部分は、レコードに関する情報を提供してもよい。例えば、キーの一部分は、レコードが帰属するテナントを一意に識別し得るテナント識別子であってもよい。キーの他の部分は、例えば、レコードの値が行の内容である場合にはテーブル番号及び行の識別子、又は値が行の識別子である場合には、テーブル番号、テーブルにおけるインデックス番号、及びインデックスされた列の識別子を識別してもよい。

更に、マルチテナント・システムは、各ノードでコンピューティング・システムを有する、ネットワークを通じて分散されたサーバー・システム上の様々なテナント・インスタンスを有することができ、本願ではインスタンス・ノードと言及され得る。インスタンス・ノードは、データベース・システムの特定の場所に保存されるデータベースのレコード、及び／又は特定のテナントのためのものであってもよいレコードを含み得る。各々のインスタンスは、データベース・ファイル又はレコードを管理する一組のメモリ構造を含み得る。データベースは、ストレージ・デバイスに保存される一組のファイル及び／又はレコードを含んでもよく、ストレージ・デバイスは本願で開示されるようなサーバー・システムの一部分であってもよい。インスタンスは、関連するデータを管理し、データベースのユーザーに応対する。インスタンスは、特定の場所に保存されたレコードのため及び／又は特定のテナントのために特定の時点を表現し、異なるインスタンスはデータベース・レコードの異なるバージョンを有し得る。各テナントのライブ又はプロダクション・データベース・インスタンスは、１つのコンピュータ・システムで処理されるトランザクションを有するだけであってもよい。そのインスタンスのトランザクションを処理するコンピューティング・システムはまた、他のテナントの他のインスタンスのトランザクションを処理してもよい。各々のサーバー・システムは、そのテナントのライブ又はプロダクション・インスタンスに関してそのサーバー・システムによりトランザクションがコミットされている順序で厳密に昇順又は降順に（テナントのインスタンスにとって）固有のトランザクション番号を指定してもよい。更に、各々のサーバー・システムは、そのテナントのライブ又はプロダクション・インスタンスに関してその特定のサーバー・システムによりトランザクションがコミットされている順序で厳密に昇順又は降順に（テナントのインスタンスにとって）固有のトランザクション番号を指定してもよい。他のノードにおける他のサーバー・システムに関し、それらは同様に、トランザクションをコミットするために同じトランザクション番号割り当て方式を使用してもよい。

全体にわたって説明されるデータベース・システム（例えば、図５−７に示されるシステム１００、図９に示されるセントラル・コンポーネント７００及び／又は別のコンピュータ８００、又は図１０に示されるデータベース１２００ａ、１２００ｂ、１２００ｃ及び／又は１２００ｄ）及びテナント・マイグレーション方法において、レコードはマルチテナント・システムのインスタンスにおけるキー・バリュー・ペアとして識別されてもよい。データベースにおけるテナンシー（Ｔｅｎａｎｃｙ）が作成され、テナンシーに関連付けられる認証されたユーザーは、そのテナンシーに関するオペレーションを眺める、アクセスする、及び／又は実行することができる。例えば、値は、リレーショナル・データベースのテーブルの行の内容、リレーショナル・データベースのテーブルにおける行の識別子、又は適切な他の任意の値であってもよい。キーは、例えば英数字シーケンス等の適切な任意の形式におけるレコードに関する識別子であってもよい。キーの一部分はレコードの内容に関する上方を提供してもよい。例えば、キーの一部分は、レコードの内容が帰属するテナントを一意に識別し得るテナント識別子であってもよい。キーの他の部分はテーブル番号を識別してもよい。キーの一部分はまた、行の識別子を提供してもよい（例えば、レコードの値が行の内容である場合である）。キーの一部分はまた、例えば、テーブル番号、テーブルにおけるインデックス番号、及び値が行の識別子である場合にインデックスされた列の識別子を含んでもよい。

データベース・システム（例えば、図５−７に示されるシステム１００、図９に示されるセントラル・コンポーネント７００及び／又は別のコンピュータ８００、又は図１０に示されるデータベース１２００ａ、１２００ｂ、１２００ｃ及び／又は１２００ｄ）は、所与のレコードの不変バージョンとしてトランザクションを保存してもよい。サーバー・システムに既に保存されているレコードの内容の不変バージョンは、内容がサーバー・システムから（極めて希に）削除されるまで変更されないであろう。即ち、受信されるトランザクションは、レコードの内容を変更する代わりに、サーバー・システムに保存されるレコードの内容の新たなバージョンを作成し得る。従って、本願で開示されるレコードの複数のバージョン（例えば、異なる内容を有するレコード）に関し、トランザクション識別子（例えば、トランザクション番号を含み得る）を除いて同じキーを有することが可能になり得る。他の点で、所与のレコードのバージョンに関する同一キーの使用は、リレーショナル・データベースに保存されたデータの変化を許容する。従って、物理的なレコードの各バージョンは不変であってもよく；即ち、それは削除されない、又は月、年又は数十年であり得る任意の長期間にわたって削除されない。例えば、レコードの早期のバージョンに対して、（トランザクション識別子以外）同一のキーを有するレコードの後のバージョンは、そのレコードに対するデータ値における変化（即ち、レコードの内容の変化）を示し得る。代替的に、トランザクションはレコードを作成し得る又はレコードを削除し得る（即ち、コンテンツを作成又はコンテンツを削除し得る）。レコードは、「トゥームストーン（ｔｏｍｂｓｔｏｎｅ）」（例えば、削除されるべきデータを識別するマーカー）を挿入することにより削除されてもよく、将来的な時点で、更新されたレコードが書き込まれてもよい（もはやトゥームストーンによりマークされたレコードを含まない）。

タイム・スタンプ又は他の時間識別子が、テナントの形成の際に作成されてもよい。その後、テナント・データは、タイム・スタンプより前に保存されたデータのプールにおけるキーに基づいて適切なバージョンにアクセスすることにより、タイム・スタンプより前のデータのバージョンのための主要キー・リクエストを解釈し得る。タイム・スタンプより後に作成又は更新されたデータにアクセスする個々のテナントのためのキーは、テナントにより作成された適切なデータにアクセスするように解釈されるであろう。あるいは、タイム・スタンプを使用するのではなく、データベース内の各トランザクションは、その後の各トランザクションに関して単調に増加する関連する固有のトランザクション番号を有してもよく、システムは、タイム・スタンプの代わりに、最も最近に作成されたトランザクション識別子に留意することができる。

開示される対象事項の実装において、トランザクション識別子は、サーバー・システムに保存されるレコードのアップデート各々に関連付けられてもよい。トランザクション識別子は、例えば、厳密に増加し得るトランザクション番号を含んでもよい。即ち、各々の以後のトランザクションのトランザクション番号は、常に、先行するトランザクションよりも高い。これは、トランザクション番号によって順序付けることが可能なトランザクションを許容することができ、あるユーザーに関して後に保存されるトランザクションは、常に、そのユーザーに関して先に保存されたトランザクションより高いトランザクション番号を有する。所与のユーザーの又はテナントのトランザクションは、トランザクション番号によって時間順にされてもよい。幾つかの実施形態において、トランザクションに関連するトランザクション番号は、クロック時間に同期した値に基づくトランザクション番号に起因して、トランザクションに関する大凡のタイム・スタンプとして振る舞うことが可能であり、レコードのバージョンであってもよいトランザクションの組織化及び抽出を、それらが保存された大凡の時間に基づいて許容する。

開示される対象事項の実装において、トランザクション番号は、トランザクションがコミットされる場合にトランザクションに割り当てられてもよい。割り当てられるトランザクション番号は、図５に示され及び後述されるトランザクション・カウンタ１１０等のカウンタに基づいてもよい。即ち、トランザクション・カウンタはトランザクション・カウンタ番号を生成することができ、生成されたトランザクション・カウンタ番号は、トランザクションがコミットされる場合に、トランザクションのトランザクション番号、又はトランザクション番号の一部分として割り当てられてもよい。以下に説明される幾つかの実装において、トランザクション番号は、タイム・スタンプとタイム・スタンプ以来のトランザクションの番号を示すトランザクション・カウントとの双方を有してもよい。そのような実装において、コミットされるトランザクションは、トランザクションに関連付けられる又は割り当てられる固有のトランザクション番号を有するであろう。

以下に詳細に説明されるように、図１−４Ｂは、開示される対象事項の実施例によるトランザクションをコミットする方法を示し、図５−１１は開示される対象事項の実施例によるトランザクション・カウンタ番号の割り振りに相応しい構成例を示す。図１−１１に関連して説明される方法及び構成を利用する具体例が、これらの方法及び構成の説明の後に続く。

図１は開示される対象事項の実装に従ってトランザクション・カウンタ番号がマルチバージョン同時制御（ＭＶＣＣ）として使用され得るようにトランザクションをスタンピングする方法例１０を示す。方法１０はデータベース・システムにとってコミットされていないように見えるトランザクションを提供し、そのトランザクションは、これらのトランザクションが、スタンプされる過程におけるものである場合に（例えば、コミットされていないトランザクションではなく、レコード・バージョンとなるように処理される場合に）、クエリに応答するために使用され得る。これは、最新であるデータを、クエリにとって利用可能にするが、そうでなければデータベース・システムがレコード・バージョンとしてコミットするまで時間がかかるであろう。オペレーション１１において、サーバー・システム及び／又はデータベース・システム（例えば、図５−９のサーバー・システム１００、図１０のデータベース１２００ａ−ｄ）は、トランザクション・カウンタ番号に関するクエリを、コンピュータ（例えば、図９に示されるコンピュータ６００及び／又は別のコンピュータ８００、及び／又は図７に示されるサーバー・システム４００等の他のサーバー・システム）から受信し得る。オペレーション１２において、データを識別するトランザクション・ヘッダが、指定されたトランザクション・カウンタ番号とともに（例えば、図５のトランザクション番号マネージャ１３０により）更新される場合、データを識別する更新されたトランザクション・ヘッダは、受信したクエリにより、マルチバージョン同時制御情報のインスタンスとして使用され得る。ストレージ（例えば、図５に示されるストレージ１４０）に保存されるトランザクション（例えば、図５に示されるコミットされていないトランザクション１４５及び／又はレコード・バージョン１６０）は、サーバー・システム（例えば、図５に示されるサーバー・システム１００）により受信されるクエリにとってトランザクションをビジブル（ｖｉｓｉｂｌｅ）及び／又は認識可能にし得るデータを識別するトランザクション・ヘッダを含んでもよい。例えば、データを識別するトランザクション・ヘッダにおけるトランザクション・カウンタ番号は、クエリにとってトランザクションをビジブル及び／又は認識可能にし得る。マルチバージョン同時制御情報は、テナント・データのインスタンスに関して及び／又はデータベース（例えば、図５−９のサーバー・システム、図１０のデータベース１２００ａ−ｄ）のインスタンス・ノードに関して特定の時点におけるコミットされていないトランザクション及び／又はレコードの状態を識別するために使用されてもよい。サーバー・システム１００は、オペレーション１４において、受信したクエリに基づいてデータベースのテーブルにおけるキー・ルックアップを実行してもよく、キーはデータベースのテーブルにおける１つ以上の行の識別子を含む。キー・ルックアップはデータベース内のコミットされていないトランザクション（例えば、図５に示されるコミットされていないトランザクション１４５）及びコミットされているトランザクション（例えば、レコード・バージョン１６０）を識別するために使用され得る。例えば、図５に示されるサーバー・システム１００は、受信したクエリに基づいて、コミットされていないトランザクション１４５（例えば、キー１５１を有するトランザクション１４６、キー１５２を有するトランザクション１４７、キー１５３を有するトランザクション１４８、及び／又はキー１５４を有するトランザクション１４９）及び／又はレコード・バージョン１６０（例えば、キー１７１を有するトランザクション１９１、キー１７２を有するトランザクション１９２等）に関してキー・ルックアップ・オペレーションを実行し得る。

オペレーション１６において、キー・ルックアップが、トランザクション番号に関してストレージ１４０におけるコミットされていない行に遭遇した場合、データを識別する対応するトランザクション・ヘッダがアクセスされ、ストレージ内のデータ・アレイ要素を識別し、トランザクション番号がコミットされるか否か、及び対応するトランザクション・カウンタ番号を決定してもよい。コミットされていない行は、それらに指定されるトランザクション・カウンタ番号を有しない行レコードであるかもしれない（即ち、トランザクション・カウンタ番号がそれらに対してスタンプされていないかもしれない）。図示されるように、例えば、図５において、ストレージ１４０はコミットされていないトランザクション４５を有し、及び／又はコミットされたトランザクションを有し得るレコード・バージョン１６０を有し得る（例えば、トランザクション番号１９１，１９２，１９３，１９４，１９５，１９６，１９７，及び／又は１９８）。トランザクション・カウンタ番号は、トランザクション番号がコミットされた場合に決定されてもよい（例えば、トランザクション番号は、ストレージ１４０のレコード・バージョン１６０の中のレコードである）。即ち、トランザクション番号は、トランザクションがコミットされた場合にトランザクションに割り当てられてもよい。割り当てられるトランザクション番号はカウンタ（例えば、図５に示されるトランザクション・カウンタ１１０）に基づいていてもよい。トランザクション・カウンタはトランザクション・カウンタ番号を生成することができ、生成されたトランザクション・カウンタ番号は、トランザクションがコミットされる場合に、トランザクションを生成してトランザクションにトランザクション番号を割り振る際に使用される。開示される対象事項の幾つかの実装では、オペレーション１６において対応するトランザクション・ヘッダ（コミットされていないトランザクション１４５及び／又はレコード・バージョン１６０のヘッダ）にアクセスすることは、行バージョン・レコード及び行ロック・レコードに関するトランザクション・ヘッダ・インデックス・フィールドを利用してデータ・アレイ要素を識別することを含み得る。データ・アレイ要素は、コミットされていないトランザクション１４５の値１５５，１５６，１５７，１５８、及び／又はレコード・バージョン１６０の１８１，１８２，１８３，１８４，１８５，１８６，１８７，及び／又は１８８を利用して識別されてもよい。オペレーション１８において、トランザクション・カウンタ番号は、（例えば、トランザクション番号マネージャ１３０により）行バージョン・レコードにスタンプされてもよい。サーバー・システムは、トランザクション・カウンタ番号のスタンピングに基づいて、トランザクションのコミット・タイム処理を完了してもよい。即ち、コミット・タイム処理は、今のところコミットされていないトランザクションであるトランザクションを処理することができ、そのためそれらはレコード・バージョン（例えば、コミットされたトランザクション）になる。

開示される対象事項の幾つかの実装において、トランザクション識別子を有するトランザクションにより影響を受ける各々の行は、トランザクション・カウンタ番号でスタンプされてもよく、任意の行のロックが解放されてもよい。このオペレーションは、コミット・タイム処理の一部分としてサーバー・システムにより実行されてもよい。

幾つかの実装では、１つ以上の行ルックアップ・レコードが、サーバー・システムにとってコミットされていないものとして見える場合に、行ルックアップが実行されてもよく（例えば、行レコードは、図５に示されるコミットされていないトランザクションの一部である）、そのため１つ以上の行ルックアップ・レコードは、それらがトランザクション・カウンタ番号でスタンプされない場合にアンコミットされる。即ち、１つ以上のアンコミットされた行ルックアップ・レコードは、サーバー・システム１００により処理され得る一方、１つ以上のアンコミットされたレコードはクエリにとって外的にビジブル及び／又は認識可能ではない。

図２はトランザクションが認識可能でない場合に（即ち、図５に示されるサーバー・システム１００により受信されるクエリに対して認識可能及び／又はビジブルでない場合に）レコードに対するトランザクションをコミットする開示される対象事項の実装による方法例２０を示す。請求項２０の方法は、トランザクションが認識可能及び／又は視察可能になるまでレコードに対するトランザクションをコミットすることができない現在のデータベース・システムを改善する。請求項２０の方法は、最新であるデータが、クエリにとって利用可能であることを許容するが、そうでない場合、データベース・システムがレコード・バージョンとしてコミットするまで時間がかかるであろう。開示される対象事項の実装において、認識可能でない及び／又はビジブルでないトランザクションは、典型的には、コミットされていないトランザクション（例えば、図５に示されるコミットされていないトランザクション１４５）である。トランザクションがトランザクション・カウンタ番号及び／又はトランザクション番号のうち少なくとも１つを有する場合、トランザクションはクエリにとって認識可能及び／又はビジブルであり得る。トランザクションは認識可能及び／又はビジブルでない場合、トランザクション・ロックがトランザクション番号に関して据えられ、そのためトランザクションは変更されず、操作されず、及び／又はクエリにとって認識可能にされてもよく、なぜならトランザクションはレコードにコミットされるように処理されているからである。

幾つかの実装において、方法２０は選択的なオペレーション２１を含み得る。選択的なオペレーション２１において、トランザクション識別子（例えば、サーバー・システムに保存されるレコードのアップデート各々に関連付けられるトランザクション番号又は他の適切な識別子）はサーバー・システム（例えば、図５に示されるサーバー・システム１００）によりハッシュされてもよい。ハッシュに対する代替として、サーバー・システム（図５に示されるサーバー・システム１００）は、オペレーション２１において、トランザクション識別子の直接的なルックアップを実行してもよい。（例えば、コミットされていないトランザクション１４５のトランザクション１４６，１４７，１４８及び／又は１４９のような）トランザクション識別子のバケットが、オペレーション２２において、レコード・チェーンに対するアクセスを制御するためにラッチされてもよい。ハッシュ・オペレーションがオペレーション２１において実行された場合、バケットは（例えば、図５に示されるような値１５５，１５６，１５７，及び／又は１５８のうちの一部であってもよいし、又はトランザクション１４６，１４７，１４８，及び／又は１４９のうちの一部分であってもよい）トランザクション識別子のハッシュを含むことができ、トランザクション識別子をハッシュすることによる如何なるハッシュ衝突もオペレーション２２において解決され得る。オペレーション２４において、（例えば、図５に示されるトランザクション番号マネージャ１３０により）トランザクション・カウンタ番号が、データを識別するトランザクション・ヘッダにおいて、トランザクション番号に対して設定され得る。オペレーション２６において、バケットはアンラッチされ（又はラッチ解除され）、（例えば、リード・オペレーションで使用されてもよい）トランザクション・カウンタ番号が、（例えば、トランザクション番号マネージャ１３０及び／又はストレージ・マネージャ１３５により）更新されてもよい。オペレーション２８において、トランザクション番号に関するトランザクション・ロック（例えば、トップ・レベルのトランザクション・ロック）は、トランザクション番号をアンブロックするためにトランザクション・マネージャにより開放されてもよい。これは、レコードに対するトランザクションをコミットすることができ、トランザクションが、クエリに対して認識可能及び／又は視察可能であることを許容し得る。

幾つかの実装において、オペレーション２４においてデータを識別するトランザクション・ヘッダにおいてトランザクション・カウンタ番号を設定することは、トランザクションに関連する全ての行ロックを解放することを更に含んでもよい。データを識別するトランザクション・ヘッダにおいてトランザクション・カウンタ番号を設定することは、１つ以上のクエリにとってトランザクションをビジブルにすることができる。

図３はトランザクションがサーバー・システムによりビジブル及び／又は認識可能である場合に（即ち、クエリに対してビジブルである場合に）レコードに対するトランザクションをコミットする開示される対象事項の実装による方法例３０を示す。即ち、方法３０は、トランザクションにより影響を受けるデータベースの行を訪れ、そしてそれらにトランザクション制御番号でスタンピングすることにより、トランザクションのためのコミット・タイム処理のオペレーションを実行することに関連する。方法３０は、複数のトランザクションのためのコミット・タイム処理を実行するために使用されてもよく、そのため、コミット・タイム処理されるために比較的長い時間がかかり得るより大きなトランザクションは、より小さな他のトランザクションとともに処理されてもよく、従って本願ではなく従来技術を利用する場合に可能になるものより比較的短い時間しかかからないであろう。オペレーション３２において、（例えば、図５に示されるトランザクション番号１９１，１９２，１９３，１９４，１９５，１９６，１９７，及び／又は１９８等の）トランザクション識別子のハッシュ・バケットは、（例えば、ストレージ１４０に保存され得る）レコード・チェーンへのアクセスを制御するためにラッチされ得る。データを識別するトランザクション・ヘッダにおいて現在のキー・ハッシュ値と現在のシーケンス番号とは、オペレーション３４において、（例えば、トランザクション番号マネージャ１３０及び／又はストレージ・マネージャ１３５により）設定されることができ、そしてハッシュ・バケットは、オペレーション３６において、（例えば、トランザクション番号マネージャ１３０及び／又はストレージ・マネージャ１３５により）トランザクション識別子に関してアンラッチされてもよい。シーケンス番号は、行バージョン・レコードにおける位置のロケーションであってもよい。現在のシーケンス番号は、サーバー・システムによりレビューされる行バージョン・レコードのうちの現在の位置であってもよい。オペレーション４０において、サーバー・システムは、行ロック・レコード及び行バージョン・レコードから、（例えば、ストレージ１４０の行レコード・バージョン１６０等における、行ロック・レコード又は行バージョン・レコードを識別する情報などの）行識別子が存在するか否かを判断することができ、ここで、トランザクション番号はトランザクション識別子と同一であり、シーケンス番号はサーバー・システムによりレビューされる現在のシーケンス番号と同一である。トランザクション番号はトランザクション識別子と同一であり、シーケンス番号はサーバー・システムによりレビューされる行における現在のシーケンス番号と同一であると判断される場合、オペレーション４２において、現在の行バージョン・レコードをコミット済みとしてマークするために、トランザクション・カウンタ番号が現在の行バージョン・レコード（例えば、図５に示されるトランザクション番号マネージャ１３０によりレビューされる現在の行）にスタンプされ得る。

開示される対象事項の幾つかの実装において、行識別子がトランザクション識別子に等しくない場合、又は行識別子がトランザクション識別子に等しく且つ行識別番号が現在のシーケンス番号以上である場合、（例えば、図３に示される方法３０のオペレーション４４，４６，及び／又は４８に従って）サーバー・システム１００は、ストレージ１４０のレコード（例えば、レコード・バージョン１６０等）のうちの次の行バージョンに移動することができる。

オペレーション４４は、前のシーケンス番号が存在するか否かを判断することができる。前のシーケンス番号が存在する場合、オペレーション４６は、前のシーケンス番号を、現在のシーケンス番号であると設定することができる。前のシーケンス番号が存在しない場合、方法３０は、オペレーション４８によりストップさせられる。

幾つかの実装において、トランザクション番号がトランザクション識別子と同一であり、シーケンス番号が、行ロック・レコードのうちの１つに対する現在のシーケンス番号と同一である場合、その行ロック・レコードのうちの１つはストレージ・デバイス（例えば、図５に示されるストレージ１４０）から除外されてもよい。即ち、（例えば、図５に示されるトランザクション番号マネージャ１３０により）トランザクション・カウンタ番号が現在の行バージョン・レコードにスタンプされ、現在の行バージョン・レコードがコミット済みとしてマークされ得る場合（即ち、オペレーション４２において）、行ロックは除外及び／又は解放され得る。

開示される対象事項の幾つかの実装において、方法３０は、現在のキー・ハッシュを前のキー・ハッシュに設定し、現在のシーケンス番号を前のシーケンス番号に設定し、キー・バケットをアンラッチすることを含んでもよく、ここで、ラッチはストレージ１４０におけるレコード・チェーンへのアクセスを制御する。幾つかの実装において、方法３０は、ダイレクト・ルックアップ・キー（ａ ｄｉｒｅｃｔ ｌｏｏｋ−ｕｐ ａ ｋｅｙ）を実行することができ、次いで現在のシーケンス番号を前のシーケンス番号に設定し、キー・バケットをアンラッチすることができる。前のシーケンス番号が末端値に到達した場合、レコード・チェーンのレビューは（例えば、トランザクション番号マネージャ１３０及び／又はストレージ・マネージャ１３５により）停止させられる。前のシーケンス番号が末端値でない場合、レコード・チェーンのうちの新たな行バージョン・レコードが（例えば、トランザクション番号マネージャ１３０により）レビューされ得る。

開示される対象事項の方法３０はまた、トランザクション識別子をハッシュし、トランザクション識別子をハッシュすることからの如何なるハッシュ衝突も解決することを含み得る。幾つかの実装では、トランザクション識別子をハッシュするのではなく、サーバー・システム（例えば、図５に示されるサーバー・システム）は、トランザクション識別子のダイレクト・ルックアップを実行してもよい。

図４Ａ−４Ｂは開示される対象事項の実装に従ってレコードにおけるトランザクションをルックアップする方法例を示す。図４Ａは、行がコミットされているか否かを判断するためにレコードの中の行をサーチする方法例５０を示す。行がコミットされていない場合、トランザクション・ヘッダが検査されることが可能であり、それをコミットされるものとしてマークするために、現在の行バージョン・レコードにトランザクション・カウンタ番号がスタンプされることが可能である。即ち、方法５０は、レコードに対してコミットされていない行におけるルックアップ・オペレーションを実行することに関連する。典型的なデータベース・システムは、コミットされていない行におけるルックアップ・オペレーションを提供せず、コミットされた行におけるルックアップ・オペレーションに限定されている。

方法５０のオペレーション５２において、キーは（例えば、図５に示されるサーバー・システム１００等の）サーバー・システムによりハッシュされ得る。オペレーション５４において、キー・ハッシュ・バケットはキーのためにラッチされ、ハッシュからの任意の衝突は解決され得る。オペレーション５６において、レコードのうちのキーの行バージョン・チェーンは、（例えば、トランザクション番号マネージャ１３０及び／又はストレージ・マネージャ１３０により）サーチされ、スナップショット・トランザクション・カウンタ番号と、キーの自己識別番号と、ストレージ１４０に保存され得るコマンド識別ステートメントとに基づいて、最も新しいビジブルな行バージョン・レコードを決定することができる。スナップショット・トランザクション・カウンタ番号は、特定の時点でレコードのスナップショットに関連するトランザクション・カウンタ番号であってもよい。即ち、スナップショットは特定の時点におけるレコードのステータス及び／又はデータを決めることができる。キーの自己識別番号は、特定のキーを識別するために使用される番号であってもよい。コマンド識別ステートメントは、サーバー・システムにより実行されるサブトランザクション・プロセスを指定するために使用され得る。コマンド識別ステートメントの値に応じて、トランザクションはビジブル及び／又は認識可能（即ち、クエリにとってビジブル及び／又は認識可能）であり得る。

図４Ｂは、図５に示されるストレージ１４０内のレコードのうちのキーの行バージョン・チェーンを検索し、オペレーション５６における最新のビジブルなレコードを決定することに含まれ得るオペレーション例を示す。即ち、図４Ｂに示される方法は、最新の認識可能及び／又はビジブルな行においてルックアップ・オペレーションを実行することに仕向けられている。オペレーション５８において、例えば、行の中のデータの情報を識別するトランザクション・ヘッダに基づいて、行がアンコミットされているか否か、及び/又は行がロックされているか否かが判断される。オペレーション５８において、行がアンコミットされ、そのためロックが存在しないと判断された場合（例えば、アンコミットされたトランザクション）、トランザクション・カウンタ番号値は、オペレーション６０において、情報を識別するトランザクション・ヘッダから読み出されてもよい。オペレーション６２において、トランザクション・カウンタ番号が有効である場合、トランザクション・カウンタ番号が、（例えば、トランザクション番号マネージャ１３０によって）現在の行バージョン・レコードにスタンプされてもよく、現在の行バージョン・レコードは、コミットされたものとしてマークされ得る。トランザクション・カウンタは、トランザクション・カウンタ番号と同じ行トランザクション・カウンタを有することによって有効であり得る。図５に示されるように、コミットされたトランザクションは、ストレージ１４０のレコード・バージョン１６０に保存されてもよい。オペレーション５８が、行バージョンはコミットされている、又はオペレーション６２が完了していると判断すると、オペレーション６４は、行バージョンがＭＶＣＣスナップショットにとってビジブルであるか否か（例えば、行バージョンがＭＶＣＣスナップショットの一部として使用されるか否か）を決定することができる。オペレーション６４が、行バージョンはＭＶＣＣスナップショットにとってビジブルであると判断した場合、オペレーション７０は、サーチを停止してもよい。オペレーション６４が、行バージョンはＭＶＣＣスナップショットにとってビジブルでないと判断した場合、オペレーション６８は、もし存在するならば次の行バージョンへ進み、オペレーション５８を実行する、又は次の行バージョンが存在しないならばサーチを停止することができる。

図４Ａ−４Ｂに示される方法５０では、キーをサーチする際に、レコードのチェーンは横断され得る（即ち、本方法は、レコードのチェーンを「歩く（ｗａｌｋ）」ことができる）。図４Ａ−４Ｂに示される方法は、コミットされた行及びコミットされていない行の両方で実行されるルックアップ・オペレーションを提供することができる。サーチされているキーがレコードのチェーン内のある地点で発見されると、方法５０は、その行がアンコミットされているか否かを判断し、もしそうであるならば、ヘッダ情報を読み出し、現在の行バージョン・レコードにトランザクション・カウンタ番号をスタンプして、それをコミット済みにするようにしてもよい。サーチされるキーがレコードのチェーン内のある地点で発見され、その行がコミットされると、サーチは停止させられてよい。レコードのチェーンが全体的に横断され、キーが発見されない場合（即ち、本方法がレコードのチェーンの全長を「歩いている」場合）もまた、方法６０は停止させられてもよい。

図５は、開示される対象事項の実装に従うトランザクション番号の割り当てに適したシステム例の機能ブロック図を示す。例えば、サーバー・システム１００は、Ａｐａｃｈｅ Ｈａｄｏｏｐに関連して動作するＰｏｓｔｇｒｅｓ、Ｍｙｓｑｌ又はオラクル・データベース１２ｃ等の適切なデータベース管理システムの一部であってもよい。サーバー・システム１００は、トランザクション・カウンタ１１０、クロック１２０、ロック・マネージャ１２５、トランザクション番号マネージャ１３０、ストレージ・マネージャ１３５、ログ・マネージャ１３８、及びストレージ１４０を含むことができる。サーバー・システム１００は、カウンタ１１０、クロック１２０、ロック・マネージャ１２５、トランザクション番号マネージャ１３０、記憶マネージャ１３５、ログ・マネージャ１３８、及びストレージ１４０を実装するための、例えば図１０に記載されるようなコンピュータ６００、又はそのコンポーネントのような任意の適切なコンピューティング・デバイスであってもよい。サーバー・システム１００は、単一のコンピューティング・デバイスであってもよく、又は複数の接続されたコンピューティング・デバイスを含んでもよく、例えば、ラップトップ、デスクトップ、個々のサーバー、サーバー・クラスタ、サーバー・ファーム、又は分散型サーバー・システムであってもよく、又は仮想コンピューティング・デバイス又はシステム、又は物理的及び仮想的なシステムの任意の適切な組み合わせであってもよい。簡明化のために、プロセッサ、短期及び長期ストレージ、オペレーティング・システム、データベース管理システムの大部分などの一般的なコンポーネントは示されていない。サーバー・システム１００は、コンピューティング・システム及びネットワーク・インフラストラクチャの一部であってもよく、又は他の方法では、サーバー・システム１００に類似する他のサーバー・システムを含み得るより大きなサーバー・ネットワークを含むコンピューティング・システム及びネットワーク・インフラストラクチャに接続されてもよい。

サーバー・システム１００のトランザクション・カウンタ１１０は、トランザクション・カウンタ番号の値を記憶及び更新するためのサーバー・システム１００上のハードウェア及びソフトウェアの任意の適切な組み合わせであり得る。クロック１２０は、所望の精度の時間値で、現在の時間又はある時点から経過した時間のような、時間を追跡するためのサーバー・システム１００上のハードウェア及びソフトウェアの任意の適切な組み合わせとすることができる。ロック・マネージャ１２５は、トランザクション番号ハッシュ・バケット及び／又はコミットされていないトランザクション１４５及び／又はレコード・バージョン１６０のキー・ハッシュ・バケットのロック及び／又はアンロックを管理するために、サーバー・システム１００におけるハードウェア及びソフトウェアの適切な組み合わせであるとすることができる。トランザクション番号マネージャ１３０は、トランザクションがサーバー・システム１００でコミットされた場合に、又はトランザクションがコミットされた順序でトランザクションにトランザクション番号を割り当て、カウンタ１１０及びカウンタ番号の値を管理するために、サーバー・システム１００におけるハードウェア及びソフトウェアの任意の適切な組み合わせであるとすることができる。ストレージ・マネージャ１３５は、サーバー・システム１００のストレージからレコードを検索するためのハードウェアとソフトウェアの任意の適切な組み合わせであってもよく、例えば、ストレージ１４０を含んでもよいデータベース管理システムに一般的に見られるようなものであってもよい。ストレージ・マネージャ１３５は、キーと時間値又はキーとトランザクション番号を含み得るリクエストに応答して、レコードのバージョンを検索することができる。ログ・マネージャ１３８は、ロック・マネージャ１２５、トランザクション・ナンバー・マネージャ１３０、及び／又はストレージ１４０の状態を記録するために、サーバー・システム１００におけるハードウェア及びソフトウェアの適切な組み合わせとすることができる。ログ・マネージャ１３８は、例えば、トランザクションのレコード・チェーン内の１つ以上のレコードの挿入を記録することができる。トランザクション番号、プライマリ・キー値、及び／又は行の値が、レコードの一部としてログに記録され得る。ストレージ１４０は、コミットされていないトランザクション１４５及びレコード・バージョン１６０を保存するためのサーバー・システム１００における任意の適切なストレージであってもよい。レコード・バージョン１６０は、サーバー・システム１００の１つ以上のユーザー又はテナントのためのデータベース用のレコードのバージョンであってもよい。

サーバー・システム１００、及びテナントのためのデータベースは、所与のレコードの不変バージョン（ｉｍｍｕｔａｂｌｅ ｖｅｒｓｉｏｎｓ）としてトランザクションを記憶することができる。サーバー・システムにすでに保存されているレコードの不変バージョンは、それらが（あったとしても）サーバー・システムから削除されるまで、変更されないであろう。即ち、受信したトランザクションは、レコードの既存のバージョンに保存されているデータを変更する代わりに、サーバー・システムに格納されることになるレコードの新しいバージョンを作成することができる。従って、ここで開示されるようなレコードの複数のバージョンに対して、同一のキーを有することが可能である。所与のレコードのバージョンに対して同一のキーを使用することは、リレーショナル・データベースに保存されるデータの変更を許容し得る。このようなレコードの各バージョンは不変であってもよい；即ち、レコードは決して削除されない、あるいは、数カ月、数年、数十年であってもよい任意の長期間にわたって削除されない。たとえば、レコードの先行バージョンと同じキーを有するレコードの後バージョンは、そのレコードのデータ値の変化を示し得る。代替的に、トランザクションはレコードを作成したり又はレコードを削除したりしてもよいが、レコードの削除は、トランザクションを排除しなくてもよい。

トランザクション・カウンタ１１０は、カウンタ番号の値を格納及び更新するためのハードウェア及びソフトウェアの任意の適切な組み合わせであってもよい。トランザクション・カウンタ１１０は、例えば、ハードウェア又はソフトウェア・レジスタ、又はサーバー・システム１００における他の形態のメモリであってもよく、任意の適切なサイズのカウンタ番号を保存してもよい。トランザクション・カウンタ１１０は、コンピュータ・システム１００によってコミットされるトランザクションに対する重複トランザクション番号を防止することができ、厳密に増加又は減少するトランザクション番号を提供することができる。例えば、カウンタ番号は６４ビット番号として記憶されてもよい。トランザクションがコミットされた場合にトランザクションに割り当てられるトランザクション番号は、トランザクション・カウンタ１１０等のカウンタに基づいてもよい。あるいは、トランザクション番号は、２つの別個のフィールドを含んでもよい。第１のフィールドは、タイム・スタンプを表すことができ、カウンタは、最後のタイム・スタンプ以降のトランザクション数を表し得る第２のフィールドを提供する。タイム・スタンプとタイム・スタンプ以降のトランザクション数を示すトランザクション・カウントとの双方を伴うトランザクション数は厳密に増加するであろう。そのような実装では、コミットされるトランザクションは、トランザクションに関連付けられる又は割り当てられる固有のトランザクション番号を有するであろう。

トランザクション・カウンタ１１０は、カウンタ番号の値を更新することが可能であってもよい。トランザクションをコミットする際に、トランザクション番号が割り当てられた後、カウンタ番号の値は、任意の適切な量だけインクリメントされてもよい。例えば、カウンタ番号の値は、同期イベントが発生していない限り、１又は１より大きな整数だけ増加されてもよい。２つのトランザクション番号が同一でなく、それらが厳密に増加又は減少している限り、連続的に割り当てられるトランザクション番号の間に、いかなる大きさのギャップがあってもよい。サーバー・システムでコミットされる各トランザクションは、カウンタ番号の現在の値に基づいてトランザクション番号を割り当てられ、次いでインクリメントされてもよく、そのため、次のトランザクションは、コミットされる前に、インクリメントされた番号を割り当てられ得る。

例えば、カウンタ番号の値は、トランザクションがコミットされる場合又はトランザクションがコミットされる直前に、トランザクション番号を、コミットされていないトランザクション１４５のうちの１つ、例えばトランザクション１４６に割り当てるために使用され得る。トランザクション・カウンタ１１０からのカウンタ番号の値がトランザクション番号を割り当てるために使用された後、トランザクション・カウンタ１１０は、例えばカウンタ番号を任意の適切な量だけ厳密にインクリメント（又は厳密にデクリメント）して、カウンタ番号の値を更新することができてもよい。また、トランザクション・カウンタ１１０は、例えば、トランザクション番号マネージャ１３０又はクロック１２０から受信されるカウンタ番号の新しい値に基づいて、カウンタの値を更新することが可能であってもよい。例えば、トランザクション・カウンタ１１０は、何らかのトランザクションがサーバー・システム１００でコミットされる前に、初期同期の間のクロックの時間値に基づいてカウンタ番号の初期値を設定することができる。

クロック１２０は、任意の適切な精度の時間値で、現在の時間又はある時点から経過した時間などのような時間を追跡するためのハードウェア及びソフトウェアの任意の適切な組み合わせであり得る。例えば、クロックは、ソフトウェア・システム・クロック、ハードウェア・クロック、又は既知の周波数で発振する信号に基づいて更新するカウンタであってもよい。例えば、クロックは、６４ビットマイクロ秒カウンタであってもよく、これは、クロックが約５８４，５５０年にわたって固有の値を提供することを意味する。クロックによって保存される時間値は、任意の適切な方法で現在の時間を表すことができる。例えば、時間値は、あらかじめ指定されたある時点から経過した時間の量をマイクロ秒で示してもよく、また、そのあらかじめ指定された時点に基づいて現在の時間に変換することが可能であってもよい。クロック１２０は、任意の適切な時間又はインターバルで、任意の適切な外部クロックと同期してもよく、又は外部同期なしに、内的に時間を保持するだけでああってもよい。

ロック・マネージャ１２５は、トランザクションのロック及び／又はアンロック、トランザクション番号ハッシュ・バケット、及び／又はコミットされていないトランザクション１４５及び／又はレコード・バージョン１６０のキー・ハッシュ・バケットを管理するためのサーバー・システム１００におけるハードウェア及びソフトウェアの適切な組み合わせであり得る。ロック・マネージャは、コミットされていないトランザクション１４５（例えば、トランザクション１４６、１４７、１４８、及び／又は１４９）、及び／又はキー１５１、１５２、１５３、及び／又は１５４のうちの１つ以上をロック及び／又はアンロックすることができる。幾つかの実装において、ロック・マネージャ１２５は、レコード・バージョン１６０（例えば、レコード・バージョン１６１、１６２、１６３、１６４、１６５、１６６、１６７、及び／又は１６８）のロック及び／又はアンロックを制御することができる。

トランザクション番号マネージャ１３０は、ハードウェアの任意の適切な組み合わせであってもよく、トランザクションがサーバー・システム１００においてコミットされたときにトランザクションにトランザクション番号を割り当て、そしてトランザクション・カウンタ１１０及びカウンタ番号の値を管理する。トランザクション番号マネージャ１３０は、トランザクションがコミットされることとなる際に、トランザクション番号を、トランザクション１４６、１４７、１４８、又は１４９の内のいずれか等のコミットされていないトランザクション１４５に割り当てることができる。コミットされるアンコミット・トランザクション１４５のうちの１つに割り当てられるトランザクション番号は、トランザクション・カウンタ１１０により保存されるカウンタ番号の値に基づいてもよい。例えば、トランザクション番号は、カウンタ番号の現在の値であってもよい。カウンタ番号の値に基づいてトランザクション番号が割り当てられた後、カウンタ番号の値は更新され得る。トランザクション・カウンタ１１０は、それ自体でカウンタ番号の値を更新することが可能であってもよく、あるいはトランザクション番号マネージャ１３０は、トランザクション・カウンタ１１０に、カウンタ番号の値を更新させることが可能であってもよい。また、トランザクション番号マネージャ１３０は、トランザクション・カウンタ１１０に、任意の適切なイベントに基づいてカウンタ番号の値を更新させてもよい。

ストレージ・マネージャ１３５は、サーバー・システム１００から、例えばストレージ１４０から、レコードを検索するためのハードウェア及びソフトウェアの任意の適切な組み合わせであるとすることができる。ストレージ・マネージャ１３５は、キー及び時間値を含み得るリクエストに応答してレコードを検索することが可能であってもよい。例えば、ストレージ・マネージャ１３５は、例えばサーバー・システム１００の所与のテナントに関連付けられるユーザーから、レコードを検索するためのリクエストを受信することができる。リクエストは、キーと時間値とを含み得る。ストレージ・マネージャ１３５は、例えば、トランザクション番号が、ここで開示されるような時間値又は近似的な時間値である又はそれらを含む場合に、リクエストに応答する、レコード・バージョン１６０からのレコードの適切なバージョンを検索することが可能であってもよい。ストレージ・マネージャ１３５は、ストレージ１４０内のレコード・バージョン１６０のうちの何れが、受信したリクエストからのキーに合致するキーと、リクエストの時間の値以下、又は同時もしくはそれよりも早い時点のトランザクション番号とを含むかを決定することが可能であってもよい。幾つかの実装において、レコード・バージョン１６０は不変レコードであってもよい。ストレージ・マネージャ１３５は、レコード・バージョン１６０のうちの何れが、同一のキーを有するレコードのグループの中で、リクエストの時間値によって指定される時間において現在のレコードとなるか、あるいはリクエストに応答し得るかを決定することが可能であってもよい。例えば、同一のキーを持つレコードのバージョンのグループからのレコード又はトランザクションの応答バージョンは、リクエストの時間値より大きくない最高のトランザクション番号を持つグループからのレコードのバージョンであってもよい。ストレージ・マネージャ１３５は、レコード・バージョン１６０からのレコードの応答バージョンを、リクエストを提出した当事者、例えばテナントに送ることが可能であってもよい。

例えば、ストレージ・マネージャ１３５は、例えばサーバー・システム１００の所与のテナントに関連付けられたユーザーから、レコードを検索するためのリクエストを受信することができる。リクエストは、コミットされていないトランザクション（例えば、トランザクション１４６、１４７、１４８、及び／又は１４９等の１つ以上のコミットされていないトランザクション１４５）に対するものであってもよい。幾つかの実装形態では、ストレージ・マネージャ１３５は、トランザクション番号マネージャ１３０と通信し、リクエストが受信される場合に、新しいＭＶＣＣスナップショットとして新しいトランザクション・カウンタ番号（例えば、コミットされていないトランザクションに対するもの）を使用することができる。これは、図１及び図２に関連して、ならびに以下に説明する動作例に関連して、説明されている。

ログ・マネージャ１３８は、トランザクションのレコード・チェーン内の１つ以上のレコードの挿入のログを記録するために、サーバー・システム１００におけるハードウェア及びソフトウェアの適切な組み合わせであり得る。トランザクション番号、プライマリ・キー値、及び／又は行の値は、レコードの一部としてログに記録され得る。即ち、ストレージ１４０内のレコードの状態は、トランザクション及び／又はトランザクションの処理の一部として変化することができ、ログ・マネージャは、レコードの挿入を含むレコードへの変更のログを記録することができる。動作例に関連して以下に説明するように、ログ・マネージャ１３８は、トランザクションをコミットするためにコミット・レコードをログに記録してもよく、及び／又は中止されたトランザクションに対するアボート・トランザクションをログに記録してもよい。

ストレージ１４０は、コミットされていないトランザクション１４５及びレコード・バージョン１６０をサーバー・システム１００で記憶するためのハードウェア及びソフトウェアの任意の適切な組み合わせであり得る。ストレージ１４０は、例えば、ハード・ディスク・ドライブ、ソリッド・ステート・ドライブ、光メディア、フラッシュ・メモリ、テープ・ドライブ、レジスタ、及びランダム・アクセス・メモリを含む任意の適切な揮発性及び不揮発性の物理ストレージ媒体の任意の適切な組み合わせを使用することができる。コミットされていないトランザクション１４５及びレコード・バージョン１６０等のデータは、任意の適切なファイル・システム又はストレージ・スキーム又は階層を使用して、任意の適切なフォーマットで記憶され得る。例えば、ストレージ１４０は、複数のレベルを有するログ構造化マージ（ＬＳＭ）ツリーを使用してデータを記憶することができる。さらに、システム１００が複数テナント・システムである場合、ストレージは、テナントのためのデータベースの各インスタンスについて、別個のログ構造マージ・ツリーに組織化されてもよい。あるいは、特定のサーバー又はシステムにおける全てのレコードは、単一のログ構造化マージ・ツリー内に格納されてもよく、その場合、レコードのバージョンに関連する固有のテナント識別子は、ここで開示されるように、各テナントのデータを区別するために使用されてもよい。より最近のトランザクションは、ツリーの最高又は最上位レベルに格納され、古いトランザクションはツリーの下位レベルに格納されてもよい。あるいは、各レコードの最新のトランザクション又はバージョンは、ツリーの最高レベルに、以前のバージョン又は以前のトランザクションは、ツリーの下位レベルに格納されてもよい。

コミットされていないトランザクション１４５は、例えばコミットされていないテナント等のサーバー・システム１００のユーザーから受信されるトランザクションであってもよい。コミットされていないトランザクション１４５のトランザクション１４６、１４７、１４８、１４９の各々は、トランザクション番号マネージャ１３０によって割り当てられるようなトランザクション番号を含み得るヘッダを含むことができる。あるいは、トランザクションのヘッダ情報（例えば、値１５５、１５６、１５７、及び／又は１５８）は、値（例えば、値１５５、１５６、１５７、及び／又は１５８）の一部として含まれてもよい。

コミットされていないトランザクション１４５のトランザクション１４６、１４７、１４８、及び１４９の各々は、キー１５１、１５２、１５３、及び１５４と、値１５５、１５６、１５７、及び１５８とを含むことができる。キー１５１、１５２、１５３、及び１５４は、トランザクション１４６、１４７、１４８、及び１４９に対するそれぞれのレコードと、トランザクション１４６、１４７、１４８、及び１４９のコミットに基づいて格納されるレコードのバージョンとに対する識別子であり得る。キー１５１、１５２、１５３、及び１５４は、例えば英数字シーケンス等の任意の適切な形態であってもよい。キー１５１、１５２、１５３、及び１５４の一部は、例えば、トランザクションをサブミットしたテナントを一意に識別し得るテナント識別子、テーブル番号及び行の識別子、例えば、レコード値が行の内容である場合、テーブル番号、テーブルのインデックス番号、そして値が行の識別子である場合、インデックスされる列の識別子であってもよい。値１５５、１５６、１５７、及び１５８は、例えば、それぞれのトランザクション１４６、１４７、１４８、及び１４９に対する、リレーショナル・データベースのテーブルの行の内容、リレーショナル・データベースのテーブルの行の識別子、又は他の任意の適切な値であり得る。

コミットされていないトランザクション１４５は、まだコミットされておらず且つレコード・バージョン１６０のレコードのバージョンとして保存されていないトランザクションであり得る。コミットされていないトランザクション１４５のうちの１つであるトランザクションは、トランザクションがまだレコードのバージョンとして保存されていないかもしれないので、トランザクションをサブミットしたテナントのためのライブ又はプロダクション・データベースでは見えないにかもしれない。

レコード・バージョン１６０は、コミットされていないトランザクション１４５からトランザクションをコミットした結果生じるレコードのバージョンであってもよい。コミットされていないトランザクションがコミットされると、トランザクションは、トランザクション番号を割り当てられる又はそれに関連付けられることができ、レコードのバージョンが、キー及びトランザクションからの値とともに、レコード・バージョン１６０に保存され得る。例えば、トランザクション１４６がコミットされた場合、キー１５１及び値１５５を伴うレコードのバージョンが、レコード・バージョン１６０に保存されてもよく、コミット中にトランザクション１４６に割り当てられたトランザクション番号に関連付けられてもよい。レコード・バージョン１６１、１６２、１６３、１６４、１６５、１６６、１６７、及び１６８の各々は、個々のキー１７１、１７２、１７３、１７４、１７５、１７６、１７７、及び１７８と、値１８１、１８２、１８３、１８４、１８５、１８６、１８７、及び１８８とを含むことができ、各自のキー及び値に基づくことができる各自のトランザクション番号１９１、１９２、１９３、１９４、１９５、１９６、１９７、及び１９８に関連付けられ、トランザクション番号は、コミットされる際にレコード・バージョン１６１、１６２、１６３、１６４、１６５、１６６、１６７、及び１６８として保存されたトランザクションに割り当てられる。トランザクション番号は、特定のトランザクションがコミットされる場合に、各々のトランザクションとともに、厳密に増加（又は厳密に減少）し得る。

幾つかの実装において、トランザクション１６１等のトランザクションは、複数のレコードの値への変更を示す複数のキー又はキー範囲を含んでもよく、そしてトランザクションに含まれる各キーの値を含んでもよい。例えば、単一のトランザクションは、テナントのデータベースにおけるテーブル内のある行数に関するキーと、各行数に対する値とを含み得る。１つより多いキーを含むコミットされていないトランザクションをコミットすることは、トランザクションに含まれる各キーについて保存されるレコードのバージョンをもたらす結果となり得る。トランザクションは、１つのトランザクション番号を割り当てられてもよく、そしてトランザクションがコミットされる場合に保存されるレコードの各バージョンは、同じトランザクション番号を受けることができる。１つのトランザクションは重複するキーを含み得ず、同じレコードの２つのバージョンが同じトランザクション番号を有することを防止する。トランザクション・カウンタ１１０及び／又はトランザクション番号マネージャ１３０は、トランザクションをサブミットしたテナントについて固有のテナント識別子を使用して、トランザクションに基づいて保存されたレコードの各バージョンに対するキーを生成することができる。

システム１００が、例えば、マルチテナント・データベースである場合、レコード・バージョン１６０は、サーバー・システム１００の任意数の様々なテナントに帰属することができる。例えば、レコード・バージョン１６１、１６２、１６４、及び１６８は、第１テナントの第１インスタンスに属するレコードのバージョンであってもよい一方、レコード・バージョン１６３、１６５、１６６、及び１６７は、第２テナントのインスタンスに属するレコードのバージョンであってもよい。レコードへのアクセス、及びレコードのバージョンとして記憶されるトランザクションは、レコード・バージョン１６０のキーによって制御され得る。例えば、キー１７１、１７２、１７４、及び１７８の各々は、第１テナントのための固有のテナント識別子を含んでもよく、テナントに関連する第１テナント又はユーザーとってアクセス可能であるだけであってもよく、そのレコードへのアクセス又は検索のリクエストは、典型的には、固有のテナント識別子を含む又は参照するキーを含むことになるであろう。これは、第１テナントに対して固有のテナント識別子を有するキーを含むレコードを求めるリクエストを、第２テナントは提出し得ないので、第２テナントが、レコード・バージョン１６１、１６２、１６４、及び１６８にアクセスすることを防止することができる。しかしながら、たとえ複数のトランザクションが異なるテナントに対するものであり、トランザクションの順序が、異なるテナントのトランザクションの間で切り替わりを維持していたとしても、トランザクション番号は、コミットされたトランザクションが異なるテナントに対するものであり得たとしても、厳密に増加（又は厳密に減少）し得る。

サーバー・システム１００のストレージ１４０内のテナントに属するレコード・バージョン１６０は、そのテナントのためのデータベースのデータであってもよい。例えば、レコード・バージョン１６１、１６２、１６４、及び１６８は、第１テナントのためのライブ又はプロダクション・データベースのインスタンスのレコードのバージョンであってもよい。レコード・バージョン１６１、１６２、１６４及び１６８の最新バージョンと、レコードのバージョンとして保存された何らかの最新でない取って代わったトランザクションとは、取って代わったトランザクションが現在のトランザクションである場合に前の時間で見えたように、第１テナントが、それらのデータベースの全部又は一部を見ることを許容し得る。同様に、レコード・バージョン１６３、１６５、１６６、及び１６７は、第２テナントのためのデータベースのレコードのバージョンであってもよい。ストレージ１４０は、任意数のテナントのためのデータベースのレコードのバージョンを含んでもよいが、レコード・バージョン自体は、サーバー・システム１００のストレージ１４０によって使用されるファイル・システム、ストレージ・スキーム、又は階層におけるテナントによる分離を伴わずに一緒に保存されてもよい。幾つかの実装において、サーバー・システム１００のストレージ１４０内のテナントに属するレコード・バージョン１６０は、サーバー・システム１００が一部であるより大きなサーバー・ネットワークにおけるテナントのためのライブ又はプロダクション・データベースのための全てのレコード・バージョンを含むことができる。

サーバー・システム１００は、より大きなサーバー・ネットワークの一部であってもよく、これは、例えば他のポッド又はデータ・センター等の他の物理的なロケーションにある他のサーバー・システム又はサーバー・システムのクラスタを含んでもよい。より大きなサーバー・ネットワーク内で、特定の目的に関して単一のテナントに属するレコードは、そのテナントのためのライブ又はプロダクション・データベースを本質的に形成し、ネットワーク内のノードにおける単一のサーバー・システムに存在することができる。より大きなサーバー・ネットワーク内の他の任意のサーバー・システムに保存される、テナントのライブ又はプロダクション・データベースの一部又は全部のコピーを含むテナントに属するレコードのトランザクションは、テナントのライブ又はプロダクション・データベースの一部ではなく、そして遠く離れたロケーションでのより速い読み込みアクセスの目的で、サンドボックス化、テスト、トレーニング、分析、バックアップ及び冗長アクセス、又はローカル・キャッシュのために使用されるだけであってもよく、そしてテナントのライブ又はプロダクション・データベースとは考えられなくてもよい。より大きなサーバー・ネットワーク内の各サーバー・システム又はサーバー・クラスタは、トランザクション番号の識別子を割り当てるために、それ自身のカウンタ及び現在のカウンタ番号を有してもよい。あるいは、カウンタ及びカウントは、サーバー又はサーバー・クラスタのストレージ・エリア・ネットワーク又はＳＡＮに維持されることが可能である。

例えばサーバー・システム１００等のサーバー・システムにおける、例えばトランザクション・カウンタ１１０等の同じカウンタ、及びカウンタ番号は、サーバー・システムにおいてライブ・インスタンスを有する全てのテナントに対してコミットされるトランザクションにトランザクション番号を割り当てるために使用され得る。これにより、サーバー・システムによってコミットされるレコードの全てのバージョンに関連するトランザクション番号が一意であり、そしてサーバー・システムにおけるレコードの全てのバージョン及びサーバー・システムにおける各テナントに属するレコードの全てのバージョンの双方について、トランザクションがコミットされた順に厳密に増加又は減少する順序を構成することが保証され得る。

図６は、開示される対象事項の実装によるコミットされていないトランザクションのためのトランザクション番号割り当てに適した構成例を示す。この例では、トランザクション１４６は、例えばサーバー・システム１００のテナントから、サーバー・システム１００によって受信され、ストレージ１４０内のコミットされていないトランザクション１４５の１つとして保存されている。例示的なトランザクション１４６は、キー１５１及び値１５５を含む。トランザクション１４６は、例えばトランザクション１４６が処理された時点からの或る期間の経過などの、任意の適切なイベントに基づいて、サーバー・システム１００においてコミットされてもよい。引き続きその例において、トランザクション番号マネージャ１３０は、トランザクション・カウンタ１１０からカウンタ番号値を受信し、カウンタ番号値に基づいてトランザクション番号２１０をトランザクション１４６に割り当てる。トランザクション番号マネージャ１３０はまた、例えば、カウンタ番号値を増分させることによって、トランザクション・カウンタ１１０が、カウンタ番号値を更新することを引き起こしてもよい。次に、レコード・バージョン２４６が、トランザクション１４６に基づいて保存される。レコード・バージョン２４６は、ストレージ１４０内のレコード・バージョン１６０とともに保存されてもよく、本願で先に開示されたように、トランザクション１４６からのキー１５１及び値１５５を含んでもよく、トランザクション１４６に署名されたトランザクション番号２１０に関連づけられてもよい。レコード・バージョン２４６がコミットされると、コミットされていないトランザクション１４６は、コミットされていないトランザクション１４５から除外又は削除され得る。

トランザクション１４６がサーバー・システム１００でコミットされる前に、コミットされていないトランザクション１４６のヘッダ（例えば、値１５５）は、割り当てられたトランザクション・カウンタ番号で（例えば、トランザクション番号マネージャ１３０により）更新されてもよい。サーバー・システム１００によって受信される新しいクエリは、この割り当てられたトランザクション・カウンタ番号をＭＶＣＣスナップショットとして使用することができる。上述したように、トランザクション１４６は、同時オペレーションにおいてコミットされる（即ち、「スタンプ」）過程におけるものであってもよく、サーバー・システム１００は、割り当てられたトランザクション・カウンタ番号をスナップショットとして使用することが可能であってもよい。

図７は、開示される対象事項の実装によるトランザクション番号の割り当てに適した構成例を示す。テナント用のライブ又はプロダクション・データベースは、１つのサーバー・システム、クラスタ、又はデータ・センターから、より大きなサーバー・ネットワーク内の別のものへマイグレーションさせられてもよい。例えば、レコードの現在のバージョン及びコミットされていないトランザクション（例えば、ＭＶＣＣスナップショットとして使用され得る指定されたトランザクション・カウンタ番号を有し得る）を含む全てのレコード及びトランザクションは、より大きなサーバー・ネットワーク内のテナントのプロダクション・データベースに属するが、１つのサーバー・システムに格納されてもよく、そして、メンテナンス、パフォーマンス、又はサーバー障害を含む種々の理由に起因して、別のサーバー・システムへ移動又はマイグレーションさせられてもよい。ここでさらに詳細に説明されるように、ライブ又はプロダクション・データベースがマイグレーションされる元のサーバー・システムは「送信」サーバー・システムと考えられてもよく、ライブ又プロダクション・データベースがマイグレーションされる先のサーバー・システムは、マイグレーションされるレコードが、マイグレーションされたレコードとなり得る「受信」サーバー・システムと考えられてもよい。

ライブ又はプロダクション・データベースがシステム間で移動させられる場合、各トランザクション、又は実装で移動させられるレコードのバージョンは、キーと共に送信サーバー・システムのカウンタを利用して割り当てられたトランザクション番号に関連付けられることができる。従って、移動させられるレコードの１つ以上のバージョンは、受信サーバー・システムのカウンタのカウンタ番号の値よりも高く、また、受信サーバー・システムにすでに保存されているレコードのバージョンに関連する任意のトランザクション番号よりも高いトランザクション番号を割り当てられてもよい。これは、送信又は受信システムにおいて割り当てられているトランザクションの数、又はトランザクション識別子が時間値を含む場合に、例えば、異なる再同期期間、受信及びコミットされたトランザクションの異なるボリューム、クロック・ドリフト等の多くの理由で生じ得る。

サーバー・システム１００は、送信サーバー・システム４００によって既にトランザクション番号を割り当てられている可能性があるレコード４６０のレコード・バージョンを受信することができる。サーバー・システム１００は、受信サーバー・システムであってもよく、サーバー・システム４００は、レコード・バージョン４６０のための送信サーバー・システムであってもよい。レコード・バージョン４６０からのレコード・バージョンは、例えば、サーバー・システム４００のテナントのインスタンスに属するレコードに関するサーバー・システム４００上のすべてのレコード・バージョンであってもよい。レコード・バージョン４６０からのレコード・バージョンのマイグレーションの前に、そのテナントに属するレコードのインスタンスに対して、サーバー・システム１００上のレコード・バージョン１６０にはレコード・バージョン１６０が存在しないかもしれない。

マイグレーションされるレコードのためのレコード・バージョン４６１、４６２、４６３、４６４、４６５、４６６、４６７、及び４６８等のレコード・バージョン４６０の一部又は全部が、サーバー・システム４００によって送信され、サーバー・システム１００のストレージ１４０に格納されてもよい。レコード・バージョン４６１、４６２、４６３、４６４、４６５、４６６、４６７、及び４６８の各々は、コミットされたトランザクションであってもよく、それ自身のキー、値、及び関連するトランザクション番号を有してもよい。トランザクション４６１ないし４６８のトランザクション番号はまた、固有であってもよく、トランザクションがサーバー４００でコミットされた順序において厳密に増加又は減少して割り当てられてもよい。

マイグレーションされるレコードに対するトランザクション４４６、４４７、４４８、及び／又は４４９等のコミットされていないトランザクション４４５の一部又は全部が、サーバー・システム４００によって送信され、サーバー・システム１００のストレージ１４０（図示せず）に格納されてもよい。例えば、マイグレーションされるこのようなコミットされていないトランザクションは、図５に示されるストレージ１４０のコミットされていないトランザクション１４５のセクションに保存されてもよい。コミットされていないトランザクション４４６、４４７、４４８、及び４４９のうちの１つ以上は、コミットされる過程におけるトランザクションであってもよく、それ自身のキー、値、及び関連するトランザクション番号を有してもよい。

さらに、ネットワーク内の全てのノードにおける全てのサーバー・システムのトランザクション番号は、固有のトランザクション番号（例えば、厳密に増加又は減少する番号）を割り当てることができる。更に、割り当てられるトランザクション番号は、全てのサーバーに対して固有で厳密に増加し得る、又は全てのサーバーに対して固有で厳密に減少し得る。幾つかの実装において、トランザクション番号は、１つのトランザクションが１つ以上のレコードの複数のバージョンを生じる場合のように、レコード・バージョン間で一意でないかもしれない。サーバー・システム１００に送信される任意のレコード・バージョン４６１、４６２、４６３、４６４、４６５、４６６、４６７、及び４６８に関連する最新のトランザクション番号が決定され得る。この最新のトランザクション番号は、レコードの送信前又は送信中に、サーバー・システム４００によって決定されてもよく、又はサーバー・システム１００によって、例えばトランザクション番号マネージャ１３０によって、マイグレーションされるレコード及びトランザクションの受信中又は受信後に決定されてもよい。代替的又は追加的に、最新のトランザクション番号は、レコード・バージョン４６０の一部となるようにコミットされる過程にある可能性がある、又はコミットされていないトランザクション１４５に保存されるためにストレージ１４０にマイグレーションされる可能性があるサーバー・システム４００のコミットされていないトランザクション４４５（例えば、トランザクション４４６、４４７、４４８、及び／又は４４９）に関連付けられてもよい。即ち、コミットされていないトランザクション（例えば、トランザクション４４６、４４７、４４８、及び／又は４４９）の最新のトランザクション番号は、ＭＶＣＣスナップショットとして使用されてもよい。

引き続きレコード・バージョン４６０を用いる上記の例に関し、サーバー・システム１００及び４００の両方が、厳密に増加する順序で（サーバー・システムに対して）固有のトランザクション番号を割り当てる同一のトランザクション番号スキーマを使用していると仮定すると、トランザクション番号マネージャ１３０は、レコード・バージョン４６１、４６２、４６３、４６４、４６５、４６６、４６７、４６７、及び４６８のいずれかに関連する最高のトランザクション番号の値と、トランザクション・カウンタ１１０のカウンタ番号値及び／又はコミットされていないトランザクション４４５（例えば、トランザクション４４６、４４７、４４８、及び／又は４４９）に関連する最高のトランザクション番号とを比較することができる。マイグレーションされたレコードに関するレコード・バージョン４６１、４６２、４６３、４６４、４６５、４６６、４６７、及び４６８のいずれかに関連する最も高いトランザクション番号が、より高い、又は時間的に先行している場合、即ち、コミットされていないトランザクション４４５（例えば、トランザクション４４６、４４７、４４８、及び／又は４４９）に関連する最高のトランザクション番号及び／又はカウンタ番号値である場合、トランザクション番号マネージャ１３０は、トランザクション・カウンタ１１０が、マイグレーションされたレコードのいずれかに関連する最も高いトランザクション番号の値よりも高いカウンタ番号値を設定することを引き起こすことができる。そうでない場合、カウンタ番号値は同じ値に留まってもよい。これは、サーバー・システム１００のストレージ１４０に保存されるトランザクションに関連するトランザクション番号の厳密な増加又は減少を保証することができ、なぜなら、サーバー・システム１００における次のコミットされるトランザクションは、より高い又は時間的に先行するトランザクション番号−即ち、マイグレーションされたレコード４６１、４６２、４６３、４６４、４６５、４６６、４６７、及び４６８を含むレコード・バージョン１６０の任意のレコード・バージョンに関連する最も高いトランザクション番号−を割り当てられるからである。

代替的に、ランザクション番号マネージャ１３０は、コミットされていないトランザクション４４６、４４７、４４８、及び４４９のいずれかに関連する最も高いトランザクション番号の値（例えば、レコード・バージョン４６０に対してコミットされる過程にあり得るもの）を、トランザクション・カウンタ１１０のカウンタ番号値と比較することができる。マイグレーションされたレコードに関するコミットされていないトランザクション４４５のいずれかに関連する最高のトランザクション番号が、より高い、又は時間的に先行している場合、即ち、カウンタ番号値及び／又はレコード・バージョン４６０のいずれかに関連する最高のトランザクション番号である場合、トランザクション番号マネージャ１３０は、トランザクション・カウンタ１１０が、マイグレーションされたレコードのいずれかに関連する最高のトランザクション番号の値よりも高いカウンタ番号値を設定することを引き起こすことができる。そうでない場合、カウンタ番号値は同じ値のまま留まってもよい。これは、サーバー・システム１００のストレージ１４０に保存されるトランザクションに関連するトランザクション番号の厳密な増加又は減少を保証することができ、なぜなら、サーバー・システム１００における次のコミットされるトランザクションは、より高い又は時間的に先行するトランザクション番号−即ち、マイグレーションされたレコード４６１、４６２、４６３、４６４、４６５、４６６、４６７、及び４６８を含むレコード・バージョン１６０の任意のレコード・バージョンに関連する最も高いトランザクション番号−を割り当てられるからである。

任意のライブ又はプロダクション・データベースの厳密な増加又は減少を維持するための代替方法も可能である。第１のサーバー・クラスタから第２のサーバー・クラスタへプロダクション・データベースをマイグレーションするための時間インターバルは、大多数のサーバー・クラスタ又はポッド間の相対スキューよりもはるかに小さい可能性が高い。従って、ほとんどの場合、単にローカル・サーバの時間を、トランザクション番号の一部として含めることで、受信サーバー・システムとマイグレーションされるデータベースとのクロックのインクリメントの間でカウンタ・カウント・トランザクションによる厳密な増減を保証するのに十分であるはずである。

図８Ａは、開示される対象事項の実装によるトランザクション番号割り当てに適した構成例を示す。ストレージ１４０のレコード・バージョン１６０内のレコード・バージョンを有するレコードの幾つかに対するリクエストは、リクエスター・システム５００からサーバー・システム１００によって受信され得る。リクエスター・システム５００は、例えば、サーバー・システム１００のテナントに関連付けられるユーザーによって使用される任意の適切なコンピューティング・デバイスであってもよい。リクエストは、サーバー・システム１００上のテナントのデータベースから、例えばテーブルの一部として、テーブル全体として、又は複数のテーブルとして、テナントが個々に見ることを望むテナントに属するレコードに対するものであり得る。あるいは、ユーザーは、データベース全体のコピーを取得することを望むかもしれない。

リクエスター・システム５００からのリクエストは、キー（ｋｅｙ）と時間値とを含むことができる。例えば、リクエストは、キー「Ａ７＊」を含むことができ、ここで、「Ａ７」は、リクエスター・システム５００を使用するテナントの固有のテナント識別子であり、ワイルドカードは、リクエストが、キーの残りの部分によらず、その固有のテナント識別子を含むキーを有する全てのレコードに対するものであることを示すことができるリクエストの時間値は、２２１８００であってもよい。これは、２２１８００の時間値で示される時点で現在（ｃｕｒｒｅｎｔ）であったテナントに属する全てのレコード・バージョンを、レコード・バージョン１６０から検索することを、テナントが望んでいることを示すことができる。

ストレージ・マネージャ１３５は、リクエスター・システム５００からリクエストを受信し、レコード・バージョン１６１、１６２、１６３、１６４、１６５、及び１６６のうちの何れがリクエストに応じているかを決定することができる。応答レコード・バージョンは、Ａ７＊のリクエストのキー値に一致するレコード・バージョンであり、且つ同じレコードの同じキーを有する別のレコード・バージョンと関連する任意の他のトランザクション番号よりも高い一方、依然としてリクエストの時間値以下であるトランザクション番号と関連し得る。レコード・バージョンは、キー値と一致するが、関連するトランザクション番号に起因して応じていないかもしれないし（例えば、トランザクションがリクエストの時間値又はトランザクション番号の後に発生した場合）、あるいは適切なトランザクション番号に関連付けられるが、キー値に一致しないことに起因して応じていないかもしれない。例えば、レコード・バージョン１６１、１６３、１６４及び１６６は、Ａ７Ｄ５、Ａ７Ｄ５、Ａ７Ｎ４、及びＡ７Ｄ５のそれぞれのキー値に関し、Ａ７＊のリクエストのキー値と一致し得る。レコード・バージョン１６１は、例えば、２２４５６というレコード・バージョン１６１に関連するトランザクション番号が２２１８００のリクエストの時間値よりも高く、レコード・バージョン１６１のトランザクションはリクエストの時間値で示された時間の後に保存されたことを示すので、リクエストに対する応答レコードにはならないであろう。別の例として、レコード・バージョン１６６は、同じレコードのために保存されたトランザクションであり得るので、レコード・バージョン１６３と同一のキーを有し、レコード・バージョン１６３は、２２１５０６というトランザクション番号に関連し、これは、２２１８００というリクエストの時間値よりも低く、２００１００というレコード・バージョン１６６に関連するトランザクション番号よりも高い。これは、レコード・バージョン１６３が、そのレコードに関してレコード・バージョン１６６に取って代わった、リクエストの時間値２２１８００によって示される時点におけるレコードの現在のレコード・バージョンであったことを示し得る。従って、レコード・バージョン１６６は、例示のリクエストに対する応答レコード・バージョンではない。レコード・バージョン１６３及び１６４は、リクエスター・システム５００からのリクエストに応じることができる。ストレージ・マネージャ１３５は、応答レコード１６３及び１６４をリクエスター・システム５００へ送信することができ、例えばテナントのデータベースからテーブルを表示する等のように、それらは任意の適切な方法で使用されることができる。

図８Ｂは、開示される対象事項の実装によるトランザクション番号の割り当てに適した構成例を示す。ストレージ１４０内のコミットされていないトランザクション（例えば、トランザクション１４６、１４７、１４８、及び／又は１４９、又はコミットされていないトランザクション１４５）であり得る幾つかのレコードに対するリクエストは、リクエスター・システム５００からサーバー・システム１００によって受信され得る。即ち、コミットされていないトランザクションは、典型的には、リクエスター・システム５００にとってビジブルではないかもしれないが、少なくとも部分的に、コミットされていないトランザクションがそれらに割り当てられたトランザクション番号を有し且つコミットされる過程にある場合にはビジブルであり得る。

リクエスター・システム５００からのリクエストは、キーと時間値とを含むことができる。例えば、リクエストは、キー「Ａ７＊」を含むことができ、ここで、「Ａ７」は、リクエスト・システム５００を使用するテナントの固有のテナント識別子であり、ワイルドカードは、リクエストが、キーの残りの部分によらず、その固有のテナント識別子を含むキーを有する全てのレコードに対するものであることを示すことができる。リクエストの時間値は２２１８００であってもよい。これは、２２１８００の時間値で示された時点で現在であったテナントに属する全てのレコード・バージョン（例えば、図８Ａに示されるもの）及び／又はコミットされていないトランザクション１４５（指定されたトランザクション番号を有するが、未だコミットされていないもの）を検索することを、テナントが望んでいることを示し得る。

ストレージ・マネージャ１３５は、リクエスター・システム５００からリクエストを受信し、コミットされていないトランザクション１４６、１４７、１４８、及び／又は１４９のうちの何れがリクエストに応じているかを決定することができる。応じているコミットされていないトランザクションは、Ａ７＊のリクエストのキー値に一致するレコード・バージョンであり、同じレコードのうち、同じキーを有する他のレコード・バージョンと関連する任意の他のトランザクション番号よりも高い一方、依然としてリクエストの時間値以下であるトランザクション番号と関連付けられ得る。トランザクション番号が未だ割り当てられていない未コミットのトランザクション（例えば、トランザクション１４６及び１４９）は考慮されなくてよい。コミットされていないトランザクションのうちのトランザクションは、キー値と一致するが、関連するトランザクション番号又は関連するトランザクション番号の欠如に起因して応じてないかもしれないし（例えば、トランザクションがリクエストの時間値又はトランザクション番号の後に発生した場合）、又は適切なトランザクション番号に関連付けられるが、キー値に一致しないことに起因して応じていないかもしれない。例えば、トランザクション１４６、１４８、及び１４９は、Ａ７Ｄ５、Ａ７Ｄ５、及びＡ７Ｎ４のそれぞれのキー値に関し、Ａ７＊のリクエストのキー値と一致し得る。トランザクション１４６は、例えばトランザクション１４６に関連するトランザクション番号が存在しないので、リクエストに対する応答レコードではあり得ない。トランザクション１４８は、リクエスター・システム５００からのリクエストに応じ得る。ストレージ・マネージャ１３５は、トランザクションをリクエスター・システム５００へ送信してもよく、これらは例えばテナントのデータベースからテーブルを表示する等のように任意の適切な方法で使用され得る。

現在開示されている対象事項の実装は、種々のコンポーネント及びネットワーク・アーキテクチャにおいて実現され、使用され得る。図９は、現在開示されている対象事項の実装を実現するのに適したコンピュータ例６００の例である。ここで更に詳細に説明されるように、コンピュータ６００は、複数のコンピュータのネットワーク内の単一のコンピュータであってもよい。図９に示されるように、コンピュータ６００は、セントラル・コンポーネント７００（例えば、サーバー、クラウド・サーバー、データベース等）と通信することができる。セントラル・コンポーネント７００は、別のコンピュータ８００等の１つ以上の他のコンピュータと通信することができる。この実装によれば、セントラル・コンポーネント７００に対する及び／又はそこから得られる情報は、コンピュータ６００がコンピュータ８００と情報を共有しないように、各コンピュータに関して分離されていてもよい。代替的又は追加的に、コンピュータ６００は別のコンピュータ８００と直接的に通信してもよい。

コンピュータ（例えば、ユーザー・コンピュータ、企業コンピュータ等）６００は、セントラル・プロセッサ６４０、メモリ６７０（典型的にはＲＡＭであるが、ＲＯＭ、フラッシュＲＡＭなどを含み得る）、入出力コントローラ６８０、ディスプレイ・アダプタを介したディスプレイ又はタッチスクリーン等のユーザー・ディスプレイ６２０、キーボード、マウス、ＷｉＦｉ／セルラ無線機、タッチスクリーン、マイクロホン／スピーカ等のような１つ以上のコントローラ及び関連するユーザー入力又はデバイスを含むことができ、Ｉ／Ｏコントローラ６８０に密接に結合され得るユーザー入力インターフェース６６０、ハード・ドライブ、フラッシュ・ストレージ、ファイバ・チャネル・ネットワーク、ＳＡＮデバイス、ＳＣＳＩデバイス等の固定ストレージ６３０、光ディスク、フラッシュドライブ等を制御及び受信するように動作するリムーバブル・メディア・コンポーネント６５０等のコンピュータ６００の主要なコンポーネントを相互接続するバス６１０を含む。

バス６１０は、先に述べたように、セントラル・プロセッサ６４０とメモリ６７０との間のデータ通信を可能にし、メモリは、リード・オンリ・メモリ（ＲＯＭ）又はフラッシュ・メモリ（いずれも図示せず）と、ランダム・アクセス・メモリ（ＲＡＭ）（図示せず）とを含んでもよい。ＲＡＭは、オペレーティング・システム及びアプリケーション・プログラムがロードされるメイン・メモリを含むことが可能である。ＲＯＭ又はフラッシュ・メモリは、特に、周辺コンポーネントとの相互作用のような基本的なハードウェア動作を制御する基本入出力システム（ＢＩＯＳ）を含むことが可能である。コンピュータ６００に常駐するアプリケーションは、ハード・ディスク・ドライブ（例えば、固定ストレージ６３０）、光ドライブ、フロッピー・ディスク、又は他の記憶媒体６５０等のコンピュータ読み取り可能な媒体に記憶され、アクセスされることが可能である。

固定ストレージ６３０は、コンピュータ６００と一体であってもよく、又は別個であって他のインターフェースを介してアクセスされてもよい。ネットワーク・インターフェース６９０は、電話リンクを介して遠隔サーバーに、インターネット・サービス・プロバイダ（ＩＳＰ）を介してインターネットに直接接続を提供してもよいし、又はＰＯＰ（ポイント・オブ・プレゼンス）又は他の技術によるインターネットへの直接的なネットワーク・リンクを介して遠隔サーバーに対する直接接続を提供してもよい。ネットワーク・インターフェース６９０は、ディジタル・セルラ電話接続、セルラ・ディジタル・パケット・データ（ＣＤＰＤ）接続、ディジタル衛星データ接続などを含む無線技術を使用してこのような接続を提供することができる。例えば、ネットワーク・インターフェース６９０は、図１０に示されるように、コンピュータが、１つ以上のローカルの、広域の、又は他のネットワークを介して他のコンピュータと通信することを可能にし得る。

他の多くのデバイス又はコンポーネント（図示せず）（例えば、文書スキャナ、ディジタル・カメラなど）は、同様の方法で接続されてもよい。逆に、図１０に示される全てのコンポーネントが、本開示を実施するために存在する必要はない。コンポーネントは、図示の方法とは異なる方法で相互接続されることが可能である。図１０に示されるようなコンピュータの動作は、当技術分野において容易に理解され、本出願において詳細には説明されない。本開示を実施するためのコードは、メモリ６７０、固定ストレージ６３０、リムーバブル・メディア６５０のうちの１つ以上のようなコンピュータ読み取り可能記憶媒体、又は遠隔ストレージ・ロケーションで保存されることが可能である。

図１０は、開示される対象事項の実装によるネットワーク構成例を示す。クラウド１２０２によって表されるネットワーク内の異なるノードにおける４つの別個のデータベース・システム１２００ａ−ｄは、ネットワーク・リンク１２０４を介して互いに及びユーザー（図示せず）と通信する。データベース・システム１２００ａ−ｄは、各々、データベースの異なるインスタンス・ノードであってもよく、及び／又はテナント・データの１つ以上のインスタンスを含んでもよい。例えば、各データベース・システム１２００は、Ｌｉｎｕｘオペレーティング・システム及びＨａｄｏｏｐフレームワークを実行するＰｏｓｔｇｒｅｓｓ、Ｍｙｓｑｌ Ｓｅｒｖｅｒ又はＯｒａｃｌｅ １２ｃのようなマルチテナント・データベースの複数のインスタンスをホストするように動作することが可能であり、各インスタンスは、特定のテナントに関連するユーザーに限ってアクセス可能である。各データベース・システムは、ストレージ・エリア・ネットワーク（図示せず）、負荷バランサ及びバックアップ・サーバーにより、ファイアウォール、他のセキュリティ・システム、及び認証システムと共に、コンピュータのクラスタを構成することができる。システム１２００のいずれかのインスタンスの幾つかは、ユーザーから受信したトランザクション、又はインスタンス内の記憶のためにデータを取り込んで提供するためのコンピューティング要素（図示せず）から受信したトランザクションを処理及びコミットするライブ又はプロダクション・インスタンスであってもよい。各データベース・システムは、シーケンスがコミットされる順に、コミットされた各トランザクションにトランザクション番号を割り当てるために、図５−９で説明されたようなシステムを使用することができる。

上述した１つ以上の実装を使用して、以下の例は、処理中の（コミットされていない）トランザクションにおけるサーバー・システムの動作を示すことができ、データ構造、ロック・マネージャ１２５、トランザクション番号マネージャ１３０、及びストレージ・マネージャ１３５、及びログ・マネージャ１３８の例示的な動作が以下に示されて説明される。

具体例では、ステートメント境界とセーブポイントのロールバック・ターゲットとして使用されるトランザクション番号とトランザクション・シーケンス番号ペアとを示すように、値が選択される。具体例において、ストレージ１４０を使用する実装はトランザクション動作を開始し、ストレージ１４０は使用され得るサブトランザクションを開始する。幾つかの実装において、これらのオペレーションは使用されない場合があり、トランザクション番号マネージャ１３０は、トランザクション番号の知識と、ストレージ１４０によって返されるストレージ１４０のトランザクション・シーケンス番号がロケーション・オペレーションを取得することに基づいて、トップレベル・トランザクション及びサブトランザクションのためのログ構造化マージ（ＬＳＭ）トランザクション番号を表す値を作成することができる。

第１具体例では、３つのトランザクション履歴が存在する（即ち、トランザクション１、トランザクション２、及びトランザクション３であり、トランザクションは以下の表１Ａに示されるトップレベル・トランザクションであってもよく、ｘは整数値である）。

表１Ａ

上記の表１Ａのライン１に示すように、３つのトップレベル・トランザクション１、２、及び３が作成される。トランザクション番号マネージャ１３０は、トランザクション番号（例えば、この例では、トランザクション番号１０１、１０２及び１０３のそれぞれ）を割り当ててもよく、トランザクション・コンテキストを作成してもよく、割り当てられたトランザクション番号を有するアクティブなトランザクションが現在存在するレジスタのようなレジスタ１４０と通信してもよい。トランザクションの開始のトランザクション・シーケンス番号（即ち、シーケンス番号ゼロ）及びＬＳＭトランザクション番号を有する対数構造マージ（ＬＳＭ）トランザクション番号値が、トランザクション・コンテキストに関連付けられ、及び／又は格納される。トランザクション番号マネージャは、各トランザクションのためのロック・タグ（ｌｏｃｋ ｔａｇｓ）を有するロック・マネージャ１２５において排他的ロック（即ち、トランザクション１０１、１０２、及び１０３に関するロック）を得ることができる。ログ・レコード（例えば、ログ・マネージャ１３８によって管理及び／又は生成されるログ・レコード）は、これらの何れのオペレーションのいずれによっても生成されない。

表１Ａのライン１に対するロック・マネージャ１２５の状態は、以下の表１Ｂに示される。

表１Ｂ

テーブル１Ａのライン１に対するトランザクション番号マネージャ１３０の状態（即ち、トランザクション番号マネージャ内のコンテキスト・スタックの状態）は、以下の表１Ｃに示される：

表１Ｃ

表１Ａのライン１に対するログ・マネージャ１３８の状態は、以下の表１Ｄに示される：

表１Ｄ

表１Ａのライン１に対するトランザクションの状態は、以下の表１Ｅに示されている：

表１Ｅ

表１Ａのライン１に対するストレージ１４０におけるプライマリ・キーの状態は、下記の表１Ｆに示される。

表１Ｆ

上記の表１Ａのライン２に示すように、トランザクション１は、第１コマンド識別ステートメント（ｃｉｄ）（ｃｉｄ＝１）を処理するための新しいサブトランザクションを開始することができる。トランザクション番号マネージャ１３０は、サブトランザクションのための新しいＬＳＭトランザクション番号値を得ることができる。トランザクション１のステータスは、（１０１，０）であってもよく、なぜなら、トランザクション番号１０１のためのストレージ１４０にレコードがまだ追加されていないからである。サブトランザクション・コンテキストは、トランザクション番号１０１に対してトランザクション番号マネージャ１３０によって管理されるコンテキスト・スタックにプッシュされてもよい。アップデートを処理するために、テーブル１Ａの行にわたってスキャンが実行されてもよく、スナップショット・トランザクション・カウンタ番号は１（ｏｎｅ）である。各行が返されると、列ｘの内容に対して計算が行われてもよく、各々の更新された行のプライマリ・キーに対する挿入レコード・オペレーションを呼び出すことによって、適切な行バージョン・レコードがストレージ１４０内に作成され得る。各々の挿入されたレコードは、トランザクション番号１０１のトランザクション・レコード・チェーン毎の内のその位置を表す単調に増加するトランザクション・シーケンス番号を割り当てられ得る。各々の挿入は、ログ・マネージャ１３８によってログに記録されてもよい。アップデートはプライマリ・キーの値に影響しないかもしれないので、挿入はキー・アップデートが存在しないことを示したロック・モードを有し得る。挿入は、キーに対する任意の既存のコミットされていないデータとコンフリクトしないかもしれないので、暗黙の行ロック・リクエストが許可され得る（例えば、リクエストは直ちに許可され得る）。１（１）であるトランザクション・カウンタ番号を持つスナップショットは、１であるプライマリ・キー値と２であるプライマリ・キー値に対するコミットされた行バージョン・レコードにスタンプされたトランザクション・カウンタ番号以下であるため、そのアップデートはスナップショット・バイオレーションを生成しないであろう。各々の行バージョン・レコードの挿入及び関連する状態の検査は、対応するプライマリ・キーのキー・バケット・ラッチの下で生じ得る。更新オペレーションが完了すると、トランザクション番号マネージャ１３０は、ステートメントのサブトランザクション・コンテキストを検索することができる。

表１Ａのライン２に対するロック・マネージャ１２５の状態は、以下の表２Ａに示される：

表２Ａ

テーブル１Ａのライン２に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表２Ｂに示される：

表２Ｂ

表１Ａのライン２に対するログ・マネージャ１３８の状態は、以下の表２Ｃに示される：

表２Ｃ

表１Ａのライン２に対するトランザクションの状態は、以下の表２Ｄに示されている：

表２Ｄ

表１Ａのライン２に対するプライマリ・キーの状態は、以下の表２Ｅに示されている：

表２Ｅ

上記の表１Ａのライン３に示すように、トランザクション１は、サブトランザクションの（１０１，２）のＬＳＭトランザクション番号を受けるために、サブトランザクションを開始するオペレーションを呼び出すことによって、ｓ１という名前のセーブポイントを定義することができる。トランザクション番号マネージャ１３０は、新しいサブトランザクション・コンテキストを、トランザクション１のトランザクション番号マネージャ１３０のコンテキスト・スタックにプッシュすることができる。ストレージ１４０の状態は変化せず、ログ・マネージャ１３８によって値はログに記録されなくてもよい。

表１Ａのライン３に対するロック・マネージャ１２５の状態は、以下の表３Ａに示される：

表３Ａ

テーブル１Ａのライン３に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキストスタックの状態）は、以下の表３Ｂに示される：

表３Ｂ

表１Ａのライン３に対するログ・マネージャ１３８の状態は、以下の表３Ｃに示される：

表３Ｃ

表１Ａのライン３に対するトランザクションの状態は、以下の表３Ｄに示されている：

表３Ｄ

表１Ａのライン１に対するプライマリ・キーの状態は、以下の表３Ｅに示されている：

表３Ｅ

ライン４に示すように、トランザクション１は、２番目のコマンド識別ステートメント（ｃｉｄ＝２）を処理するための新しいサブトランザクションを開始することができる。トランザクション番号マネージャ１３０は、サブトランザクションを開始するオペレーションを実行し、サブトランザクションのＬＳＭトランザクション番号（即ち（１０１，２））を取得する。このサブトランザクション・コンテキストは、トランザクション番号１０１のトランザクション番号マネージャ１３０のコンテキスト・スタックにプッシュされてもよい。更新を処理するために、オペレーションが実行され、トランザクション番号１０１及び１であるスナップショットトランザクション番号のためのテーブルの行にわたってスキャンを開始し、スキャン・キーは１であるプライマリ・キーを有する行を返すことになる。コミットされていない行バージョン・レコードは、リターンされ、１０１であるトランザクション番号と１であるコマンド識別ステートメント（ｃｉｄ＝１）とを有する。トランザクション（即ち、トランザクション１）は、トランザクション１のコマンド識別ステートメント（即ち、ｃｉｄ＝１）が現在のコマンド識別ステートメント（即ち、ｃｉｄ＝２）より小さいので、ビジブル（即ち、クエリーにとって可視）であり得る。ｘの新しい値は、１０１＋６６６＝７６７として計算されてもよく、挿入レコード・オペレーションは、新しい行バージョンをストレージ１４０に記録するように実行されてもよい。プライマリ・キーは変更されないかもしれず、そのため、キー・アップデートが存在しないロック・モードとともに挿入が生じる。行バージョン・レコードのトランザクション・カウンタ番号が１０１であるので、プライマリ・キーが１である場合の既存の暗黙の「キー・アップデートなし」モードの行ロックとの競合は存在しない。トランザクションは、それ自身とコンフリクトせず、スナップショット・バイオレーションは存在しない。挿入は、ログ・マネージャ１３８によってログに記録され得る。更新オペレーションが完了すると、トランザクション番号マネージャ１３０は、ステートメントのサブトランザクション・コンテキストを検索することができる。

表１Ａのライン４に対するロック・マネージャ１２５の状態は、以下の表４Ａに示される：

表４Ａ

テーブル１Ａのライン４に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表４Ｂに示される：

表４Ｂ

表１Ａのライン４に対するログ・マネージャ１３８の状態は、以下の表４Ｃに示されている：

表４Ｃ

表１Ａのライン４に対するトランザクションの状態は、以下の表４Ｄに示されている：

表４Ｄ

表１Ａのライン４に対するプライマリ・キーの状態は、以下の表４Ｅに示されている：

表４Ｅ

上記の表１Ａのライン５に示すように、トランザクションは、１であるコマンド識別ステートメント１（ｃｉｄ＝１）を有する第１ステートメントを処理するための新しいサブトランザクションを開始することができる。トランザクション番号マネージャ１３０は、サブトランザクションを開始するためのオペレーションを実行することができ、サブトランザクションのＬＳＭトランザクション番号（即ち（１０２，０））を取得することができ、このサブトランザクション・コンテキストは、トランザクション番号１０２のトランザクション番号マネージャ１３０のコンテキスト・スタックにプッシュされ得る。オペレーションは、トランザクション番号１０２及びスナップショット・トランザクション・カウンタ番号１のためのテーブルの行にわたってスキャンするために実行されてもよく、スキャン・キーは、１というプライマリ・キーを有する行を返す。行バージョン・レコードが返され、これは１であるトランザクション・カウンタ番号を有するトランザクションのコミットされたバージョンである。これはトランザクション２にとってビジルブルであり得るが、なぜなら、トランザクション・カウンタ番号は１であり、それはトランザクション２のスナップショット・トランザクション・カウンタ番号以下である一方、トランザクション１からのコミットされていない行バージョン・レコードはビジブルではないからである。トランザクション２は、ｘ＝２を有する新しいバージョンの行を記録することによって、更新の処理に進むことができる。ロック・モードは、キー・アップデートではないかもしれないが、上述の表１Ａの行とは異なり、トランザクション１によって保持されている暗黙のキー・アップデートなしの行ロックとコンフリクトが存在するかもしれない。更新のための行バージョン・レコードは、プライマリ・キーが１である場合にキー・バケット・ラッチを保持しながらストレージ１４０内に作成され得るが、フラグは、この更新がペンディング・ロック収集であることを示すために、ｆａｌｓｅに設定されてもよい（即ち、ｇｒａｎｔｅｄ ｆｌａｇ＝ ｆａｌｓｅ）。１のプライマリ・キーの現在の行ロック状態に対して、トランザクション２はトランザクション１によってブロックされ（トランザクション番号は＝１０１）、トランザクション２はトランザクション１の完了を待機し、又は１のプライマリ・キーの行ロックを明示的に解放する、と判断されてもよい。共有モードでロックタグ・トランザクション・ロック（１０１）を取得しようとする場合に、トランザクション２はブロックされ得る。トランザクション１はまだアクティブであり得、トランザクション番号マネージャ１３０は、ロックタグ・トランザクション（１０１）上の排他的ロックを維持することができ、従って、共用ロック・リクエストはスリープすることができる。

表１Ａのライン５に対するロック・マネージャ１２５の状態は、以下の表５Ａに示される：

表５Ａ

表１Ａのライン５に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表５Ｂに示される：

表５Ｂ

表１Ａのライン５に対するログ・マネージャ１３８の状態は、以下の表５Ｃに示されている：

表５Ｃ

表１Ａのライン５に対するトランザクションの状態は、以下の表５Ｄに示されている：

表５Ｄ

表１Ａのライン５に対するプライマリ・キーの状態は、以下の表５Ｅに示されている：

表５Ｅ

表１Ａのライン６に示されるように、トランザクション１はセーブポイントｓ１へロールバックされ得る。トランザクション番号マネージャ１３０は、ロールバックのターゲットを記録し（即ち、（１０１，２））、同じＬＳＭトランザクション番号によりストレージ１４０とともにロールバック・オペレーションを実行することができる。ロールバック・オペレーションにおいて、トランザクション１の行バージョン・レコードのリストは、ロールバック・ターゲットより小さなＬＳＭトランザクション番号を有する行バージョン・レコードを発見するまで、逆のシーケンス番号順で（例えば、最大から最小へ）レビューされ得る。このリストの横断中に、訪問する各行バージョン・レコードのキー・バケット・ラッチが取得され得る。ラッチを保持しながら、ストレージ１４０のデータ構造からロールバック・レコードをアンリンク解除することと、行バージョン・レコードに関連する暗黙の行ロックの解放に起因して何らかのブロックされた行レベル・ロッカーがブロック解除され得るか否かを検査することとの両方を行うことができる。ＬＳＭトランザクション番号（１０１，２）及びシーケンス番号３を有する行バージョン・レコードは、ストレージ１４０から除去され得る。プライマリ・キー１のためのコミットされていない行バージョン・レコード、即ちＬＳＭトランザクション番号（１０１，０）とシーケンス番号１とを有する行バージョン・レコードが存在するので、トランザクション２が、トランザクション１のペンディング行ロックを取得することを許容しないかもしれない。トランザクション１に関連する最新のシーケンス番号は、２にロールバックされ得る。トランザクション番号マネージャ１３０は、セーブポイントｓ１に対応するサブトランザクション・コンテキストを検索することができる。

表１Ａのライン６に対するロック・マネージャ１２５の状態は、以下の表６Ａに示されている：

表６Ａ

テーブル１Ａのライン６に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表６Ｂに示される：

表６Ｂ

表１Ａのライン６に対するログ・マネージャ１３８の状態は、以下の表６Ｃに示される：

表６Ｃ

表１Ａのライン６に対するトランザクションの状態は、以下の表６Ｄに示されている：

表６Ｄ

表１Ａのライン６に対するプライマリ・キーの状態は、以下の表６Ｅに示されている：

表６Ｅ

上記の表１Ａのライン７において、トランザクション３は、第１コマンド識別ステートメント（即ち、ｃｉｄ＝１）を処理するための新しいサブトランザクションを開始することができる。トランザクション番号マネージャ１３０は、サブトランザクションのためのＬＳＭトランザクション番号（即ち、（１０３，０））を検索することができ、サブトランザクション・コンテキストは、トランザクション番号１０３のためのコンテキスト・スタックにプッシュされ得る。トランザクション番号マネージャ１３０は、トランザクション番号１０２及びスナップショット・トランザクション・カウンタ番号１のためのテーブルの行にわたってスキャンするように、１というプライマリ・キーを有する行を返すスキャン・キーを用いてオペレーションを実行することができる。行バージョン・レコードが返され、これは１であるトランザクション・カウンタ番号のコミット済みバージョンである。これはトランザクション３にとってビジブルであり得るが、なぜなら、トランザクション１のトランザクション・カウンタ番号はトランザクション３のスナップショット・トランザクション・カウンタ番号以下である一方、トランザクション１からの未コミットの行バージョン・レコードはビジブルでないからである。トランザクション３は、ｘ＝３を有する行の新しいバージョンを記録するように、ストレージ１４０にレコードを挿入することによって、更新の処理に進むことができる。ロック・モードは、キー・アップデート・モードではないかもしれないが、トランザクション１によって保持される暗黙のキー・アップデートなしモードの行ロックと、トランザクション２によって要求されるペンディングの暗黙のキー・アップデートなし行ロックとでコンフリクトが存在するかもしれない。トランザクション３の更新のための行バージョン・レコードは、１であるプライマリ・キーのためのキー・バケット・ラッチが保持される間に、ストレージ１４０内に作成されることができ、フラグはｆａｌｓｅに設定されてもよい（即ち、ｇｒａｎｔｅｄ ｆｌａｇ＝ｆａｌｓｅ）。現在の行ロック状態は、１のプライマリ・キーに対して決定されてもよく、トランザクション３がトランザクション２（即ち、トランザクション番号１０２）によって近位にブロックされることが決定されてもよい。トランザクション３は、トランザクション２が終了するのを待つか、又は１という値を有するプライマリ・キーの行ロックを明示的に解放してもよい。ストレージ１４０は、共有モードでトランザクション番号１０２のロックに対するロックタグを取得することを試みることにより、トランザクション３をブロックすることができる。トランザクション２はアクティブであってもよく、トランザクション番号マネージャ１３０は、トランザクション番号１０２のロックタグの排他的ロックを維持していてもよく、従って、共有ロック・リクエストは待機することができる（即ち、「スリープ」）。

表１Ａのライン７に対するロック・マネージャ１２５の状態は、以下の表７Ａに示されている：

表７Ａ

テーブル１Ａのライン７に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表７Ｂに示されている：

表７Ｂ

表１Ａのライン７に対するログ・マネージャ１３８の状態は、以下の表７Ｃに示されている：

表７Ｃ

表１Ａのライン７に対するトランザクションの状態は、以下の表７Ｄに示されている：

表７Ｄ

表１Ａのライン７に対するプライマリ・キーの状態は、以下の表７Ｅに示されている：

表７Ｅ

上記の表１Ａのライン８において、トランザクション１は中断され得る。トランザクション番号マネージャ１３０は、ログ・マネージャ１３８によりアボートをログに記録し、トランザクション番号１０１のトランザクションをアボートするためにストレージ１４０においてオペレーションを実行することができる。アボート・トランザクション・オペレーションにおいて、ストレージ１４０内で逆順序で、トランザクション１の行バージョン・レコードのリストのレビュー（例えば、「ウォーク」）が存在し得る。このリストの横断中に、ストレージ１４０は、訪問する各行バージョン・レコードのキー・バケット・ラッチを取得してもよい。ラッチを保持している間、ストレージ１４０のデータ構造からのレコードはリンク解除されてもよく、また、行バージョン・レコードに関連する暗黙の行ロックの解放に起因して、任意のブロックされた行レベル・ロッカーがブロック解除され得るか否かの検査が存在してもよい。この場合、トランザクション１を中断することは、プライマリ・キー１の行ロックを解放する。プライマリ・キー１のペンディング・ロックのリストが調査され、トランザクション２がロックに対して次のラインにあると判断されてもよく、トランザクション番号１０１のブロックされたロックタグ・トランザクション・ロックのウェイクアップが実行されてもよい。アボート・トランザクション・オペレーションは、トランザクション番号１０１のトランザクション・ヘッダ・レコードを再利用するために解放してもよい。トランザクション番号マネージャ１３０は、トランザクション１のトランザクション・コンテキスト・スタックをパージ（ｐｕｒｇｅ）し、トランザクション（１０１）のためのロックタグに関してその排他的ロックを解除することができる。ロック・マネージャ１２５は、ロックタグ・トランザクション（１０１）がもはや参照されなくなると、「ごみ収集（ｇａｒｂａｇｅ−ｃｏｌｌｅｃｔ）」してもよい。

表１Ａのライン８に対するロック・マネージャ１２５の状態は、以下の表８Ａに示されている：

表８Ａ

テーブル１Ａのライン８に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表８Ｂに示されている：

表８Ｂ

表１Ａのライン８に対するログ・マネージャ１３８の状態は、以下の表８Ｃに示されている：

表８Ｃ

表１Ａのライン８に対するトランザクションの状態は、以下の表８Ｄに示されている：

表８Ｄ

表１Ａのライン８に対するプライマリ・キーの状態は、以下の表８Ｅに示されている：

表８Ｅ

上表１Ａのライン９に示すように、トランザクションは、ライン８におけるトランザクション１のアボート・オペレーション（即ち、ロールバック・オペレーション）によってブロック解除された。ロック・マネージャ１２５は、ロック解除の通知後に制御を取り戻し、１のプライマリ・キーに対するバケット・ラッチを再取得し、キーに対する現在のロック状態を調べることができる。トランザクション２は、キーにおける「キー非付与（ｎｏ ｋｅｙ ｇｒａｎｔｅｄ）」ロックを取得することが可能であるので、トランザクション２のペンディング行バージョン・レコード上のフラグは、ｔｒｕｅに設定され（即ち、ｇｒａｎｔｅｄ ｆｌａｇ＝ｔｒｕｅ）、上述の表１Ａのライン５からストレージ１４０にレコードを挿入するブロックされたオペレーションが続き（即ち、スナップショット・バイオレーションは存在せず）、バケット・ラッチが解放され得る。インサートは、ログ・マネージャ１３８によってログに記録され得る。トランザクション番号マネージャ１３０は、更新ステートメントのためのトランザクション・コンテキストを検索することができ、コミットを処理するように進行することができる。トランザクション番号マネージャ１３０を介して、トランザクション・カウンタ番号がトランザクション２（この場合、トランザクション・カウンタ番号は２）に割り当てられ、副次的に、ログ・マネージャ１３８によりコミット・レコードをログに記録する。コミット・トランザクション・オペレーションは、ストレージ１４０内のトランザクション２のトランザクション・ヘッダに、２であるトランザクション・カウンタ番号をスタンプするために呼び出され得る。表１Ａのこの時点で、トランザクション２のデータはコミットされ、２以上のスナップショット・トランザクション・カウンタ番号を有する任意のトランザクションにとってビジブルである。トランザクション番号マネージャ１３０は、ロックタグ・トランザクション（１０２）における排他的ロックを中止し、トランザクション２のトランザクション・コンテキストをパージすることができる。トランザクション２の行バージョン・レコードに、２であるトランザクション・カウンタ番号をスタンプし、トランザクション番号１０２のトランザクション・ヘッダ・レコードをリリースして、ストレージ１４０内で再利用するために、ポスト・コミットメント・トランザクションが呼び出されてもよい。トップレベル・コミット又はアボートに関し、通知により行ロックを明示的に解放する必要はないかもしれない。ブロックされたバックエンドは、ロックタグ・トランザクション（１０２）の排他的ロックが解除されると、自然に目覚め得る。

表１Ａのライン９に対するロック・マネージャ１２５の状態は、以下の表９Ａに示されている：

表９Ａ

表１Ａのライン９に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表９Ｂに示されている：

表９Ｂ

表１Ａのライン９に対するログ・マネージャ１３８の状態は、以下の表９Ｃに示されている：

表９Ｃ

表１Ａのライン９に対するトランザクションの状態は、以下の表９Ｄに示されている：

表９Ｄ

表１Ａのライン９に対するプライマリ・キーの状態は、以下の表９Ｅに示されている：

表９Ｅ

上記の表１Ａのライン１０に示されるように、トランザクション３は、表１Ａのライン９に示されるトランザクション２のコミットによってブロック解除され得る。ロック・マネージャ１２５は、トランザクション３がロックタグ・トランザクション（１０２）の共有ロックを取得し、共有ロックを解除し、プライマリ・キー１のバケット・ラッチを再取得し、キーの現在のロック状態を検査した後に、制御を取り戻すことができる。トランザクション３は、キー（プライマリ・キー）のＮｏＫｅｙＧｒａｎｔｅｄロックを取得することができるので、トランザクション３のペンディング行バージョン・レコードのフラグは、ｔｒｕｅに設定され（即ち、ｇｒａｎｔｅｄ ｆｌａｇ＝ｔｒｕｅ）、テーブル１Ａのライン７からストレージ１４０にレコードを挿入するためのブロックされたオペレーションが続いてもよい。しかしながら、この場合、スナップショット・バイオレーションが存在する。トランザクション３は、スナップショット・トランザクション・カウンタ番号１において行バージョン・レコードを挿入することを試みている可能性があるが、２であるトランザクション・カウンタ番号２を有するプライマリ・キー１対してコミットされた行バージョン・レコードが存在する。バケット・ラッチが解除され、挿入レコード・オペレーションが、スナップショット・バイオレーションが存在していることを示すエラーを返すことができる。幾つかの実装では、ステートメントはロールバックされ、新しいスナップショット・トランザクション・カウンタ番号で再始動されるかもしれない。トランザクション番号マネージャ１３０は、ＬＳＭトランザクション番号（１０３，０）でステートメントの開始にログ・マネージャ１３８によりロールバックを記録し、ストレージ１４０のロールバック・オペレーションを実行し、プライマリ・キー１のペンディング行バージョン・レコードをパージすることができる。この場合、通知を要するブロックされたウェイタ（ｗａｉｔｅｒｓ）は存在しない。トランザクション番号マネージャ１３０は、ステートメントのサブトランザクション・コンテキストを検索することができる。

別の例では、上記の表１Ａを使用して、オペレーションは、２であるスナップショット・トランザクション・カウンタ番号２を使用して実行されてもよい。トランザクション３は、第１コマンド識別ステートメント（ｃｉｄ＝１）を処理するための新しいサブトランザクションを開始してもよい。トランザクション番号マネージャ１３０は、サブトランザクションのためのＬＳＭトランザクション番号（即ち（１０３，０））を得るために、サブトランザクション開始オペレーションを実行することができる。このサブトランザクション・コンテキストは、トランザクション番号１０３のためにトランザクション番号マネージャ１３０のコンテキスト・スタックにプッシュされ得る。スキャン・オープン・オペレーションが実行され、トランザクション番号１０２及び１であるスナップショット・トランザクション・カウンタ番号のためのストレージ１４０内のテーブルの行にわたるスキャンを開始してもよく、そのスキャン・キーは１であるプライマリ・キーを有する行を返す。行バージョン・レコードは、２であるトランザクション・コミット番号を有するコミットされたバージョンとともに返され得る。この行バージョン・レコードはトランザクション３に対してビジブルであってもよく、なぜなら、２であるトランザクション・カウンタ番号が、トランザクション３のスナップショット・トランザクションカウンタ番号以下であるからである。トランザクション３は、３であるｘ値を有する新しいバージョンの行を記録するために、挿入レコード・オペレーションを実行することにより、更新の処理に進むことができる。ロック・モードは、「キー・アップデートなし（ｎｏ ｋｅｙ ｕｐｄａｔｅ）」であってもよい。ロック・コンフリクトは存在しないかもしれないので、ストレージ１４０は、トランザクション３の更新のための行バージョン・レコードを作成する一方、１であるプライマリ・キーに対するキー・バケット・ラッチを保持し、フラグをｔｒｕｅに設定することができる（即ち、ｇｒａｎｔｅｄ ｆｌａｇ＝ｔｒｕｅ）。バケット・ラッチは解放されてもよく、挿入はログ・マネージャ１３８によってログに記録されてもよい。トランザクション番号マネージャ１３０は、更新ステートメントのためのトランザクション・コンテキストを検索することができ、コミットを処理するために進むことができる。ログ・マネージャ１３８がコミット・レコードをログに記録すると、トランザクション番号マネージャ１３０により、トランザクション・カウンタ番号が、トランザクション３に割り当てられ得る（即ち、この場合、トランザクション・カウンタ番号は３であってもよい）。コミット・トランザクションは、トランザクション３のトランザクション・ヘッダに、３であるトランザクション・カウンタ番号をスタンプするようにストレージ１４０において実行されてもよい。トランザクション番号マネージャ１３０は、ロックタグ・トランザクション（１０３）における排他的ロックを排除し、トランザクション３のトランザクション・コンテキストをパージすることができる。ポスト・コミット・トランザクションは、ストレージ１４０内のトランザクション３の行バージョン・レコードにトランザクション・カウンタ番号３をスタンプし、トランザクション番号１０３のトランザクション・ヘッダ・レコードを再利用に備えて解放するために呼び出されてもよい。

表１Ａのライン７から始まるロック・マネージャ１２５のステータスは、２であるスナップショット・トランザクション・カウンタ番号を使用して、以下の表１０Ａに示されている：

表１０Ａ

表１Ａのライン７から始まるトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、２であるスナップショット・トランザクション・カウンタ番号を使用して、以下の表１０Ｂに示されている：

表１０Ｂ

表１Ａのライン７から始まるログ・マネージャ１３８の状態は、２であるスナップショット・トランザクション・カウンタ番号を使用して、以下の表１０Ｃに示されている：

表１０Ｃ

表１Ａのライン７から始まるプライマリ・キーのスナップショット・トランザクション・カウンタ番号２の状態は、２であるスナップショット・トランザクション・カウンタ番号を使用して、以下の表１０Ｄに示されている：

表１０Ｄ

下記の例は、明示的な行ロックに向けられている。下記の表１１Ａでは、３つのトランザクション履歴が存在し得る。

表１１Ａ

表１１Ａのライン１に示されるように、３つのトップ・レベルのトランザクション１、トランザクション２、及びトランザクション３が作成される。トランザクション番号マネージャ１３０は、トランザクション番号を（即ち、この例では、トランザクション番号１０１、１０２、及び１０３をそれぞれ）割り当て、トランザクション・コンテキストを作成し、トランザクション開始オペレーションを（即ち、そのトランザクション番号を有するアクティブなトランザクションが存在することを登録するために）実行することができる。トランザクション開始オペレーションは、トランザクションの開始のトランザクション・シーケンス番号（即ち、シーケンス番号ゼロ）でＬＳＭトランザクション番号値を初期化することができ、ＬＳＭトランザクション番号はトランザクション・コンテキストに配置される。更に、トランザクション番号マネージャ１３０は、ロックタグ・トランザクション（１０１）、ロックタグ・トランザクション（１０２）、及びロックタグ・トランザクション（１０３）のロックタグを有するロック・マネージャ１２５における排他的ロックを取得する。ログ・レコードは、これらのオペレーションの何れによっても生成されなくてよい。

表１１Ａのライン１に対するロック・マネージャ１２５の状態は、下記の表１１Ｂに示されている：

表１１Ｂ

表１１Ａのライン１に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表１１Ｃに示されている：

表１１Ｃ

テーブル１１Ａのライン１に対するログ・マネージャ１３８の状態は、以下の表１１Ｄに示されている：

表１１Ｄ

テーブル１１Ａのライン１に対するトランザクションの状態は、以下の表１１Ｅに示されている：

表１１Ｅ

表１１Ａのライン１に対するプライマリ・キーの状態は、以下の表１１Ｆに示されている：

表１１Ｆ

上表のライン２に示されるように、トランザクション１は、第１コマンド識別ステートメント（ｃｉｄ＝１）を処理するために、新しいサブトランザクションを開始することができる。トランザクション番号マネージャ１３０は、開始サブトランザクション・オペレーションを実行することができ、サブトランザクションのＬＳＭトランザクション番号値（即ち、（１０１，０））を取得することができる。このサブトランザクション・コンテキストは、トランザクション番号１０１のトランザクション番号マネージャ１３０のコンテキスト・スタックにプッシュされてもよい。「共有用選択」（“ｓｅｌｅｃｔ ｆｏｒ ｓｈａｒｅ”）ステートメントの処理は、１であるプライマリ・キー（ｐ＝１）に関する「共有（ｓｈａｒｅ）」のロック・モードでロック取得を行うことを含んでもよい。ロック取得オペレーションの中で、ストレージ１４０は、１のプライマリ・キー（ｐ＝１）に対するキー・バケットをラッチし、キーに対する現在のロック状態を調べることができる。グラントされた行ロックがないかもしれないので、行ロック・レコード（即ち、ｇｒａｎｔｅｄ＝ｔｒｕｅ）がキーのレコード・チェーンに挿入される。バケット・ロックは解除され、ロック取得オペレーションはノーマルの動作状態に戻ることができる。幾つかの実装では、ロック取得のログがないかもしれない。更新オペレーションが完了すると、トランザクション番号マネージャ１３０は、ステートメントのサブトランザクション・コンテキストを検索することができる。

表１１Ａのライン２に対するロック・マネージャ１２５の状態は、下記の表１２Ａに示されている：

表１２Ａ

テーブル１１Ａのライン２に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表１２Ｂに示されている：

表１２Ｂ

テーブル１１Ａのライン２に対するログ・マネージャ１３８の状態は、以下の表１２Ｃに示されている：

表１２Ｃ

表１１Ａのライン２に対するトランザクションの状態は、以下の表１２Ｄに示されている：

表１２Ｄ

表１１Ａのライン１に対するプライマリ・キーの状態は、以下の表１２Ｅに示されている：

表１２Ｅ

上述した表のライン３に示されるように、トランザクション２は、第１コマンド識別ステートメント（ｃｉｄ＝１）を処理するための新しいサブトランザクションを開始することができる。トランザクション番号マネージャ１３０は、開始サブトランザクション・オペレーションを実行することができ、サブトランザクションのＬＳＭトランザクション番号（即ち、（１０２，０））を取得することができる。このサブトランザクション・コンテキストは、トランザクション番号１０２のトランザクション番号マネージャ１３０のコンテキスト・スタックにプッシュされてもよい。「ｓｅｌｅｃｔ ｆｏｒ ｓｈａｒｅ」ステートメントの処理は、１であるプライマリ・キー１（ｐ＝１）に関する「ｓｈａｒｅ」のロック・モードでのロック取得オペレーションを含む。ロック取得オペレーションの中で、ストレージ１４０は、１のプライマリ・キー（ｐ＝１）に対するキー・バケットをラッチし、キーに対する現在のロック状態を調べることができる。このロック・リクエストは、トランザクション１に付与された「共有」ロックとコンパチブルであり得るため、行ロック・レコード（即ち、ｇｒａｎｔｅｄ＝ｔｒｕｅ）がキーのレコード・チェーンに挿入される。バケット・ロックは解除され、ロック取得オペレーションはノーマル・オペレーションに戻ることができる。幾つかの実装では、ロック取得のためのログは存在しない。更新オペレーションが完了すると、トランザクション番号マネージャ１３０は、ステートメントのサブトランザクション・コンテキストを検索することができる。

表１１Ａのライン３に対するロック・マネージャ１２５の状態は、下記の表１３Ａに示されている：

表１３Ａ

テーブル１１Ａのライン３に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表１３Ｂに示されている：

表１３Ｂ

テーブル１１Ａのライン３に対するログ・マネージャ１３８の状態は、以下の表１３Ｃに示されている：

表１３Ｃ

表１１Ａのライン３に対するトランザクションの状態は、以下の表１３Ｄに示されている：

表１３Ｄ

表１１Ａのライン３に対するプライマリ・キーの状態は、以下の表１３Ｅに示されている：

表１３Ｅ

上述した表のライン４に示されるように、トランザクション３は第１コマンド識別ステートメント（ｃｉｄ＝１）を処理するために新しいサブトランザクションを開始する。トランザクション番号マネージャ１３０は、開始サブトランザクション・オペレーションを呼び出し及び／又は実行することができ、サブトランザクションのＬＳＭトランザクション番号（即ち（１０３，０））を取得することができる。このサブトランザクション・コンテキストは、トランザクション番号１０３に対するトランザクション番号マネージャ１３０のコンテキスト・スタックにプッシュされてもよい。「アップデート」ステートメントの処理は、ｘ＝３の行の新しいバージョンを挿入するために、１のプライマリ・キー（ｐ＝１）に対して「キー・アップデートなし（ｎｏ ｋｅｙ ｕｐｄａｔｅ）」のロック・モードで挿入レコード・オペレーションを実行することができる。挿入レコード・オペレーションの中で、ストレージ１４０は、１というプライマリ・キーに関するキー・バケットをラッチし（ｐ＝１）、キーの現在のロック状態を調べることができる。更新リクエストは、トランザクション１及びトランザクション２に付与される共有ロックとコンパチブルではないかもしれないため、行バージョン・レコード（即ちここでは、ｇｒａｎｔｅｄ＝ｆａｌｓｅ）がキーのレコード・チェーンに挿入され、トランザクション３は、ロックタグ・トランザクション（１０２）ロックに対する共有リクエストにおいてスリープに移行することができる。バケット・ラッチは、スリープ・オペレーションからコールバックを介して解放されてもよい。

表１１Ａのライン４に対するロック・マネージャ１２５の状態は、下記の表１４Ａに示されている：

表１４Ａ

表１１Ａのライン４に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキストスタックの状態）は、以下の表１４Ｂに示されている：

表１４Ｂ

表１１Ａのライン４に対するログ・マネージャ１３８の状態は、以下の表１４Ｃに示されている：

表１４Ｃ

表１１Ａのライン４に対するトランザクションの状態は、以下の表１４Ｄに示されている：

表１４Ｄ

表１１Ａのライン４に対するプライマリ・キーの状態は、以下の表１４Ｅに示されている：

表１４Ｅ

上記の表のライン５は、トランザクション１がアボートになる（即ち、ロールバック・オペレーションが発生する）ことを示す。トランザクション番号マネージャ１３０は、ログ・マネージャ１３８でアボートをログに記録し、ＸＩＤ １０１のアボート・トランザクションを呼び出すことができる。ストレージ１４０のアボート・トランザクション・オペレーションにおいて、ストレージ１４０は、トランザクション１のレコードのリストを、逆順序で横断（即ち、「ウォーク」）し得る。このリスト横断中に、ストレージ１４０は、訪問する各々の行バージョン・レコード及び／又は行ロック・レコードのキー・バケット・ラッチを取得することができる。ラッチを保持する間、ストレージ１４０のデータ構造からのレコードはリンク解除されてもよく、また、暗黙的又は明示的な行ロックの解放に起因して、任意のブロックされた行レベル・ロッカーがブロック解除され得るか否かが決定されてもよい。この場合、トランザクション１をアボートすることは、ｐ＝１の共有される行ロックを解除する。プライマリ・キー１（即ち、ｐ＝１）のペンディング・ロッカーのリストを調べた後、ストレージ１４０は、トランザクション３がトランザクション２によってブロックされたままであることを決定することができ、従って、トランザクション３はウェイクアップするように通知されない。また、オペレーション中断トランザクションは、トランザクション番号１０１のトランザクション・ヘッダ・レコードを再利用するために解放することもできる。中断トランザクション・オペレーションから戻ると、トランザクション番号マネージャ１３０は、トランザクション番号マネージャ１３０におけるトランザクション１のトランザクション・コンテキスト・スタックをパージし、ロックタグ・トランザクション（１０１）における排他的ロックを解除することができる。

表１１Ａのライン５に対するロック・マネージャ１３８の状態は、下記の表１５Ａに示されている：

表１５Ａ

表１１Ａのライン５に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表１５Ｂに示されている：

表１５Ｂ

表１１Ａのライン５に対するログ・マネージャ１３８の状態は、以下の表１５Ｃに示されている：

表１５Ｃ

表１１Ａのライン５に対するトランザクションの状態は、以下の表１５Ｄに示されている：

表１５Ｄ

表１１Ａのライン５に対するプライマリ・キーの状態は、以下の表１５Ｅに示されている：

表１５Ｅ

上記の表のライン６は、トランザクション２がアボートすること（即ち、ロールバック・オペレーションが発生すること）を示す。トランザクション番号マネージャ１３０は、ログ・マネージャ１３８によりアボートをログに記録し、トランザクション番号１０２のアボート・トランザクション・オペレーションを呼び出すことができる。アボート・トランザクションでは、ストレージ１４０において逆順序でトランザクション２のレコードのリストを横断することがあり得る。トランザクション１（ｐ＝１）をアボートすると、１のプライマリ・キーの共有行ロックを解除する。ｐ＝１のためのペンディング・ロッカーのリストを検討した後、ストレージ１４０は、トランザクション３が行ロックを取得し得ると判断し、ウェイクアップ・オペレーションを呼び出すことによって、トランザクション番号１０２のためのロックタグ・トランザクション・ロックにおいてブロックされたバックエンドのウェイクアップ・オペレーションを呼び出すことができる。また、アボート・トランザクションは、トランザクション番号１０２のトランザクション・ヘッダ・レコードを再利用するために解放することもできる。アボート・トランザクションオペレーションから戻ると、トランザクション番号マネージャ１３０は、トランザクション番号マネージャ１３０のトランザクション・コンテキスト・スタックをパージし、ロックタグ・トランザクション（１０２）の排他的ロックを解除することができる。

表１１Ａのライン６に対するロック・マネージャ１２５の状態は、下記の表１６Ａに示されている：

表１６Ａ

テーブル１１Ａのライン６に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表１６Ｂに示されている：

表１６Ｂ

表１１Ａのライン６に対するログ・マネージャ１３８の状態は、以下の表１６Ｃに示されている：

表１６Ｃ

表１１Ａのライン６に対するトランザクションの状態は、以下の表１６Ｄに示されている：

表１６Ｄ

表１１Ａのライン６に対するプライマリ・キーの状態は、以下の表１６Ｅに示されている：

表１６Ｅ

上記の表におけるライン行７は、ライン６におけるトランザクション２のアボートによって、トランザクション３がブロック解除されたことを示す。ロック・マネージャ１２５は、共有ロック・ロックタグ・トランザクション（１０２）を取得するロック・マネージャ１２５の試みから「通知されるステータス」によりトランザクション３が呼び起こされた後に制御を取り戻すことができる。ロック・マネージャ１２５は、１のプライマリ・キー（ｐ＝１）のバケット・ラッチを再取得し、キーの現在のロック状態を調べることができる。トランザクション３は、キーに関する「許可キーなし（ｎｏ ｋｅｙ ｇｒａｎｔｅｄ）」のロックを取得することができるので、トランザクション３のペンディングの行バージョン・レコードのフラグは、ｔｒｕｅ に設定され（即ち、ｇｒａｎｔｅｄ ｆｌａｇ＝ｔｒｕｅ）、上記の表のライン４からの挿入レコード・オペレーションに対するブロックされたコールが継続してよい。バケット・ラッチは解放されることが可能であり、挿入はログ・マネージャ１３８によってログに記録されることが可能である。トランザクション番号マネージャ１３０は、更新ステートメントのためのトランザクション・コンテキストを検索することができ、コミットを処理することができる。トランザクション番号マネージャ１３０により、トランザクション・カウンタ番号は、トランザクション３に割り当てられ（この場合、トランザクション・カウンタ番号は２であり）、副次的にコミット・レコードを記録する。コミット・トランザクション・オペレーションは、トランザクション３のトランザクション・ヘッダにトランザクション・カウンタ番号２をスタンプするために実行されてもよい。トランザクション番号マネージャ１３０は、ロックタグ・トランザクション（１０３）における排他的ロックをドロップし、トランザクション３のトランザクション・コンテキストをパージすることができる。ポスト・コミット・トランザクション・オペレーションは、トランザクション３の行バージョン・レコードに、２であるトランザクション・カウンタ番号をスタンプし、トランザクション番号１０３に関するトランザクション・ヘッダ・レコードを再利用するために解放するように実行されてもよい。

表１１Ａのライン７に対するロック・マネージャ１２５の状態は、下記の表１７Ａに示されている：

表１７Ａ

表１１Ａのライン７に対するトランザクション番号マネージャ１３０の状態（即ち、コンテキスト・スタックの状態）は、以下の表１７Ｂに示されている：

表１７Ｂ

表１１Ａのライン７に対するログ・マネージャ１３８の状態は、以下の表１７Ｃに示されている：

表１７Ｃ

表１１Ａのライン７に対するトランザクションの状態は、以下の表１７Ｄに示されている：

表１７Ｄ

表１１Ａのライン７に対するプライマリ・キーの状態は、以下の表１７Ｅに示されている：

表１７Ｅ

より一般的には、現在開示している対象事項の様々な実装は、これらのプロセスを実現するためのコンピュータ実装プロセス及び装置の形態を含んでもよく、又はそれらで実現されてもよい。また、実装は、フロッピー・ディスケット、ＣＤ−ＲＯＭ、ハード・ドライブ、ＵＳＢ（ユニバーサル・シリアル・バス）ドライブ、又は任意の他のマシン読み取り可能な記憶媒体のような、非一時的な及び／又は有形の媒体に実装される命令を含むコンピュータ・プログラム・コードを有するコンピュータ・プログラム製品の形態で実現されてもよく、コンピュータ・プログラム・コードがコンピュータにロードされ、実行される場合、コンピュータは、開示された対象事項の実装を実現するための装置となる。また、実装は、例えば、記憶媒体に格納されているか、コンピュータにロードされるか、及び／又はコンピュータによって実行されるか、又は電気配線若しくはケーブル配線を介して、光ファイバを介して、又は電磁放射を介して何らかの伝送媒体によって伝送されるかにかかわらず、コンピュータ・プログラム・コードの形態で実行されてもよく、コンピュータ・プログラム・コードがコンピュータにロードされ、コンピュータによって実行される場合、コンピュータは、開示された対象事項の実装を実現するための装置となる。汎用マイクロプロセッサで実施される場合、コンピュータ・プログラム・コードのセグメントは、特定の論理回路を作り出すようにマイクロプロセッサを構成する。幾つかの構成では、コンピュータ読み取り可能な記憶媒体に保存される一組のコンピュータ読み取り可能な命令は、汎用プロセッサにより実現されてもよく、その命令は、汎用プロセッサ又は汎用プロセッサを含む装置を、命令を実装又は実行するように構成された専用装置に変えることができる。実装は、汎用マイクロプロセッサ及び／又は特定用途向け集積回路等のプロセッサを含むハードウェアを利用して実現されることが可能であり、汎用マイクロプロセッサ等は、ハードウェア及び／又はファームウェアにおいて、開示された対象事項の実装に従う技術の全部又は一部を実施する。プロセッサは、ＲＡＭ、ＲＯＭ、フラッシュ・メモリ、ハードディスク、又は電子情報を記憶することができる任意の他の装置などのメモリに結合されてもよい。メモリは、開示される対象事項の実装に従う技術を実行するようにプロセッサによって実行されるように構成される命令を記憶することができる。

上記の説明は、説明の目的で、特定の実装を参照して記述されている。しかしながら、上記の例示的な議論は、網羅的であるように、又は開示された対象事項の実装を、開示された形態どおりに限定するようには意図されていない。上記の教示を考慮して多くの修正及び変形が可能である。実施例は、開示された対象事項の実装の原理及びそれらの実用的応用を説明するために、選択及び説明されており、それによって、想定される特定の用途に適するように、当業者が、これらの実装だけでなく様々な修正を施した様々な実装をも利用できるようにする。

以下、更なる具体例を記載する：
（具体例１）
ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するコンピュータで実現される方法であって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションでレコードとして保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、各々のレコードはデータベースのテーブルにおける１つ以上の行の識別子を含むキーにより識別され、前記方法は：
トランザクション・カウンタ番号に関するクエリを前記サーバー・システムで受信するステップ；
データを識別するトランザクション・ヘッダが、前記サーバー・システムにおいて、割り当てられたトランザクション・カウンタ番号で更新される場合、更新された前記データを識別するトランザクション・ヘッダを、マルチバージョン同時制御情報のインスタンスとして、受信したクエリにより使用するステップ；
前記サーバー・システムにおいて、前記受信したクエリに基づいて、前記データベースの前記テーブルにおいてキー・ルックアップを実行するステップ；
前記キー・ルックアップが、コミットされていない行に遭遇した場合、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションにおいて、トランザクション番号がコミットされるか否かを判断するためにデータ・アレイ要素を識別し、対応するトランザクション・カウンタ番号を決定するために、データを識別する対応するトランザクション・ヘッダにアクセスするステップ；及び
前記サーバー・システムにおいて、行バージョン・レコードにトランザクション・カウンタ番号をスタンプするステップ；
を含む方法。
（具体例２）
前記対応するトランザクション・ヘッダにアクセスする前記ステップは：
前記行バージョン・レコード及び行ロック・レコードにおけるトランザクション・ヘッダ・インデックス・フィールドを利用して前記データ・アレイ要素を識別するステップ；
を含む、具体例１に記載の方法。
（具体例３）
トランザクション識別子を有するトランザクションにより影響を受ける各々の行に関し、前記トランザクション・カウンタ番号で、前記トランザクションにより影響を受ける各々の行をスタンプし、任意の行ロックを解放するステップを更に含む具体例１に記載の方法。
（具体例４）
１つ以上の行ルックアップ・レコードがコミットされていない場合に行ルックアップを実行するステップであって、前記１つ以上の行ルックアップ・レコードは、前記トランザクション・カウンタ番号でスタンプされていない場合には、コミットされていない、ステップを更に有する具体例１に記載の方法。
（具体例５）
前記１つ以上のコミットされていないレコードがクエリにとって外的に認識可能でない場合に、前記１つ以上のコミットされていない行ルックアップ・レコードを独立に処理するステップを更に含む具体例４に記載の方法。
（具体例６）
ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するコンピュータで実現される方法であって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、１つ以上のストレージ・デバイス・ロケーションで保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、トランザクションは１つ以上のクエリにとって当初は認識可能でなく、前記方法は：
前記サーバー・システムにおいて、レコード・チェーンに対するアクセスを制御するために、前記サーバー・システムに保存されるレコードのアップデート各々に関連するトランザクション識別子のためのバケットをラッチし、前記トランザクション識別子をハッシュすることからの任意のハッシュ衝突を解決するステップであって、前記バケットは、前記トランザクション識別子の前記ハッシュを含む、ステップ；
前記サーバー・システムにおいて、データを識別する前記トランザクション・ヘッダにおけるトランザクション・カウンタ番号を、トランザクション番号に設定するステップ；
前記サーバー・システムにおいて前記バケットをアンラッチし、前記サーバー・システムにおいて前記トランザクション・カウンタ番号を更新し、前記サーバー・システムにおいて、前記サーバー・システムにより受信される１つ以上のクエリに対して、前記トランザクションを認識可能にするステップ；及び
前記サーバー・システムにおけるトランザクション・マネージャにより、前記トランザクション番号をアンロックするために前記トランザクション番号におけるトランザクション・ロックを解放し、前記サーバー・システムにおいて、前記サーバー・システムにより受信される１つ以上のクエリに対して認識可能にするステップ；
を含む方法。
（具体例７）
前記トランザクション識別子をハッシュするステップ；
を更に含む具体例６に記載の方法。
（具体例８）
前記トランザクション識別子のダイレクト・ルックアップを実行するステップ；
を更に含む具体例６に記載の方法。
（具体例９）
データを識別する前記トランザクション・ヘッダにおけるトランザクション・カウンタ番号を設定する前記ステップが：
前記トランザクションに関連する全ての行ロックを解放するステップ；
を更に含む、具体例６に記載の方法。
（具体例１０）
ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するコンピュータで実現される方法であって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションでレコードとして保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、各々のレコードはデータベースのテーブルにおける１つ以上の行の識別子を含むキーにより識別され、トランザクションは１つ上のクエリに対して認識可能であり、前記方法は：
前記サーバー・システムにおいて、レコード・チェーンに対するアクセスを制御するために前記サーバー・システムに保存されるレコードのアップデート各々に関連するトランザクション識別子のためのハッシュ・バケットをラッチするステップ；
前記サーバー・システムにおいて、前記レコードのトランザクションに関連するデータを識別するトランザクション・ヘッダにおける現在のキー・ハッシュ値及び現在のシーケンス番号を設定し、前記トランザクション識別子のための前記ハッシュ・バケットをアンラッチするステップであって、前記シーケンス番号は前記レコードの行のシーケンスにおける位置を識別する、ステップ；
前記サーバー・システムにおいて、行ロック・レコード及び行バージョン・レコードから、前記行ロック・レコード及び前記行バージョン・レコードのうち少なくとも１つに行識別子が存在するか否かを判断するステップであって、トランザクション番号は前記トランザクション識別子と同一であり、シーケンス番号は、前記サーバー・システムによりレビューされる現在のシーケンス番号と同一である、ステップ；
前記サーバー・システムにおいて、前記トランザクション・カウンタ番号を前記現在の行バージョン・レコードにスタンプし、そのため、前記トランザクション番号が前記トランザクション識別子と同一であり、前記シーケンス番号が前記現在のシーケンス番号と同一である場合に、前記現在の行バージョン・レコードはコミットされる、ステップ；
を含む方法。
（具体例１１）
前記行識別子が前記トランザクション識別子に等しくないトランザクション番号を有する場合、又は前記行識別子が前記トランザクション識別子に等しいトランザクション番号を有し且つ前記シーケンス番号が前記現在のシーケンス番号以上である場合に、前記レコードにおける次の行バージョンに移動するステップを更に含む具体例１０に記載の方法。
（具体例１２）
前記行ロック・レコードのうちの１つが同時ルックアップ動作によりスタンプされていない場合に、前記スタンプが生じる、具体例１０に記載の方法。
（具体例１３）
前記トランザクション番号が前記トランザクション識別子と同一であり、前記シーケンス番号が前記行ロック・レコードのうちの１つに対する現在のシーケンス番号と同一である場合に、前記行ロック・レコードのうちの１つを、前記１つ以上のストレージ・デバイス・ロケーションから除外するステップを更に含む具体例１０に記載の方法。
（具体例１４）
前記行バージョン・レコードのうちの１つは、同時ルックアップ動作によりスタンプされていない、具体例１０に記載の方法。
（具体例１５）
以前のシーケンス番号が存在するか否かを判断するステップを更に含む具体例１０に記載の方法。
（具体例１６）
以前のキー・ハッシュ値に前記現在のキー・ハッシュ値を設定するステップ；
前記現在のシーケンス番号を前記以前のシーケンス番号に設定するステップ；及び
キー・バケットをアンラッチするステップ；
を更に含み、前記ラッチは前記レコード・チェーンに対するアクセスを制御する、具体例１５に記載の方法。
（具体例１７）
前記以前のシーケンス番号が末端値に達した場合に、前記レコード・チェーンのレビューをストップするステップを更に含む具体例１５に記載の方法。
（具体例１８）
トランザクション識別子をハッシュするステップ；及び
前記トランザクション識別子をハッシュすることからの任意のハッシュ衝突を解決するステップ；
を更に含む具体例１０に記載の方法。
（具体例１９）
前記トランザクション識別子のダイレクト・ルックアップを実行するステップを更に含む具体例１０に記載の方法。
（具体例２０）
ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するコンピュータで実現される方法であって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションでレコードとして保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、各々のレコードはデータベースのテーブルにおける１つ以上の行の識別子を含むキーにより識別され、トランザクションは１つ以上のクエリに対して認識可能であり、前記方法は：
前記サーバー・システムにおいて前記キーをハッシュするステップ；
前記サーバー・システムにおいて、前記キーに対するキー・ハッシュ・バケットをラッチし、ハッシュすることからの任意の衝突を解決するステップ；
前記サーバー・システムにおいて、スナップショット・トランザクション・カウンタ番号、キーの自己識別番号、及びコマンド識別ステートメントに基づいて、最新の認識可能な行バージョン・レコードを決定するために、レコードについてのキーの行バージョン・チェーンをサーチするステップ；
を含み、前記サーチするステップは：
前記サーバー・システムにおいて、レコードの行バージョン・チェーンの行がアンコミットされているか否かを判断するステップ；
前記行がアンコミットされている場合、前記サーバー・システムにおいて、情報を識別する前記トランザクション・ヘッダから、トランザクション・カウンタ番号値を読み込むステップ；及び
前記トランザクション・カウンタ番号と同じ行トランザクション・カウンタを有することにより、前記トランザクション・カウンタ番号が有効である場合に、前記サーバー・システムにおいて、現在の行バージョン・レコードに前記トランザクション・カウンタ番号をスタンプし、前記現在の行バージョン・レコードを、コミットされているものとしてマークするステップ；
を含む方法。
（具体例２１）
前記行バージョン・レコードが、マルチバージョン同時制御（ＭＶＣＣ）に対して認識可能であるか否かを判断するステップ；及び
前記行バージョン・レコードが前記ＭＶＣＣに対して認識可能である場合に、前記サーチをストップするステップ；
を更に含む具体例２０に記載の方法。
（具体例２２）
前記行バージョン・レコードが、マルチバージョン同時制御（ＭＶＣＣ）に対して認識可能であるか否かを判断するステップ；及び
存在する場合には次の行バージョン・レコードに進み、又は前記サーチをストップするステップ；
を更に含む具体例２０に記載の方法。
（具体例２３）
ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するサーバー・システムであって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションでレコードとして保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、各々のレコードはデータベースのテーブルにおける１つ以上の行の識別子を含むキーにより識別され、前記サーバー・システムは：
トランザクション・カウンタ番号に関するクエリを受信するステップ；
前記キー・ルックアップが、前記１つ以上のストレージ・デバイス・ロケーションにおいてトランザクション番号についてコミットされていない行に遭遇した場合に、受信したクエリにより、マルチバージョン同時制御情報のインスタンスとして、データを識別する更新されたトランザクション・ヘッダを利用するステップ；
前記受信したクエリに基づいて、前記データベースの前記テーブルにおいてキー・ルックアップを実行するステップ；
前記キー・ルックアップが、コミットされていない行に遭遇した場合に、前記サーバー・システムが、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションにおいて、前記１つ以上のストレージ・デバイス・ロケーションにおけるデータ・アレイ要素を識別し、トランザクション番号がコミットされるか否かを判断するために、データを識別する対応するトランザクション・ヘッダにアクセスし、対応するトランザクション・カウンタ番号を決定するステップ；及び
前記１つ以上のストレージ・デバイス・ロケーションにおける行バージョン・レコードに前記トランザクション・カウンタ番号をスタンプするステップ；
を行うシステム。
（具体例２４）
前記サーバー・システムは、前記行バージョン・レコード及び行ロック・レコードにおけるトランザクション・ヘッダ・インデックス・フィールドを利用して前記データ・アレイ要素を識別することにより、前記１つ以上のストレージ・デバイス・ロケーションにおける前記対応するトランザクション・ヘッダにアクセスする、具体例２３に記載のシステム。
（具体例２５）
前記サーバー・システムは、前記トランザクション・カウンタ番号で、前記トランザクションにより影響を受ける各々の行をスタンプし、前記１つ以上のストレージ・デバイス・ロケーションにおいてトランザクション識別子を有するトランザクションにより影響を受ける各々の行について任意の行ロックを解放する、具体例２３に記載のシステム。
（具体例２６）
前記サーバー・システムは、１つ以上の行ルックアップ・レコードがコミットされていない場合に、前記１つ以上のストレージ・デバイス・ロケーションにおいて行ルックアップを実行し、そのため、前記１つ以上の行ルックアップ・レコードは、前記トランザクション・カウンタ番号でスタンプされていない場合には、コミットされていない、具体例２３に記載のシステム。
（具体例２７）
前記１つ以上のコミットされていないレコードがクエリにとって外的に認識可能でない場合に、前記１つ以上のストレージ・デバイス・ロケーションの前記１つ以上のコミットされていない行ルックアップ・レコードを独立に処理する、具体例２６に記載のシステム。
（具体例２８）
ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するサーバー・システムであって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、１つ以上のストレージ・デバイス・ロケーションで保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、トランザクションは１つ以上のクエリにとって当初は認識可能でなく、前記サーバー・システムは：
前記１つ以上のストレージ・デバイス・ロケーションにおいてレコード・チェーンに対するアクセスを制御するために、前記サーバー・システムに保存されるレコードのアップデート各々に関連するトランザクション識別子のためのバケットをラッチし、前記トランザクション識別子をハッシュすることからの任意のハッシュ衝突を解決するステップであって、前記バケットは、前記トランザクション識別子の前記ハッシュを含む、ステップ；
データを識別する前記トランザクション・ヘッダにおけるトランザクション・カウンタ番号を、前記１つ以上のストレージ・デバイス・ロケーションにおいてトランザクション番号に設定するステップ；
前記バケットをアンラッチし、前記１つ以上のストレージ・デバイス・ロケーションにおいてシステム・リード・トランザクション・カウンタ番号を更新し、前記サーバー・システムにより受信される１つ以上のクエリに対して、前記トランザクションを認識可能にするステップ；及び
前記サーバー・システムのトランザクション・マネージャにより、前記トランザクション番号をアンロックするために前記１つ以上のストレージ・デバイス・ロケーションにおける前記トランザクション番号のトランザクション・ロックを解放し、前記サーバー・システムにより受信される１つ以上のクエリに対して認識可能にするステップ；
を行うシステム。
（具体例２９）
前記サーバー・システムは、前記トランザクション識別子をハッシュする、具体例２８に記載のシステム。
（具体例３０）
前記サーバー・システムは、前記１つ以上のストレージ・デバイス・ロケーションにおいて前記トランザクション識別子のダイレクト・ルックアップを実行する、具体例２８に記載のシステム。
（具体例３１）
前記サーバー・システムは、前記１つ以上のストレージ・デバイス・ロケーションにおいてデータを識別する前記トランザクション・ヘッダにおける前記トランザクション・カウンタ番号を設定し、前記トランザクションに関連する全ての行ロックを解放する、具体例２８に記載のシステム。
（具体例３２）
ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するサーバー・システムであって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションでレコードとして保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、各々のレコードはデータベースのテーブルにおける１つ以上の行の識別子を含むキーにより識別され、トランザクションは１つ上のクエリに対して認識可能であり、前記サーバー・システムは：
前記１つ以上のストレージ・デバイス・ロケーションにおいてレコード・チェーンに対するアクセスを制御するために前記サーバー・システムに保存されるレコードのアップデート各々に関連するトランザクション識別子のためのハッシュ・バケットをラッチするステップ；
前記１つ以上のストレージ・デバイス・ロケーションにおいて、前記レコードのトランザクションに関連するデータを識別するトランザクション・ヘッダにおける現在のキー・ハッシュ値及び現在のシーケンス番号を設定し、前記トランザクション識別子のための前記ハッシュ・バケットをアンラッチするステップであって、前記シーケンス番号は前記レコードの行のシーケンスにおける位置を識別する、ステップ；
行ロック・レコード及び行バージョン・レコードから、前記行ロック・レコード及び前記行バージョン・レコードのうち少なくとも１つに行識別子が存在するか否かを判断するステップであって、トランザクション番号は前記トランザクション識別子と同一であり、シーケンス番号は、前記サーバー・システムによりレビューされる前記１つ以上のストレージ・デバイス・ロケーションにおける現在のシーケンス番号と同一である、ステップ；及び
前記１つ以上のストレージ・デバイス・ロケーションにおいて、前記現在の行バージョン・レコードに前記トランザクション・カウンタ番号をスタンプし、そのため、前記トランザクション番号が前記トランザクション識別子と同一であり、前記シーケンス番号が前記現在のシーケンス番号と同一である場合に、前記現在の行バージョン・レコードはコミットされる、ステップ；
を行うシステム。
（具体例３３）
前記行識別子が前記トランザクション識別子に等しくないトランザクション番号を有する場合、又は前記行識別子が前記トランザクション識別子に等しいトランザクション番号を有し且つ前記シーケンス番号が前記現在のシーケンス番号以上である場合に、前記サーバー・システムは前記レコードにおける次の行バージョンに移動する、具体例３２に記載のシステム。
（具体例３４）
前記少なくとも１つのサーバー・システムにおいて前記行ロック・レコードのうちの１つが同時ルックアップ動作によりスタンプされていない場合に、前記サーバー・システムによる前記スタンプが生じる、具体例３２に記載のシステム。
（具体例３５）
前記トランザクション番号が前記トランザクション識別子と同一であり、前記シーケンス番号が前記行ロック・レコードのうちの１つに対する現在のシーケンス番号と同一である場合に、前記サーバー・システムは、前記行ロック・レコードのうちの１つを、前記１つ以上のストレージ・デバイス・ロケーションから除外する、具体例３２に記載のシステム。
（具体例３６）
前記１つ以上のストレージ・デバイス・ロケーションの前記行バージョン・レコードのうちの１つが、同時ルックアップ動作によりスタンプされていない場合に、前記サーバー・システムによる前記スタンプが生じる、具体例３２に記載のシステム。
（具体例３７）
前記サーバー・システムは、以前のシーケンス番号が存在するか否かを判断する、具体例３２に記載のシステム。
（具体例３８）
前記サーバー・システムは、以前のキー・ハッシュ値に前記現在のキー・ハッシュ値を設定し、前記現在のシーケンス番号を前記以前のシーケンス番号に設定し、キー・バケットをアンラッチし、前記ラッチは、前記１つ以上のストレージ・デバイス・ロケーションにおける前記レコード・チェーンに対するアクセスを制御する、具体例３７に記載のシステム。
（具体例３９）
前記以前のシーケンス番号が末端値に達した場合に、前記サーバー・システムは、前記１つ以上のストレージ・デバイス・ロケーションにおける前記レコード・チェーンのレビューをストップする、具体例３７に記載のシステム。
（具体例４０）
前記サーバー・システムは、トランザクション識別子をハッシュし、前記トランザクション識別子をハッシュすることからの任意のハッシュ衝突を解決する、具体例３２に記載のシステム。
（具体例４１）
前記サーバー・システムは、前記トランザクション識別子のダイレクト・ルックアップを実行する、具体例３２に記載のシステム。
（具体例４２）
ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するサーバー・システムであって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションで、データベースのテーブルにおける１つ以上の行の識別子を含むキーにより識別されるレコードとして保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、トランザクションは１つ以上のクエリに対して認識可能であり、前記サーバー・システムは：
前記キーをハッシュするステップ；
前記キーに対するキー・ハッシュ・バケットをラッチし、ハッシュすることからの任意の衝突を解決するステップ；
スナップショット・トランザクション・カウンタ番号、キーの自己識別番号、及びコマンド識別ステートメントに基づいて、最新の認識可能な行バージョン・レコードを決定するために、前記１つ以上のストレージ・デバイス・ロケーションにおいてレコードについてのキーの行バージョン・チェーンをサーチするステップ；
レコードの行バージョン・チェーンの行がアンコミットされているか否かを判断するステップ；
前記行がアンコミットされている場合、情報を識別する前記トランザクション・ヘッダから、トランザクション・カウンタ番号値を読み込むステップ；及び
前記トランザクション・カウンタ番号と同じ行トランザクション・カウンタを有することにより、前記トランザクション・カウンタ番号が有効である場合に、現在の行バージョン・レコードに前記トランザクション・カウンタ番号をスタンプし、前記現在の行バージョン・レコードを、コミットされているものとしてマークするステップ；
を行うサーバー・システム。
（具体例４３）
前記サーバー・システムは、前記行バージョン・レコードがマルチバージョン同時制御（ＭＶＣＣ）に対して認識可能であるか否かを判断し、前記行バージョン・レコードが前記ＭＶＣＣに対して認識可能である場合に、前記サーチをストップする、具体例４２に記載のシステム。
（具体例４４）
前記サーバー・システムは、前記行バージョン・レコードがマルチバージョン同時制御（ＭＶＣＣ）に対して認識可能であるか否かを判断し、存在する場合には次の行バージョン・レコードに進み、又は前記サーチをストップする、具体例４２に記載のシステム。

Claims (44)

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. ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するサーバー・システムであって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、１つ以上のストレージ・デバイス・ロケーションで保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、トランザクションは１つ以上のクエリにとって当初は認識可能でなく、前記サーバー・システムは：
    前記１つ以上のストレージ・デバイス・ロケーションにおいてレコード・チェーンに対するアクセスを制御するために、前記サーバー・システムに保存されるレコードのアップデート各々に関連するトランザクション識別子のためのバケットをラッチし、前記トランザクション識別子をハッシュすることからの任意のハッシュ衝突を解決するステップであって、前記バケットは、前記トランザクション識別子の前記ハッシュを含む、ステップ；
    データを識別する前記トランザクション・ヘッダにおけるトランザクション・カウンタ番号を、前記１つ以上のストレージ・デバイス・ロケーションにおいてトランザクション番号に設定するステップ；
    前記バケットをアンラッチし、前記１つ以上のストレージ・デバイス・ロケーションにおいてシステム・リード・トランザクション・カウンタ番号を更新し、前記サーバー・システムにより受信される１つ以上のクエリに対して、前記トランザクションを認識可能にするステップ；及び
    前記サーバー・システムのトランザクション・マネージャにより、前記トランザクション番号をアンロックするために前記１つ以上のストレージ・デバイス・ロケーションにおける前記トランザクション番号のトランザクション・ロックを解放し、前記サーバー・システムにより受信される１つ以上のクエリに対して認識可能にするステップ；
    を行うシステム。
29. 前記サーバー・システムは、前記トランザクション識別子をハッシュする、請求項２８に記載のシステム。
30. 前記サーバー・システムは、前記１つ以上のストレージ・デバイス・ロケーションにおいて前記トランザクション識別子のダイレクト・ルックアップを実行する、請求項２８に記載のシステム。
31. 前記サーバー・システムは、前記１つ以上のストレージ・デバイス・ロケーションにおいてデータを識別する前記トランザクション・ヘッダにおける前記トランザクション・カウンタ番号を設定し、前記トランザクションに関連する全ての行ロックを解放する、請求項２８に記載のシステム。
32. ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するサーバー・システムであって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションでレコードとして保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、各々のレコードはデータベースのテーブルにおける１つ以上の行の識別子を含むキーにより識別され、トランザクションは１つ上のクエリに対して認識可能であり、前記サーバー・システムは：
    前記１つ以上のストレージ・デバイス・ロケーションにおいてレコード・チェーンに対するアクセスを制御するために前記サーバー・システムに保存されるレコードのアップデート各々に関連するトランザクション識別子のためのハッシュ・バケットをラッチするステップ；
    前記１つ以上のストレージ・デバイス・ロケーションにおいて、前記レコードのトランザクションに関連するデータを識別するトランザクション・ヘッダにおける現在のキー・ハッシュ値及び現在のシーケンス番号を設定し、前記トランザクション識別子のための前記ハッシュ・バケットをアンラッチするステップであって、前記シーケンス番号は前記レコードの行のシーケンスにおける位置を識別する、ステップ；
    行ロック・レコード及び行バージョン・レコードから、前記行ロック・レコード及び前記行バージョン・レコードのうち少なくとも１つに行識別子が存在するか否かを判断するステップであって、トランザクション番号は前記トランザクション識別子と同一であり、シーケンス番号は、前記サーバー・システムによりレビューされる前記１つ以上のストレージ・デバイス・ロケーションにおける現在のシーケンス番号と同一である、ステップ；及び
    前記１つ以上のストレージ・デバイス・ロケーションにおいて、前記現在の行バージョン・レコードに前記トランザクション・カウンタ番号をスタンプし、そのため、前記トランザクション番号が前記トランザクション識別子と同一であり、前記シーケンス番号が前記現在のシーケンス番号と同一である場合に、前記現在の行バージョン・レコードはコミットされる、ステップ；
    を行うシステム。
33. 前記行識別子が前記トランザクション識別子に等しくないトランザクション番号を有する場合、又は前記行識別子が前記トランザクション識別子に等しいトランザクション番号を有し且つ前記シーケンス番号が前記現在のシーケンス番号以上である場合に、前記サーバー・システムは前記レコードにおける次の行バージョンに移動する、請求項３２に記載のシステム。
34. 前記少なくとも１つのサーバー・システムにおいて前記行ロック・レコードのうちの１つが同時ルックアップ動作によりスタンプされていない場合に、前記サーバー・システムによる前記スタンプが生じる、請求項３２に記載のシステム。
35. 前記トランザクション番号が前記トランザクション識別子と同一であり、前記シーケンス番号が前記行ロック・レコードのうちの１つに対する現在のシーケンス番号と同一である場合に、前記サーバー・システムは、前記行ロック・レコードのうちの１つを、前記１つ以上のストレージ・デバイス・ロケーションから除外する、請求項３２に記載のシステム。
36. 前記１つ以上のストレージ・デバイス・ロケーションの前記行バージョン・レコードのうちの１つが、同時ルックアップ動作によりスタンプされていない場合に、前記サーバー・システムによる前記スタンプが生じる、請求項３２に記載のシステム。
37. 前記サーバー・システムは、以前のシーケンス番号が存在するか否かを判断する、請求項３２に記載のシステム。
38. 前記サーバー・システムは、以前のキー・ハッシュ値に前記現在のキー・ハッシュ値を設定し、前記現在のシーケンス番号を前記以前のシーケンス番号に設定し、キー・バケットをアンラッチし、前記ラッチは、前記１つ以上のストレージ・デバイス・ロケーションにおける前記レコード・チェーンに対するアクセスを制御する、請求項３７に記載のシステム。
39. 前記以前のシーケンス番号が末端値に達した場合に、前記サーバー・システムは、前記１つ以上のストレージ・デバイス・ロケーションにおける前記レコード・チェーンのレビューをストップする、請求項３７に記載のシステム。
40. 前記サーバー・システムは、トランザクション識別子をハッシュし、前記トランザクション識別子をハッシュすることからの任意のハッシュ衝突を解決する、請求項３２に記載のシステム。
41. 前記サーバー・システムは、前記トランザクション識別子のダイレクト・ルックアップを実行する、請求項３２に記載のシステム。
42. ソフトウェア・インスタンスに対する複数のテナントのディジタル・データを管理するサーバー・システムであって、各々のテナントは、アプリケーションのソフトウェア・インスタンスに対する特定の一組の特権を有する共通アクセスを共有するユーザーのグループを含み、各々のインスタンスは、互いに通信するサーバー・システムの複数のインスタンス・ノードのうちの少なくとも１つで実現され、前記管理することは、前記サーバー・システムに通信可能に結合される１つ以上のストレージ・デバイス・ロケーションで、データベースのテーブルにおける１つ以上の行の識別子を含むキーにより識別されるレコードとして保存され得る前記ディジタル・データの異なるインスタンスのマルチバージョン同時制御を管理することを含み、トランザクションは１つ以上のクエリに対して認識可能であり、前記サーバー・システムは：
    前記キーをハッシュするステップ；
    前記キーに対するキー・ハッシュ・バケットをラッチし、ハッシュすることからの任意の衝突を解決するステップ；
    スナップショット・トランザクション・カウンタ番号、キーの自己識別番号、及びコマンド識別ステートメントに基づいて、最新の認識可能な行バージョン・レコードを決定するために、前記１つ以上のストレージ・デバイス・ロケーションにおいてレコードについてのキーの行バージョン・チェーンをサーチするステップ；
    レコードの行バージョン・チェーンの行がアンコミットされているか否かを判断するステップ；
    前記行がアンコミットされている場合、情報を識別する前記トランザクション・ヘッダから、トランザクション・カウンタ番号値を読み込むステップ；及び
    前記トランザクション・カウンタ番号と同じ行トランザクション・カウンタを有することにより、前記トランザクション・カウンタ番号が有効である場合に、現在の行バージョン・レコードに前記トランザクション・カウンタ番号をスタンプし、前記現在の行バージョン・レコードを、コミットされているものとしてマークするステップ；
    を行うサーバー・システム。
43. 前記サーバー・システムは、前記行バージョン・レコードがマルチバージョン同時制御（ＭＶＣＣ）に対して認識可能であるか否かを判断し、前記行バージョン・レコードが前記ＭＶＣＣに対して認識可能である場合に、前記サーチをストップする、請求項４２に記載のシステム。
44. 前記サーバー・システムは、前記行バージョン・レコードがマルチバージョン同時制御（ＭＶＣＣ）に対して認識可能であるか否かを判断し、存在する場合には次の行バージョン・レコードに進み、又は前記サーチをストップする、請求項４２に記載のシステム。
    
    

Images