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

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语句。