Exchange 存储的 ESEUTIL 碎片整理是否也对其执行完整性检查/修复？

Question

今天早上早些时候，store.exe 以某种方式模糊不清，这需要重新启动我们的 Exchange 服务器。它重新上线，没有错误或问题，所有事务日志都成功重放，并且所有商店都正常安装。对我来说，这只是随机崩溃之一；然而，我们的顾问怀疑这是由其中一家商店的腐败造成的。也许他是对的，因为他的经验比我多得多，但这不是重点。

为了修复可疑的错误，他计划运行 ESEUTIL 碎片整理（通过 PerfectDisk）来修复它们，他声称这也将修复存在的任何错误。

据我了解，碎片整理、验证和修复是 3 个独立的操作，碎片整理并不意味着任何类型的完整性检查。这样对吗？在可能损坏的数据库上运行直接碎片整理是否有任何危险？

编辑：

这是事件日志中的第一个错误，它表明我们遇到的问题的开始。有谁知道它可能表示什么？

Event Type: Error
Event Source:   Microsoft Exchange Server
Event Category: None
Event ID:   1000
Date:       11/23/2011
Time:       8:15:47 AM
User:       N/A
Computer:   SERVER
Description:
Faulting application exsp.dll, version 6.5.7638.1, stamp 430e735b, faulting module kernel32.dll, version 5.2.3790.4480, stamp 49c51f0a, debug? 0, fault address 0x0000bef7.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00   A.p.p.l.
0008: 69 00 63 00 61 00 74 00   i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00   i.o.n. .
0018: 46 00 61 00 69 00 6c 00   F.a.i.l.
0020: 75 00 72 00 65 00 20 00   u.r.e. .
0028: 20 00 65 00 78 00 73 00    .e.x.s.
0030: 70 00 2e 00 64 00 6c 00   p...d.l.
0038: 6c 00 20 00 36 00 2e 00   l. .6...
0040: 35 00 2e 00 37 00 36 00   5...7.6.
0048: 33 00 38 00 2e 00 31 00   3.8...1.
0050: 20 00 34 00 33 00 30 00    .4.3.0.
0058: 65 00 37 00 33 00 35 00   e.7.3.5.
0060: 62 00 20 00 69 00 6e 00   b. .i.n.
0068: 20 00 6b 00 65 00 72 00    .k.e.r.
0070: 6e 00 65 00 6c 00 33 00   n.e.l.3.
0078: 32 00 2e 00 64 00 6c 00   2...d.l.
0080: 6c 00 20 00 35 00 2e 00   l. .5...
0088: 32 00 2e 00 33 00 37 00   2...3.7.
0090: 39 00 30 00 2e 00 34 00   9.0...4.
0098: 34 00 38 00 30 00 20 00   4.8.0. .
00a0: 34 00 39 00 63 00 35 00   4.9.c.5.
00a8: 31 00 66 00 30 00 61 00   1.f.0.a.
00b0: 20 00 66 00 44 00 65 00    .f.D.e.
00b8: 62 00 75 00 67 00 20 00   b.u.g. .
00c0: 30 00 20 00 61 00 74 00   0. .a.t.
00c8: 20 00 6f 00 66 00 66 00    .o.f.f.
00d0: 73 00 65 00 74 00 20 00   s.e.t. .
00d8: 30 00 30 00 30 00 30 00   0.0.0.0.
00e0: 62 00 65 00 66 00 37 00   b.e.f.7.
00e8: 0d 00 0a 00               ....    

Answer 1

eseutil如果遇到数据库中的页面级损坏，使用脱机碎片整理将失败，因为。您必须使用/p选项 (rePair) 来丢弃损坏的页面。

逻辑级别的数据损坏（认为损坏数据库中的“数据”，而不是数据库的“结构”）无法通过eseutil. 该isinteg工具可以在 Exchange 2007 之前的版本中查找数据库中的逻辑不一致。在 Exchange 2010 中，isinteg已替换为new-MailboxRepairRequestcmdlet（更多详细信息可在 Exchange 团队博客上找到）。

说了这么多，我很担心你的顾问的建议。您是否在来自 ESE 或 Exchange 相关服务的应用程序事件日志中看到表明任何数据库损坏的事件？通常，Exchange 不会“随机崩溃”，硬件驱动程序或硬件本身的问题似乎比 Exchange 问题更可能是原因。此外，由于日志重播没有问题，我发现您不太可能进行页面级损坏。

最后，如果您正在处理页面级损坏，仅清除损坏不是解决方案。您需要找到导致损坏的根本原因（硬件故障等）并消除它。做任何其他事情只会让您面临持续的风险。

离线碎片整理本身并不是主要风险。您必须在离线碎片整理完成后立即进行完整备份，因为无法恢复之前的所有增量和差异备份（因为新数据库只是一个全新的数据库）。显然，在碎片整理期间，用户也将无法访问您的服务器。

在我开始花钱“修复”它之前，我会详细研究今天早上发生的事情并得出根本原因结论（或至少是一个非常可能的假设）。

我最近遇到了一个案例，Exchange Server 2003 机器在尝试备份期间不会拍摄 VSS 快照并报告各种 JET 错误。我选择在另一台机器上启动一个新的 Exchange 安装，将所有用户邮箱移到新机器上，然后删除原始服务器上有问题的数据库并允许创建一个新的。在我们进行了一些压力测试并验证原始服务器运行正常后，我们将所有邮箱移回了原位。在您所描述的情况下，我更喜欢这种策略（如果我有足够的事件日志消息表明原始 Exchange Server 计算机的邮箱数据库中存在真正的“损坏”）。

编辑：

您在上面发布的条目是 Microsoft 搜索的 Exchange 提供程序（生成 Exchange 数据库的全文索引）中的一个错误。我有兴趣从系统事件日志中查看更多之后发生的事情，以及紧接此事件之前发生的任何事件。您是否有任何服务器计算机卷上的磁盘空间不足？