Exchange 2003 数据库edb文件损坏后的修复步骤

摘要：
Exchange数据库作为承载用户邮箱的核心组件，其重要性不言而喻。数据库一旦卸载，其承载的所有邮箱将无法工作，通常引起卸载的原因有很多种，此次我们所要探讨的是数据库损坏这种极端情况。
可能你会说，有备份做保证，损坏又何妨。但是，你必然不能忽视一个问题，即还原后的数据库与原数据库存在一定的差异。因此，我们不推荐数据库损坏后第一时间还原。如果故障发生在非工作时间，比如晚上或周末，建议优先尝试数据库的修复。
正文：
笔者最近就遭遇了一起数据库损坏的故障。为此，将处理的思路分享给大家。
1. 事件描述
磁盘逻辑错误（通过系统NTFS日志可以分析）导致2个数据库无法装入，影响200多用户；
在此故障发生之前因为管理员疏忽，数据库的副本状态一直不正常，所以无法在故障发生时激活副本；
2. 处理思路
通常解决这种问题，我们需要做以下操作：
1） 检查数据库的状态:
eseutil.exe /mh “数据库EDB文件全路径”
Eseutil /M 文件转储模式
http://technet.microsoft.com/zh-cn/library/aa997795(v=exchg.65).aspx
如果发现数据库为“Dirty Shutdown”状态，需要修复该数据库。而且通常这种状态，通过“eseutil /r” 软修复是不能修复数据库的，而需要硬修复。
2） 需要硬修复该数据库，通过以下命令：
eseutil.exe /P “数据库EDB文件全路径”
Eseutil /P 修复模式
http://technet.microsoft.com/zh-cn/library/aa996773(v=exchg.65).aspx
如何在各种情况下运行 Eseutil /P（修复）
http://technet.microsoft.com/zh-cn/library/aa997215(v=exchg.65).aspx
3） 同时做完硬修复后，建议做以下两个操作完成整个修复的操作：
在 /D 模型下运行 Eseutil，以完整地重建索引并对数据库进行碎片整理
eseutil.exe /d “数据库EDB文件全路径”
如何运行 Eseutil /D（碎片整理）
http://technet.microsoft.com/zh-cn/library/aa995748(v=exchg.65).aspx
然后运行 ISInteg，以便在应用程序级别修复数据库
isinteg -s “服务器名称” -fix -test alltests
注意: 执行该命令后需选择需要修复的数据库，该数据库必须是卸载状态的（offline）。
Isinteg.exe 工具的 Exchange 命令行参数
http://support.microsoft.com/kb/301460/zh-cn
4） 执行完以上步骤后，装入数据库。
3. 特别注意
此次执行以上操作并非一帆风顺，在第二步eseutil.exe /P过程中遇到阻碍，执行命令不成功，报错如下：
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Bin>eseutil /p I:\Mailbox\db01.edb
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.01
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating REPAIR mode...
Database: I:\Mailbox\db06.edb
Temp. Database: TEMPREPAIR8168.EDB
Operation terminated with error -1032 (JET_errFileAccessDenied, Cannot access file, the file is locked or in use) after
10.31 seconds.
经过一番排查与分析，发现问题在于
1） 因执行的命令在C盘，而在修复过程中会产生临时文件，如果不为此临时文件指定路径，将默认存放在执行的命令所在位置
2） Windows Server 2008默认对C盘进行了保护，因此需将eseutil.exe拷贝至其他分区后执行。
4. 总结
1） 日常巡检/监控很重要。如果此次数据库副本状态是正常的，则不至于如此被动；
2） 对原理理解很重要。Eseutil /p是对数据库做硬修复，但是在修复过程中会产生临时文件，且与数据库大小相当，因此需要注意磁盘空间是否足够。同时也需要注意当前用户是否有在此路径下创建文件的权限；
3） 数据库损坏的根源在磁盘逻辑错误导致，因此仅仅修复数据库，不能避免后续问题再次发生。所以还需建议客户尽快修复磁盘故障；
4） 做了硬修复后的数据库，相比其他正常数据库，再次出现损坏的几率要大很多，因此需尽快创建新的数据库，将硬修复的数据库中的用户邮箱做迁移。