当一切正常时，没有必要特别留意什么是事务日志，它是如何工作的。你只要确保每个数据库都有正确的备份。当出现问题时，事务日志的理解对于采取修正操作是重要的，尤其在需要紧急恢复数据库到指定点时。这系列文章会告诉你每个DBA应该知道的具体细节。
这个标题近乎是用词不当，因为很大程度上，运行在简单模式里不需要日志管理。在简单模式里，事务日志的唯一目的是在数据库恢复操作期间，保证事务的ACID属性，还有强制数据库的一致性和事务的持久性。事务日志不能被备份，不能用来数据库恢复，也不能用作日志传输。
在简单模式里工作
所有事务还是被记录，尽管特定大容量操作是最小化日志；实际上，日志级别和大容量日志里的应用非常类似。日志的活动部分还是照常维护，因此任何时候数据库在简单模式里启动后，恢复进程会进入，数据文件会用事务日志内容调和。
但是，在简单模式里，所有的虚拟日志文件（VLF）被标记为如第2篇里的不活动（可恢复），在定期的数据库检查点期间会自动截断。这就是说，当检查点发生时，文件里任何最高LSN小于最低LSN的VLF都会被截断，结果在事务文件里的空间会定期和经常重用。
简单恢复模式里的数据库总会是自动截断模式。如第3篇里描述的，所有的用户数据库，在第一次完整备份进行前，实际上是自动截断模式。
检查点多少时间发生一次？
为了恢复数据库到恢复区间（recovery interval）服务器配置选项指定时间里，基于需要处理的日志记录数，SQL Server引擎决定多少时间进行一次检查点。如果你的数据库是只读的，检查点之间的时间可能会很长。但是，在业务上频繁更新的系统，检查点会近每一分钟发生一次。点击https://msdn.microsoft.com/zh-cn/library/ms189573.aspx查看详细介绍。
正如上一篇文章讨论的，完整恢复模式里，事务日志维护“不活动的历史或关闭的事务”，连同活动/打开的事务。这个”历史“可以在日志备份里捕获，用来还原数据库到先前的一个时间点。但是，在简单模式里，这个历史不存在因此日志不能用来还原数据库到先前的一个时间点。事实上，在简单恢复模式里，你甚至不能进行事务日志备份，如下代码所演示。
1 USE master; 2 ALTER DATABASE TestDB 3 SET RECOVERY SIMPLE; 4 BACKUP Log TestDB 5 TO DISK =‘C:\BACKUP\TestDB_log.bak‘ 6 GO
这表示你的备份计划只能在完整和差异备份计划里执行。
简单模式的支持与反对
简单模式的缺点，肯定是你丢失数据的机率会很高，因为你只能恢复数据库到最近的完整或差异备份。刚才提到过，如果丢失数据是以分钟衡量，不是以小时衡量，不要使用简单模式。
但是，如果你运行的是开发或测试数据库，或者甚至是一个只读的生产数据库，那么使用简单模式可能是一个可行的，甚至是一个明智的选择，这会大大减轻数据库上的维护负担。备份的存储空间会更少，后续的恢复操作会更简单。此外，因为事务日志是自动截断的，你很少有日志增长失控的风险，引起9002错误。
尽管简单模式明显减轻了事务日志管理的负担，这样认为是错误的。如果你使用这个模式，你会完全忘记日志维护。事务日志在数据库的日常操作中还是扮演着重要角色，你还是需要正确调整事务日志的大小和增长，根据数据库受到的事务本质和频率。不是因为日志是自动截断的，这不表示健壮和长时间运行的事务不会导致日志快速增长，如果你没有正确调整大小，还是会给你带来麻烦——这个会在第7篇-第8篇详细介绍。