ESEUTIL，2003的解药，2013的毒药

上个月小编发表了一篇关于摒弃ESEUTIL的文章（ESEUTIL过时了？），相信大家已经领会了其中精神。今天我们把这个话题再深入下去，对于Exchange2013的DAG的数据库，在使用ESEUTIL时则要考虑得更多。

众所周知，在DAG的各个数据库副本中，所有的EDB和事务日志都会在不同服务器的同一路径下进行同步。Replication服务会将事务日志复制到每台成员服务器然后Information Store服务保证所有的副本内容一致，以便可以快速无损地切换数据库的主动节点。

基于上述的共识，我们再来看看ESEUTIL是如何做碎片整理或重建数据库的：通过压缩空白页面在指定的磁盘路径下创建一个新的数据库文件，期间还会清理受损的页面，但不管做不做清理页面的工作，它的本质都是创建出一个新的数据库。

让我们假设老板交代了你一个任务，要求你对邮箱数据库进行碎片清理以释放一些磁盘空间。然后你就去上网找办法，在了解了ESEUTIL的所有参数和用法后，你信心十足地卸载了数据库。

虽然是在非工作时间，但是手机用户还是会抱怨邮箱连不上了，然后你凭借个人魅力很好地平抑了抱怨。接下来你使用ESEUTIL /D进行离线碎片整理，你很高兴地看到数据库正自动地压缩空间，等压缩完成后，你惊喜地发现通过ESEUTIL工具释放了100MB左右的磁盘空间。

然后按照网上的文档，我们把整理好的数据库Mount上线，用户可以恢复使用了，一切看似这么地美好知道你尝试激活其他数据库副本时。。。请看以上的EAC截图，或者Active Manager在当前活动数据库不可用时自动切换也会失败，这个时候你就一边开始查日志一边向老板抱怨DAG是多么不靠谱的东西！

搜集日志的结果无外以下几个错误：

The Exchange store database <DB> copy on this server appears to be inconsistent with the active database copy or is corrupted (事件1004 — 如上图所示)
An Active Manager operation failed withMapiExceptionJetErrorAttachedDatabaseMismatch. Unable to mount database.
Information Store (PID) <DB>: database recovery/restore failed with unexpected error -1216 (事件454)
Database recovery failed with error -1216 because it encountered references to a database which is no longer present (事件494)
An error occurred while trying to select a database copy for possible activation (事件4087).
The following error occurred while starting database <DB>: 0xfffffb40. Failed to configure MDB (事件9519)

你猜测问题的原因可能是是你新挂载的数据库和其他副本的ID不一致，导致副本无法同步。是的，ESEUTIL创建的新数据库使用新的识别号，与之前的识别号没有任何关系。

通过ESEUTIL /MH命令可以查看数据库的签名。这时你又需要把数据库卸载以检查状态，但这次老板给你的时间不会太多。