对于数据库损坏的问题,防患于未然要远远比事后亡羊补牢来的有效。数据库的损坏一般可以分为物理损坏和逻辑损坏。<br>
<br>
物理损坏往往是由磁盘介质、控制卡等硬件设备的故障引起的。这种类型的损坏都会引起数据丢失,唯一的解决办法就是从备份的磁带进行恢复。<br>
<br>
Exchange Server为了确保数据的一致性,会在向数据库写入内容时(写入的单位是4KB的页面),把根据数据内容计算得出的校验和跟实际的数据一并写入。当读取时,系统会重新计算校验和,并跟保存的校验和进行比较,如果这两个值不同,说明读出的数据和当初写入的数据相比,已经发生了变化。这种变化往往是由磁盘故障、控制器总线传输故障等引起的。为了排除干扰因素,当校验和不匹配的情况出现时,Exchange Server会再次到磁盘上去读取那个页面,如此循环16次。如果连续读取16次,校验和跟原始的值仍然无法匹配,Exchange Server就会认为数据库已经发生了物理损坏。在事件日志中,会有如下的内容被记录下来:<br>
<br>
Event ID: 23<br>
Source: EDB<br>
Type: Error<br>
Category: Database Page Cache<br>
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.<br>
<br>
另外,当事件日志的错误描述中出现如下的代码,基本上也可以认定数据库发生了物理损坏:<br>
<br>
-1018 (JET_errReadVerifyFailure)<br>
The data read from disk is not the same as the data that was written to disk.<br>
-1022 (JET_errDiskIO)<br>
The hardware, device driver, or operating system is returning errors.<br>
-510 JET_errLogWriteFail<br>
The log files are out of disk space or there is a hardware failure with the log file disk.<br>
<br>
数据库的物理损坏往往会带来数据丢失和Exchange Server停机等等损失。我们可以采取下面的一些建议来避免物理损坏的发生:<br>
<br>
1. 采用高质量的磁盘和磁盘控制系统,对硬件RAID系统进行正确的配置。<br>
2. 不要使用文件级别的工具或防病毒软件扫描数据库文件和日志文件。<br>
3. 避免使用磁盘控制卡上的写入缓存(Write-back caching)。<br>
4. 定期地进行全备份。全备份一方面保证了数据的安全,另一方面也能及早地发现数据库的物理损坏。在执行全备份时,备份程序会把数据库的每一个页面读取出来并重新计算校验和,如果有损坏的页面存在,管理员可以及早的发现问题并采取行动。<br>
<br>
当物理损坏发生时,我们可以采取如下的步骤来进行恢复:<br>
<br>
1. 如果有全备份,一定要先从备份进行恢复。<br>
2. 在没有备份的情况下,可以使用Eseutil /p来进行手工的修复。但这是不推荐的做法,从备份恢复是最好的解决办法。<br>
<br>
关于数据库的物理损坏,更详细的内容请参考微软知识库文档“Understanding and analyzing -1018, -1019, and -1022 Exchange database errors”,这篇文章的代号是314917。<br>
<br>
另外一种常见的数据库损坏是逻辑损坏。数据库的内容本身没有问题,但是一些内部的视图、关联发生问题时,就会发生逻辑损坏。逻辑损坏的症状往往表现为:大部分用户使用正常,某些用户在点击特定的邮箱文件夹或者邮件时,会发生死机等现象。对于这种故障,一般可以使用ISINTEG命令来进行修复。<br>
<br>
关于Exchange Server数据库的更多内容,大家可以阅读微软知识库文档“Overview of Exchange Server Database Architecture and Database Engine”这篇文章的代号是217987。<br>