Exchange备份和恢复小结(3)

文档不能匹配在另一天备份的流式文档。为避免对哪些日志文档属于各个存储组产生混乱，以唯一的日志前缀命名属于指定存储组的 Exchange 日志，该前缀是文档名的前三个字符，存储组的当前日志文档总是 E0n.log。事务日志的大小统一为 5 MB。假如当前日志文档已满，将用十六进制序列号（称为日志生成编号）将其重命名，并生成新的当前日志文档。日志文档被编号为 E0n00001.log、E0n00002.log，依此类推。带编号的日志文档一般被指定为 E0nxxxxx.log。
假如数据库异常停止，则检查点文档 (E0n.chk) 将记录作为恢复起点的事务日志，恢复必须从此起点处开始重放，以恢复数据库一致性。该过程称为“软恢复”。软恢复和“硬恢复”相对，后者是在恢复联机备份后重放日志文档的过程。软恢复和硬恢复之间最重要的区别是：在硬恢复期间，将修补文档数据插入了日志文档重放过程。不一致的 Exchange 数据库文档是没有将任何未完成事务全部写入其中的文档。在正常操作期间，Exchange 数据库文档是不一致的，因为在缓存中存在尚未物理写入该文档的信息。通常，只有数据库服务正常关闭后，Exchange 数据库文档才被认为是一致的。但是，数据库作为一个整体（该整体被认为是事务日志和数据库文档中的信息总和）始终是一致的，除非所需的日志文档被过早删除。 www.bitsCN.com
处理数据库签名和路径不匹配问题
和日志文档相同，数据库也有自己的签名。不同的是，虽然自创建 E0n000001.log 文档之后日志签名不会再更改，但每当数据库的物理拓扑改变时，数据库签名将会更改，并且不通过日志文档对这些更改进行跟踪。使用 Eseutil 对数据库进行脱机碎片整理或修复时，会更改 DB 签名。经过这样的事件后，数据库能够附加到先前的同一日志流，但他将不接受数据库具备先前签名时所执行的任何事务的重放。数据库的以前副本不接受数据库签名更改后所执行的任何事务的重放。由于数据库签名以这种方式重置，因此强烈建议您在对数据库进行脱机碎片整理或修复后，立即创建完全数据库备份。假如您以后恢复具备旧签名的数据库副本，将会成功重放到签名更改点，但您将会丢失该点之后的任何更改。假如在日志流中间更改了数据库路径，其效果和更改签名类似：重放将在更改点中断。（联机备份 API 提供了一种手段，能够在恢复过程中重新映射路径；因此，即使在创建备份后更改了路径，联机备份 API 也能够完全重放日志。） www.bitsCN.com
,

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有