|
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命令来进行修复 |
