恢复模型
事务日志是SQL Server的一种内部机制，用来保存所有事务的日志，以及每个事务做的数据库修改。这些日志在操作发生时以字符串日志记录的形式顺序记录。这项功能很重要，如果发生了系统故障可以用此功能将数据库回滚到某个一致的状态。但是，事务日志会一直增长的，我们怎么控制其大小呢？
恢复模型是控制和管理事务日志文件的一种机制。恢复模型控制事务日志如何记录，日志是否自动截断，日志是否需要或者允许备份，哪种恢复操作是允许的。
SQLServer中的每个数据库都有 “恢复模型（Recovery Model）”的属性，它提供三种设置：简单恢复模式，批量恢复模式和完整恢复模式，我们可以根据性能、存储空间和保护数据防丢失的不同需求选择设置。你需要评估你的大批量操作（创建索引或者大批量数据加载）的性能，事务日志存储需求的存储空间，数据丢失的可能性（提交事务丢失），备份和恢复操作的简单程度。数据库可以随时切换到另一种设置以满足业务需求，但是在操作设置之前请评估一下可能产生的影响。
因需求不同，你可能需要不只一种恢复模型。例如，考虑你有一项关键任务的OLTP数据库，为了能在任何时点恢复它（这样就不会有提交的事务会丢失），你应该使用完整恢复模式。但是在你执行一些大操作时（例如，创建索引，SELECT INTO，INSERT SELECT，BCP，BULKINSERT）你可以切换到批量日志恢复模式，这样可以最小化日志量，在完成该操作之后再设置为完整恢复模式。这样可以降低在大批量操作过程中占用掉可用事务日志空间的可能性。
完整恢复模式
正如其名，完整恢复模式对每一个事务都记录日志，并维护这些日志直到做过了日志备份。在这种恢复模式下，你可以设计灾备计划，其中包括一组全备份（或者差异备份）和事务日志备份。要控制事务日志的大小，你需要做事务日志备份，这样它就可以截断处理了。
在完整恢复模式下，你可以利用事务日志备份恢复到任意时间点，因此任何数据都不会丢失，也不会有损坏的数据文件。
优点：完整恢复模式提供了避免数据丢失的全面保护。在最不幸的灾难或者应用程序和用户错误情况下，你可以利用可用的事务日志备份恢复到任何时间点，前提是你的事务日志备份在那个时间点已经完成了。
缺点：在完整恢复模式下，你需要设置定期的事务日志备份，确保事务日志增长可控。否则它会一直增长直到你做下一次全备份。另外，如果事务日志损坏了，那么在最近的事务日志备份之后的变化必须重做。
何时采用：完整恢复模式推荐用于OLTP数据库，这种场景下有很多短事务，你不想丢失提交事务的数据。SQL Server中也有其它一些选项功能（比如：AlwaysOn，数据库镜像，日志迁移，事务复制，变化数据捕获）需要启用完整恢复模式才可用。
批量日志恢复模式
批量日志恢复模式与完整恢复模式类似，都预期会有大批量的数据修改操作（例如，创建索引，SELECT INTO，INSERT SELECT，BCP，BULKINSERT），在这种情况下可以最小化日志记录量，因此它降低了性能影响。但是同时代价就是你可能不能做任何时点的恢复了。作为一种推荐的实践，批量日志恢复模式可以与完整恢复模式一起使用，例如，你通常应该在常规操作时设置为完整恢复模式，然后在偶尔发生大批量操作时临时切换到批量日志恢复模式。最后在完成大批量操作以后，再回到完整恢复模式。如果时间点恢复很重要的话，我们非常推荐在切换回到完整恢复模式以后做一次事务日志备份。
与完整恢复模式类似，事务日志文件将会持续增长，因此你需要频繁做事务日志备份。如果没有大批量操作，批量日志模式与完整恢复模式是一样的，你可以恢复到任何时点，只要事务日志包含对数据库后续做的所有变更记录。
优点：通过对一些事务做最小化日志记录优化大批量操作的性能。不会让事务日志由于这些大批量数据操作而显著增长。
缺点：如果日志损坏，或者在最近日志备份之后发生大批量数据操作，存在数据丢失的可能性。因此自最后一次备份后的变化必须被重做。
何时采用：推荐在偶尔发生的大批量数据操作之前切换到批量日志恢复模式，然后在完成大批量数据操作之后切换回到完整恢复模式。采用这种方式你仍然可以恢复到任何时间点，只是你最后一次事务日志备份不包含大批量数据操作，同时可以将大批量数据操作的日志量最小化。
要注意的是，最小化日志记录意味着只记录恢复事务需要的信息，而不支持时间点恢复。在最小化日志的情况下，事务日志基于大批量变更映射（MCP）页做的大批量数据变更记录页轨迹，而不是对每次变化做日志。这种方式数据库日志会更小，但是在你备份事务日志时，它包括了所有变更页，因此即使事务日志非常小，事务日志备份也可能比它更大。
简单恢复模式
简单恢复模式是所有这几种中最简单的。它只维护最小量信息的SQL Server事务日志文件。SQL Server自己截断事务日志文件，并删除已经达到事务检查点的信息有关的事务。这样空间就可以被重用，完全没有用于灾备目的的事务日志。也就是说，在简单恢复模式下，数据只有最近的全备份或者差异备份中的内容是可恢复的（不支持事务日志备份）。在简单恢复模式下，事务日志会在检查点之后或者在你把数据库切换到简单恢复模式的瞬间马上截断。
用简单恢复模式管理数据库更容易，但是代价是如果数据文件损坏了会丢失更多数据。你只能从最近的全备份或者差异备份中恢复数据；也就是说你会丢失在上一次全备份或者差异备份之后到故障发生之时的所有变化数据。因此，如果你的数据库采用简单恢复模式，你应该保证备份间隔足够长以免影响正常生产运营，同时还要保证备份周期足够短，以免数据丢失太多。
优点：简单恢复模式的可管理性更容易，不需要做事务备份。它只占用检查点事务的空间，确保事务日志文件的增长得以控制。大批量日志操作执行会更优，因为日志最小化了，而且事务日志占用空间也最小。
缺点：你会丢失最后一次全备份或者差异备份之后到故障发生时的所有数据变更，再做恢复就不可能了。
何时采用：在数据仓库的应用场景下，大部分时候做的可能都是在数据加载时做大批量操作，如果遇到故障数据可以从数据源重新生成。你还可以在开发环境或者测试环境使用简单恢复模式，这样事务日志文件增长就可以得到控制。