事务日志备份与恢复 1

本章要点

† 事务日志备份与恢复原理

† 尾日志备份

† 产生备份集

† 将数据库恢复到故障点

† 备份恢复中的疑难问题

一个不懂事务日志的DBA，是很难掌握数据库的精髓的。事务日志忠实地记录了数据库的活动，所以基于这些记录的活动就可以随心所欲地将数据库的状态恢复到特定的即时点或恢复到故障点。

然而，不是每个DBA都能够正确完成这些操作的。其中的奥秘在哪里呢？

本章深入研究事务日志备份与恢复操作。

14.1 事务日志备份与恢复原理

下面我们首先来学习事务日志备份与恢复的原理。

14.1.1 事务日志备份与恢复原理

事务日志备份只能与完全恢复模型和大容量日志记录恢复模型一起使用。在简单模型下，事务日志有可能被破坏，所以事务日志备份可能不连续，不连续的事务日志备份没有意义，因为基于日志的恢复要求日志是连续的。

可以使用事务日志备份将数据库恢复到特定的即时点（如输入多余数据前的那一点）或恢复到故障点。恢复事务日志备份时，SQL Server 2005重做事务日志中记录的所有更改。当SQL Server 2005到达事务日志的最后时，已重新创建了与开始执行备份操作的那一刻完全相同的数据库状态。如果数据库已经恢复，则SQL Server 2005将回滚备份操作开始时尚未完成的所有事务。

一般情况下，事务日志备份比数据库备份使用的资源少。因此可以比数据库备份更经常地创建事务日志备份。经常备份将减少丢失数据的危险。

图14-1所示为基于完全恢复模型下的1个完全备份＋N个连续的事务日志备份的策略。如果中间的日志备份02删除或者损坏，则数据库只能恢复到日志备份01的即时点。

图14-1 事务日志备份与恢复原理

假如日志备份01、02和03都是完整的，那么在恢复时，先恢复数据库完全备份，然后依次恢复日志备份01、02和03。如果要恢复到故障点，就需要看数据库的当前日志是否完整，如果是完整的，可以做一个当前日志的备份，然后依次恢复日志备份04就可以了。

基于事务日志的备份还可以恢复到某个日志备份中间的时刻，称为时点恢复。比如我们可以在恢复数据库完全备份后，恢复数据库在完全备份和日志备份01中间的某个时刻，这就是时点恢复。这里的时点必须是合法的（看日志备份的时间），而不能超出日志备份的时间序列，否则系统不会执行。比如现在只有日志备份01，其时刻为12:11，假如我们指定恢复到12:12，那么这样的时点是非法的。

14.1.2 事务日志备份连续的奥秘

连续的事务日志备份是备份和恢复事务日志的基本要求。那么，什么样的事务日志备份是连续的呢？

LSN（日志序列号）是用于衡量事务日志备份是否连续的基本方法。

1．连续的事务日志备份

当我们通过备份操作形成备份后，我们可以执行restore headeronly语句来查看备份集中的事务日志备份，判断其是否连续。

restore headeronly from disk='c:"test2.bak'

查看的结果如图14-2所示。

我们可以得出结论：该事务日志备份序列是连续的！为什么呢？

因为这些事务日志备份的LSN首尾连接，后一个日志备份的FirstLSN等于前一个日志备份的LastLSN。

— 日志备份（编号2）：FirstLSN：29000000035800179，LastLSN：29000000047000001。

— 日志备份（编号3）：FirstLSN：29000000047000001，LastLSN：30000000001900001。

— 日志备份（编号4）：FirstLSN：30000000001900001，LastLSN：30000000008100001。

图14-2 实例的事务日志备份序列

因为根据这3个日志备份序列，它记录的事务日志起点是第1个日志备份的FirstLSN：29000000035800179。终点是最后一个日志备份的LastLSN：30000000008100001。

光盘视频："视频"1402.exe（连续的事务日志备份）。

2．不连续的事务日志备份

不连续的日志备份就是指在产生的日志备份序列中，出现了前后首尾不能续接的情况。这种情况主要发生在初学或者刚开始做DBA的读者身上，不断切换数据库的恢复模型，比如从简单恢复模型切换到完全恢复模型，或者从完全恢复模型切换到大容量日志记录模型，这都是DBA的大忌！

假如你的日志备份出现下列情况。那么，这样的日志序列LSN首尾不能衔接，无法连接起来执行恢复操作！

— 日志备份（编号2）：FirstLSN：29000000035800179，LastLSN：29000000047000001。

— 日志备份（编号3）：FirstLSN：30000000001900001，LastLSN：30000000008100001。

提示：DBA一定要千方百计确保当前日志和日志备份序列的安全，同时还要保证日志序列的完整，判断是否完整的方法就是执行restore headeronly语句。

14.1.3 恢复到即时点的奥秘

正是因为有了连续的、完整的事务日志备份序列，配合一个完整数据库备份，我们可以将数据库的状态恢复在日志序列中间的任意一个即时点。

但是，这样做是有前提条件的。

1．正确的完整数据库备份

首先，必须要有一个正确的完整数据库备份，为什么这里要强调“正确”二字呢？如果读者已经对事务日志的连续性概念有正确认识和理解的话，那么这里的“正确”二字就代表完整数据库备份必须是在第1个日志备份序列的时间点之间完成的。

