拡張可能なストレージエンジン

Extensible Storage Engine ( ESE ) は、 JET Blueとも呼ばれ、MicrosoftのISAM (インデックス シーケンシャル アクセス メソッド) データ ストレージ テクノロジです。ESE は、Microsoft Exchange Server、Active Directory、およびWindows Searchの中核です。また、 Windows Updateクライアントやヘルプとサポート センターなど、多くの Windows コンポーネントでも使用されています。その目的は、アプリケーションがインデックス アクセスとシーケンシャル アクセスを介してデータを保存および取得できるようにすることです。

ESE はトランザクションデータの更新と取得を提供します。クラッシュ回復メカニズムが提供され、システム クラッシュが発生した場合でもデータの一貫性が維持されます。ESE のトランザクションは同時実行性が高いため、ESE はサーバー アプリケーションに適しています。ESE はデータをインテリジェントにキャッシュし、データへの高パフォーマンス アクセスを保証します。さらに、ESE は軽量であるため、補助アプリケーションに適しています。

ESE ランタイム (ESENT.DLL) は、Windows 2000以降のすべてのWindowsリリースに同梱されており、ネイティブ x64 バージョンの ESE ランタイムは、x64 バージョンのWindows XPおよびWindows Server 2003に同梱されています。Microsoft Exchange は、 Exchange 2003までは、サポートされている唯一のプラットフォームであったため、32 ビット エディションのみが同梱されていました。Exchange 2007では、64 ビット エディションが同梱されています。

データベースは、データの物理的かつ論理的なグループです。ESE データベースは、Windows からは単一のファイルのように見えます。内部的には、データベースは 2、4、8、16、または 32 KB のページのコレクションであり (16 KB および 32 KB のページ オプションは、Windows 7 および Exchange 2010 でのみ使用可能)、^[1]バランスのとれたB ツリー構造に配置されています。^[2]これらのページには、データベース内に含まれるデータを説明するメタデータ、データ自体、データの興味深い順序を維持するためのインデックス、およびその他の情報が含まれています。この情報はデータベース ファイル内で混在していますが、一緒に使用されるデータはデータベース内でクラスター化されるように努めています。ESE データベースには、8キロバイトサイズのページ の場合、最大 2 ³²ページ、つまり 16テラバイトのデータを含めることができます^{[3] 。}

ESE データベースは、インスタンスと呼ばれるグループに編成されます。ほとんどのアプリケーションは単一のインスタンスを使用しますが、すべてのアプリケーションは複数のインスタンスを使用することもできます。インスタンスの重要性は、単一のリカバリ ログ シリーズを 1 つ以上のデータベースに関連付けることです。現在、最大 6 つのユーザー データベースをいつでも ESE インスタンスに接続できます。ESE を使用する各プロセスには、最大 1024 の ESE インスタンスを含めることができます。

データベースは、実行中の ESE インスタンスから切り離して、後で同じまたは別の実行中のインスタンスに接続できるという点で移植可能です。切り離されている間は、標準の Windows ユーティリティを使用してデータベースをコピーできます。ESE はデータベース ファイルを排他的に開くため、データベースがアクティブに使用されている間は、データベースをコピーできません。データベースは、Windows によって直接アドレス指定可能な I/O 操作がサポートされている任意のデバイスに物理的に存在できます。

テーブルは、各レコードが同じ列セットを持つ同種のレコードのコレクションです。各テーブルはテーブル名で識別され、そのスコープはテーブルが含まれているデータベースに対してローカルです。データベース内のテーブルに割り当てられるディスク領域の量は、CreateTable 操作でテーブルを作成するときに指定するパラメータによって決まります。テーブルは、データの作成に応じて自動的に拡張されます。

テーブルには 1 つ以上のインデックスがあります。レコード データには、少なくとも 1 つのクラスター化インデックスが必要です。アプリケーションによってクラスター化インデックスが定義されていない場合は、レコード挿入の時系列順にレコードを並べ替えてクラスター化する人工インデックスが使用されます。インデックスは、データの興味深い順序を保持し、インデックス順序でのレコードへの順次アクセスと、インデックス列値によるレコードへの直接アクセスの両方を可能にするように定義されます。ESE のクラスター化インデックスもプライマリである必要があり、つまり、インデックス キーは一意である必要があります。

