今天早些時候，store.exe 以某種方式出現問題，需要重新啟動我們的 Exchange 伺服器。它重新上線，沒有錯誤或問題，所有交易日誌都成功重播，並且所有儲存都正常安裝。對我來說，這只是隨機崩潰之一；然而，我們的顧問懷疑這是由其中一家商店的腐敗造成的。也許他是對的，因為他比我有更多的經驗，但這不是重點。
為了修復可疑的錯誤，他計劃運行 ESEUTIL defrag（透過 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 ....
答案1
eseutil如果遇到資料庫中的頁級損壞，離線碎片整理將會失敗，因為。您必須使用/p選項（修復）來丟棄損壞的頁面。
邏輯層級的資料損壞（認為是資料庫中「資料」的損壞，而不是資料庫「結構」的損壞）無法通過 修復eseutil。該工具可以isinteg在 Exchange 2007 版本之前尋找資料庫中的邏輯不一致問題。isintegnew-MailboxRepairRequest有關更多詳細信息，請訪問 Exchange 團隊博客）。
話雖如此，我還是擔心你顧問的建議。您是否在 ESE 或 Exchange 相關服務的應用程式事件日誌中看到表明任何資料庫損壞的事件？一般來說，Exchange 不會“隨機崩潰”，硬體驅動程式或硬體本身的問題似乎比 Exchange 的問題更可能是原因。此外，由於日誌重播沒有問題，我發現您不太可能發生頁面級損壞。
最後，如果您要進行頁面級損壞，僅清理損壞並不是解決方案。您需要找到導致損壞的根本原因（有故障的硬體等）並消除它。做任何其他事情只會讓你面臨持續的風險。
離線碎片整理本身並不是主要風險。離線碎片整理完成後必須立即進行完整備份，因為之前的所有增量備份和差異備份都無法恢復（因為新資料庫就是一個全新的資料庫）。顯然，在碎片整理期間，使用者也將無法存取您的伺服器。
在我開始花錢「修復」它之前，我會詳細研究今天早上發生的事情並得出根本原因的結論（或至少是一個非常可能的假設）。
我最近遇到一個案例，一台 Exchange Server 2003 電腦無法拍攝 VSS 快照，並在嘗試備份期間報告各種 JET 錯誤。我選擇在另一台電腦上啟動新的 Exchange 安裝，將所有使用者郵箱移至新計算機，然後刪除原始伺服器上有問題的資料庫並允許建立新資料庫。在我們進行了一些壓力測試並驗證原始伺服器正常運作後，我們將所有郵箱移回原處。在您所描述的情況下，我更喜歡該策略（如果我有足夠的事件日誌訊息表明原始 Exchange Server 電腦的郵件資料庫中存在真正的「損壞」）。
編輯：
您上面發布的條目是 Microsoft 搜尋的 Exchange 提供者（它為 Exchange 資料庫建立全文索引）中的錯誤。我有興趣了解更多之後發生的事情，以及系統事件日誌中緊接在此事件之前的任何事件。伺服器電腦的任何磁碟區上是否出現磁碟空間不足的情況？
答案2
ESEUTIL 碎片整理並非專門用於廣泛的 Exchange 資料庫修復。碎片整理功能是透過建立新的壓縮資料庫檔案來回收資料庫中的可用空間並優化資料庫效能。
當您執行碎片整理時，當發現任何不一致或問題時，它還可能會對資料庫執行某些修復。這是整體碎片整理過程的一部分，可以修復小問題。
如果您的 Exchange Server 資料庫已損壞，建議先執行 ESEUTIL /mh 指令來檢查資料庫的完整狀態。如果您發現，資料庫處於髒狀態。稍後，您可以根據資料庫損壞情況使用 ESEUTIL /P 或 ESEUTIL /R 命令。確保在嘗試任何修復作業之前已備份資料庫。
我建議諮詢 Microsoft 支援人員以確保採取正確的復原步驟。
您可以參考以下微軟文章：