备份数据库包含两个步骤。主要就是对数据库执行 IO 读取操作以及对备份设备执行 IO 写入操作:
备份步骤 1 读取数据文件中所有分配的数据,然后将其写入备份设备。
备份步骤 2 读取某些事务日志,然后将其写入备份设备。
所需的事务日志数量可能会差异很大,但其数量一定能将还原的数据库恢复到相同的时间点
而还原数据库最多可能包含四个步骤。涉及的工作要比读写 IO 复杂得多:
还原步骤 1 如果数据库文件不存在,则创建它们。
还原步骤 2 从备份中读取所有数据和事务日志,然后将其写入相关的数据库文件。
还原步骤 3 对事务日志运行恢复过程的“重做”阶段。
还原步骤 4 对事务日志运行恢复过程的“撤消”阶段。
两个备份步骤所需时间与还原步骤 2 所需时间大致相同(假定硬件配置类似并且服务器上没有用户活动)。如果数据文件较大并且需要进行零初始化(这在 SQL Server 2000 中是需要执行的操作,在 SQL Server 2005 中是默认操作),则还原步骤 1 可能需要较长时间。
为避免花费较长时间,请不要在开始还原之前删除现有文件。或者,也可以启用即时初始化,以便快速创建这些文件(有关详细信息,请访问 msdn.microsoft.com/library/ms175935.aspx)。
还原步骤 3 和 4 是对还原的数据库进行恢复,以便确保事务一致性;此流程与崩溃恢复期间对数据库执行的操作流程相同。恢复操作所需时间取决于需要处理的事务日志量。例如,如果在进行备份时恰好有一个长时间运行的事务处于活动状态,则该事务的所有事务日志都会被备份进来,因此届时不得不进行回滚。
数据库镜像过程是通过将实际的事务日志记录从主体数据库发送到镜像服务器来完成的,这些记录在镜像数据库中将被“重播”。对于镜像的数据库,既不存在任何类型的转换或筛选,也不存在任何类型的 T-SQL 命令拦截。
数据库镜像仅支持 FULL 恢复模式,这意味着始终会完全记录索引重建操作。根据涉及的索引大小的不同,这可能意味着会生成大量事务日志,从而导致主体数据库的日志文件很大,在将日志记录发送到镜像时需要占用大量的网络带宽。
您可以将数据库镜像视为实时日志传送(实际上,这正是早期在 SQL Server 2005 开发期间该功能所使用的名称)。在日志传送过程中,主数据库的事务日志备份会定期传送到辅助服务器上,并在辅助数据库中进行还原。
日志传送功能支持 FULL 和 BULK_LOGGED 恢复模式。对于使用 FULL 恢复模式在日志传送数据库中所执行的索引重建操作,生成的事务日志量将与镜像数据库中生成的数量完全相同。但是,在日志传送数据库方案中,数据是以日志备份(或系列日志备份)而非连续流的形式发送到冗余数据库的。
如果在索引重建完毕后在日志传送数据库中使用 BULK_LOGGED 恢复模式,则只会生成少量的事务日志。但是在下次事务日志备份时,还将会包含被所记录的最低限度索引重建操作改变的全部数据文件范围。这意味着无论是纳入在 BULK_LOGGED 恢复模式下重建的索引的日志备份还是纳入在 FULL 恢复模式下重建的索引的日志备份,其大小都几乎完全相同。
因此,对于镜像数据库与日志传送数据库中的索引重建而言,需要发送到冗余数据库的信息量几乎完全相同。实际的差别仅在于发送信息的方式 — 是连续发送还是成批发送。
在这两种方法之间进行选择时需要考虑许多其他因素(因素太多,仅在一次 SQL 问题解答中无法全部讨论)。您应该先了解所有这些因素与您的需求的关联程度(例如,可接受的数据丢失限制和允许的停机时间),然后再做决定。
在完全恢复模式下进行事务日志备份很重要,在这一点上您是对的。但是,还有其他一些因素可导致事务日志增大。这完全取决于究竟是什么在要求事务日志成为被使用的日志(或活动日志)。除了缺乏事务日志备份以外,可能会导致此现象发生的其他常见因素还包括复制、数据库镜像和活动事务等。
复制过程是通过异步读取事务日志记录,然后加载这些事务并将其复制到单独的分布数据库来完成的。尚未被复制日志读取器任务读取的任何事务日志记录都无法被释放。如果您的工作负载生成了大量事务日志记录,而您又为复制日志读取器的运行频率设置了较长的时间间隔,则会累积大量记录,导致事务日志增大。
如果您运行的是异步数据库镜像,则可能会存在尚未从主体数据库发送到镜像服务器的事务日志记录储备(称为数据库镜像 SEND 队列)。这些事务日志记录在成功发出之前无法被释放。如果生成了大量事务日志记录,而网络带宽又受到限制(或出现其他硬件问题),则储备可能会变得很大,导致事务日志不断增大。
最后,如果用户启动了一个显式事务(如使用 BEGIN TRAN 语句),然后进行了某些形式的修改(如 DDL 语句或插入/更新/删除操作),则所生成的事务日志记录在用户提交或回滚该事务前都需要进行保留。这意味着由其他事务生成的任何后继事务日志记录也无法被释放,因为事务日志无法选择性地进行释放。如果假设该用户当天没有结束该事务就下班回家了,则随着越来越多的事务日志记录被不断生成而又无法释放,事务日志就会越来越大。
备份步骤 1 读取数据文件中所有分配的数据,然后将其写入备份设备。
备份步骤 2 读取某些事务日志,然后将其写入备份设备。
所需的事务日志数量可能会差异很大,但其数量一定能将还原的数据库恢复到相同的时间点
而还原数据库最多可能包含四个步骤。涉及的工作要比读写 IO 复杂得多:
还原步骤 1 如果数据库文件不存在,则创建它们。
还原步骤 2 从备份中读取所有数据和事务日志,然后将其写入相关的数据库文件。
还原步骤 3 对事务日志运行恢复过程的“重做”阶段。
还原步骤 4 对事务日志运行恢复过程的“撤消”阶段。
两个备份步骤所需时间与还原步骤 2 所需时间大致相同(假定硬件配置类似并且服务器上没有用户活动)。如果数据文件较大并且需要进行零初始化(这在 SQL Server 2000 中是需要执行的操作,在 SQL Server 2005 中是默认操作),则还原步骤 1 可能需要较长时间。
为避免花费较长时间,请不要在开始还原之前删除现有文件。或者,也可以启用即时初始化,以便快速创建这些文件(有关详细信息,请访问 msdn.microsoft.com/library/ms175935.aspx)。
还原步骤 3 和 4 是对还原的数据库进行恢复,以便确保事务一致性;此流程与崩溃恢复期间对数据库执行的操作流程相同。恢复操作所需时间取决于需要处理的事务日志量。例如,如果在进行备份时恰好有一个长时间运行的事务处于活动状态,则该事务的所有事务日志都会被备份进来,因此届时不得不进行回滚。
数据库镜像过程是通过将实际的事务日志记录从主体数据库发送到镜像服务器来完成的,这些记录在镜像数据库中将被“重播”。对于镜像的数据库,既不存在任何类型的转换或筛选,也不存在任何类型的 T-SQL 命令拦截。
数据库镜像仅支持 FULL 恢复模式,这意味着始终会完全记录索引重建操作。根据涉及的索引大小的不同,这可能意味着会生成大量事务日志,从而导致主体数据库的日志文件很大,在将日志记录发送到镜像时需要占用大量的网络带宽。
您可以将数据库镜像视为实时日志传送(实际上,这正是早期在 SQL Server 2005 开发期间该功能所使用的名称)。在日志传送过程中,主数据库的事务日志备份会定期传送到辅助服务器上,并在辅助数据库中进行还原。
日志传送功能支持 FULL 和 BULK_LOGGED 恢复模式。对于使用 FULL 恢复模式在日志传送数据库中所执行的索引重建操作,生成的事务日志量将与镜像数据库中生成的数量完全相同。但是,在日志传送数据库方案中,数据是以日志备份(或系列日志备份)而非连续流的形式发送到冗余数据库的。
如果在索引重建完毕后在日志传送数据库中使用 BULK_LOGGED 恢复模式,则只会生成少量的事务日志。但是在下次事务日志备份时,还将会包含被所记录的最低限度索引重建操作改变的全部数据文件范围。这意味着无论是纳入在 BULK_LOGGED 恢复模式下重建的索引的日志备份还是纳入在 FULL 恢复模式下重建的索引的日志备份,其大小都几乎完全相同。
因此,对于镜像数据库与日志传送数据库中的索引重建而言,需要发送到冗余数据库的信息量几乎完全相同。实际的差别仅在于发送信息的方式 — 是连续发送还是成批发送。
在这两种方法之间进行选择时需要考虑许多其他因素(因素太多,仅在一次 SQL 问题解答中无法全部讨论)。您应该先了解所有这些因素与您的需求的关联程度(例如,可接受的数据丢失限制和允许的停机时间),然后再做决定。
在完全恢复模式下进行事务日志备份很重要,在这一点上您是对的。但是,还有其他一些因素可导致事务日志增大。这完全取决于究竟是什么在要求事务日志成为被使用的日志(或活动日志)。除了缺乏事务日志备份以外,可能会导致此现象发生的其他常见因素还包括复制、数据库镜像和活动事务等。
复制过程是通过异步读取事务日志记录,然后加载这些事务并将其复制到单独的分布数据库来完成的。尚未被复制日志读取器任务读取的任何事务日志记录都无法被释放。如果您的工作负载生成了大量事务日志记录,而您又为复制日志读取器的运行频率设置了较长的时间间隔,则会累积大量记录,导致事务日志增大。
如果您运行的是异步数据库镜像,则可能会存在尚未从主体数据库发送到镜像服务器的事务日志记录储备(称为数据库镜像 SEND 队列)。这些事务日志记录在成功发出之前无法被释放。如果生成了大量事务日志记录,而网络带宽又受到限制(或出现其他硬件问题),则储备可能会变得很大,导致事务日志不断增大。
最后,如果用户启动了一个显式事务(如使用 BEGIN TRAN 语句),然后进行了某些形式的修改(如 DDL 语句或插入/更新/删除操作),则所生成的事务日志记录在用户提交或回滚该事务前都需要进行保留。这意味着由其他事务生成的任何后继事务日志记录也无法被释放,因为事务日志无法选择性地进行释放。如果假设该用户当天没有结束该事务就下班回家了,则随着越来越多的事务日志记录被不断生成而又无法释放,事务日志就会越来越大。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/16436858/viewspace-541410/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/16436858/viewspace-541410/