クラスター化インデックスと非クラスター化インデックスは、B+ ツリーを使用して表されます。挿入または更新操作によってページがオーバーフローすると、ページが分割されます。つまり、新しいページが割り当てられ、それまで隣接していた 2 つのページの間に論理的に連結されます。この新しいページは、論理的に隣接するページと物理的に隣接していないため、アクセスは効率的ではありません。ESE には、データを再圧縮するオンライン圧縮機能があります。テーブルが頻繁に更新されることが予想される場合は、テーブルまたはインデックスの作成時に適切なページ密度を指定して、将来の挿入用にスペースを予約できます。これにより、分割操作を回避または延期できます。

レコードは、関連付けられた列値のセットです。レコードは、Update 操作によって挿入および更新され、Delete 操作によって削除できます。列は、それぞれ SetColumns 操作と RetrieveColumns 操作によって設定および取得されます。レコードの最大サイズは、長い値の列を除いて、8 キロバイト ページの場合 8110 バイトです。LongText および LongBinary の列タイプは、このサイズ制限に大きく影響しません。また、データが長い値の列に格納されている場合、レコードはデータベース ページ サイズよりもはるかに大きなデータを保持できます。長い値の参照がレコードに格納されている場合、レコード内データは 9 バイトのみ必要です。これらの長い値自体のサイズは、 最大 2ギガバイト(GB) になる場合があります。

通常、レコードは均一であり、各レコードには同じ列セットの値のセットが含まれます。ESE では、テーブルに多数の列を定義し、特定のレコードに少数の非 NULL 列値のみを含めることもできます。この意味で、テーブルは異種レコードのコレクションである場合もあります。

ESE は、1 ビットから 2 GB までの範囲の幅広い列値をサポートしています。列の型によって、インデックスの順序など、多くのプロパティが決まることから、適切な列型を選択することが重要です。ESE では、次のデータ型がサポートされています。

各 ESE テーブルでは、最大 127 個の固定長列、128 個の可変長列、および 64,993 個のタグ付き列を定義できます。

• 固定列は、基本的に、値に関係なく、各レコードで同じ量のスペースを占める列です。固定列は、列値の NULL を表す 1 ビットと、その列または後で定義される固定列が設定されている各レコードの固定量のスペースを占めます。
• 可変列は、基本的に、特定の列値のサイズに応じて、設定されている各レコードで可変量のスペースを占める列です。可変列は、NULL 値とサイズを決定するために 2 バイトを占め、その列が設定されている各レコードで可変量のスペースを占めます。
• タグ付き列は、レコードに設定されていない場合にはまったくスペースを取らない列です。タグ付き列は単一の値を取ることも、複数の値を取ることもできます。同じタグ付き列が、単一のレコードに複数の値を持つことができます。タグ付き列がレコードに設定されている場合、タグ付き列の各インスタンスは、タグ付き列インスタンス値のサイズに加えて、約 4 バイトのスペースを取ります。単一のタグ付き列のインスタンスの数が多い場合、タグ付き列インスタンスあたりのオーバーヘッドは約 2 バイトです。タグ付き列は、設定されていない場合にはまったくスペースを取らないため、スパース列に最適です。複数の値を持つタグ付き列にインデックスが付けられている場合、インデックスには、タグ付き列の各値に対してレコードの 1 つのエントリが含まれます。

特定のテーブルでは、列は 2 つのカテゴリのいずれかに分類されます。レコードごとに 1 回だけ出現し、NULL 値がいくつかある可能性のある列と、めったに出現しないか、1 つのレコードに複数回出現する可能性のある列です。固定列と可変列は前者のカテゴリに属し、タグ付き列は後者に属します。2 つの列カテゴリの内部表現は異なるため、列カテゴリ間のトレードオフを理解することが重要です。固定列と可変列は、出現に NULL 値がある場合でも、通常、すべてのレコードに表されます。これらの列は、オフセット テーブルを使用して簡単にアドレス指定できます。タグ付き列の出現の前には列識別子が付いており、タグ付き列のセットをバイナリ検索することで列が検索されます。