本书配套光盘收录了一个bak备份文件，包括了1个完整数据库备份和3个连续的事务日志备份，我们看到编号为1的是完整数据库备份，其余3个是事务日志备份。如图14-3所示。

图14-3 正确的完整数据库备份

完整数据库备份的日志区间是：29000000035800179～29000000043400001。

第1个事务日志备份的区间是：29000000035800179～29000000047000001。

所以，这里的完整数据库备份就是正确的，因为恢复完整数据库备份，其状态会停留在事务日志备份1中间的某个即时点。然后可以连续执行事务日志备份来进行恢复。

什么是不正确的完整数据库备份呢？

就是完整数据库备份完成的即时点处于日志备份序列之外。如图14-4所示。

图14-4 事务日志备份与恢复原理

提示：永远也不能指望停留在日志备份之外，即时点的完整数据库备份和日志备份能够配合起来进行恢复，因为完整数据库备份和日志备份的日志序列之间产生了中断。

我们可以把这个过程理解为火车的工作机制。火车头（完整数据库备份）和车厢（日志备份序列）之间首尾相接，所以我们可以从头走到尾。如果车头和车厢之间发生断裂（不正确的完整数据库备份），我们就只能开走火车头了（将数据库恢复到完整数据库备份完成的即时点）！同样，如果车厢之间发生断裂（事务日志备份序列断裂），我们就只能走到相连接的部分（恢复连续的日志备份序列），其余部分没有任何意义！

2．正确的即时点

这句话的含义是，永远不要指望将数据库的状态恢复到日志序列记录的LSN区间之外！

这很好理解，因为LSN没有记录的数据库活动，数据库的恢复机制无凭无据，如何恢复？

14.1.4 恢复到故障点的奥秘

无论我们翻阅SQL Server 2005的联机丛书，还是我们查阅有关的资料，都会告诉我们：SQL Server 2005拥有将数据库恢复到故障点的能力！

然而，很遗憾的是，没有一本图书好好地告诉我们作者是如何将数据库恢复到故障点的！

我们首先从原理上来理解恢复到故障点的奥秘，如图14-5所示。

图14-5 恢复到故障点的奥秘

从图中我们可以看出，要将数据库恢复到故障点，必须满足3个条件。

1．正确的完整数据库备份

这个很好理解，而且DBA一般都会做。

2．连续的事务日志备份序列

除非存储设备出现故障，否则这个问题也很好解决。

3．正确备份最后一个日志备份和故障点之间的日志

这一点在目前的SQL Server 2005的图书中几乎没有提到！稍微有点实际经验的DBA（这里是指真正从事大型数据库管理的DBA），肯定会意识到这个问题的严重性！

如果我们按照目前的市面上的其他图书去操作，当某个故障发生的时候，我们永远无法将数据库恢复到故障点，因为我们最多只能将数据库恢复到最后一个日志备份完成的时刻，那么，在最后一个日志备份完成的时刻到故障点之间的日志呢？

等待DBA的将是被老板炒鱿鱼的悲惨命运！

提示：要想将数据库恢复到故障点，就必须深刻理解SQL Server 2005的尾日志备份的原理。

很显然，我们必须将这一段特殊的日志（最后日志备份完成时刻～故障点发生时刻）备份下来，从而使从完整数据库备份时刻到故障点时刻的所有日志备份序列是完整的！如图14-6所示。

图14-6 尾日志备份

14.1.5 尾日志备份

因此，要想完成故障点的恢复，就必须完成尾日志的备份。接下来我们就来学习尾日志的相关话题。

1．尾日志的存储

首先一个问题，尾日志存储在哪里？

很显然，答案是当前的日志文件中。当前日志文件保存的内容包括了最后一个成功的日志备份到当前故障点所有的事务。

所以，一旦最后一个日志文件备份和故障点之间数据库的日志文件不幸发生介质故障，比如存放日志文件的硬盘损坏，那么这种情况下，上帝也无法挽救一个DBA的命运！

由此可以看出，日志文件对数据库，对DBA的重要性！

所以如果无法完成尾日志备份，则只能将数据库恢复到创建最后一个事务日志备份时的点。自上一次事务日志备份后对数据库所做的更改将丢失，必须手工重做。

2．与正常日志备份的区别

与正常日志备份相似，尾日志备份将捕获所有尚未备份的事务日志记录。但尾日志备份与正常日志备份在下列几个方面有所不同。

— 如果数据库损坏或离线，则可以尝试进行尾日志备份。仅当日志文件未损坏且数据库不包含任何大容量日志更改时，尾日志备份才会成功。如果数据库包含要备份的、在记录间隔期间执行的大容量日志更改，则仅在所有数据文件都存在且未损坏的情况下，尾日志备份才会成功。

— 尾日志备份可使用COPY_ONLY选项独立于定期日志备份进行创建。仅复制备份不会影响备份日志链。事务日志不会被尾日志备份截断，并且捕获的日志将包括在以后的正常日志备份中。这样就可以在不影响正常日志备份过程的情况下进行尾日志备份，例如，为了准备进行在线还原。

— 如果数据库损坏，则尾日志可能会包含不完整的元数据，这是因为某些通常可用于日志备份的元数据在尾日志备份中可能会不可用。使用CONTINUE_AFTER_ ERROR进行的日志备份可能会包含不完整的元数据，这是因为此选项将通知进行日志备份而不考虑数据库的状态。