故障现象： 今天在检查邮件归档Server时（windows 2008 SP1+Exchange 2007 SP2)，看到MailArchiva最新的邮件是20号7点的，今天已经24号，然后接下来检查Mailarchiva,均未发现异常，难道不是MailArchiva的问题，因为一直担心是它的问题，因为它是开源的软件（基于Linux)的免费软件，把其debug的log看了一遍，也无异常，难道是EX的问题，因为平时都是同事去打理Mail Serve的，所以基本都不去看它，这时同事也跑过来说，今天EX备份完后示：“应用程序将不能用于从备份中恢复，组件 Microsoft Exchange Server \ Microsoft Information Store\MAIL\f1e36eba-b0a9-4a0e-9d4b-b1a6220ee839的一致性检查失败。将无法在“2010/7/24 8:09:48”完成的备份中获得应用程序“Exchange”

             然后我在日志中看一下，发现ESE 474错误，具体描述如下：

 “MSExchangeIS (5800) First Storage Group: 由于页校验和不匹配，从文件“E:\Program Files\MicrosoftExchange Server\Mailbox\First Storage Group\Mailbox Database.edb”中读取的数据库页(偏移量: 22752239616 (0x000000054c23a000)，数据库页 2777372 (0x2A611C)，字节数: 8192 (0x00002000))验证失败。校验和应该是 3888236000516024956 (0x35f5ca0aada4aa7c)，而实际是 11928722210467201 (0x002a611c11faad81)。读取操作将失败，出现错误 -1018 (0xfffffc06)。如果此情况再次出现，请用以前的备份还原数据库。此问题可能是由于硬件故障引起的。有关进一步帮助诊断该问题的信息，请与硬件供应商联系。有关详细信息，请单击 http://www.Microsoft.com/contentredirect.asp。
          474错误MS的说法是：“(JET_errReadVerifyFailure）-1018年错误更频繁地看到，指示的 Exchange 数据库已遭受文件系统级别的损坏。磁盘子系统中的问题被引起此错误。由有故障的磁盘驱动器、 过期或不兼容的磁盘驱动器的固件或固件过期或不兼容的控制器，则可能导致在磁盘子系统问题。有时，磁盘驱动器子系统组件周围太多散热可能导致此错误。损坏可能发生到 Exchange 数据。”

         磁盘系统的错误，难道是我的HD有问题？我的MAIL SERVER上了五块HD，两块做RAID 1，三块做RAID5，我们用户不多，也只有100多个用户，EX的Database也就30G左右，查了一下硬件系统，HD并无问题，备份完后有出错说是一致性检查失败，所以就马上对Database进行了一次一致性检查:

EX一致性检查

果然发现了问题 “ERROR: page 2777372 checksum failed ( 0x35f5ca0aada4aa7c / 0x002a611c11faad81 )” ，原来这个地方就是问题所在啦，知道问题出在哪里就好办啦，根据MS的解决方法基本上是比较恐怖，他的建议是把现的用户重新全部移到另外一个好的数据库中去，第二是用原来的备份进行复原，感觉这两方法就有点误导人，如果这么干下去的话，那就够你受的，如果你用户成千上万的话怎么办，数据库大的话要消耗很多时间，像我30来G的数据库，弄不好就一上午，仔细想一想，只是数据库的不一致性，既然硬件存储系统没有问题，那也未必就要按此方法进行，依过去的经验：

        1、对数据库做一次整理，所谓整理也就是离线整理，离线整理首先要umount数据库，停掉HUB Transport Service,执行Eseutil /d  "Mailbox Database.edb"这会花比较长的时间，取决你的数据库的大小，我的花了一个多小时，完成之后，就要看第二点啦。

       2、离线整理之后，再度执行Eseutil /k  "Mailbox Database.edb",一切OK，已经没有ERROR的信息，再把HUB Transport service起起来，然后马上进行一次备份，结果也是备份成功，无错误提示。再回到Mailarchiva系统上，发现OK啦，邮件已经在慢慢收啦，想起来为什么Mailarchiva收不下Mail啦，因为日志中显示“数据库页 2777372 (0x2A611C)，字节数: 8192 (0x00002000))验证失败。校验和应该是 3888236000516024956 (0x35f5ca0aada4aa7c)，而实际是 11928722210467201 (0x002a611c11faad81)。读取操作将失败，因为我是在EX上设定所有的进行MAIL会先记帐一个专门的信箱帐号里，由于几天的MAIL没有push到mailarchiva上，里面已经积聚了大量的邮件，恰好发生错误的地方恰好在记帐信箱的数据段上，导致Mailarchiva无法从其读到数据，故无法下载邮件。

       最后总结到，因为从MAIL SERVER架起来之后，也没有对数据库做过离线的处理，运行一年多啦，数据库每天24小时不断进行频繁的读写操作，加上同事每次备份的时候都在白天邮件使用的高峰期，因此长时间的读写有可能就造成数据库的逻辑“混乱”，事实并不是物理性的损坏，所以对其只要加其软处理，类似于HD的“碎片整理”，使一些紊乱的数据重新排列，修正其中的逻辑性错误。