長いテキストと長いバイナリの列タイプは、大きなバイナリ オブジェクトです。これらは、長い値 ID とバイト オフセットでキー付けされたクラスター化インデックスとは別の B+ ツリーに格納されます。ESE は、これらの列の追加、バイト範囲の上書き、およびサイズの設定をサポートします。また、ESE には、複数のレコードが同じ大きなバイナリ オブジェクトを参照できる単一インスタンス ストア機能があり、各レコードに情報のコピーがあるかのように、つまりレコード間のロック競合がないかのようになります。長いテキストまたは長いバイナリの列値の最大サイズは 2 GB です。

バージョン列は、この列を含むレコードが更新操作によって変更されるたびに、ESE によって自動的に増分されます。この列はアプリケーションによって設定できず、読み取りのみ可能です。バージョン列の用途には、特定のレコードのメモリ内コピーを更新する必要があるかどうかを判断するために使用されることが含まれます。テーブル レコードの値がキャッシュされたコピーの値より大きい場合、キャッシュされたコピーは古くなっていることがわかります。バージョン列は Long 型である必要があります。

自動インクリメント列は、列に含まれる値がテーブル内のすべてのレコードに対して一意になるように、ESE によって自動的に設定されます。バージョン列と同様に、これらの列はアプリケーションによって設定できません。自動インクリメント列は読み取り専用で、Update 操作によって新しいレコードがテーブルに挿入されると自動的に設定されます。列の値はレコードの存続期間中一定のままで、テーブルごとに 1 つの自動インクリメント列のみが許可されます。自動インクリメント列は、Long 型または Currency 型にすることができます。

エスクロー列は、EscrowUpdate 操作によって変更できます。エスクロー更新は数値デルタ操作です。エスクロー列は Long 型である必要があります。数値デルタ操作の例には、値に 2 を加算したり、値から 1 を減算したりすることが含まれます。ESE は、更新の終了値ではなく、値の変更を追跡します。ESE は、どのトランザクションがコミットされ、どのトランザクションがロールバックされるかに関係なく、実際の終了値を決定できるため、複数のセッションでそれぞれ、EscrowUpdate を介して同じ値に行われた未処理の変更が存在する場合があります。これにより、複数のユーザーが数値デルタ変更を行って同時に列を更新できます。オプションで、データベース エンジンは、列の値がゼロのレコードを消去できます。このようなエスクロー列の一般的な用途は参照カウンターです。多くのスレッドがロックなしで値を増分/減分し、カウンターがゼロに達すると、レコードは自動的に削除されます。

インデックスは、テーブル内のレコードの永続的な順序です。インデックスは、定義された順序で行に順次アクセスする場合と、インデックス付きの列の値に基づいてレコードを直接移動する場合の両方に使用されます。インデックスによって定義される順序は、優先順位に従って列の配列で記述されます。この列の配列は、インデックス キーとも呼ばれます。各列はインデックス セグメントと呼ばれます。各インデックス セグメントは、順序付けの寄与度の観点から、昇順または降順のいずれかになります。テーブルには任意の数のインデックスを定義できます。ESE は、豊富なインデックス機能を提供します。

1 つのインデックスをクラスター化インデックス (プライマリ インデックス) として指定できます。ESE では、クラスター化インデックスは一意である必要があり、プライマリ インデックスと呼ばれます。その他のインデックスは非クラスター化インデックス (セカンダリ インデックス) と呼ばれます。プライマリ インデックスは、インデックス エントリがレコード自体であり、レコードへの論理ポインタではないという点でセカンダリ インデックスと異なります。セカンダリ インデックスには、プライマリ インデックスのレコードに論理的にリンクするための主キーがリーフにあります。つまり、テーブルはプライマリ インデックスの順序で物理的にクラスター化されます。プライマリ インデックスの順序でインデックス化されていないレコード データを取得すると、セカンダリ インデックスの順序で取得するよりもはるかに高速になります。これは、1 回のディスク アクセスで、アクセスが近い複数のレコードをメモリに取り込むことができるためです。同じディスク アクセスで、複数のレコード アクセス操作が満たされます。ただし、プライマリ インデックスの順序によって決定されるインデックスの中央へのレコードの挿入は、インデックスの末尾への追加よりも大幅に遅くなる可能性があります。テーブル設計を実行するときは、更新頻度と取得パターンを慎重に考慮する必要があります。テーブルにプライマリ インデックスが定義されていない場合は、データベース キー (DBK) インデックスと呼ばれる暗黙のプライマリ インデックスが作成されます。DBK は、レコードが挿入されるたびに増加する一意の昇順番号です。その結果、DBK インデックス内のレコードの物理的な順序は挿入時系列順になり、新しいレコードは常にテーブルの末尾に追加されます。アプリケーションが一意でないインデックスでデータをクラスター化する場合は、一意でないインデックス定義の末尾に自動増分列を追加することでこれが可能になります。

