次の方法で共有

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

  • [アーティクル]

適用対象: Windows |Windows Server

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

拡張可能記憶域エンジンは、次の種類のファイルを使用します。

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

Label 値

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows Vista: Windows Vista 以降では、予約済みトランザクション ログ ファイルの名前 <は base>RESXXXXX.jrs です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データベース ファイル

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

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

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

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

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

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

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

一時データベース

一時データベースは、誘惑性のバッキング ストアとして使用され、インデックスの作成時にも使用されます。

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

Temptables は、 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" に設定されている場合、クライアント アプリケーションがデータベースに変更を加えると、フラッシュ マップの更新が実行されます。 平均して、フラッシュ マップ全体は、生成されたトランザクション ログの 20% JET_paramCheckpointDepthMax価値 ( バイト単位) ごとに 1 回、非揮発性メディアに書き込まれます。 書き込み操作の数は、変更がデータベース全体でどのように分散されているかによって異なります。 しかし、それは最大で、おおよそ(バイト単位のすべてのサイズ)です。

<flush map file size> / JET_paramMaxCoalesceWriteSize

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

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

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