分类：
2008-09-10 10:20:14
有两种形式的恢复：
软恢复 在当数据库意外停止后被重新加载时的日志重放过程，或当事务日志被重放到数据库的离线备份中。
硬恢复 事务日志重放过程发生在从在线备份恢复数据库后。
软恢复
在缺省的软恢复场景中，外部的事件意外终止了Exchange 数据库，但是数据库和日志文件保持完好无损并仍在原来的位置。当数据库被重新加载的时候，Exchange阅读检查点文件，并开始重放被列在检查点日志中的事务日志。如果没有检查点文件存在的话，重放从组中事务日志文件夹中最老的可用日志文件开始。
Exchange 服务器将它们写到数据库中，完成那些日志文件中发现的还没有被写到数据库中的事务。Exchange 服务器从来不会将事务写进数据库文件中直到所有的操作组成的整体被放置到日志文件中。您不需要在数据库中物理地撤消或收回一个事务，当重放开始的时候如果所有的未提交的事务日志还在这时意外中止出现。
重要信息：软恢复过程的一个基本的假设是，由于故障或在故障之后，没有数据库或日志文件被管理员移动、删除或损坏。
如果您从重播序列中删除任何需要的事务日志，Exchange 服务器软恢复将立即失败。如果需要的日志丢失的话，您必须要么从旧的日志执行恢复，从数据库的备份(一个不需要那些日志副本)中还原，要么您必须使用Exchange 服务器数据库工具(Eseutil.exe)来修复这个数据库。
事务日志文件重播的一些基础规则
事务日志文件重播的一些基础规则有下面一些：
1. 您不能将日志文件从一个数据库重播到另一个数据库中。日志文件内部的操作是低级别的。您无法看到日志文件里面的东西像“传递邮件A到邮箱B”。日志文件操作的一个好的例子是“在数据库页面7890上写123字节的流到偏移量456字节”。
想像您要编辑一个文档给出一些指令，您的指令是“在第五页第四段的第三个句子中的第二个单词后插入 '将是或将不是'”。如果这些指令被应用到文档而不是您打算的地方，结果是将随机地损坏该文档。同样地，如果错误的日志文件被重播到一个Exchange 服务器数据库中，类似的结果将发生。Exchange 服务器因此必须有多个机制来阻止这样的损坏发生。如果您修复或整理Exchange 服务器数据库，以前和该数据库关联的事务日志不能在被重播到它里面。
如果您尝试重播日志在完全整理或修复之后，Exchange 服务器跳过这些不正确的事务日志。再一次考虑类似文档编辑。如果一个段被移动、编辑或删除由于指令被创建，应用过期的指令将具有毁坏性因为将它们变成了一个完全不同的文档。
2. 您不能重播日志文件除非所有未提交的日志文件从数据库上次运行的时候是可用的。您必须让所有的日志文件从检查点开始并且在那个时间数据库被备份。接着您才能从该点重播日志文件只要它们不存在中断的序列。如果中间或序列的开始有单个文件丢失的话，重播将停在那里。
3. 您不能重播日志文件如果数据库文件已经被移动到不同的文件路径(在Exchange 2000 Server SP2之前)。该限制不会应用如果您正在使用Exchange 2000 Server SP2 或后续版本，因为Eseutil.exe 处理重播即使路径已经发生更改。下面的部分将具体描述重播过程是如何工作的。
4. 您不能重播日志文件如果检查点指向了错误日志。Exchange 服务器对待检查点日志好象它是第一个可用日志并忽略所有旧的日志文件。如果您还原了数据库的旧文件备份，检查点将回到以前很远，Exchange 服务器尝试从一个很新的日志文件开始重播。您能够解决该问题通过删除检查点文件，这样强制Exchange 服务器扫描所有可用的日志文件。(如果您恢复一个在线备份，硬恢复将忽略检查点文件。)
5. 您不能重播日志文件如果组的任何数据库文件已经被删除。所有的以前正在运行的突然出现意外出现终止的数据库必须存在，这样才能保证软恢复成功。该限制能够被克服通过使用Eseutil.exe 来运行软恢复。
如果一个存储组中的其他数据库正在运行软恢复这时一个数据库丢失了，以后的日志重播将变的比较复杂。通过软恢复失败，Exchange 服务器给管理员一个机会来分析情况并决定是否不通过数据库来处理。
[1]
