你是否想知道为什么事务日志文件会变得越来越大？事务日志有时候甚至会比你的实际数据库文件还要大，尤其是在应用数据仓库的情况下。为什么会发生这种情况呢？如何控制其大小？数据库恢复模型如何控制事务日志增长？在本系列文章中，我们就将一一给出解答。
批量日志恢复模式
批量日志恢复模式与完整恢复模式类似，都预期会有大批量的数据修改操作(例如，创建索引，SELECT INTO，INSERT SELECT，BCP，BULKINSERT)，在这种情况下可以最小化日志记录量，因此它降低了性能影响。但是同时代价就是你可能不能做任何时点的恢复了。作为一种推荐的实践，批量日志恢复模式可以与完整恢复模式一起使用，例如，你通常应该在常规操作时设置为完整恢复模式，然后在偶尔发生大批量操作时临时切换到批量日志恢复模式。最后在完成大批量操作以后，再回到完整恢复模式。如果时间点恢复很重要的话，我们非常推荐在切换回到完整恢复模式以后做一次事务日志备份。
与完整恢复模式类似，事务日志文件将会持续增长，因此你需要频繁做事务日志备份。如果没有大批量操作，批量日志模式与完整恢复模式是一样的，你可以恢复到任何时点，只要事务日志包含对数据库后续做的所有变更记录。
优点：通过对一些事务做最小化日志记录优化大批量操作的性能。不会让事务日志由于这些大批量数据操作而显著增长。
缺点：如果日志损坏，或者在最近日志备份之后发生大批量数据操作，存在数据丢失的可能性。因此自最后一次备份后的变化必须被重做。
何时采用：推荐在偶尔发生的大批量数据操作之前切换到批量日志恢复模式，然后在完成大批量数据操作之后切换回到完整恢复模式。采用这种方式你仍然可以恢复到任何时间点，只是你最后一次事务日志备份不包含大批量数据操作，同时可以将大批量数据操作的日志量最小化。
要注意的是，最小化日志记录意味着只记录恢复事务需要的信息，而不支持时间点恢复。在最小化日志的情况下，事务日志基于大批量变更映射(MCP)页做的大批量数据变更记录页轨迹，而不是对每次变化做日志。这种方式数据库日志会更小，但是在你备份事务日志时，它包括了所有变更页，因此即使事务日志非常小，事务日志备份也可能比它更大。
大容量日志恢复模式bulk_logged recovery model
transaction-by-transaction basis.
BCM) tracks the extents that have been modified by bulk logged operations since the last BACKUP LOG statement.
If using the bulk-logged recovery model,only details of the modified data pages are logged,allowing for better performance.
大容量日志恢复模式的工作原理
与完整恢复模式（完全记录所有事务）相比，大容量日志恢复模式只对大容量操作进行最小记录（尽管会完全记录其他事务）。大容量日志恢复模式保护大容量操作不受媒体故障的危害，提供最佳性能并占用最小日志空间。
但是，大容量日志恢复模式会增加这些大容量复制操作丢失数据的风险，因为大容量日志操作阻止再次捕获对每个事务逐一所做的更改。如果日志备份包含大容量日志操作，则无法还原到该日志备份中的时点，而只能还原整个日志备份。
在大容量日志恢复模式下，如果日志备份覆盖了任何大容量操作，则日志备份包含由大容量操作所更改的日志记录和数据页。这对于捕获大容量日志操作的结果至关重要。合并的数据区可使日志备份变得非常庞大。此外，备份日志需要访问包含大容量日志事务的数据文件。如果无法访问任何受影响的数据库文件，则事务日志将无法备份，并且在此日志中提交的所有操作都会丢失。
为跟踪数据页，日志备份操作依赖于位图页的大容量更改，位图页针对每个区包含一位。对于自上次日志备份后由大容量日志操作所更新的每个区，在位图中将每个位都设置为 1。数据区将复制到日志中，后跟日志数据。下图显示了日志备份的构造方式。
重要提示：
在完整或大容量日志恢复模式下，如果没有其他因素使日志记录保持为活动状态，则到进行第一次完整备份时，自动检查点才会截断事务日志的未使用部分。第一次完整备份后，截断要求备份事务日志。有关截断延迟因素的信息，请参阅可能延迟日志截断的因素。
原文链接：https://www.f2er.com/mssql/63151.html