Exchange

前言 　　数据能够存在于Exchange 服务器上的三个地方:内存、日志文件和数据库存储。但是我们对Exchange 和ESE通过这三个地方移动数据的底层步骤有一些混淆。 　　该文章的目的是提供一个容易理解的过程解释和将来灾难恢复的一个快速参考指南。然而，它也解释了.edb和.stm数据库文件的细节信息，更准确地说，如何以及为什么在这两者之间做数据移动。 　　什么是ESE? 　　ESE是一个DLL，Exchange 存储过程用它在Exchange 数据库内存储记录和创建索引。它是Microsoft Exchange 信息存储服务和实际数据库之间的中间技术。 　　ESE允许应用程序存储记录和创建索引，以不同的方式来访问这些记录。尽管ESE不直接接受结构化查询语言(SQL)请求，它处理从客户端传递给它的事务，在这种情况下，Exchange 是代表实际数据操作的组件。因为该引擎是多线程和基于JET技术，对于快速数据存储和检索它是最优化的。 　　什么是事务? 　　事务是一系列必须一起完成的操作。如果这些操作中的某个失败的话，整个事务是无效的。和大多数数据库事务类似，最后一个操作后面跟着COMMIT 声明，说明该事务是完整的。因此事务中一个或多个操作失败，COMMIT 声明将从不运行，数据库将不会收到该事务。 　　事务的一个例子是将邮件从一个文件夹移动到另一个文件夹。这样的操作也许对终端用户来说很容易，但实际上有一系列的事务组成了从Microsoft Outlook 看起来简单的动作。不管什么时候像这样简单的事情发生在Exchange 环境中，ESE一般要执行多个事务来完成该请求。 　　事务是如何发起的? 　　事务是从客户端请求发起的。客户端请求不来自终端用户，如Outlook 客户端。它们直接来自Exchange。因此在这种情况下，Exchange 或具体的Microsoft Exchange 信息存储服务是客户端。 　　例如，当在Outlook 中执行一个操作，一个远程过程调用(RPC)对Exchange 生成，然后组成事务并传递给ESE来处理。只有当它能保证数据是持续或持久的，并受到保护不会失败，紧接着一系列子组件确保Exchange提交了一个事务。这些相同的组件确保这些事务如下： 　　●Atomic 所有的操作都发生或它们都没有发生发生 　　●Consistent 数据库从一个正确的状态转换到另一个状态 　　●Isolated 更改直到它们被提交后才可见 　　●Durable 提交的事务保护在数据库中，即使系统出现故障。 　　为了准确理解ESE是如何完成这些事务，在它们从Microsoft Exchange 信息存储服务器传递给ESE来处理后，您需要研究这些事务发生怎样的变化。 [1] [2] [3] < 事务发生了哪些变化? 　　下面五个ESE子组件一共工作，来移动数据到数据库中和它自己的静态表格中。对正确排除像灾难恢复这样的事件来说，理解数据流经过ESE的方式是相当重要的。 　　日志缓冲器 当ESE开始接收一个事务的时候，把它存储在日志缓冲器。这些日志缓冲器用来保存内存中的信息在被写进事务日志中之前。在缺省情况下，每个缓冲器单元是一个磁盘扇区大小，它意味是512字节大小。JET做一些卫生工作来确保缓冲器的数量最小是128个扇区，最大10240个扇区，并对齐它们，最大的边界为64KB。因此，对于Exchange 2000 服务器(和所有服务包)的日志缓冲器缺省数量是84，JET用掉128，因此实际的缓冲区域是64K字节。对于Exchange 2003，日志缓冲器缺省数量是500，JET用掉384，因此实际的缓冲区域是192K字节。 　　注意： 　　Microsoft 建议，在Exchange 2000 和Exchange 2003服务器，手动调整缺省值到512字节，它不要求干净，并导致256KB区域。在磁盘性能很慢的情况下，Microsoft 建议缓冲应该调整到9000(也就是大于4MB)。 　　日志记录器 当缓冲区填满后，ESE将数据从缓冲区移动到磁盘上和日志文件中。在该操作过程中，这些事务以同步的方式提交到磁盘的日志中。该过程很快，因为将数据从内存中迅速移动到事务日志中是很关键的，以防系统出现故障。 　　IS 缓冲区 将事务转化为实际的数据的第一步是IS或高速缓冲区。IS缓冲区是一组从内存中分配4KB的页面，Exchange 使用它的目的是缓存数据库页面在它们被写入磁盘之前。当第一被创建的时候，这些页面是干净的，因为它们还没有任何事务要写入。接着ESE将播放事务从日志到内存中这些空的页面，因此更改它们的状态为不干净的。在Exchange 2000 Server SP3 中，这些缓冲器缺省的最大值能达到900MB。 　　存储版本 ESE写多个不同的事务到内存中的单个页面中。存储一直跟踪和管理这些事务。它也组织这些页面当事务发生的时候。 　　Lazy writer 在该点上，AESE必须更新内存中的不干净页面。Lazy writer 承担将页面从缓冲器移动到磁盘的任务。因为有很多事务进来，因此有很多页面变成不干净的，lazy writer 的任务就是排列它们的优先级，并随后处理移动它们在不加重磁盘I/O子系统的负担的情况下。这是最后的阶段和时间点，在这点上事务正式变成静态数据。也是在这点上不干净的页面变成干净的并准备再次使用。 　　在在线备份期间，该过程如何发生? 　　与前面提到的相比，在在线备份期间，没有多少不同的。当备份一开始，检查点就停止增加。因为备份进程需要备份所有的日志文件在冻住检查点后，尽管事务仍然通过ESE的五个阶段来移动。接着，在备份进程完成拷贝数据库文件和必要的日志文件到磁带后，检查点文件将允许被赶上。 　　在一些案例中，备份停止响应尽管事务继被ESE处理。Exchange 2000 Server SP3 和以后的都采用硬编码来限制检查点深度到大约1000左右。如果发生这样情况，有足够多的事务需要处理，大约只有1000个日志文件被临时创建，Exchange 将卸载该特定存储组的数据库。该错误将被记录为JET_errCheckpointDepthTooDeep。 　　.edb 文件 　　.edb 文件主要用来存储邮箱数据。.edb文件的基础架构是b-tree 结构，它只存在于该文件中，不存在于.stm 文件中。b-tree 被设计用来同时快速访问很多页面。.edb 文件设计允许一个最顶级的节点和许多子节点。 　　在一个b-tree 中，每个子节点只能有一个父节点。尽管通常b-tree 允许没有限制的深度，Microsoft在大多数应用中限制b-tree 的深度，来促进快速访问能够和引擎一起工作，不管引擎发生什么。通过允许像这样高速和低树深度，Exchange 和ESE能保证用户在四个I/O内，能够访问数据的任何页面，也称为一个叶节点。 　　树的深度对性能有很大的影响。跨整个结构的统一树深度，每个叶节点或者数据页面到根节点的距离是相等的，意味着数据库性能是连续和可预知的。通过这种方式，ESE 4KB 页面被安排到表格，形成一个包含Exchange 数据的大的数据库文件。 　　数据库实际上由多个b-tree组成。这些其他辅助树持有与主树一起工作的索引和视图。 　　.edb 文件被ESE直接访问。 [1] [2] [3] < .stm 文件 　　.stm 或流媒体文件用来和.edb 文件结合起来组成Exchange 数据库。两个文件一起组成数据库，同样地，它们应该总是被当作一个实体。通常，如果您在.edb文件上执行一个操作，如通过Exchange 服务器数据库工具(Eseutil)，.stm文件被自动包含进来。 　　.stm 文件的目的是存储纯流式的Internet 内容。为了理解它的真正含义，您应该首先理解传统的Exchange 产品通过单个文件处理数据的方式。 　　在Exchange 5.5中，例如，Internet Mail Connector 接收入站的多用途 Internet 邮件扩展 (MIME)邮件，并将它们写入到磁盘队列中，在那里Exchange 接着转换它们为纯MAPI内容或MDBEF为了信息存储和MAPI客户端使用。接着，如果一个Internet API，像POP3或者IMAP4请求数据，在发送之前它又被转换回去。这种前后转换过程能引起过载和性能问题。 　　流媒体文件能有助于减轻一些这种转换。 　　不像前面提到的.edb文件，.stm文件不以b-tree 结构存储数据。当一个邮件通过Internet 或者SMTP到达时，它总是以字节流到达。在Exchange Server 2003 和Exchange Server 2000 服务器中，这些邮件被直接注入.stm文件，它们一直被存储在那里直到被MAPI客户端访问。因此这些内容不被转换。那样的话，如果终端用户一向通过POP3访问邮件，邮件从.stm文件被直接拉下来，同时邮件已经处于正确的状态以被传递。在这种情况下，该邮件被MAPI客户端访问，然而，该邮件被移动到.edb文件，同时被转换为Exchange 纯格式，在也不会转换成.stm文件。 　　如果.stm文件丢失或者损坏，它能够被重建。根据实际的情况，这也许是一个灾难性的损失。如果终端用户工作在非MAPI环境中，它们也许丢失了大量的数据。为了完成重建，您也许要使用Eseutil工具的/createstm 开关。因为实际的内容存储在.stm文件中，但邮件的指针和头信息被存储在.edb文件中，该工具使用这些信息来重建.stm文件，但是没有内容。 　　总结 　　有三个ESE组件在内存中：事务日志缓冲器、数据缓存和版本存储。有个组件在磁盘上：日志文件和数据库文件。事务通过像下面的组件移动不管备份是否被执行。 　　1、 日志缓冲器 　　2、 日志文件 　　3、 缓存和版本存储 　　4、 数据库文件 　　.edb和.stm文件结合起来组成Exchange 数据库。.edb文件存储所有被MAPI客户端访问的数据，在一些数据被移动到.edb文件后并被转换为纯Exchange 格式，它保持那种格式。.stm文件存储所有通过Internet 流入的的内容。被MAPI 客户端重新查看的Internet 邮件首先通过SMTP以.stm文件到达在被提升为.edb文件之前。如果一封邮件源自另一个Exchange 服务器，但是通过SMTP传输的，它先被保存为STM格式，然后紧接着被提升为EDB格式。如果该邮件从没有被MAPI客户端访问的话，它将停留在它原来的.stm格式。 　　这两个文件的分裂和它们扮演的角色显著地减少了旧Exchange 产品所能承受的过载的繁重的转换。 [1] [2] [3] <