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

　　SQL大型事务日志备份与修复问题教育资源库 　　问：我在备份时注意到一些异常现象，希望您能解释一下。我们需要经常备份 62GB 的生产数据库，以刷新应用程序开发人员所使用的数据。我们总是先删除旧副本然后再还原新副本。还原的副本与生产数据库大小相同，而且数据看起来也一样，但是与备份过程相比，还原过程所需的时间要长很多。这是怎么回事?为什么还原比备份需要更长的时间? 　　答：其实这不属于异常现象。根据您所处的环境，这种现象通常是预料之中的。备份和还原所需的时间之所以不同，是由于每个流程必须执行的步骤不同。 　　备份数据库包含两个步骤。主要就是对数据库执行 IO 读取操作以及对备份设备执行 IO 写入操作： 　　备份步骤 1 读取数据文件中所有分配的数据，然后将其写入备份设备。 　　备份步骤 2 读取某些事务日志，然后将其写入备份设备。 　　所需的事务日志数量可能会差异很大，但其数量一定能将还原的数据库恢复到相同的时间点 　　而还原数据库最多可能包含四个步骤。涉及的工作要比读写 IO 复杂得多： 　　还原步骤 1 如果数据库文件不存在，则创建它们。 　　还原步骤 2 从备份中读取所有数据和事务日志，然后将其写入相关的数据库文件。 　　还原步骤 3 对事务日志运行恢复过程的重做阶段。 　　还原步骤 4 对事务日志运行恢复过程的撤消阶段。 　　两个备份步骤所需时间与还原步骤 2 所需时间大致相同(假定硬件配置类似并且服务器上没有用户活动)。如果数据文件较大并且需要进行零初始化(这在 SQL Server 2000 中是需要执行的操作，在 SQL Server 2005 中是默认操作)，则还原步骤 1 可能需要较长时间。 　　为避免花费较长时间，请不要在开始还原之前删除现有文件。或者，也可以启用即时初始化，以便快速创建这些文件(有关详细信息，请访问 msdn.microsoft.shy;library/ms175935.aspx)。 　　还原步骤 3 和 4 是对还原的数据库进行恢复，以便确保事务一致性;此流程与崩溃恢复期间对数据库执行的操作流程相同。恢复操作所需时间取决于需要处理的事务日志量。例如，如果在进行备份时恰好有一个长时间运行的事务处于活动状态，则该事务的所有事务日志都会被备份进来，因此届时不得不进行回滚。 　　问：我打算在日志传送和数据库镜像之间选择一种提供生产数据库冗余副本的方法。我很担心需要在两个服务器之间传送的事务日志数量，尤其是对于我们每晚都需要执行的索引重建操作。听说镜像功能发送的是实际的重建命令而非事务日志，而重建是在镜像中完成的。真的是这样吗?如果是这样，那么对于 BULK_LOGGED 恢复模式，镜像解决方案要优于日志传送，对吗? 　　答：您听说的观点是错误的。数据库镜像过程是通过将实际的事务日志记录从主体数据库发送到镜像服务器来完成的，这些记录在镜像数据库中将被重播。对于镜像的数据库，既不存在任何类型的转换或筛选，也不存在任何类型的 T-SQL 命令拦截。 　　数据库镜像仅支持 FULL 恢复模式，这意味着始终会完全记录索引重建操作。根据涉及的索引大小的不同，这可能意味着会生成大量事务日志，从而导致主体数据库的日志文件很大，在将日志记录发送到镜像时需要占用大量的网络带宽。 　　您可以将数据库镜像视为实时日志传送(实际上，这正是早期在 SQL Server 2005 开发期间该功能所使用的名称)。在日志传送过程中，主数据库的事务日志备份会定期传送到辅助服务器上，并在辅助数据库中进行还原。 　　日志传送功能支持 FULL 和 BULK_LOGGED 恢复模式。对于使用 FULL 恢复模式在日志传送数据库中所执行的索引重建操作，生成的事务日志量将与镜像数据库中生成的数量完全相同。但是，在日志传送数据库方案中，数据是以日志备份(或系列日志备份)而非连续流的形式发送到冗余数据库的。 　　如果在索引重建完毕后在日志传送数据库中使用 BULK_LOGGED 恢复模式，则只会生成少量的事务日志。但是在下次事务日志备份时，还将会包含被所记录的最低限度索引重建操作改变的全部数据文件范围。这意味着无论是纳入在 BULK_LOGGED 恢复模式下重建的索引的日志备份还是纳入在 FULL 恢复模式下重建的索引的日志备份，其大小都几乎完全相同。 　　因此，对于镜像数据库与日志传送数据库中的索引重建而言，需要发送到冗余数据库的信息量几乎完全相同。实际的差别仅在于发送信息的方式 是连续发送还是成批发送。 　　在这两种方法之间进行选择时需要考虑许多其他因素(因素太多，仅在一次 SQL 问题解答中无法全部讨论)。您应该先了解所有这些因素与您的需求的关联程度(例如