次の方法で共有

拡張可能なストレージ エンジン ファイル

適用対象: Windows |Windows Server

拡張可能なストレージ エンジン ファイル

拡張可能ストレージ エンジンは、次の種類のファイルを使用します。

この表には、ESE によって管理されるデータ ファイル名の概要が含まれています。 Windows Vista 以降の場合、JET_paramLegacyNames設定は使用されるファイル名に影響します。

ラベル 価値

トランザクション ログ ファイル

トランザクション ログ ファイルには、データベース ファイルに対する操作が含まれています。 予期しないプロセスの終了またはシステムのシャットダウン後に、データベースを論理的に一貫性のある状態にするのに十分な情報が含まれています。

ログ ファイルの名前は、JET_paramBaseNameで設定できる 3 文字のベース名に依存します。 次の例では、"edb" というベース名を使用します。これは既定のベース名であるためです。 トランザクション ログ ファイルの拡張子は、JET_paramLegacyFileNames パラメーターにJET_bitESE98FileNamesが設定されているかどうかに応じて、.logまたは .jtx のいずれかになります。 詳細については、「拡張可能な記憶域エンジン のシステム パラメーターを参照してください。

トランザクション ログ ファイルの名前は、1 から始まる基本><世代番号>.log <。 ログ生成番号は 16 進形式です。 たとえば、edb00001.logは最初のログで、edb000ff.logは 255 番目のログです。 ログ ファイルは、1048576 番目のログ ファイルが 11.3 形式 (たとえば、edb00100000.log) で名前付けされ始めるまで、ログ ファイル名に 5 桁の 16 進数を持っています。 基本>.log <は、常に現在使用されているログ ファイルです。 データベース エンジンがアクティブでない場合は、次のコマンドを使用してedb.logの生成を識別できます: esentutl.exe -ml edb.log。

トランザクション ログ ファイルには .LOG 拡張子はテキスト ファイルに一般的に関連付けられます。トランザクション ログ ファイルはバイナリ形式であり、ユーザーが編集することはできません。データベース操作は、最初にログに書き込まれます。 データは後でデータベース ファイルに書き込むことができます。おそらくすぐに、おそらくずっと後です。 予期しないプロセスまたはシステムの終了が発生した場合でも、操作はログ ファイルに残り、不完全なトランザクションはロールバックできます。 トランザクション ログ ファイルを再生する操作は、ソフト 回復 呼び出され、JetInit または JetInit2 呼び出されたときに自動的に実行されます。 ソフトリカバリは、Esentutl.exe プログラムの「-r」オプションを使用して手動で実行することもできます。 バックアップから復元されたデータベースでトランザクション ログ ファイルを再生する操作は、ハード リカバリ 呼び出されます。

ログ ファイルは固定サイズで、JET_paramLogFileSizeでカスタマイズできます。 現在のログ ファイル (つまり、edb.log) が入力されると、<基本><世代番号>.log に名前が変更され、トランザクション ログ ストリームに新しいトランザクション ログ ファイルが必要になります。

各データベース インスタンスには、1 つのログ ファイル シーケンスが関連付けられています。 Windows XP JetCreateInstanceが導入され、複数のトランザクション ログ ファイル シーケンスを 1 つのプロセスで使用できます。 ただし、同じディレクトリに複数のトランザクション ログ ファイル シーケンスを存在することはできません。

データが破損する可能性があるため、トランザクション ログ ファイルを手動で操作、名前変更、移動、または削除することはほとんどありません。

トランザクション ログ ファイルは、完全バックアップ中にデータベース エンジンによって削除されます (jetBackup 、JetTruncateLog、JetTruncateLogInstanceを参照)、または循環ログが有効になっている場合は通常の操作中に削除されます。

トランザクション ログ ファイルがいっぱいになった後、データベース エンジンは新しいログ ファイルを作成する必要があります。 循環ログは、クラッシュ復旧に必要なくなったログ ファイルをデータベース エンジンによって自動的にクリーンアップするための手段です。 このプロセスは、バックアップを実行する成果物としてログ ファイルを削除する代わりに使用します。 循環ログは、JET_paramCircularLog システム パラメーターを使用して制御できます。 トランザクション ログ ファイルは、他の方法を使用して削除しないでください。

一時トランザクション ログ ファイル

edb.logがいっぱいになったら、ESE は新しいファイルを作成する必要があります。 新しいログ トランザクション ファイルは、ESE で使用される前の一時トランザクション ログ ファイルと呼ばれます。

新しいログ ファイルが作成され、そのサイズが拡張されている間は、基本>tmp.log <呼び出されます。 新しいファイルの作成はコストの高い操作になる可能性があるため、ESE はバックグラウンド タスクとして次のログ ファイルを事前に作成します。