インデックスは、複数値列に対して定義できます。インデックス列に複数の値を持つレコードの場合、これらのインデックスに複数のエントリが存在することがあります。複数値列は、単一値列と組み合わせてインデックス付けできます。2 つ以上の複数値列が一緒にインデックス付けされている場合、複数値プロパティは、インデックスの最初の複数値列に対してのみ適用されます。優先順位の低い列は、単一値であるかのように扱われます。

インデックスはスパースとして定義することもできます。スパース インデックスには、テーブル内の各レコードに対して少なくとも 1 つのエントリがありません。スパース インデックスを定義するには、いくつかのオプションがあります。インデックス キー全体が NULL の場合、いずれかのキー セグメントが NULL の場合、または最初のキー セグメントだけが NULL の場合に、レコードをインデックスから除外するオプションがあります。インデックスには条件列を含めることもできます。これらの列はインデックス内には表示されませんが、条件列が NULL または NULL 以外の場合、レコードがインデックス付けされない原因となることがあります。

インデックスは、テキスト列または長いテキスト列の各サブ文字列に 1 つのエントリを含めるように定義することもできます。これらのインデックスはタプル インデックスと呼ばれます。これらは、サブ文字列一致述語を使用したクエリを高速化するために使用されます。タプル インデックスは、テキスト列に対してのみ定義できます。たとえば、テキスト列の値が「I love JET Blue」で、インデックスが最小タプル サイズ 4 文字、最大タプル長 10 文字に設定されている場合、次のサブ文字列がインデックス化されます。

タプル インデックスは非常に大きくなる可能性がありますが、次のような形式のクエリの速度を大幅に向上させることができます。「JET Blue」を含むすべてのレコードを検索します。タプル インデックスは、検索サブ文字列を最大タプル長の検索文字列に分割し、その結果を交差させることで、最大タプル長よりも長いサブ文字列に使用できます。インデックスの交差なしで、最大タプル長と同じ長さの文字列または最小タプル長と同じ長さの文字列の完全一致に使用できます。ESE でインデックスの交差を実行する方法の詳細については、「インデックスの交差」を参照してください。検索文字列が最小タプル長よりも短い場合、タプル インデックスではクエリの速度を向上できません。

トランザクションは、BeginTransaction および CommitTransaction、または Rollback 操作によって区切られる論理的な処理単位です。トランザクション中に実行されるすべての更新はアトミックです。つまり、すべて同時にデータベースに表示されるか、まったく表示されないかのどちらかです。他のトランザクションによる後続の更新は、トランザクションからは見えません。ただし、トランザクションは、その間に変更されていないデータのみを更新できます。それ以外の場合は、操作は待機せずにすぐに失敗します。読み取り専用トランザクションは待機する必要がなく、更新トランザクションは、他の更新トランザクションにのみ干渉します。Rollback またはシステム クラッシュによって終了されたトランザクションは、データベースに痕跡を残しません。一般に、データの状態は、Rollback で BeginTransaction の前の状態に復元されます。

トランザクションは最大 7 レベルまでネストできます。さらに 1 つのレベルは ESE 内部使用のために予約されています。つまり、トランザクション全体をロールバックする必要はなく、トランザクションの一部をロールバックできます。ネストされたトランザクションの CommitTransaction は、処理の 1 つのフェーズが成功したことを示すだけであり、外側のトランザクションが失敗する可能性があります。変更は、最も外側のトランザクションがコミットされたときにのみデータベースにコミットされます。これは、トランザクション レベル 0 へのコミットと呼ばれます。トランザクションがトランザクション レベル 0 にコミットされると、トランザクションを記述するデータが同期的にログにフラッシュされ、その後のシステム クラッシュが発生した場合でもトランザクションが完了することが保証されます。ログを同期的にフラッシュすると、ESE トランザクションが永続的になります。ただし、場合によっては、アプリケーションは更新を順序付けたいが、変更がすぐに行われるとは保証したくないことがあります。この場合、アプリケーションは JET_bitIndexLazyFlush を使用して変更をコミットできます。

