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

PlanB Windows评论4,388阅读模式

摘要:

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

weinxin
我的微信
我的微信
微信扫一扫
 
PlanB
  • 本文由 PlanB 发表于 2020年11月4日 23:39:10
  • 转载请务必保留本文链接:https://kper.net/847.html
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: