使用eseutil命令进行修复

  执行ESEUTIL /MH <数据库绝对路径>，查看state是 dirtyshutdown还是cleanshutdown.

1.如果是clean shutdown状态可以执行软修复

   注意：软恢复过程的一个基本假设是故障未移动、删除或破坏任何数据库文件或日志文件，管理员在故障之后也没有这样做。

   运行一遍exeutil /r,然后使用isinteg.exe修复Pub1和Priv1数据库  isinteg -s (servername) -fix -test alltests,重新启动信息存储服务，挂载数据库.

2.如果是dirtyshutdown状态需要执行硬修复。（更多的是这个状态）

   2.1  eseutil /r E01 /D /I

       即使运行硬修复也建议首先使用eseutil /r命令试图修复下逻辑错误。

TIPS:说一下软修复的一些事项：

1.软修复的一本基本要求是：{故障未移动、删除、或者破坏任何数据库文件或者日志文件，管理员在故障之后也没有这样做}。

2.参数介绍下

/R ：软修复参数

/E01:  日志记录文件名称，不能包含后缀。01是ex数据库创建的序号，例如，第一个数据库日志文件是E00.LOG,第二个数据库日志文件就是E01.LOG，以此类推。

  日志文件的名称在  安装目录下--》mailbox目录下---》数据库名称下面    找到！

/i:恢复的数据库处于非正常关机状态（Dirty shutdown状态），请使用此参数

/D:忽略数据库错误。

   2.2  eseutil /mh

        然后再次执行eseutil /mh <数据库句对路径>，进行状态的检查

   2.3  eseutil /p

        把数据库文件夹中所有的log、chk、temp.edb文件剪切到别的文件夹    然后执行 eseutil /p <数据库绝对路径>  命令直至修复完成。

{注意：也可直接进行ESEUTIL /P 修复，当尝试无法挂载时再移除log、chk、temp.edb等所有文件}

   2.4  eseutil /d

         执行eseutil /d <数据库绝对路径>进行碎片整理，如果不进行碎片整理可能导致数据库出现索引和空间分配错误。（生产环境建议执行，也可跳过）

   2.5  isinteg-s(servername)-fix-testalltests （可跳过,EX13\16也没测试此命令）

         此时应该能够正常挂载数据库了。为了在应用程序级别修复数据库执行上述命令，执行此命令数据库必须是离线状态，如果挂载了请卸除数据库。

isinteg 完成之后，应当报告数据库中有零个错误。如果错误计数大于零，请再次运行 Isinteg 直到计数变为零，或在后续运行中计数不再减少。如果无法让错误计数归零，挂在后建议进行数据库的迁移。