Exchange Server邮件存储系统-原理篇

    MAPI格式的邮件是基于微软的RPC和二进制标准的，而Internet格式的邮件是由纯文本的邮件头和经过MIME编码的字符流组成的。这两者的特性就决定他们无法共存在一种数据库结构的文件中。

　　因此，在Exchange Server 2000中，微软分别使用edb文件和stm文件保存这两种格式的邮件，并在edb和stm文件之间建立了关联和引用。对于用户来说，他的邮箱内容实际上是由跨越了edb和stm文件中的内容共同组成的。值得一提的是，edb文件中除了实际的信件信息以外，还保存了每个用户的邮箱结构、每一个文件夹的内容列表和视图等信息。这是区别于stm中只保存字符流的地方。

　　我们分下面几种情况讨论edb和stm文件的使用：

　　1.用户使用Outlook 以MAPI协议的方式和发送和访问邮件
    2.用户使用 SMTP/POP3等Internet协议访问Exchange Server。

　　情景一：

　　当邮件从MAPI协议的客户端(通常是Microsoft Office中的Outlook)提交到数据库后，邮件内容被保存在edb文件中。

　　当用户通过MAPI协议的客户端对邮箱中的邮件进行读取访问时，如果请求的邮件是保存在edb文件中的，那么信件被直接打开后返回给用户。如果被请求的信件保存在stm文件中(此信件是SMTP格式的)，那么，Exchange Server数据库引擎首先会做一个转换，把stm文件中的数据格式转换成MAPI可以识别的格式，然后再发送给客户端。这个过程称之为“On- demand Conversion”。

　　情景二：

　　用户使用SMTP/POP3客户端(如Outlook Express, FoxMail等)跟邮箱连接。当SMTP协议向Exchange Server提交邮件时，邮件的内容被保存在stm文件中。前面提到过，edb文件中包含了用户邮箱的文件夹和信件内容列表，因此，当邮件被保存到stm 文件后，数据库引擎把这封邮件的一些重要信息(通常是邮件头中的内容和信件在stm文件中的位置)提取出来，保存到edb文件，这个过程称之为 “Property Promotion”。正是有了这个过程，用户才可以得到信箱内容的完整列表，MAPI客户端需要访问位于stm文件中的邮件时，由此能够得到stm文件中信件的正确保存位置。当用户使用POP3协议来读取邮件时，如果被访问的邮件位于edb文件中，同样，一个从MAPI到Internet格式的转化(“ On-demand Conversion”)也会在后台悄悄的发生。

  
    通过上面的描述，我们知道在实际的Exchange Server环境中，这两个文件是紧密关联的。在任何时候都不要单独的操作这两个文件，要始终把他们视为一个整体。edb文件中包含了每一个邮箱的内容列表(store tables)，当客户端需要得到文件夹的内容时，都必须向edb文件发出请求。两种格式的文件，对两种类型的协议分别提供了支持，有效的减少了不必要的格式转换的发生。

    Log文件的作用

　　我们讨论Exchange Server的邮件存储，就不得不谈谈它的日志文件。我不止一次的听到Exchange Server的管理员抱怨：日至文件每天都在疯长，太消耗硬盘空间了。

　　我们来看看这些日志文件到底有些什么作用。对于每一个Storage Group，Exchange Server会产生一系列与之对应的日志文件。这些日志文件的大小为5M，扩展名为log，他们的前缀为E0x,其中x是日志文件所对应的Storage Group的编号[脚注:虽然在Storage Group的属性中有“Log File Prefix”这一个文本框，但实际上这是不能更改的。]。因此第一个Storage Group的日志文件前缀为E00，第二个的为E01，依次类推。这样做的目的是当存在多个Storage Group时，可以避免管理员在维护的时候把日志文件”张冠李戴”。另外，除了连续的Log文件，我们还能看到E0x.chk、Res1.log、 Res2.log等文件。

　　很多管理员都对日志文件非常的头疼，那么，微软在Exchange Server的数据库系统中引入Log文件的目的是什么呢?我们从以下几个方面来看：

　　1.作为一个企业级的邮件数据库系统，必须做到数据安全和完整性的万无一失。必须能够面对随时可能发生的崩溃和宕机，What happens if we crash? 要能够把数据的损失减少到最新程度。
    2.必须提供高性能的邮件吞吐能力，对数据库中的邮件的事务操做在完成后必须马上被记录到存储介质上(事务的持久性)。
    3.当灾难发生时，使用数据库的备份恢复必须要返回到灾难发生前一刻的数据库状态。

　　现在我们更进一步的来看一下，当我要修改邮箱中的内容时，被修改的内容首先被读取出来放到内存中。实际的修改发生在内存中，当修改完成后，这些内容必须被写回存储介质，才能表示一个修改成功地完成了。

　　对于这样的修改过程，在数据库级别上，我们叫做一个“事务”。我们知道，为了确保数据库的完整性和一致性，事务的操作是“原子级别”的。如果一个事务成功，那么标志着他所作的改变被永久的保存下来了;如果一个事务失败，系统必须回到事务开始之前的状态。