1.对现有的sg进行一次完整备份；
2.unmout、mount、unmout（检查整理前是否能正常mount、unmount）
3.对edb和stm文件进行文件级备份；
4.运行eseutil工具，使用参数 /k 对原有数据库进行checksum
5.使用参数 /d /p 对现有数据库进行脱机碎片整理，（不改写原库，产生临时新库）
6.对新产生的临时库进行checksum；
7.用新库的相关edb文件、stm文件覆盖原有库的相应文件；
8.重新mount、unmount、mount
9执行一次完全备份。
效果：
执行前priv库的edb文件1.8G，stm文件800M；整理后edb文件786M，stm文件118M；
pub库数字分别为：226M，272M，180M，28M；
客户端的速度有待验证。
心得：
1.临时文件最好指定路径存放，否则可能充满系统盘。
2.使用eseutil工具过程用，尽量不使用资源管理器实时观察临时库文件的大小，关乎整理结果是否出错和速度！！
我对priv库整理后，发现新库在checksum时出现2处错误（原库没有错），，后来再进行一次整理，发现速度很慢，，甚至我午饭回来还没有明显的进度！无奈cancel掉。
第3次，我关掉资源管理器（之前的整理我比较心急，盯住临时库文件，看着它增长
),发现这次速度很快，，仅用1041s就完成整理过程！！！而第1次，我要不停敲回车才能继续，并且耗时30分钟以上，第2次，我去了吃饭，回来根本没有明显进度，cancel了。第3次整理处理的库，顺利通过checksum！！！
所以，我初步总结原因是，不能实时监视临时库文件的增长，否则容易出校验错，而且速度奇慢，甚至需要敲回车键，进度才往前蠕动。
本人想向各位讨教的问题：
1.如果数据库真的经checksum后发现有错，如何处理？使用eseutil /p修理？
2.isinteg这个工具一般用来干啥？什么情况下使用？
1、临时库的存放地点默认是当前路径，就是启动ESEUTIL的目录，你可以将ESEUTIL的路径加入搜索路径PATH里，这样就可以在任何地方执行了。
2、数据库由于断电、日志文件满等都有可能出现校验和错误，此时可以使用/P参数修复。如一次不行，可进行多次。
3、ISINTEG是检查IS服务完整性的，在整理数据库后重新MOUNT以后，建议做一次。
刚刚完成了isinteg
1.unmount （注意，isinteg只能检查修复offline状态得DB）
2.isinteg －s servername －fix －test alltests
3.mount
4.restart is service.
修复了一些warnning