浅谈Exchange Server邮件存储系统-原理篇(2)

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.当灾难发生时，使用数据库的备份恢复必须要返回到灾难发生前一刻的数据库状态。 现在我们更进一步的来看一下，当我要修改邮箱中的内容时，被修改的内容首先被读取出来放到内存中。实际的修改发生在内存中，当修改完成后，这些内容必须被写回存储介质，才能表示一个修改成功地完成了。 对于这样的修改过程，在数据库级别上，我们叫做一个“事务”。我们知道，为了确保数据库的完整性和一致性，事务的操作是“原子级别”的。如果一个事务成功，那么标志着他所作的改变被永久的保存下来了；如果一个事务失败，系统必须回到事务开始之前的状态。 当系统在内存中完成修改时，事务并没有完成。如果这个时候宕机，数据库中保存的仍然是没有更改的内容。那么，怎么样确保在内存中完成的修改能够在第一时间写入到数据库呢（以达到数据库事务持久性的要求）？注意，这里的要是第一时间，也就是越快越好。如果我们直接向edb文件写入，无法做到最快，因为，edb 文件通常都很大，I/O系统在对大的文件进行随机写入操作时，会花费大量的时间在等待磁盘查找到合适的磁道和扇区，当系统繁忙时，这将会是一个瓶颈。因此，数据库系统使用日志文件，当内存中的更改完成后，首先写入到日志文件中。日志文件的尺寸很小，写入性能要远远优于庞大的edb文件。在写入完成后，事务也随之成功的保存在存储介质上了。Exchange Server 的数据库引擎会在后台把Log文件中的内容写入到数据库中，因为此时事务操作已经完成，即使此时掉电或者宕机，也不会使完成的事务遗失。这是日志文件的第一个作用：确保事务能够在第一时间保存到非易失存储介质上。（提供持久性Durable支持） 根据上面的描述，我们知道在运行中的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. 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）的编号。 下面我们再看一下日志文件对系统备份和恢复的作用。 前面提到过，Exchange Server要求在灾难发生后能够恢复到灾难发生前一刻的状态。对于一般的系统，我们总是每周或者每天进行备份，那么，在备份之后和灾难发生之前这段时间的数据如何保护？答案是日志文件。我们知道，对于数据库的任何更改，都会先被写入到日志文件，然后再由日志文件更新到数据库中。我们现在假设有这样一套系统，在每天的3:00 AM进行备份，备份完成后，系统正常运转。如果在中午12:00的时候系统出现故障，管理员用3:00AM的磁带恢复了系统，那么，从3:00AM到 12:00AM这段时间的数据，将由log文件来填补的。具体的情况是，当3:00AM的备份恢复完成后，Exchange Server会自动扫描到跟这个store相关联的日志文件夹，如果发现有比当前数据库还新的日志存在，Exchange Server会自动把这些日志按照顺序写入到数据库中。因此，从3:00AM到12:00AM这段时间对数据库所作的更改，可以被恢复回来。这是日志文件第二个重要的作用。（前提是没有开启循环日志功能） 有人可能会问，如果数据库文件和日志文件同时损坏怎么办？答案是这样的：避免这种情况发生。首先，数据库文件损坏的概率要远远大于日志文件，另外，微软推荐的做法是把数据库文件和日志文件分别放置在不同的磁盘上。我们会在下一期的文章中着重讨论这个问题。 管理员针对日志文件的抱怨是，这些文件会每天不断的增长，大量消耗硬盘空间。对于这个问题，唯一合理的解决办法是：定期的做针对Storage Group的全备份或增量备份。因为Exchange Server会在全备份或增量备份完成后把这次备份之前产生的Log文件全部删除。很多管理员手动的删除日志文件，或者启动“循环日志”来减少对硬盘空间的消耗，这都是不正确的做法。残缺不全的日志文件会使系统在进行备份恢复的时候无法还原到最近的状态。如果你的系统是一周做一次全备份，而你碰巧又在备份后删除了一些日志文件，那么你就有可能在需要恢复的时候丢失备份以后的数据。记住，数据总是比磁盘空间更宝贵。 ESE数据库引擎以及Information Store服务的启动和关闭 在ESE 引擎加载数据库文件时，它会检查数据库文件的一个特殊标志位。这个标志位保存了数据库文件上次是否被正常关闭。这个状态由“ Consistent”或“ Inconsistent”来表示。对于一个正常关闭的数据库文件，所有在Log文件和内存中的内容都应该已经提交到数据库文件中，只有在这个时候，数据库才会被标记为“ Consistent”。有一点需要注意，在运行中的数据库，它的状态一定是“ Inconsistent”，因为在Log文件中肯定还有没提交到数据库文件内容。对于一个已经关闭并且状态被标示为“ Inconsistent”的数据库，并不意味着这个数据库库文件损坏了，“ Inconsistent”只是表示，还有未曾写入到数据库文件的内容保存在Log文件中。 使用命令 ESEUTIL /MH可以查常看数据库的关闭状态。

C:/.../Exchsrvr/BIN> ESEUtil /mh “C:/.../Exchsrvr/mdbdata/priv1.edb” Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0 Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved. Initiating FILE DUMP mode...      Database: C:/program files/exchsrvr/mdbdata/priv1.edb File Type: Database Format ulMagic: 0x89abcdef Engine ulMagic: 0x89abcdef Format ulVersion: 0x620,9 Engine ulVersion: 0x620,9 Created ulVersion: 0x620,9 DB Signature: Create time:03/28/2004 20:26:24 Rand:6536656 Computer: cbDbPage: 4096 dbtime: 63139 (0-63139) State: Clean Shutdown     <-----表示数据库关闭时的状态 Log Required: 0-0 Streaming File: Yes Shadowed: Yes Last Objid: 574      …<略> …     Operation completed successfully in 1.391 seconds.

State字段的“Clean Shutdown”表示数据库处在Consistent状态。 当ESE 加载数据库文件时，对于“Consistent”的数据库文件，它直接Mount其中的Store；对于“In consistent”的数据库文件，ESE将执行称之为“Soft Recovery”的过程，在这个过程中，未及时提交进数据库文件的日志内容将被写入数据库。当所有的日志都写入完毕，数据库才会被标记为“ Consistent”状态，然后正常加载。 Soft Recovery开始的时候，ESE会根据check point文件所指向的位置来进行Log文件的写入(如果check point文件也损坏或者不存在，那么数据库就从最旧的Log文件开始)。当ESE从Log文件向Store写入数据时，它会根据dbTime这个时间戳来决定是否需要把Log文件写入到数据库。

原文出处http://bbs.5dmail.net (中文名称:5Dmail邮件资讯网)