ESEUTIL已经过时了？

熟悉Exchange的人对ESEUTIL工具一定不会陌生，这是一个自Exchange4.0以来就一直广泛应用的命令行工具。这个工具现在是时候退出历史舞台了。

在他的时代里，Exchange服务器只能挂载一个数据库，硬件可靠性差，软件漏洞不断。如果不考虑数据丢失的情况，ESEUTIL确实每每都能简单粗暴地将数据库恢复到健康状态。

今天，ESEUTIL就像是个江湖郎中，对某些特定数据库“病症”经验丰富，能够迅速“治愈”并“疗效”显著，但对于新版本的新问题，你不会再求助于他。出于一项产品发展的角度，微软也不再推荐这一工具。但是依然有不少管理员认为，一旦数据库发生问题，尤其是健康性的问题，Eseutil依然是他们的首选甚至是唯一的排错工具。

今年是我参加工作的第9年，中文站成立的第7年。我在大三的时候去一家外资公司实习第一次接触到Exchange，那时的Exchange服务器只能挂载一个数据库，数据库的大小限制是16GB，这对于当时最大只能达到128GB的硬盘来说已经非常可观了，况且单用户的最大邮箱限制仅为50MB，以至于公司的有些部门每天都要归档邮件。

无论从磁盘负载还是网络带宽角度，这些限制对于服务器来说绝对是好事儿，直到你发现Exchange的数据库引擎并不是那么高效：它在管理空白页的时候非常凌乱，东一碎片西一碎片；在页面的释放与回收方面也很不理想，导致即便删除了邮件，页面依然被占用，进而数据库引擎不得不从文件系统中索取更多的磁盘空间。这就直接导致数据库臃肿，数据读写缓慢。再加上数据库还免不了收到物理或逻辑的损坏。物理损坏往往是存储控制器造成的；逻辑损坏往往是由于数据库本身，表现为应用日志中-1018，-1019，-1022等等的报错。

每每发生这种情况时，系统管理员就会通知用户说邮箱会暂停使用一段时间，然后在非工作时间冲一杯咖啡，熟练地敲击着ESEUTIL和ISINTEG各种命令和参数组合，此时，领导往往站在一旁对其技术水平大加赞赏。

说到ISINTEG，这个命令仅仅用来处理数据库的逻辑错误，譬如说事务日志的计数错误，它在Exchange2010时最终被微软弃用了。相较之下，ESEUTIL的功能强大得多，在日志连续的情况下，哪怕检查点文件丢失，校验失败，它都能手动填补数据库，使其恢复到最新状态。对于之前所说数据库引擎低效率问题，ESEUTIL可以手动地清理磁盘碎片，重置数据库空白页，从而压缩数据库容量，释放磁盘空间。

通常我们会使用ESEUTIL /D命令对数据库做离线碎片整理或ESEUTIL /P命令（也叫“硬恢复”）来挽救数据库于物理故障。两者的恢复速度都在2-3GB/小时左右；两者都要求目标磁盘的剩余空间至少是数据库大小的110%；另外在执行这两个命令前都建议备份一次数据库，执行之后再备份一次，因为通过ESEUTIL重建好的数据库与之前的数据库及事务日志就没有任何关联了。

那时不懂ESEUTIL的管理员是根本没法工作的。但是自打微软在1999年发布了Exchange2000之后，ESEUTIL的许多功能就开始被迅速削弱，除了用来转存数据库头文件（headers）的ESEUTIL /M命令。更好的编码避免了软件自身的bug，同时借助于自动在线碎片整理功能，数据库可以更好地重复利用释放的页面文件。现在的数据库有更少的空白页面,加上存储价格的锐减，离线碎片整理还有必要么？尤其在移动互联网时代对可用性的要求是极其苛刻的。几个小时的离线整理？你一定是在逗我。

Exchange 2010的DAG无疑是刺向ESEUTIL的又一把尖刀。多数据库副本以及自动页面修复功能根除了上文提到的-1018及类似的应用错误。Exchange2010之后一般只有微软的技术支持工程师建议并且他们有非常充足的理由，才会建议并指导你用ESEUTIL重建数据库。

现在微软面对数据库故障的最后一个办法是将邮箱迁移到新的数据库，这一来可以保证数据库的健康，二来可以避免系统宕机时间，这个方法即便是在用户层面感受到的影响也是微乎其微的，因为系统会分三次迁移数据，见下图。