可扩展存储引擎文件

适用于： Windows |Windows Server

可扩展存储引擎文件

可扩展存储引擎使用以下类型的文件：

• 事务日志文件

• 临时事务日志文件

• 保留事务日志文件

• 检查点文件

• 数据库文件

• 临时数据库

• 刷新映射文件

此表包含由 ESE 管理的数据文件名称的概述。 对于 Windows Vista 及更高版本，JET_paramLegacyNames设置会影响使用的文件名。

事务日志文件

事务日志文件包含对数据库文件执行的作。 它们包含足够的信息，以便在意外的进程终止或系统关闭后使数据库处于逻辑一致状态。

日志文件的名称依赖于三个字母基名称，可以使用 JET_paramBaseName进行设置。 下面的示例使用基名称“edb”，因为这是默认基名称。 事务日志文件的扩展名将.log或 .jtx，具体取决于JET_paramLegacyFileNames参数中是否设置了JET_bitESE98FileNames。 有关详细信息，请参阅 可扩展存储引擎系统参数。

从 1 开始，事务日志文件 <基><代数>.log 命名。 日志生成编号采用十六进制格式。 例如，edb00001.log是第一个日志，edb000ff.log是第 255 个日志。 日志文件名称中有五个十六进制数字，直到第 1048576 个日志文件，此时日志文件开始以 11.3 格式（例如，edb00100000.log）命名。 <基>.log 始终是当前使用的日志文件。 如果数据库引擎未处于活动状态，可以使用以下命令识别生成edb.log：esentutl.exe -ml edb.log。

虽然事务日志文件具有 .通常与文本文件关联的 LOG 扩展，事务日志文件采用二进制格式，不应由用户编辑。数据库作首先写入日志。 稍后可将数据写入数据库文件;可能立即，可能以后很多。 如果出现意外的进程或系统终止，则日志文件中仍存在作，并且可以回滚不完整的事务。 重播事务日志文件的行为称为 软恢复，并在调用 JetInit2 或 JetInit2 时自动执行。 还可以使用 Esentutl.exe 程序的“-r”选项手动执行软恢复。 对从备份还原的数据库重播事务日志文件的行为称为 硬恢复。

日志文件的大小固定，可通过 JET_paramLogFileSize进行自定义。 当当前日志文件（即edb.log）被填充时，它会重命名为 <基><代数>.log，并且事务日志流中需要新的事务日志文件。

每个数据库实例都有一个与之关联的日志文件序列。 Windows XP 引入了 JetCreateInstance，允许单个进程使用多个事务日志文件序列。 但是，同一目录中不能存在多个事务日志文件序列。

由于数据损坏，几乎不应该手动作、重命名、移动或删除事务日志文件。

在完整备份期间，数据库引擎将删除事务日志文件（如果启用了循环日志记录，请参阅 JetBackup、JetTruncateLog、JetTruncateLogInstance）。

填写事务日志文件后，数据库引擎需要创建新的日志文件。 循环日志记录是指当不再需要日志文件进行崩溃恢复时，数据库引擎可以自动清理日志文件。 此过程是作为执行备份的副产品删除日志文件的替代方法。 可以使用 JET_paramCircularLog 系统参数控制循环日志记录。 不应使用任何其他方法删除事务日志文件。

临时事务日志文件

当edb.log填满时，ESE 需要创建新文件。 新日志事务日志文件在 ESE 使用之前称为临时事务日志文件。

创建新日志文件并扩展其大小时，将调用 <基本>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_paramLegacyFileNames参数中设置JET_bitESE98FileNames，其位置由 JET_paramSystemPath提供。

数据库作首先写入日志文件，然后将缓存在内存中。 稍后将作写入数据库文件，但由于性能原因，作写入数据库文件的顺序可能与最初记录的顺序不匹配。 写入事务日志文件的作将处于以下两种状态之一：

• 写入事务日志文件和数据库文件。

• 写入事务日志文件，但尚未写入数据库文件。

许多数据库作可以存储在单个事务日志文件中。 给定日志文件可以包含以下项：

• 写入数据库文件的所有作。

• 未写入数据库文件的作

• 写入数据库文件和尚未写入数据库文件的作的组合。

检查点是指事务日志流中的时间点，其中检查点之前的所有作都已写入数据库文件。 无法保证检查点后发生的作;有些可能位于内存中，有些可能写入数据库。

由于在检查点之前日志文件中的所有作都表示在数据库文件中，所以软恢复需要检查点后才需要事务日志文件才能使特定数据库处于干净状态。

数据库文件

数据库文件包含数据库中所有表的架构、数据库中所有表的记录以及表上的索引。 其位置使用 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错误。

只能安全地移动或重命名关闭数据库。 如果数据库未完全关闭，则无法自动移动或重命名数据库。

多个数据库可以与单个事务日志文件序列相关联。

临时数据库

临时数据库用作诱人的后盾存储，在创建索引时也使用它。

名称和位置配置为 JET_paramTempPath。

使用 JetOpenTempTable 、JetOpenTempTable2、JetOpenTempTable3、JetOpenTemporaryTable创建。 它们也由一些 API 调用创建，用于返回架构信息（如 JetGetIndexInfo）。

刷新映射文件

从 Windows 10 周年更新（客户端）和 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 字节（或 24KB）。

刷新映射文件需要刷新，因为刷新数据库页。 如果启用了事务日志记录（例如，JET_paramRecovery 设置为“on”，则默认），刷新刷新映射时，客户端应用程序对数据库进行修改。 平均而言，对于生成的事务日志的每 20% JET_paramCheckpointDepthMax -worth（字节），整个刷新映射都会写入非易失性媒体一次。 写入作数取决于修改在整个数据库中的分布方式。 但它最多，大约（所有大小（以字节为单位）：

<flush map file size> / JET_paramMaxCoalesceWriteSize

如果事务日志记录被禁用（例如，JET_paramRecovery 设置为“off”），则刷新映射仅在显式分离数据库时刷新一次（通过 JetDetachDatabase，或通过终止其关联的 ESE 实例（通过任何 JetTerm 函数（只要未传递 JET_bitTermDirty）即可完全分离）。

1 丢失的写入（或丢失刷新）定义为从作系统成功返回到 ESE 数据库引擎的写入作，但实际数据永远不会持久保存到非易失介质中的数据库文件。 它通常是由故障或配置错误的存储堆栈（软件或硬件）引起的。 如果数据位于发生丢失写入事件的区域中，客户端应用程序可能会收到 ESE 函数的 JET_errReadLostFlushVerifyFailure 错误，这些函数需要从数据库读取数据。

2 自 Windows 8（客户端）和 Windows Server 2012（服务器）以来，进程生存期内检测到丢失的写入的能力一直存在。