Exchange Server邮件存储系统-操作篇

　　C:\Program Files\Exchsrvr\BIN>eseutil /d

　　X:\Exchsrvr\Mdbdata\SG1MS1.edb

　　/tX:\Exchsrvr\Mdbdata\SG1MS1_temp.edb /o /p

　　命令会有如下的输出：

　　Initiating DEFRAGMENTATION mode...

　　Database: F:\Exchsrvr\Mdbdata\SG1MS1.edb

　　Streaming file: F:\Exchsrvr\Mdbdata\SG1MS1.STM

　　Temp. Database: F:\Exchsrvr\Mdbdata\SG1MS1_temp.edb

　　Temp. Streaming file: F:\Exchsrvr\Mdbdata\SG1MS1_temp.STM

　　Defragmentation Status (% complete)

　　0 10 20 30 40 50 60 70 80 90 100

　　|-----|-----|-----|-----|-----|-----|------|------|------|------|

　　.................................................................................

　　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 13.110 seconds.

　　碎片整理的实际时间取决于数据库文件的大小，在Exchange 2000中，一般一小时可以处理7~10GB的数据。在碎片整理完成后，系统会根据制定的文件名生成两个不含碎片的edb和stm文件。

　　5.在把新的数据库文件Mount之前，需要确保其完整性，我们要执行如下的命令

　　C:\Program Files\Exchsrvr\BIN>eseutil /g X:\Exchsrvr\Mdbdata\SG1MS1_temp.edb /sX:\exchsrvr\mdbdata\SG1MS1_temp.stm

　　其输出如下：

　　Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0

　　Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

　　Initiating INTEGRITY mode...

　　Database: priv1.edb

　　Streaming file: priv1.stm

　　Temp. Database: TEMPINTEG3976.EDB

　　Checking database integrity.

　　Scanning Status (% complete)

　　0 10 20 30 40 50 60 70 80 90 100

　　|-----|-----|-----|-----|-----|-----|------|------|------|------|

　　.................................................................................

　　Integrity check successful.

　　Operation completed successfully in 9.62 seconds.

　　此项操作也需要较长的时间，一般的速度是10GB每小时。

　　6.文件改名。把旧的edb文件和stm文件从mdbdata文件夹中移走。把执行过碎片整理的临时文件改为同旧的edb文件和stm文件相同的名字。然后Mount数据库。

　　7.如果Mount数据库失败，最快的恢复办法就是把旧的edb文件和stm文件再复制到mdbdata文件夹。Defrag过程中，旧的edb文件和stm文件没有被更改，即使defrag失败，也可以恢复到defrag之前的状态。

　　关于碎片整理得更多细节，我们可以参考下面的文档：

　　192185 XADM: How to Defragment with the ESEUTIL Utility

　　如果避免Exchange Server的数据库文件损坏

　　对于数据库损坏的问题，防患于未然要远远比事后亡羊补牢来的有效。数据库的损坏一般可以分为物理损坏和逻辑损坏。

　　物理损坏往往是由磁盘介质、控制卡等硬件设备的故障引起的。这种类型的损坏都会引起数据丢失，唯一的解决办法就是从备份的磁带进行恢复。

　　Exchange Server为了确保数据的一致性，会在向数据库写入内容时(写入的单位是4KB的页面)，把根据数据内容计算得出的校验和跟实际的数据一并写入。当读取时，系统会重新计算校验和，并跟保存的校验和进行比较，如果这两个值不同，说明读出的数据和当初写入的数据相比，已经发生了变化。这种变化往往是由磁盘故障、控制器总线传输故障等引起的。为了排除干扰因素，当校验和不匹配的情况出现时，Exchange Server会再次到磁盘上去读取那个页面，如此循环16次。如果连续读取16次，校验和跟原始的值仍然无法匹配，Exchange Server就会认为数据库已经发生了物理损坏。在事件日志中，会有如下的内容被记录下来：

　　Event ID: 23

　　Source: EDB

　　Type: Error

　　Category: Database Page Cache

　　Description: MSExchangeIS ((455)) Direct read found corrupted page error -1018 ((1:251563) (0-2295758), 251563 379225672 381322824). Please restore the database from a previous backup.

　　另外，当事件日志的错误描述中出现如下的代码，基本上也可以认定数据库发生了物理损坏：

　　-1018 (JET_errReadVerifyFailure)

　　The data read from disk is not the same as the data that was written to disk.

　　-1022 (JET_errDiskIO)

　　The hardware, device driver, or operating system is returning errors.

　　-510 JET_errLogWriteFail

　　The log files are out of disk space or there is a hardware failure with the log file disk.

　　数据库的物理损坏往往会带来数据丢失和Exchange Server停机等等损失。我们可以采取下面的一些建议来避免物理损坏的发生：

　　1.采用高质量的磁盘和磁盘控制系统，对硬件RAID系统进行正确的配置。

　　2.不要使用文件级别的工具或防病毒软件扫描数据库文件和日志文件。

　　3.避免使用磁盘控制卡上的写入缓存(Write-back caching)。

　　4.定期地进行全备份。全备份一方面保证了数据的安全，另一方面也能及早地发现数据库的物理损坏。在执行全备份时，备份程序会把数据库的每一个页面读取出来并重新计算校验和，如果有损坏的页面存在，管理员可以及早的发现问题并采取行动。

　　当物理损坏发生时，我们可以采取如下的步骤来进行恢复：

　　1.如果有全备份，一定要先从备份进行恢复。

　　2.在没有备份的情况下，可以使用Eseutil /p来进行手工的修复。但这是不推荐的做法，从备份恢复是最好的解决办法。

　　关于数据库的物理损坏，更详细的内容请参考微软知识库文档“Understanding and analyzing -1018, -1019, and -1022 Exchange database errors”，这篇文章的代号是314917。

　　另外一种常见的数据库损坏是逻辑损坏。数据库的内容本身没有问题，但是一些内部的视图、关联发生问题时，就会发生逻辑损坏。逻辑损坏的症状往往表现为：大部分用户使用正常，某些用户在点击特定的邮箱文件夹或者邮件时，会发生死机等现象。对于这种故障，一般可以使用ISINTEG命令来进行修复。

　　【转自www.bitsCN.com】