Exchange 2010数据库损坏后的修复步骤

摘要：

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） 做了硬修复后的数据库，相比其他正常数据库，再次出现损坏的几率要大很多，因此需尽快创建新的数据库，将硬修复的数据库中的用户邮箱做迁移。