Exchange Server 运维管理02：邮箱数据库存储原理

重申一下，出此系列文章的目的是为了加强运维管理的能力，也就是说不是部署或者是常规配置，这就需要掌握一些基本的理论知识。如果有朋友需要了解Exchange的部署或者是基本操作，可以参考其他的资源，也可以看我之前的Exchange系列文章。

本文将了解一下Exchage 2010数据库文件的存储原理，可能Exchange部署配置完成后，客户很少去关心底层数据库文件的存储格式，只要DAG副本能正常复制，用户邮箱正常使用就可以了，当然，这是理想状态，但万一数据库发生故障需要对数据库进行修复或者是还原时候，就需要用到和数据库存储相关的知识。

首先，Exchange 2010 Standard 版支持多达五个数据库。Exchange 2010 Enterprise 版支持多达 100 个数据库。但需要注意的是，这是指一台服务器上所支持的数据库的最大数量，包括活动数据库和被动数据库。

存储内容：

Exchange Server 2010中主要存储邮箱数据库和共用文件夹的内容，邮箱数据库是大家接触最多的，至于公用文件夹，大家简单了解即可，在 Outlook 2007之前的版本中，对于像忙/闲信息和脱机通讯簿 (OAB) 下载等功能，需要用到公用文件夹。也就是说如果企业中都是使用Outlook2007之后的版本，就可以和公用文件夹说拜拜了。因此，我们今天的重点是介绍邮箱数据库的内容。

邮箱数据库：

如果大家学习过任一数据库系统，则对于学习Exchange邮箱数据库一样简单。Exchange邮箱数据库分为数据库文件和事务日志文件两大类，当然除此之外，还有检查点文件，我们下面会一一介绍：

数据库文件：(.edb)    此文件是重中之重，用于存储真正的数据，只要此文件在，就没有什么大不了。Exchange版本每一次升级都号称对存储的IO要求越来越低，不再需要专业的存储设备支撑，就与此文件结构的设计有很大的关系。就其Exchange 2010来说，采用B树结构，使得用户可以在一个I/O循环内访问任意数据页面，与早期2007相比，速度提高了四倍。

事务日志文件（.log） Log文件中存储的不是真正的数据，而是对数据库所进行的操作，像创建、删除、修改等，存放的是一个动作。其主要目的是为了保证数据的完整性和致性，对于已提交的操作，将被写到数据库文件中。当前使用是E04.log文件，此文件用来存放目前最新的邮件更改信息,在到达日志文件目标大小后，将会被重命名为下一个带有lGeneration 数字序列的日志文件，比如从 E0000000001.log 到 E000000000E.log，这里的数字是16进制。 在重命名完成后，会创建新的 E0x.log 文件。

还有一个e04tmp.log文件，每当 E0x.log 文件被写满之后，这个临时的 E0xtmp.log 文件将被用来接收新的内容，最后将会被改名为新的E0x.log。

这里面还有一些jrs的文件是干什么的？.jrs文件称为保留日志文件，如果当前日志文件已满，这些文件可以用来预留额外日志文件空间的。当磁盘即将写满的时候，此时已经写入日志的数据也没法提交应用到EDB数据库中，可能会导致文件丢失，有了预留文件件以后，在磁盘即将写满的时候，系统会自动将 .jrs作为下一个新的日志文件，以保证以前的事务数据能够正常写入，然后再自动卸载数据库以保证数据的一致性。就是说，在挂载数据库的时候，系统已经预留了10MB的空间来预防数据的丢失。

总来的说一个数据库，最多可以达到1亿个日志文件。

检查点文件：（.chk） chk文件称为检查点文件，此文件的重要性在于，Exchange将通过检查点文件来标记哪些日志已经被写入数据库文件了，哪些还没有写入。如果在某个时刻，系统发生故障了，Exchange正常恢复时，扩展存储引擎 (ESE)实例会将上次未写的数据开妈，将日志文件自动重播至不一致的数据库中，从而保证了数据的一致性和完整性。其实就是用来检查哪些日志写了数据文件，哪些没有写入。Exchange 每隔三十秒更新一次检查点文件。.chk 文件与 .log 文件放置在相同的日志位置。

理论上创建一个邮箱数据库至少要求50MB的磁盘空间，数据库所用到的文件至少占用23MB，但在创建的过程中需要额外的空间来完成数据的读、写操作。除此之外，在子文件夹中，还有.ci .wid .dir .000等索引文件。

事务日志记录：

Exchange 不是将所有日志信息写入单个大文件中，而是使用一系列日志文件，每个日志文件的大小正好是 1 MB（即 1,024 KB）。如果日志文件已满，Exchange 将关闭该文件并使用序号重命名该文件。第一个写满的日志以名称 Enn00000001.log 结尾。nn 代表一个两位数，称为基本名称或日志前缀。每个数据库的日志文件用带有编号前缀（例如，E00、E01、E02 、 E03、…… E09、E0A）的文件名进行区分。当前对数据库打开的日志文件名为 Enn.log。该文件在被填充并关闭之后才会有序号。