一時トランザクション ログ ファイルは、新しいトランザクション ログ ファイルが必要であることを想定して作成されるため、有用な情報は含まれません。

予約済みトランザクション ログ ファイル

予約済みトランザクション ログ ファイルは、クリーン シャットダウンを取得するために重要な操作をログに記録できるようにエンジンが起動したときに作成されます。

Windows Vista: Windows Vista 以降の、予約済みトランザクション ログ ファイルの名前は、ベース>RESXXXXX.jrs <名前が付けられます。

Windows Server 2003: Windows Server 2003 以前の、予約済みトランザクション ログ ファイルの名前は res1.log および res2.log です。

データベース エンジンのディスク領域が不足すると、新しいログ ファイルを作成できません。 最も安全な操作は、正常にシャットダウンすることですが、一部の操作 (ロールバック操作など) はログに記録する必要があります。 ほとんどのデータベース操作は、この段階では失敗します。

予約済みトランザクション ログ ファイルは、ディスク外のシナリオでのトランザクション ログ ファイルの必要性を想定して作成されるため、有用な情報は含まれません。

チェックポイント ファイル

チェックポイント ファイルには、特定のトランザクション ログ ファイル シーケンスのチェックポイントが格納されます。 チェックポイント ファイルの名前は、JET_paramLegacyFileNames パラメーターにJET_bitESE98FileNamesが設定されているかどうかに応じて、.chk <または .jcp>ベース>ベース <名前が付けられ、その場所は JET_paramSystemPathによって指定されます。

データベース操作は、最初にログ ファイルに書き込まれた後、メモリにキャッシュされます。 後で操作がデータベース ファイルに書き込まれますが、パフォーマンス上の理由から、操作がデータベース ファイルに書き込まれる順序が、最初にログに記録された順序と一致しない可能性があります。 トランザクション ログ ファイルに書き込まれる操作は、次の 2 つの状態のいずれかになります。

  • トランザクション ログ ファイルとデータベース ファイルに書き込まれます。

  • トランザクション ログ ファイルに書き込まれ、データベース ファイルにまだ書き込まれていません。

多くのデータベース操作は、1 つのトランザクション ログ ファイルに格納できます。 特定のログ ファイルは、次の項目で構成できます。

  • データベース ファイルに書き込まれるすべての操作。

  • データベース ファイルに書き込まれた操作はありません

  • データベース ファイルに書き込まれた操作と、データベース ファイルにまだ書き込まれていない操作の組み合わせ。

チェックポイントとは、チェックポイントより前のすべての操作がデータベース ファイルに書き込まれた、トランザクション ログ ストリーム内の時点を指します。 チェックポイントの後に発生する操作に関する保証はありません。一部はメモリ内にあり、一部はデータベースに書き込まれる可能性があります。

チェックポイントより前のログ ファイル内のすべての操作はデータベース ファイルで表されるため、論理的な復旧で特定のデータベースをクリーンな状態にするには、チェックポイント後のトランザクション ログ ファイルのみが必要です。

データベース ファイル

データベース ファイルには、データベース内のすべてのテーブルのスキーマ、データベース内のすべてのテーブルのレコード、およびテーブルに対するインデックスが含まれています。 その場所は、JetCreateDatabase 、JetCreateDatabase2、JetAttachDatabase、または JetAttachDatabase2 を使用して指定されます。

JetTerm または JetTerm2 の呼び出し 正常に呼び出された後にのみ、データベースがクリーンにシャットダウンされます。

Esentutl.exe プログラムは、"-mh" オプションを使用して、データベースが正常にシャットダウンされているかどうかを検出できます。 たとえば、"esentutl.exe -mh sample.edb" は sample.edb という名前のデータベースのデータベース ヘッダーを読み取り、sample.edb の状態を出力します。 "State: Clean Shutdown" または "State: Dirty Shutdown" が出力されることがあります。

クリーン シャットダウンされていないデータベースがダーティ シャットダウン状態です。 Windows XP より前は、この状態は一貫性のない 呼び出されていました。 ダーティ (不整合) データベースは、ソフト リカバリーを使用してクリーンな状態にすることができます。 破損したデータベースは、ダーティ ("不整合") データベースと同じではありません。

破損したデータベースは、物理的または論理的な破損を指し、ソフト リカバリーでは修正できません。 物理的な破損にはビット フリップが考えられます。これは、データベース ページのチェックサムによって頻繁にキャッチされます。 データベース ファイルのチェックサムが失敗すると、JET_errReadVerifyFailure エラーとして現れます。

安全に移動したり、名前を変更したりできるのは、クリーンにシャットダウンされたデータベースだけです。 データベースが正常にシャットダウンされていない場合、自動的に安全に移動したり名前を変更したりすることはできません。

複数のデータベースを 1 つのトランザクション ログ ファイル シーケンスに関連付けることができます。

