你的位置:首页 > 数据库

[数据库]SQL Server中的事务日志管理(4/9):简单恢复模式里的日志管理


当一切正常时,没有必要特别留意什么是事务日志,它是如何工作的。你只要确保每个数据库都有正确的备份。当出现问题时,事务日志的理解对于采取修正操作是重要的,尤其在需要紧急恢复数据库到指定点时。这系列文章会告诉你每个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 TestDB3  SET RECOVERY SIMPLE;4  BACKUP Log TestDB5   TO DISK ='C:\BACKUP\TestDB_log.bak'6   GO

这表示你的备份计划只能在完整和差异备份计划里执行。

简单模式的支持与反对

简单模式的缺点,肯定是你丢失数据的机率会很高,因为你只能恢复数据库到最近的完整或差异备份。刚才提到过,如果丢失数据是以分钟衡量,不是以小时衡量,不要使用简单模式。

但是,如果你运行的是开发或测试数据库,或者甚至是一个只读的生产数据库,那么使用简单模式可能是一个可行的,甚至是一个明智的选择,这会大大减轻数据库上的维护负担。备份的存储空间会更少,后续的恢复操作会更简单。此外,因为事务日志是自动截断的,你很少有日志增长失控的风险,引起9002错误。

尽管简单模式明显减轻了事务日志管理的负担,这样认为是错误的。如果你使用这个模式,你会完全忘记日志维护。事务日志在数据库的日常操作中还是扮演着重要角色,你还是需要正确调整事务日志的大小和增长,根据数据库受到的事务本质和频率。不是因为日志是自动截断的,这不表示健壮和长时间运行的事务不会导致日志快速增长,如果你没有正确调整大小,还是会给你带来麻烦——这个会在第7篇-第8篇详细介绍。