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、E0一、E02 、 E0三、…… E0九、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数据库进行备份时，能够启用循环日志记录，为防止日志文件过多，影响到正常应用，须要启用循环日志记录。因此说，针对数据库进行有效的备份才是控制日志文件增加的有效办法。