今天早上，store.exe模糊不清，这就需要重启Exchange服务器。 它恢复在线，没有任何错误或问题，所有事务日志成功重播，所有的商店正常安装。 对我来说，这只是随机崩溃之一。 然而，我们的顾问怀疑是由于其中一家商店的腐败造成的。 也许他是对的，因为他比我有更多的经验，但那不是重点。
为了解决可疑的错误，他计划运行一个ESEUTIL碎片整理（通过PerfectDisk）来修复它们，他声称这也将修复任何错误。
根据我的理解，碎片整理，validation和修复是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 Appl 0008: 69 00 63 00 61 00 74 00 icat 0010: 69 00 6f 00 6e 00 20 00 ion . 0018: 46 00 61 00 69 00 6c 00 Fail 0020: 75 00 72 00 65 00 20 00 ure . 0028: 20 00 65 00 78 00 73 00 .exs 0030: 70 00 2e 00 64 00 6c 00 p...dl 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. .in 0068: 20 00 6b 00 65 00 72 00 .ker 0070: 6e 00 65 00 6c 00 33 00 nel3. 0078: 32 00 2e 00 64 00 6c 00 2...dl 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 .fDe 00b8: 62 00 75 00 67 00 20 00 bug . 00c0: 30 00 20 00 61 00 74 00 0. .at 00c8: 20 00 6f 00 66 00 66 00 .off 00d0: 73 00 65 00 74 00 20 00 set . 00d8: 30 00 30 00 30 00 30 00 0.0.0.0. 00e0: 62 00 65 00 66 00 37 00 bef7. 00e8: 0d 00 0a 00 .... 如果在数据库中遇到页级损坏，使用eseutil的脱机碎片整理将失败。 您必须使用/p选项（rePair）来丢弃损坏的页面。
在逻辑级别上损坏数据（认为损坏数据库中的“数据”，而不是数据库的“结构”）不能由eseutil修复。 isinteg工具可以在Exchange 2007版本中的数据库中查找逻辑不一致。在Exchange 2010中， isinteg被replace为new-MailboxRepairRequest cmdlet（ 更多详细信息可在Exchange团队博客上find ）。
说了这么多，我很关心你的顾问的build议。 您是否从ESE或Exchange相关服务的应用程序事件日志中看到事件，指出任何数据库损坏？ 一般来说，Exchange不会“随机崩溃”，硬件驱动程序的问题或者硬件本身似乎是Exchange比Exchange问题更可能的原因。 此外，由于日志重播没有问题，我觉得有点不太可能，你正在采取页面级腐败。
最后，如果你正在进行页面级的腐败，只是清理腐败不是一个解决scheme。 你需要find引起腐败的根本原因（错误的硬件等），并消除它。 做其他事情只是暴露你持续的风险。
脱机碎片整理本身不是一个主要风险。 完成脱机碎片整理后，您必须立即进行完整备份，因为所有以前的增量备份和差异备份都无法恢复（因为新数据库就是这样一个全新的数据库）。 显然，在碎片整理期间，用户也无法访问您的服务器。
我会在今天上午详细研究发生的事情，并在开始花钱“修理”它之前，得出一个根本原因结论（或至less是一个非常可能的假设）。
我有一个最近的情况，一个Exchange Server 2003计算机不会采取VSS快照，并在尝试备份期间报告各种JET错误。 我select在另一台计算机上启动新的Exchange安装，将所有用户邮箱移动到新计算机上，然后删除原始服务器上有问题的数据库，并允许创build新的计算机。 在我们做了一些压力testing，并确认原来的服务器运行正常后，我们将所有的邮箱移回。 在描述的情况下（如果我有足够的事件日志消息，指示原始Exchange Server计算机的邮箱数据库中存在“损坏”），我更喜欢这种策略。
编辑：
您在上面发布的条目是Microsoftsearch（使Exchange数据库的全文索引）的Exchange提供程序中的一个错误。 我有兴趣从系统事件日志中看到更多事件以及紧接在这之前的任何事件。 您是否在任何服务器计算机的卷上拥有较低的磁盘空间状况？