可延伸儲存引擎檔案
適用于： Windows |Windows Server
可延伸儲存引擎檔案
可延伸儲存引擎會使用下列類型的檔案：
此資料表包含 ESE 所管理之資料檔案名稱的概觀。 針對 Windows Vista 和更新版本，JET_paramLegacyNames設定會影響使用的檔案名。
| 標籤 | 值 |
|---|---|
交易記錄檔
交易記錄檔包含資料庫檔案的作業。 它們包含足夠的資訊，可讓資料庫在非預期的進程終止或系統關機之後，以邏輯上一致的狀態。
記錄檔的名稱相依于三個字母基底名稱，可使用 JET_paramBaseName來設定。 下列範例使用 「edb」 的基底名稱，因為這是預設基底名稱。 交易記錄檔的副檔名將會是 .log 或 .jtx，視JET_bitESE98FileNames是否在 JET_paramLegacyFileNames 參數中設定而定。 如需詳細資訊，請參閱 可延伸儲存引擎系統參數。
交易記錄檔從 1 開始命名為 < base >< generation-number.log > 。 記錄產生編號的格式為十六進位。 例如，edb00001.log 是第一個記錄，而 edb000ff.log 是第 255 個記錄檔。 記錄檔在記錄檔名稱中有五個十六進位數位，直到第 1048576 個記錄檔為止，此時記錄檔會以 11.3 (格式開始命名，例如 edb00100000.log) 。 <base.log > 一律是目前正在使用的記錄檔。 如果資料庫引擎不是使用中，可以使用下列命令來識別 edb.log 的產生：esentutl.exe -ml edb.log。
雖然交易記錄檔具有 。LOG 延伸模組通常與文字檔相關聯，交易記錄檔的格式為二進位格式，且絕對不應該由使用者編輯。資料庫作業會先寫入記錄檔。 資料稍後可以寫入資料庫檔案;可能立即，可能稍後再多。 如果發生非預期的進程或系統終止，記錄檔中仍會出現作業，而且可以回復不完整的交易。 重新執行交易記錄檔的動作稱為軟體復原，而且會在呼叫JetInit 或 JetInit2時自動完成。 您也可以使用Esentutl.exe程式的 「-r」 選項手動執行軟體復原。 在從備份還原的資料庫上重新執行交易記錄檔的動作稱為 硬式復原。
記錄檔的大小固定，可使用 JET_paramLogFileSize進行自訂。 當目前的記錄檔 (即 edb.log) 填滿時，它會重新命名為 < 基底 >< 世代號碼 > .log，而且交易記錄資料流程中需要新的交易記錄檔。
每個資料庫實例都有一個與其相關聯的單一記錄檔序列。 Windows XP 引進 JetCreateInstance，允許單一進程使用多個交易記錄檔序列。 不過，多個交易記錄檔序列不能存在於相同的目錄中。
交易記錄檔幾乎永遠不會手動操作、重新命名、移動或刪除，因為資料損毀可能會造成。
資料庫引擎會在完整備份期間刪除交易記錄檔， (如果啟用迴圈記錄，請參閱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。
當資料庫引擎用盡磁碟空間時，就無法建立新的記錄檔。 要執行的最安全動作是完全關閉，但仍必須記錄某些作業 (例如復原作業) 。 大部分的資料庫作業在此階段都會失敗。
由於保留的交易記錄檔是在非磁片案例中預期交易記錄檔的需求所建立，因此不會包含任何有用的資訊。
檢查點檔案
檢查點檔案會儲存特定交易記錄檔序列的檢查點。 檢查點檔案命名為 < base.chk > 或 < base.jcp > ，視JET_bitESE98FileNames是在 JET_paramLegacyFileNames 參數中設定，而其位置是由 JET_paramSystemPath所指定。
資料庫作業會先寫入記錄檔，然後在記憶體中快取。 在稍後，作業會寫入資料庫檔案，但基於效能考慮，作業寫入資料庫檔案的順序可能不符合原本記錄的順序。 寫入交易記錄檔的作業將處於兩種狀態之一：
寫入交易記錄檔和資料庫檔案。
寫入交易記錄檔，尚未寫入資料庫檔案。
許多資料庫作業都可以儲存在單一交易記錄檔中。 指定的記錄檔可以包含下列專案：
寫入資料庫檔案的所有作業。
沒有寫入資料庫檔案的作業
混合寫入資料庫檔案的作業，以及尚未寫入資料庫檔案的作業。
檢查點是指交易記錄資料流程中的時間點，其中檢查點之前的所有作業都已寫入資料庫檔案。 不保證檢查點之後發生的作業;有些可能位於記憶體中，有些可能寫入資料庫。
由於在檢查點之前記錄檔中的所有作業都會以資料庫檔案表示，因此只有檢查點之後的交易記錄檔才能讓特定資料庫進入乾淨狀態。
資料庫檔案
資料庫檔案包含資料庫中所有資料表的架構、資料庫中所有資料表的記錄，以及資料表上的索引。 其位置是使用JetCreateDatabase、JetCreateDatabase2、JetAttachDatabase 或 JetAttachDatabase2來指定。
只有在成功呼叫JetTerm 或 JetTerm2之後，才會完全關閉資料庫。
Esentutl.exe程式可以使用 「-Esentutl.exe選項來偵測資料庫是否完全關閉。 例如，「esentutl.exe -esentutl.exe-edb」 會讀取名為 sample.edb 的資料庫資料庫標頭，並列印 sample.edb 的狀態。 它可能會列印出「狀態：清除關機」或「狀態：已變更關機」。
尚未完全關閉的資料庫處於已變更的關機狀態。 在 Windows XP 之前，此狀態稱為 不一致。 ) 資料庫 (不一致的變更，可以透過軟復原進入全新狀態。 損毀的資料庫與已變更的資料庫不同 (「不一致」) 資料庫。
損毀的資料庫是指實體或邏輯損毀，而且無法使用軟復原來修正。 實體損毀可以是位翻轉，資料庫頁面上總和檢查碼經常攔截到。 資料庫檔案中的失敗總和檢查碼會以JET_errReadVerifyFailure錯誤的形式顯示。
只有完全關閉資料庫可以安全地移動或重新命名。 如果資料庫未完全關閉，則無法自動安全地移動或重新命名資料庫。
多個資料庫可以與單一交易記錄檔序列相關聯。
暫存資料庫
暫存資料庫是用來作為可吸引人之用的備份存放區，而且也會在建立索引時使用。
名稱和位置會以 JET_paramTempPath進行設定。
會使用JetOpenTempTable、JetOpenTempTable2、JetOpenTempTable3、JetOpenTemporaryTable來建立。 它們也會由某些 API 呼叫建立，並用來傳回架構資訊 (，例如 JetGetIndexInfo) 。
排清對應檔案
從 Windows 10 Anniversary Update (用戶端) 和Windows Server 2016 (伺服器) 開始，ESE 新增了額外的保護層級，以防止遺失的寫入 (或遺失排清) 1，讓它偵測這類事件跨進程重新初始化2。 這項功能需要將中繼資料保存到稱為「排清對應」檔案的個別檔案。
系統會為每個資料庫檔案建立一個排清對應檔案，且位於相同的目錄中。 檔案的命名方式與資料庫檔案類似，但副檔名不同。 例如，如果用戶端應用程式建立具有完整路徑 C：\MyDirectory\MyDabatase.edb 的資料庫，其對應的排清對應檔案為 C：\MyDirectory\MyDabatase.jfm。
這項增強功能針對資料庫檔案的命名方式有兩個需求：
相同目錄中的兩個資料庫不得具有相同副檔名的檔案名。 例如：C：\MyDirectory\MyDabatase.db1 和 C：\MyDirectory\MyDabatase.db2。
2.資料庫不能有 .jfm 副檔名。
當您手動複製或移動資料庫檔案時，其對應的排清對應檔案也應該分別複製或移至相同的目的地目錄。 如果排清對應檔在透過 JetAttachDatabase (的新資料庫附件時不存在，則會建立新的對應檔，並視需要重新填入頁面，因為從資料庫讀取頁面。 混合不相符的資料庫和排清對應檔案是由 ESE 處理，並強制從頭刪除並重新建立不相符的排清對應。
排清對應檔案的大小會與其相關聯的資料庫檔案直接成正比，且大約等於以位元組為單位的所有大小 (，結果必須四捨五入到下一個 8，192) 的倍數：
8,192 + ((<database file size> / <database page size>) / 4)
例如：針對使用 32KB 頁面大小的 1.5GB 資料庫，排清對應的大小大約是 24，576 個位元組 (或 24 KB) 。
排清對應檔必須重新整理，因為資料庫頁面已排清。 例如，如果啟用交易記錄 (， JET_paramRecovery 設定為 「on」，則預設) 會執行排清對應，因為用戶端應用程式對資料庫進行修改。 平均來說，整個排清對應會針對每 20% 的 JET_paramCheckpointDepthMax -worth (寫入非變動性媒體一次，以位元組為單位) 產生的交易記錄。 寫入作業數目取決於修改在整個資料庫中散發的方式。 但基本上，大約 (以位元組為單位的所有大小) ：
<flush map file size> / JET_paramMaxCoalesceWriteSize
例如，如果交易式記錄已停用 (， JET_paramRecovery 設定為 「off」) ，則只有在透過 JetDetachDatabase明確 (卸離資料庫時，才會重新整理排清對應一次，或者透過任何 JetTerm 函式終止其相關聯的 ESE 實例 (，只要不會傳遞 ) JET_bitTermDirty，才會重新整理一次。
1 遺失的寫入 (或遺失排清) 定義為從作業系統成功傳回至 ESE 資料庫引擎的寫入作業，但實際資料永遠不會保存到非變動性媒體中的資料庫檔案。 它通常是因為軟體或硬體 () 發生故障或設定錯誤的儲存體堆疊所造成。 如果資料位於發生遺失寫入事件的區域，用戶端應用程式可能會收到來自 ESE 函式的 JET_errReadLostFlushVerifyFailure 錯誤，需要從資料庫讀取資料。
2 自Windows 8 (用戶端) 和Windows Server 2012 (伺服器) 以來，偵測進程存留期內遺失的寫入能力。