ESEUTIL,2003的解药,2013的毒药

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

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

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

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

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

ActivateFailure1

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

Event1004

 

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

  • 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命令可以查看数据库的签名。这时你又需要把数据库卸载以检查状态,但这次老板给你的时间不会太多。

ESEUTIL-MH

可以看到输出中有DB Signature项,Rand号1179680486就是当前的数据库识别号,这显然和先前的识别号不同,这就是导致副本挂载不上的原因。

当ESEUTIL修复后的数据库挂载上线后,ActiveManager会试图检查其他副本的状态。在这个过程中,AM会验证各个数据库的一致性,就是这个时候AM连同DAG崩塌了,此时除了在线的修复后的数据库,其他的数据库副本全部失效。

此时为使副本数据库达到一致性,只能通过Update-MailboxDatabaseCopy加DeleteExistingFiles参数将原来的MDB连同事务日志从副本位置移除,同时重新初始化数据库副本,当然这在目标数据库只有几个G时不会太费时,但如果你有几百G的数据库,呵呵。。

ESEUTIL诞生于上个世纪,在当时数据库可用性不是很高的背景下,它可以非常简单粗暴地还原数据库而为人所熟知。时过境迁,在Exchange2010及Exchange2013当道的今天,数据库的高可用性已经是部署系统的前提条件,这样的一款离线工具是时候退出历史舞台了。

李 章毅
Exchange MVP

李 章毅

找张正经又不装逼的照片挺难的。。。
李 章毅
Exchange MVP
发布于: 浏览:5517 次

现有 2 条评论

  1. 游客 2015年9月1日 下午5:38

    技术变化快,也要跟着一起进步,无止境啊。。。

    回复
  2. 游客 2016年7月7日 上午9:07

    eseutil退出了,谁来接替它的工作呢。

    回复

欢迎参与到我们的技术讨论,问题和分享都可以。