你是否想知道为什么事务日志文件会变得越来越大？事务日志有时候甚至会比你的实际数据库文件还要大，尤其是在应用数据仓库的情况下。为什么会发生这种情况呢？如何控制其大小？数据库恢复模型如何控制事务日志增长？在本系列文章中，我们就将一一给出解答。
批量日志恢复模式
批量日志恢复模式与完整恢复模式类似，都预期会有大批量的数据修改操作(例如，创建索引，SELECT INTO，INSERT SELECT，BCP，BULKINSERT)，在这种情况下可以最小化日志记录量，因此它降低了性能影响。但是同时代价就是你可能不能做任何时点的恢复了。作为一种推荐的实践，批量日志恢复模式可以与完整恢复模式一起使用，例如，你通常应该在常规操作时设置为完整恢复模式，然后在偶尔发生大批量操作时临时切换到批量日志恢复模式。最后在完成大批量操作以后，再回到完整恢复模式。如果时间点恢复很重要的话，我们非常推荐在切换回到完整恢复模式以后做一次事务日志备份。
与完整恢复模式类似，事务日志文件将会持续增长，因此你需要频繁做事务日志备份。如果没有大批量操作，批量日志模式与完整恢复模式是一样的，你可以恢复到任何时点，只要事务日志包含对数据库后续做的所有变更记录。
优点：通过对一些事务做最小化日志记录优化大批量操作的性能。不会让事务日志由于这些大批量数据操作而显著增长。
缺点：如果日志损坏，或者在最近日志备份之后发生大批量数据操作，存在数据丢失的可能性。因此自最后一次备份后的变化必须被重做。
何时采用：推荐在偶尔发生的大批量数据操作之前切换到批量日志恢复模式，然后在完成大批量数据操作之后切换回到完整恢复模式。采用这种方式你仍然可以恢复到任何时间点，只是你最后一次事务日志备份不包含大批量数据操作，同时可以将大批量数据操作的日志量最小化。
要注意的是，最小化日志记录意味着只记录恢复事务需要的信息，而不支持时间点恢复。在最小化日志的情况下，事务日志基于大批量变更映射(MCP)页做的大批量数据变更记录页轨迹，而不是对每次变化做日志。这种方式数据库日志会更小，但是在你备份事务日志时，它包括了所有变更页，因此即使事务日志非常小，事务日志备份也可能比它更大。
大容量日志恢复模式bulk_logged recovery model
The bulk-logged recovery model minimally logs bulk operations, although fully logging other transactions. The bulk-logged recovery model protects against media failure and, for bulk operations(bcp,BULK INSERT,SELECT INTO), provides the best performance and least log space usage.
The bulk-logged recovery model increases the risk of data loss for these bulk-copy operations, because bulk logging operations prevents recapturing changes on a
