?

在这篇文章里，我们会回顾下当运行在完整恢复模式时，为什么和如何进行日志备份，还有如何使用这些日志备份文件和完整数据库备份一起，进行数据库恢复。完整恢复模式支持数据库数据库还原到有效日志备份里的任何时间点，在尾日志已经备份的情况下，直到上一个提交事务的时间，在灾难发生前。

?

什么被记录？

?

在完整恢复模式里，所有操作被完整记录。对于INSERT，UPDATE和DELETE操作，这意味着对于修改的每一行，都有日志记录描述执行语句的事务ID，事务何时开始，何时结束，哪一页被修改，做出的数据改变等等。

?

当运行在完整恢复模式时，操作会被最小化记录，SELECT INTO，BULK INSERT和CREATE INDEX还是会完全记录，但有完成方法有一点区别。这些操作影响的行不是各自记录，只有数据页被记录，因为它们被填充。这会减少这类操作的日志负荷，但还是会保证存在需要同样的信息来进行回滚，重做和恢复到时间点。Kalen Delaney已经发布了对于SELECT INTO 和索引重建操作日志插入的一些研究，包括在完整和大容量日志恢复模式。当运行在大容量日志模式里时，最小化日志操作的日志区别，会在第6篇——大容量恢复模式里的日志管理里详细讨论。

?

为什么备份事务日志？

?

在完整恢复模式里，只有日志备份会引起日志截断。这样的话，自上次事务日志备份起，事务日志会保存事务运行的全部和完整记录。很多新手或业余DBA会在他们的数据库上进行完整备份，但他们不进行事务日志备份。这样的话，事务日志不会截断，不停的增长增长直到用完磁盘空间，导致SQL Server停止工作。

?

一旦日志备份发生，日志截断就会发生，例如自上一个备份后，且没有其他因素（例如数据备份或还原操作）延迟截断，有个检查点已发生。对于会延迟可恢复VLFs截断的完整列表，同样保持否则不需要的活动日志的大片，例如淘气的，长时间运行不提交的事务或数据库镜像或复制过程，点击查看可能引起日志截断的因素。

?

事务日志的复制备份

?

事务日志的复制备份不会截断事务日志。日志复制备份“单独”存在于普通日志备份计划里，它不会中断日志备份链。

?

简单来说，进行事务日志备份有2个目的：可以恢复或还原到先前一个时间点，还有控制事务日志的大小。最常见事务相关引起的问题是运行在完整恢复模式里，绝不做日志备份，或进行日志备份的频率不够控制事务日志文件的大小。

?

如果你不确定是否要对一个数据库进行事务日志备份，你可以简单查询下MSDB数据库里的backupset表，使用如下的查询：

?

?

1 SE msdb ;

2 SELECT ? backup_set_id ,

3 ? ? ? ? ?backup_start_date ,

4 ? ? ? ? ?backup_finish_date ,

5 ? ? ? ? ?backup_size ,

6 ? ? ? ? ?recovery_model ,

7 ? ? ? ? ?[type]

8 FROM ? ? dbo.backupset

9 WHERE ? ?database_name = 'TestDB'

?

(代码5.1:日志备份发生了么？)

?

在type列里，D代表数据库备份，L代表日志备份，I代表差异备份。

?

注意因为backupset表里的数据不会受备份和还原行为影响，你可以从另外一个查询来验证你的发现，通过查询sys.database_recovery_status看下last_log_backup_lsn的值，或者查询sys.databases表看下log_reuse_wait_desc的值（如果备份需要的话会返回LOG_BACKUP）。

?

如何备份事务日志？

我们已经提过，如果不首先进行至少一次完整备份是不能进行日志备份的。事实上，你的数据库要运行在完整恢复模式，但从未备份过的话，它不是运行在完整恢复模式里的。数据库会是在自动截断模式里直到第一次完整备份完成。

?

数据库备份，完整，日志或者其他方面的，使用BACKUP命令进行备份。这个命令接受很多选项，它的文档在这里：https://msdn.microsoft.com/zh-cn/library/ms186865. aspx 。但是，它最基本的，进行完整备份到磁盘的命令如下：

?

1 BACKUP DATABASE DatabaseNameTO DISK ='FileLocation\DatabaseName.bak';

如果这是第一个进行的备份，DatabaseName.bak会在指定目录里创建。如果已经存在这样的文件，默认会在那个文件增加一个序号。为了避免这个行为，保证任何已存的文件被覆盖，我们可以使用如下的INIT选项：

?

1 BACKUP DATABASE DatabaseNameTO DISK ='FileLocation\DatabaseName.bak'WITH INIT;

通常，每个连续的备份会有一个唯一的名称；在下个部分，恢复到灾难点会有详细介绍。

?

在每个定期（例如每天）完整备份后，会有频繁（每小时）的日志备份，这个的基本命令非常简单：

?

1 BACKUP LOG DatabaseNameTO DISK ='FileLocation\DatabaseName_Log.bak';

?

存储日志备份

?

很明显，数据和日志文件备份不应该和服务器存储在同个硬盘。如果那个硬盘硬件失败的话，你的所有备份会和原数据文件一起丢失，备份就没用了。文件应该备份到独立的设备，或备份到本地另一个硬盘或网络映射硬盘。

?

日志备份频率

?

在以前的文章提过，你会在每15分钟备份一次日志，甚至更高频率。这样的话，为了避免恢复大量事务日志的需要，你会选择包含有差异备份、事务日志备份穿插的完整备份计划。

?

实际上，备份计划经常会在理想和现实之间妥协，即在真正丢失数据的风险和公司涉及缓解磁盘花费之间。很多非常重要的业务程序使用稍微简单，但严谨的备份计划，可能涉及每晚定期的完整备份和每小时的日志备份。

?

日志备份的频率也会由数据库提交的日志数决定。对于非常忙碌的数据库，频繁备份来控制日志大小是很有必要的。

?

计算日志备份的频率是没有简单的方法。大多数DBA会采用对于日志应该备份频率的最佳估计，然后观察文件的增长情况，需要的话再调整备份计划来阻止过度增长。

?

日志链和如何中断它

?

已经提过，没有第一次至少一次的完整备份是不能进行事务日志备份的。为了恢复数据库到某个时间点，要么到特定日志备份的结尾或特定日志的某个时间点，必须要有完整不截断的日志记录链，从在完整（或差异备份）后的第一个日志备份，刚好一直到灾难时间点。这被称为日志链（log chain）。

?