事务日志备份与恢复 1

最新推荐文章于 2022-01-31 19:33:03 发布

weixin_34292959

最新推荐文章于 2022-01-31 19:33:03 发布

阅读量194

点赞数

文章标签：数据库

原文链接：http://www.cnblogs.com/dragonlhf/archive/2008/09/05/1284977.html

版权

本章要点

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

† 尾日志备份

† 产生备份集

† 将数据库恢复到故障点

† 备份恢复中的疑难问题

一个不懂事务日志的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 事务日志备份与恢复原理

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

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