我们可以把这个过程理解为火车的工作机制。火车头（完整数据库备份）和车厢（日志备份序列）之间首尾相接，所以我们可以从头走到尾。如果车头和车厢之间发生断裂（不正确的完整数据库备份），我们就只能开走火车头了（将数据库恢复到完整数据库备份完成的即时点）！同样，如果车厢之间发生断裂（事务日志备份序列断裂），我们就只能走到相连接的部分（恢复连续的日志备份序列），其余部分没有任何意义！
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 Serve
r 2005的尾日志备份的原理。
很显然，我们必须将这一段特殊的日志（最后日志备份完成时刻～故障点发生时刻）备份下来，从而使从完整数据库备份时刻到故障点时刻的所有日志备份序列是完整的！如图14-6所示。
图14-6 尾日志备份
14.1.5 尾日志备份
因此，要想完成故障点的恢复，就必须完成尾日志的备份。接下来我们就来学习尾日志的相关话题。
1．尾日志的存储
首先一个问题，尾日志存储在哪里？
很显然，答案是当前的日志文件中。当前日志文件保存的内容包括了最后一个成功的日志备份到当前故障点所有的事务。
所以，一旦最后一个日志文件备份和故障点之间数据库的日志文件不幸发生介质故障，比如存放日志文件的硬盘损坏，那么这种情况下，上帝也无法挽救一个DBA的命运！
由此可以看出，日志文件对数据库，对DBA的重要性！
所以如果无法完成尾日志备份，则只能将数据库恢复到创建最后一个事务日志备份时的点。自上一次事务日志备份后对数据库所做的更改将丢失，必须手工重做。
2．与正常日志备份的区别
与正常日志备份相似，尾日志备份将捕获所有尚未备份的事务日志记录。但尾日志备份与正常日志备份在下列几个方面有所不同。
— 如果数据库损坏或离线，则可以尝试进行尾日志备份。仅当日志文件未损坏且数据库不包含任何大容量日志更改时，尾日志备份才会成功。如果数据库包含要备份的、在记录间隔期间执行的大容量日志更改，则仅在所有数据文件都存在且未损坏的情况下，尾日志备份才会成功。
— 尾日志备份可使用COPY_ONLY选项独立于定期日志备份进行创建。仅复制备份不会影响备份日志链。事务日志不会被尾日志备份截断，并且捕获的日志将包括在以后的正常日志备份中。这样就可以在不影响正常日志备份过程的情况下进行尾日志备份，例如，为了准备进行在线还原。
— 如果数据库损坏，则尾日志可能会包含不完整的元数据，这是因为某些通常可用于日志备份的元数据在尾日志备份中可能会不可用。使用CONTINUE_AFTER_ ERROR进行的日志备份可能会包含不完整的元数据，这是因为此选项将通知进行日志备份而不考虑数据库的状态。
14.2 尾日志备份
对于将数据库恢复到即时点，很好理解也很好操作。下面我们重点来研究将数据库恢复到故障点时必不可少的操作，即尾日志备份。
但是，需要注意的是，如果在Management Studio中按照默认设置是永远无法完成尾日志备份的。
14.2.1 图形化尾日志备份操作
图14-7所示为选择日志备份的数据库的【选项】选项卡。默认情况下选择的是【截断事务日志】单选按钮，这样将永远无法备份尾日志。
提示：要完成尾日志备份，需要在图14-7中选择“备份日志尾
部，并使数据库处于还原状态”选项。