文件详析邮件服务器邮件存储和日志（电子商务范文）

封面

《详析邮件服务器邮件存储和日志》Word格式可编辑含目录

精心整理放心阅读欢迎下载

文档信息

详析邮件服务器邮件存储和日志

目录

一、 IS服务和ESE的层次关系

A--Atomic 原子的 事务必须是全或全无的操作

C--Coistent 一致的

I--Isolated 孤立的

D--Durable 持久的  当事务一旦提交

二、 EXCHANGE 2000/2003存储系统的新特点

三、 EDB和STM的关系

四、 LOG文件的重大作用

1、作为一个企业级的邮件系统必须要保证数据安全和完整

2、必须提供高性能的邮件处理能力

3、灾难发生后

五、 ESE与IS服务的启动和关闭

正文

本文以数据库的基本原理为基础分析了EXCHANGE SERVER的存储系统并说明了各部分的作用。

一、 IS服务和ESE的层次关系

I S服务是E XCHANGE服务器中重要的服务之一它控制着对邮箱和PF的存储操作请求 EX CHANGE服务器的存储实际上是由ESE的数据库引擎来管理的。这个ESE引擎是微软专门为保存非关系型数据而开发的 目前在微软的很多产品中都有广泛的应用如 AD数据库、DHCP、 W I、 S等等。

EXCHANGE的数据库是由EDB文件、 STM文件和LOG文件组成。在这些文件里微软使用了“B+树”的内部数据结构。 ESE的引擎的任务之

一就是当IS服务请求访问数据库的时候把这些请求转化为对内部数据结构的读写访问。 B+树的特点是能够对存储在硬盘上的数据提供快速访问能力。微软利用“B+树”作为ESE的后台结构的主要原因就是尽可能的提高访问数据时I/O性能。当然这些结构对于

EXCHANGE STORE来说是透明的。

另外作为一个数据库系统 ESE有责任提供事务级别的操作的支持并维护数据库的完整性和一致性。对数据库系统而言我们提到事务时一般用AC I D来描述事务的特点。

A--Atomic 原子的 事务必须是全或全无的操作要么全部成功更新要么全部不被更新

C--Coistent 一致的 一个成功提交的事务必须使数据库处于一个一致的状态。

I--Isolated 孤立的 所有未提交的更改都必须能够和其他事务孤立。

D--Durable 持久的  当事务一旦提交所做的更改必须存储到稳定的介质上防止系统失败导致的数据库不一致。 此点非常重要

二、 EXCHANGE 2000/2003存储系统的新特点

在中 ESE的版本为ESE97而在EX2000/2003里 ESE版本已经升级ESE98了。 ESE引起在以下方面得到了改进

* I/O性能进一步提高和优化

*对日志文件增加了计算校验操作

*提高了ESEUTIL等工具的维护速度

而IS也在以下方面有了更新

*在每个SERVER上提供多个SG支持

*数据库STM文件格式的引入提高了I NT ERNET邮件的性能

* WSS的引入用户可以使用多种协议访问数据库

三、 EDB和S TM的关系

常有人问 EDB文件是数据库那S TM文件是做什么用的可以删除吗

在里只有EDB文件 因为在发布时微软主推的是内部邮件系统 因此其主要协议为MAP I这是微软的私有邮件西医 EDB文件是专门为此协议优化过的。因此在中为了支持INTERNET邮件必须在每次处理INTERNET邮件时做一个格式转换。这显然带来了性能的损失。

在EX2000里微软加大了对I NTERNET邮件的支持这就是STM文件的来源。 MAP I格式是RPC和二进制标准的而STM是纯文本加上一些M I ME编码格式这样的区别使得它们不可能存储在同一数据库里。因此EX2000中微软开始使用EDB和STM两个文件来分别保存两种格式的邮件。并且在两个文件之间建立了引用和关联。对于用户来说它的邮箱实际上是跨越了E DB和S TM文件共同组成的。另外需要注意的是 EDB文件中还保留着用户的邮箱结构。所以EDB文件更加重要。那么EDB和STM是怎么协同工作的呢我们以几个情景来分析之。

情景一用户使用OUTLOOK MAPI发送接收邮件

在该情景下用户将邮件通过MAP I协议提交给数据库直接被保存EDB文件中。当用户通过MAP I访问邮箱里的邮件时如果被访问的邮件在EDB里直接返回如果在STM里如外来邮件 则执行转换将STM转换为E DB文件格式再返回用户。

情景二用户使用标准SMTP/POP3/IMAP4等协议访问

用户使用非MAP I协议提交的邮件 内容保存在STM文件里但是由于E DB里有邮箱结构 STM没有 因此系统会把邮件的重要信息提取出来放在E DB里。当用户用MAP I提取邮件时过程同上 当用户通过标准协议访问时 同样需要进行格式转换转换为S TM文件格式返回。 这些转换是在后台发生的。对用户来说是透明的。通过上面的描述你会看到这两个文件是紧密联系的缺一不可。所以在任何时间我们都不要单独操作这两个文件它们是一个整体。 同时也要注意的是无论用户使用何方式访问邮箱都需要向EDB文件请求邮箱结构信息这是需要注意的。

