C:\Program Files\Exchsrvr\BIN>eseutil /d
X:\Exchsrvr\Mdbdata\SGMSedb
/tX:\Exchsrvr\Mdbdata\SGMS_tempedb /o /p
命令會有如下的輸出
Initiating DEFRAGMENTATION mode
Database: F:\Exchsrvr\Mdbdata\SGMSedb
Streaming file: F:\Exchsrvr\Mdbdata\SGMSSTM
Temp Database: F:\Exchsrvr\Mdbdata\SGMS_tempedb
Temp Streaming file: F:\Exchsrvr\Mdbdata\SGMS_tempSTM
Defragmentation Status (% complete)
|||||||||||
Note:
It is REQUIRED that you immediately perform a full backup of this database If you restore a backup made before the defragmentation the database will be rolled back to the state it was in at the time of that backup
Operation completed successfully in seconds
碎片整理的實際時間取決於數據庫文件的大小在Exchange 中一般一小時可以處理~GB的數據在碎片整理完成後系統會根據制定的文件名生成兩個不含碎片的edb和stm文件
在把新的數據庫文件Mount之前需要確保其完整性我們要執行如下的命令
C:\Program Files\Exchsrvr\BIN>eseutil /g X:\Exchsrvr\Mdbdata\SGMS_tempedb /sX:\exchsrvr\mdbdata\SGMS_tempstm
其輸出如下
Microsoft(R) Exchange Server(TM) Database Utilities Version
Copyright (C) Microsoft Corporation All Rights Reserved
Initiating INTEGRITY mode
Database: privedb
Streaming file: privstm
Temp Database: TEMPINTEGEDB
Checking database integrity
Scanning Status (% complete)
|||||||||||
Integrity check successful
Operation completed successfully in seconds
此項操作也需要較長的時間一般的速度是GB每小時
文件改名把舊的edb文件和stm文件從mdbdata文件夾中移走把執行過碎片整理的臨時文件改為同舊的edb文件和stm文件相同的名字然後Mount數據庫
如果Mount數據庫失敗最快的恢復辦法就是把舊的edb文件和stm文件再復制到mdbdata文件夾Defrag過程中舊的edb文件和stm文件沒有被更改即使defrag失敗也可以恢復到defrag之前的狀態
關於碎片整理得更多細節我們可以參考下面的文檔
XADM: How to Defragment with the ESEUTIL Utility
如果避免Exchange Server的數據庫文件損壞
對於數據庫損壞的問題防患於未然要遠遠比事後亡羊補牢來的有效數據庫的損壞一般可以分為物理損壞和邏輯損壞
物理損壞往往是由磁盤介質控制卡等硬件設備的故障引起的這種類型的損壞都會引起數據丟失唯一的解決辦法就是從備份的磁帶進行恢復
Exchange Server為了確保數據的一致性會在向數據庫寫入內容時（寫入的單位是KB的頁面）把根據數據內容計算得出的校驗和跟實際的數據一並寫入當讀取時系統會重新計算校驗和並跟保存的校驗和進行比較如果這兩個值不同說明讀出的數據和當初寫入的數據相比已經發生了變化這種變化往往是由磁盤故障控制器總線傳輸故障等引起的為了排除干擾因素當校驗和不匹配的情況出現時Exchange Server會再次到磁盤上去讀取那個頁面如此循環次如果連續讀取次校驗和跟原始的值仍然無法匹配Exchange Server就會認為數據庫已經發生了物理損壞在事件日志中會有如下的內容被記錄下來
Event ID:
Source: EDB
Type: Error
Category: Database Page Cache
Description: MSExchangeIS (()) Direct read found corrupted page error ((:) () ) Please restore the database from a previous backup
另外當事件日志的錯誤描述中出現如下的代碼基本上也可以認定數據庫發生了物理損壞
(JET_errReadVerifyFailure)
The data read from disk is not the same as the data that was written to disk
(JET_errDiskIO)
The hardware device driver or operating system is returning errors
JET_errLogWriteFail
The log files are out of disk space or there is a hardware failure with the log file disk
數據庫的物理損壞往往會帶來數據丟失和Exchange Server停機等等損失我們可以采取下面的一些建議來避免物理損壞的發生
采用高質量的磁盤和磁盤控制系統對硬件RAID系統進行正確的配置
不要使用文件級別的工具或防病毒軟件掃描數據庫文件和日志文件
避免使用磁盤控制卡上的寫入緩存（Writeback caching）
定期地進行全備份全備份一方面保證了數據的安全另一方面也能及早地發現數據庫的物理損壞在執行全備份時備份程序會把數據庫的每一個頁面讀取出來並重新計算校驗和如果有損壞的頁面存在管理員可以及早的發現問題並采取行動
當物理損壞發生時我們可以采取如下的步驟來進行恢復
如果有全備份一定要先從備份進行恢復
在沒有備份的情況下可以使用Eseutil /p來進行手工的修復但這是不推薦的做法從備份恢復是最好的解決辦法
關於數據庫的物理損壞更詳細的內容請參考微軟知識庫文檔Understanding and analyzing and Exchange database errors這篇文章的代號是
另外一種常見的數據庫損壞是邏輯損壞數據庫的內容本身沒有問題但是一些內部的視圖關聯發生問題時就會發生邏輯損壞邏輯損壞的症狀往往表現為大部分用戶使用正常某些用戶在點擊特定的郵箱文件夾或者郵件時會發生死機等現象對於這種故障一般可以使用ISINTEG命令來進行修復
From:http://tw.wingwit.com/Article/os/fwq/201311/10245.html
