郁闷的一天.
有一台exchange server报磁盘控件满，删除一些无用的文件，再重新加载能正常使用，过一会儿又出现了存储无法加载的问题，手动加载提示"C1041737 错误，说此存储中的某个数据库文件的名称无效“，查微软的kb发现通常出现原因：一是磁盘问题，二是文件夹的权限问题，三可能是杀毒软件导致的。文件夹权限是不会有问题的，杀毒软件也可以排除，因为以前出现过杀毒软件干掉日志导致无法加载的情况，所以都在杀毒软件中排除了，最大的可能是磁盘问题，
使用chkdsk /f/r，到了第四阶段就死掉了，文件数不变，任务管理器中虽然有小的动静，但不像是在处理数据，我没有耐心等待下去，就关掉了。
根据以往的处理方法，删除所有log文件和检查点文件，删log文件的时候系统提示i/o错误，看来的确是磁盘问题导致的，不管了，使用eseutil /p修复，修复的前期都比较顺利，但是到了后来又出现了deleting unicode fixup table....，我是最怕这个错误，但现在没有办法只能等，看见一个网友留言：
I ran eseutil.exe /p on a EDB file that was 42,014,285,824 bytes (~ 39.1 GB) and it took 15370 seconds (4.27 hours). At least 4 hours of the 4.27 was on the "Deleting unicode fixup table." This was done on a Windows 2003 server with 4 GB RAM and an 8-drive RAID-5 SCSI configuration ... in case somebody else wants some additional info on how to calculate how many hours late you will be getting home tonight.
看来我也只能这样等了。
也太离奇了，居然我第二天早上上班的时候，文件还没有修复完毕，都十二小时了。本以为一个晚上肯定能好，早知道这样，应该按先“恢复服务，再恢复数据"的原则了。
只能等，虽然有电话催，总比再来十二小时好的多，想想我的 edb文件有60G，时间长点也是正常的。
终于见到了出现几个点的进度条，已经是到了吃中午饭的时间了，又一个上午过去了，加上昨天一个晚上都将近20个小时了，吃过饭过来终于看见修复成功了，不管他重新启动服务器。 再登录进去，系统好了。立即着手将那些邮件放在服务器的用客户端下载到本地去，看来不限制邮箱大小是不行了，有的邮箱居然都5G了。edb文件一大，备份还原速度都太慢。
看来对于修复过程中出现deleting unicode fixup table",除了耐心等待，没有别的方法。