ESE は、マルチバージョンと呼ばれる同時実行制御メカニズムをサポートしています。マルチバージョンでは、すべてのトランザクションが、トランザクションの開始時のデータベース全体の一貫したビューを照会します。トランザクションが遭遇する更新は、トランザクションによって行われた更新のみです。このように、各トランザクションは、書き込み競合の場合を除き、システムで実行されている唯一のアクティブなトランザクションであるかのように動作します。トランザクションは、別のトランザクションで既に更新された読み取りデータに基づいて変更を加える可能性があるため、マルチバージョンだけではトランザクションのシリアル化は保証されません。ただし、更新の基になる読み取りデータをロックするために明示的なレコード読み取りロックを使用するだけで、必要に応じてシリアル化を実現できます。読み取りロックと書き込みロックの両方を、GetLock 操作で明示的に要求できます。

さらに、ESE では、エスクロー ロックと呼ばれる高度な同時実行制御機能がサポートされています。エスクロー ロックは、数値が相対的に変更される、つまり別の数値を追加または減算する、非常に同時実行性の高い更新です。エスクロー更新は、同じデータに対する他の同時エスクロー更新と競合しません。これが可能なのは、サポートされている操作が交換可能であり、独立してコミットまたはロールバックできるためです。その結果、同時更新トランザクションに干渉しません。この機能は、保守された集計によく使用されます。

ESE は、トランザクション セマンティクスをデータ操作操作からデータ定義操作にまで拡張します。テーブルにインデックスを追加し、同時に実行中のトランザクションで同じテーブルを更新できます。トランザクション ロックの競合はまったく発生しません。後でこれらのトランザクションが完了すると、新しく作成されたインデックスはすべてのトランザクションで使用可能になり、更新時にインデックスの存在を認識できなかった他のトランザクションによって行われたレコード更新のエントリが含まれます。データ定義操作は、レコード更新のトランザクション メカニズムに期待されるすべての機能を使用して実行できます。この方法でサポートされるデータ定義操作には、AddColumn、DeleteColumn、CreateIndex、DeleteIndex、CreateTable、および DeleteTable があります。

カーソルは、テーブル インデックス内の論理ポインタです。カーソルは、レコード上、最初のレコードの前、最後のレコードの後、またはレコード間に配置できます。カーソルがレコードの前または後に配置されている場合は、現在のレコードはありません。同じテーブル インデックスに複数のカーソルを配置できます。多くのレコードおよび列の操作は、カーソルの位置に基づいています。カーソルの位置は、Move 操作によって順番に移動するか、Seek 操作でインデックス キーを使用して直接移動できます。カーソルは、インデックス内の小数点以下の位置に移動することもできます。この方法では、カーソルをサム バーの位置にすばやく移動できます。この操作は、Seek 操作と同じ速度で実行されます。中間のデータにアクセスする必要はありません。

各カーソルには、新しいレコードを作成したり、既存のレコードを列ごとに変更したりするためのコピー バッファーがあります。これは、SetColumns 操作で内容を変更できる内部バッファーです。コピー バッファーを変更しても、格納されているデータが自動的に変更されることはありません。現在のレコードの内容は、PrepareUpdate 操作を使用してコピー バッファーにコピーできます。Update 操作では、コピー バッファーの内容をレコードとして格納します。コピー バッファーは、トランザクションのコミットまたはロールバック、およびナビゲーション操作で暗黙的にクリアされます。RetrieveColumns を使用すると、レコードまたはコピー バッファー (存在する場合) から列データを取得できます。

ESE アプリケーションは、常にデータをクエリします。このドキュメントのセクションでは、アプリケーションが ESE でクエリ処理ロジックを記述するための機能と手法について説明します。

