SQL大型事务日志备份与修复问题

核心提示： 还原步骤 3 和 4 是对还原的数据库进行恢复，以便确保事务一致性;此流程与崩溃恢复期间对数据库执行的操作流程相同，SQL大型事务日志备份与修复问题(2)，恢复操作所需时间取决于需要处理的事务日志量，例如，但是，在日志传送数据库方案中，如果在进行备份时恰好有一个长时间运行的事务处于活动状态

还原步骤 3 和 4 是对还原的数据库进行恢复，以便确保事务一致性;此流程与崩溃恢复期间对数据库执行的操作流程相同。恢复操作所需时间取决于需要处理的事务日志量。例如，如果在进行备份时恰好有一个长时间运行的事务处于活动状态，则该事务的所有事务日志都会被备份进来，因此届时不得不进行回滚。

问：我打算在日志传送和数据库镜像之间选择一种提供生产数据库冗余副本的方法。我很担心需要在两个服务器之间传送的事务日志数量，尤其是对于我们每晚都需要执行的索引重建操作。听说镜像功能发送的是实际的重建命令而非事务日志，而重建是在镜像中完成的。真的是这样吗?如果是这样，那么对于 BULK_LOGGED 恢复模式，镜像解决方案要优于日志传送，对吗?

答：您听说的观点是错误的。数据库镜像过程是通过将实际的事务日志记录从主体数据库发送到镜像服务器来完成的，这些记录在镜像数据库中将被“重播”。对于镜像的数据库，既不存在任何类型的转换或筛选，也不存在任何类型的 T-SQL 命令拦截。

数据库镜像仅支持 FULL 恢复模式，这意味着始终会完全记录索引重建操作。根据涉及的索引大小的不同，这可能意味着会生成大量事务日志，从而导致主体数据库的日志文件很大，在将日志记录发送到镜像时需要占用大量的网络带宽。

您可以将数据库镜像视为实时日志传送(实际上，这正是早期在 SQL Server 2005 开发期间该功能所使用的名称)。在日志传送过程中，主数据库的事务日志备份会定期传送到辅助服务器上，并在辅助数据库中进行还原。

日志传送功能支持 FULL 和 BULK_LOGGED 恢复模式。对于使用 FULL 恢复模式在日志传送数据库中所执行的索引重建操作，生成的事务日志量将与镜像数据库中生成的数量完全相同。但是，在日志传送数据库方案中，数据是以日志备份(或系列日志备份)而非连续流的形式发送到冗余数据库的。