通过上面的描述，我们知道在实际的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? 要能够把数据的损失减少到最新程度。 www_bitscn_com
2.必须提供高性能的邮件吞吐能力，对数据库中的邮件的事务操做在完成后必须马上被记录到存储介质上（事务的持久性）。
3.当灾难发生时，使用数据库的备份恢复必须要返回到灾难发生前一刻的数据库状态。
现在我们更进一步的来看一下，当我要修改邮箱中的内容时，被修改的内容首先被读取出来放到内存中。实际的修改发生在内存中，当修改完成后，这些内容必须被写回存储介质，才能表示一个修改成功地完成了。
对于这样的修改过程，在数据库级别上，我们叫做一个“事务”。我们知道，为了确保数据库的完整性和一致性，事务的操作是“原子级别”的。假如一个事务成功，那么标志着他所作的改变被永久的保存下来了；假如一个事务失败，系统必须回到事务开始之前的状态。
当系统在内存中完成修改时，事务并没有完成。假如这个时候宕机，数据库中保存的仍然是没有更改的内容。那么，怎么样确保在内存中完成的修改能够在第一时间写入到数据库呢（以达到数据库事务持久性的需要）？注意，这里的要是第一时间，也就是越快越好。假如我们直接向edb文档写入，无法做到最快，因为，edb文档通常都很大，I/O系统在对大的文档进行随机写入操作时，会花费大量的时间在等待磁盘查找到合适的磁道和扇区，当系统繁忙时，这将会是个瓶颈。因此，数据库系统使用日志文档，当内存中的更改完成后，首先写入到日志文档中。日志文档的尺寸很小，写入性能要远远优于庞大的edb文档。在写入完成后，事务也随之成功的保存在存储介质上了。Exchange Server 的数据库引擎会在后台把Log文档中的内容写入到数据库中，因为此时事务操作已完成，即使此时掉电或宕机，也不会使完成的事务遗失。这是日志文档的第一个作用：确保事务能够在第一时间保存到非易失存储介质上。（提供持久性Durable支持） bitsCN_com
根据上面的描述，我们知道在运行中的Exchange Server数据库，是由三部分组成的
－－内存中已完成修改但是还没有写入日志文档的内容（Dirt Page）。
－－还没有写入到数据库文档的日志文档内容。
－－Edb和stm文档。
对于内存中的数据（Dirt Page），这些数据会在系统掉电或崩溃时遗失。
Exchange Server使用了一个名为E0x.chk（Check Point）的文档记录了那些Log文档已写入到了数据库文档。这是个类似指针的记录。
我们能够使用命令 ESEUTIL /MK来查看这个文档chk的内容
C:\...\Exchsrvr\BIN> ESEUtil /mk “C:\...\Exchsrvr\mdbdata\e00.chk” Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0 Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved. www_bitscn_com Initiating FILE DUMP mode... Checkpoint file: C:\program files\exchsrvr\mdbdata\e00.chk LastFullBackupCheckpoint: (0x0,0,0) Checkpoint: (0x8,26DA,30) FullBackup: (0x0,0,0) FullBackup time: 00/00/1900 00:00:00 IncBackup: (0x0,0,0) IncBackup time: 00/00/1900 00:00:00 Signature: Create time:03/28/2004 20:26:10 Rand:6519986 Computer: Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers) ( off, 202, 10100, 1365, 10100, 128, 10240, 40828) Operation completed successfully in 1.47 seconds. |
在命令的输出中， Checkpoint: <0x8,26DA,30>表示了当前提交到数据库文档的Log完全位置。其中，0x8是Log文档的序号，一般对应于E0x00008.log,剩下的两个参数是Log文档内部页面（page）的编号。
DL.bitsCN.com网管软件下载
下面我们再看一下日志文档对系统备份和恢复的作用。
前面提到过，Exchange Server需要在灾难发生后能够恢复到灾难发生前一刻的状态。对于一般的系统，我们总是每周或每天进行备份，那么，在备份之后和灾难发生之前这段时间的数据如何保护？答案是日志文档。我们知道，对于
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