ESE は、一時テーブルの形式で並べ替え機能を提供します。アプリケーションは、データ レコードを 1 レコードずつ並べ替えプロセスに挿入し、並べ替え順に 1 レコードずつ取得します。並べ替えは、最後のレコード挿入と最初のレコード取得の間で実際に実行されます。一時テーブルは、部分的または完全な結果セットにも使用できます。これらのテーブルは、並べ替え定義に一致するインデックス キーを使用して行に順番にまたは直接移動する機能など、基本テーブルと同じ機能を提供できます。一時テーブルは、複雑な集計を計算するために更新することもできます。単純な集計は、並べ替えに似た機能を使用して自動的に計算でき、必要な集計は並べ替えプロセスの自然な結果になります。

セカンダリ インデックスから列データを直接取得することは、パフォーマンスを最適化する上で重要です。RetrieveColumns 操作の RetrieveFromIndex フラグを使用すると、データ レコードにアクセスせずに、セカンダリ インデックスから列を直接取得できます。インデックスでナビゲートする場合、レコードから取得するよりも、セカンダリ インデックスから列を取得する方がはるかに効率的です。列データがレコードから取得された場合、主キーでレコードを見つけるために追加のナビゲーションが必要になります。これにより、追加のディスク アクセスが発生する可能性があります。必要なすべての列がインデックスに用意されている場合、そのインデックスはカバー インデックスと呼ばれます。テーブルのプライマリ インデックスで定義された列はセカンダリ インデックスにも存在し、JET_bitRetrieveFromPrimaryBookmark を使用して同様に取得できることに注意してください。

インデックス キーは正規化された形式で保存されますが、多くの場合、元の列値に非正規化できます。正規化は必ずしも元に戻せるわけではありません。たとえば、テキストおよび長いテキストの列タイプは非正規化できません。また、列データが非常に長い場合、インデックス キーが切り捨てられることがあります。列をセカンダリ インデックスから直接取得できない場合は、常にレコードにアクセスして必要なデータを取得できます。

クエリには、データに対する制限の組み合わせが含まれることがよくあります。制限を処理する効率的な方法は、使用可能なインデックスを使用することです。ただし、クエリに複数の制限が含まれる場合、アプリケーションは、単一のインデックスで満たされる最も制限の厳しい述語のインデックス範囲全体をたどって制限を処理することがよくあります。残りの述語は残余述語と呼ばれ、述語をレコード自体に適用することで処理されます。これは単純な方法ですが、残余述語を適用するためにレコードをメモリに取り込むために多くのディスク アクセスを実行する必要がある可能性があるという欠点があります。

インデックスの交差は、複数のインデックスを組み合わせて複雑な制限をより効率的に処理する重要なクエリ メカニズムです。単一のインデックスのみを使用する代わりに、複数のインデックスのインデックス範囲を結合して、残余述語を適用できるレコードの数を大幅に減らします。ESE では、IntersectIndexes 操作を提供することでこれを簡単に実行できます。この操作は、同じテーブルのインデックスの一連のインデックス範囲を受け入れ、すべてのインデックス述語を満たすベース テーブル レコードに移動するために使用できるプライマリ キーの一時テーブルを返します。

結合は、正規化されたテーブル設計における一般的な操作であり、論理的に関連するデータをアプリケーションで使用するためにまとめます。結合は、関連するデータをメモリに取り込むために多くのデータ アクセスが必要になる場合があるため、コストのかかる操作になる可能性があります。この作業は、2 つ以上の論理テーブルのデータを含む単一の基本テーブルを定義することで、場合によっては最適化できます。基本テーブルの列セットは、これらの論理テーブルの列セットの結合です。タグ付き列は、複数値データとスパース値データの両方を適切に処理できるため、これが可能になります。関連データは同じレコードにまとめて格納されるため、一緒にアクセスされ、結合を実行するためのディスク アクセスの数が最小限に抑えられます。ESE は最大 64,993 個のタグ付き列をサポートできるため、このプロセスは多数の論理テーブルに拡張できます。複数値列に対してインデックスを定義できるため、「内部」テーブルにインデックスを付けることもできます。ただし、いくつかの制限があるため、アプリケーションでは、この手法を使用する前に事前結合を慎重に検討する必要があります。