一時データベース

一時データベースは、魅力的なオブジェクトのバッキング ストアとして使用され、インデックスの作成時にも使用されます。

名前と場所は、JET_paramTempPathで構成されます。

JetOpenTempTable、 JetOpenTempTable2、 JetOpenTempTable3、 JetOpenTemporaryTableを使用して作成されます。 また、一部の API 呼び出しによって作成され、スキーマ情報 (JetGetIndexInfo など) を返すために使用されます。

マップ ファイルのフラッシュ

Windows 10 Anniversary Update (クライアント) と Windows Server 2016 (サーバー) 以降、ESE は書き込みの損失 (またはフラッシュの損失) 1 に対する保護レベルを追加し、このようなイベントのクロスプロセス再初期化 2 を検出できるようにしました。 この機能では、"フラッシュ マップ" ファイルと呼ばれる別のファイルにメタデータを保持する必要があります。

データベース ファイルごとに 1 つのフラッシュ マップ ファイルが作成され、同じディレクトリに配置されます。 ファイルの名前はデータベース ファイルと同様ですが、拡張子は異なります。 たとえば、クライアント アプリケーションが完全なパス C:\MyDirectory\MyDabatase.edb を持つデータベースを作成する場合、対応するフラッシュ マップ ファイルは C:\MyDirectory\MyDabatase.jfm です。

この拡張機能では、データベース ファイルの名前を付ける方法について、次の 2 つの要件が導入されています。

  • 同じディレクトリ内の 2 つのデータベースは、拡張子が異なる同じファイル名を持つ必要があります。 例: C:\MyDirectory\MyDabatase.db1 と C:\MyDirectory\MyDabatase.db2。

  • 2. データベースに .jfm 拡張子を付けてはなりません。

データベース ファイルを手動でコピーまたは移動する場合は、対応するフラッシュ マップ ファイルをそれぞれコピーするか、同じコピー先ディレクトリに移動する必要があります。 (JetAttachDatabase 経由で) 新しいデータベース添付ファイルの時点でフラッシュ マップ ファイルが存在しない場合は、データベースからページが読み込まれると、新しいマップ ファイルが作成され、オンデマンドで再入力されます。 不一致のデータベース ファイルとフラッシュ マップ ファイルの混在は ESE によって処理され、一致しないフラッシュ マップが強制的に削除され、最初から再作成されます。

フラッシュ マップ ファイルのサイズは、関連付けられたデータベース ファイルに直接比例し、ほぼ等しくなります (すべてのサイズ (バイト単位)、結果は次の 8,192 の倍数に切り上げる必要があります)。

8,192 + ((<database file size> / <database page size>) / 4)

たとえば、32 KB のページ サイズを使用する 1.5 GB データベースの場合、フラッシュ マップのおおよそのサイズは 24,576 バイト (または 24 KB) です。

データベース ページがフラッシュされると、フラッシュ マップ ファイルを更新する必要があります。 トランザクション ログが有効になっている場合 (たとえば、JET_paramRecovery "on" に設定されている場合は、クライアント アプリケーションがデータベースに変更を加えると、フラッシュ マップの更新が実行されます。 平均して、フラッシュ マップ全体は、生成されたトランザクション ログの JET_paramCheckpointDepthMax -worth (バイト単位) の 20% ごとに 1 回、不揮発性メディアに書き込まれます。 書き込み操作の数は、変更がデータベース全体でどのように分散されているかによって異なります。 ただし、最大で約 (バイト単位のすべてのサイズ) です。

<flush map file size> / JET_paramMaxCoalesceWriteSize

トランザクション ログが無効になっている場合 (たとえば、JET_paramRecovery "off" に設定されている場合)、フラッシュ マップは、データベースが明示的に (JetDetachDatabase を介して) 明示的にデタッチされた場合、または関連付けられている ESE インスタンスを (JetTerm 関数を介して) 暗黙的にデタッチ JET_bitTermDirty が渡されない限り、1 回だけ更新されます。

1 失われた書き込み (またはフラッシュの損失) は、オペレーティング システムから ESE データベース エンジンに正常に戻る書き込み操作として定義されますが、実際のデータは非揮発性メディアのデータベース ファイルに保持されません。 これは通常、ストレージ スタック (ソフトウェアまたはハードウェア) の誤動作または正しく構成されていないことが原因で発生します。 クライアント アプリケーションは、失われた書き込みイベントが発生したリージョンにデータがある場合、データベースからのデータの読み取りを必要とする ESE 関数から JET_errReadLostFlushVerifyFailure エラーを受け取る可能性があります。

2 プロセスの有効期間内に失われた書き込みを検出する機能は、Windows 8 (クライアント) と Windows Server 2012 (サーバー) 以降に存在しています。