四、 LOG文件的重大作用

在论坛里经常会看到有人说我的硬盘怎么很快就没了一看原来是日志文件搞的鬼于是就有人删除日志文件甚至使用循环日志来强制减少日志甚至有人提出这样的疑问 日志到底有什么用是不是多余的那我们来看看日志的重大作用。

对于一个SG来说系统会产生一系列的日志这些日志的扩展名为LOG前缀一般是E00、 E01„„除了这些连续的日志文件外还有一些特殊的日志文件     它们又有什么用呢我们的管理员通常不喜欢备份这一操作 因此对这些日志是痛恨不已啊。那么微软在E XCHANGE数据库系统中引入日志的作用难道真的是多此一举吗我们从以下几个方面来考察一下日志的作用

1、作为一个企业级的邮件系统必须要保证数据安全和完整。必须能够面对随时可能发生的意外灾难把数据损失降低到最小。

2、必须提供高性能的邮件处理能力对数据库中的邮件的事务操作在完成后必须马上或是说立即被记录在存储介质上见前面的事务持久性说明

3、灾难发生后使用数据库备份恢复必须要返回到灾难发生前一刻的数据库状态这是至关重要的

现在我们来更进一步的看一下 当用户要修改邮箱中的内容时被修改的内容首先被提取出来放到内存中实际的修改是发生在内存里的这是众所周知的当修改完成后这些内容必须被尽快写回存储介质这样才表示一个事务成功完成了。

从事务的描述中我们可以看到事务是具有原子特性的为了保证数据库的一致和完整事务必须全部成功或全部失败如果事务失败则必须回滚到事务开始的状态。而当邮件在内存中修改完成后此时事务并没有完成为什么呢 因为一旦系统崩溃这些修改就丢失了。所以要确保事务修改完成必须尽快将修改写回到数据库里去也就是硬盘上 。这也是事务的持久性要求。注意我们这里说的第一时间或是尽快是一个什么样的概念。如果我们直接修改EDB 文件 由于EDB文件比较大那么在硬盘上修改一个大文件就需要花费大量的时间在等待和寻找数据存储块上见操作系统原理 当系统出现高负载的繁忙状态时这将是一个非常大的瓶颈。也就无法

做到“尽快”了。那怎么办呢所以数据库系统使用了日志而日志通常很小EXCHANGE的日志只有5MB  向这些文件写入修改结果是很快速的 因此当内存的修改完成后这些结果就会立即写入日志中 以保证了事务的持久性。当成功写入日志后该事务就成功完成了现在在硬盘上了不会因为当机丢失了接下来 ESE引擎会在后台慢慢将这些日志里的修改记录写回真正的数据库里去这对用户来说已经不是那么重要了 这就是日志的第一个作用确保事务在第一时间尽可能快的保存到非易失存储器上提供了事务持久性支持

根据上面的藐视我们看到运行中的EXCHANGE数据库是由三个部分组成的

* 内存中已经完成处理还没有写会到日志里的内容Dirt page

*还没有写到数据库文件里的日志内容

* EDB和STM数据库文件

对于第一个部分一旦掉电就回丢失的是最不安全的。而对于第二部分的内容系统通过检查点文件CHK来标记哪些日志已经被写入数据库了而哪些还没有。 CHK文件类似一个指针。我们可以用“ES EUT I L /MK”来检查CHK文件里的内容在该命令的输出中的checkpoint:这样的东西就是检查点位置它表示E0x00008的日志的页面序号已经被成功写入数据库了。大家可以自己看看。

前面提到过 E XCHANGE系统在出现灾难时应能恢复到灾难发生前的时刻的状态。这是非常重要的。但即使是最勤快的管理员也只能在指定的预定时间内做系统备份而不可能时时刻刻的都在备份。那么在备份完成后到灾难发生之前的这段数据该如何保护呢是不是就任由它丢失呢显然是不可能的。那答案是什么呢就是日志文件。前面我们知道任何对数据库的更改都先写入日志里再由日志写入数据库这样我们只要找到日志文件就可以重新进行模拟的操作来完成备份后的数据库文件的更改了我们举个例子来看看

假设我们在凌晨3点完成了一次FULLBAC KUP备份完成后系统正常运行到下午4点的时候系统突然崩溃。管理员用凌晨3点的数据恢复了数据库那么从凌晨3点到下午4点这段时间的数据变更就只能依赖于日志了。当完成数据库恢复后系统会自动的跟踪到关联的日志文件如果发现有比当前数据库还新的日志存在系统就会自动的按照日志的顺序将更改写回到数据库中去。因此这样一来从凌晨3点到下午4点的数据变更就被完整的恢复了。这就是日志的第二个作用保证系统备份和恢复的完整性。当然前提是没有使用循环日志  看到了吧使用循环日志的危害是相当大的 比起你的数据来说多做几次备份不是没有意义的吧

说到这里有人可能要问如果数据库和日志同时损坏如何办答案是尽量避免这样的情况发生。首先数据库损坏的几率要大于日志另外微软建议将数据库和日志分别存储在不同的磁盘上要是这样还会同时坏那就没有办法了呵呵。 。对于管理员对日志文件