ESE のログ記録および回復機能は、システム クラッシュが発生した場合にデータの整合性と一貫性を保証します。ログ記録は、データベース更新操作をログ ファイルに冗長的に記録するプロセスです。ログ ファイルの構造は、システム クラッシュに対して非常に堅牢です。回復は、システム クラッシュ後にこのログを使用してデータベースを一貫した状態に復元するプロセスです。

トランザクション操作はログに記録され、トランザクション レベル 0 への各コミット時にログがディスクにフラッシュされます。これにより、リカバリ プロセスは、トランザクション レベル 0 にコミットしたトランザクションによって行われた更新をやり直し、トランザクション レベル 0 にコミットしなかったトランザクションによって行われた変更を元に戻すことができます。このタイプのリカバリ スキームは、多くの場合、「ロールフォワード/ロールバック」リカバリ スキームと呼ばれます。ログは、以下で説明するバックアップ プロセスによってデータが安全にコピーされるまで保持できます。または、システム クラッシュからのリカバリにログが不要になったらすぐに循環的に再利用できます。循環ログにより、ログに必要なディスク領域が最小限に抑えられますが、メディア障害が発生した場合にデータ状態を再作成する機能に影響があります。

ログ記録と回復は、メディア障害からデータを保護する役割も果たします。ESE は、データベース操作に影響を与えない方法で、ログ ファイルとともに 1 つ以上のデータベースがコピーされるオンライン バックアップをサポートします。バックアップの実行中も、データベースのクエリと更新は継続できます。バックアップは「ファジー バックアップ」と呼ばれます。これは、一貫性のあるデータベース セットを復元するために、バックアップ復元の一部として回復プロセスを実行する必要があるためです。ストリーミング バックアップとシャドウ コピー バックアップの両方がサポートされています。

ストリーミング バックアップは、必要なすべてのデータベース ファイルと必要なログ ファイルのコピーがバックアップ プロセス中に作成されるバックアップ方法です。ファイルのコピーはテープに直接保存することも、他のストレージ デバイスに作成することもできます。ストリーミング バックアップでは、いかなる種類のアクティビティも停止する必要はありません。データベースとログ ファイルの両方にチェックサムが計算され、バックアップ プロセス中にデータ セット内にデータ破損がないことが保証されます。ストリーミング バックアップは増分バックアップになることもあります。増分バックアップでは、ログ ファイルのみがコピーされ、以前の完全バックアップとともに復元して、すべてのデータベースを最新の状態にすることができます。

シャドウ コピーバックアップは、新しい高速バックアップ方法です。シャドウ コピー バックアップは、アプリケーションを短時間停止させた後に仮想的にコピーが作成されるため、大幅に高速化されます。その後、データが更新されると、仮想コピーが実現されます。場合によっては、シャドウ コピー バックアップのハードウェア サポートにより、仮想コピーを実際に保存する必要がありません。シャドウ コピー バックアップは常に完全バックアップです。

復元は、単一のバックアップを適用する場合や、単一の完全バックアップと 1 つ以上の増分バックアップの組み合わせを適用する場合に使用できます。さらに、既存のログ ファイルを再生して、トランザクション レベル 0 にコミットされた最後のトランザクションまで、データ セット全体を再作成することもできます。バックアップの復元は、元のアプリケーションをサポートできる任意のシステムに行うことができます。同じマシンである必要はなく、同じマシン構成である必要もありません。ファイルの場所は、復元プロセスの一部として変更できます。

ESENT データベースが作成されると、物理ディスクのセクターサイズがデータベースに保存されます。物理セクター サイズはセッション間で一貫している必要があります。そうでない場合は、エラーが報告されます。物理ドライブがドライブ イメージから異なる物理セクター サイズを使用するドライブ ( Advanced Format Drives) にクローンまたは復元されると、ESENT はエラーを報告します。^[4]

これは既知の問題であり、Microsoft ではホットフィックスを提供しています。Windows Vista または Windows Server 2008 については、KB2470478 を参照してください。^[5] Windows 7 または Windows Server 2008 R2 については、KB982018 を参照してください。^[6]

JET BlueはもともとMicrosoft AccessのJET Redデータベースエンジンのアップグレード候補としてMicrosoftによって開発されましたが、この用途には使用されませんでした。代わりに、Exchange Server、Active Directory、ファイルレプリケーションサービス（FRS）、セキュリティ構成エディター、証明書サービス、Windowsインターネットネームサービス（WINS）、およびその他のMicrosoftのサービス、アプリケーション、Windowsコンポーネントのホストで使用されるようになりました。^[7]長年、Microsoftのみが使用するプライベートAPIでしたが、その後、誰でも使用できる公開APIになりました。