检查点文件 (Enn.chk) 跟踪 Exchange 将记录的信息写入数据库文件的进度。每个数据库都有各自的日志流，每个日志流都有一个检查点文件。

下面，咱们来研究一下日志文件头，每个日志文件的第一个 4KB 页包含文件头信息，说明并标识日志文件及其所属的数据库。可以使用命令：Eseutil /ml [log file name] 来查看文件头的信息，但注意如果是Exchange SP1 可能会出现下图所示的提示：

我这里直接升级到SP3，然后重启再运行此命令eseutil /ml 日志文件名，如下图所示：

下面，咱们就查看一个具体的看一下，着重查看前四行，

日志文件文件头的这几行表明此日志文件是当前日志文件，lGeneration 行表明在日志已被填充并关闭时，其序号将是 49，对应于十进制值 73。基本名称是 e01，因此，最终的日志文件名将是 E0100000049.log。 Checkpoint 值实际上不是从日志文件文件头中读取的，但是看上去好像是从日志文件文件头中读取的它。Eseutil.exe 直接从 Enn.chk 读取 Checkpoint 值，这样就不必输入单独的命令即可了解检查点文件的位置。如果检查点文件已被破坏，Checkpoint 值将显示为 NOT AVAILABLE。在此例中，检查点位于当前日志文件 (0x50) 中，数字 FFFF 和 FFFF 指示检查点在日志文件中的位置。一般，我们在修复或者是还原数据文件时，很少会用到检查点的信息。如果检查点文件被破坏，Exchange 仍可以正确地恢复并重播日志文件。只是Exchange 将从头开始扫描日志文件，从最早的可用文件开始，而不是从检查点日志开始。Exchange 跳过已应用于数据库的数据（写入到数据库的数据），并按顺序处理日志，直到遇到必须应用的数据。通常，Exchange 扫描已应用于数据库的日志文件只需要一两秒的时间。如果日志文件中包含必须被写入数据库的操作，应用操作可能需要 10 秒到几分钟不等。平均来算，可以在 30 秒或更短的时间内将一个日志文件的内容写入数据库。

Exchange 数据库正常关闭时，所有未处理的数据都将被写入数据库文件。正常关闭后，将认为数据库文件集是一致的，Exchange 将其与日志流分离。这表明数据库文件现在是自包含文件（最新）。不需要事务日志即可启动数据库文件。尽管在关闭所有数据库之后可以删除日志文件，但这样做将影响还原早期备份并前滚的能力。当前数据库不再需要现有的日志文件，但是如果必须还原早期数据库，则可能需要这些日志文件。

通过运行 Eseutil /mh 命令并检查数据库文件头，可以判断数据库是否已正常关闭，如果显示状态是cleanshutdown。则显示为正常关闭，否则，恭喜您，就修复吧。。。。。。。。。一个痛苦而漫长的过程。如果数据库处于异常关闭状态，必须提供检查点之后的所有现有事务日志，才能再次装入数据库。如果这些日志不可用，则必须运行 Eseutil /p 命令来修复数据库，以使数据库处于一致状态并可以启动。修复数据库，就有数据会丢失。尽管数据丢失量通常非常少，但是可能是灾难性的。对数据库运行 Eseutil /p 之后，应运行 Eseutil/ d 对数据库进行碎片整理。此操作将丢弃并重建所有数据库索引和空间树，如下图所示：

循环日志记录

很多管理员很喜欢针对数据库启用循环日志记录功能，目的就是为了节省磁盘空间，不然空间上会生成很庞大的日志信息，直至耗尽磁盘空间，影响到正常使用。在 Exchange 2010 中，默认情况下禁用循环日志记录。通过启用循环日志记录，可以降低对驱动器存储空间的要求。但是，如果没有一组完整的事务日志文件，则无法恢复晚于上一次完整备份的任何数据。在正常的生产环境中，建议不启用循环日志记录：

如果 Exchange 2010 使用的是标准事务日志记录方式，则每个数据库事务都会被写入日志文件中，然后写入数据库中。如果日志文件的大小达到 1 MB，则将重命名该文件并新建日志文件。随着时间的推移，将产生一组日志文件。如果 Exchange 意外地停止，可以通过将这些日志文件中的数据重播到数据库中来恢复事务。循环日志记录方式则允许 Exchange 在事务日志文件包含的数据提交到数据库之后覆盖这些事务日志文件。但是，如果启用循环日志记录，则可以将数据只恢复到上一完整备份。因此，一般没有专门对Exchange数据库进行备份时，可以启用循环日志记录，为防止日志文件过多，影响到正常应用，需要启用循环日志记录。所以说，针对数据库进行有效的备份才是控制日志文件增长的有效办法。