Data Access Engine (DAE) の作業は、Allen Reiter が Microsoft に入社した 1989 年 3 月に開始されました。次の 1 年間、4 人の開発者チームが Allen の下で ISAM をほぼ完成させました。Microsoft にはすでに BC7 ISAM (JET Red) がありましたが、当時の新しいクライアント サーバー アーキテクチャ領域への参入として、より堅牢なデータベース エンジンを構築するため、Data Access Engine (DAE) の取り組みを開始しました。1990 年の春、BC7 ISAM チームと DAE チームが統合されて Joint Engine Technology (JET) の取り組みとなり、同じ API 仕様 (JET API) に準拠する 2 つのエンジン、v1 ( JET Red ) と v2 (JET Blue) の作成を担当しました。DAE は、イスラエルの国旗の色にちなんで JET Blue になりました。BC7 ISAM は、ロシアの国旗の色にちなんで JET Red になりました。JET Blue と JET Red は同じ API 仕様で作成されていましたが、ISAM コードはまったく共有していませんでした。どちらも共通のクエリ プロセッサである QJET をサポートしており、これは後に BC7 ISAM とともに JET Red と同義になりました。

JET Blue は、1994 年に Windows NT 3.5 の WINS、DHCP、および現在は廃止されたRPLサービス用の ISAM として初めて出荷されました。1996 年には、Microsoft Exchange のストレージ エンジンとして再出荷されました。追加の Windows サービスがストレージ テクノロジとして JET Blue を選択し、2000 年までにすべてのバージョンの Windows に JET Blue が付属するようになりました。JET Blue は Active Directory で使用され、Trusted Computing Base (TCB) と呼ばれる特別な Windows コード セットの一部になりました。JET Blue を使用する Microsoft アプリケーションの数は増え続けており、Windows 内外のますます増え続けるアプリケーションやサービスでの使用を容易にするために、2005 年に JET Blue API が公開されました。

Microsoft Exchange Web Blogのエントリ^[8]によると、JET Blueに貢献した開発者には、Cheen Liao、Stephen Hecht、Matthew Bellew、Ian Jose、Edward "Eddie" Gilbert、Kenneth Kin Lum、Balasubramanian Sriram、Jonathan Liem、Andrew Goodsell、Laurion Burchall、Andrei Marinescu、Adam Foxman、Ivan Trindev、Spencer Low、Brett Shirleyなどが含まれる。

2021年1月にマイクロソフトはESEをオープンソース化した。^{[9]これは寛容な}MITライセンスでGitHubに投稿された。

共通の系譜を共有しているものの、JET Redと ESE の間には大きな違いがあります。

• JET Red はファイル共有テクノロジですが、ESE はサーバー アプリケーションに組み込むように設計されており、ファイルを共有しません。
• JET Red はベストエフォートのファイル回復を行いますが、ESE は先行書き込みログとスナップショット分離を備えており、クラッシュ回復を保証します。
• バージョン 4.0 より前の JET Red ではページ レベルのロックのみがサポートされていますが、ESE および JET Red バージョン 4.0 ではレコード レベルのロックがサポートされています。
• JET Red は、 ODBCやOLE DBなど、さまざまなクエリ インターフェイスをサポートしています。ESE にはクエリ エンジンが付属しておらず、代わりにアプリケーションが独自のクエリをC ISAM コードとして記述する必要があります。
• JET Red の最大データベース ファイル サイズは 2 GiBですが、ESE の最大データベース ファイル サイズは 4 KiBページの場合は8 TiB、8 KiB ページの場合は 16 TiB です。

• 「Exchange 用語集」。2008 年 11 月 9 日にオリジナルからアーカイブ。2015年 8 月 20 日に閲覧。
• 「情報ストアの基本を理解する」。2007 年 6 月 9 日時点のオリジナルよりアーカイブ。2007 年 6 月 18 日閲覧。

• 公式サイト
• GitHubの Extensible-Storage-Engine
• 拡張ストレージエンジン - CodeProject