核心提示：事务日志是大部分数据库中必具备的一项功能。通过管理管理事务日志，可以将数据库恢复到一个数据库管理员任意指定的一个点，如数据库或者应用程序发生故障的那一个点。不过对于SQLServer 2008数据库来说，在管理事务日志的时候有一个比较特殊的地方，即结尾日志备份。

一、 结尾日志备份的含义。

由于结尾日志备份是SQLServer数据库特有的一个内容。所以对于从其他数据库转型过来的管理员可能并不了解这个结尾日志备份的含义。在大多数情况下，如在完成恢复模式或者大容量日志恢复模式下，SQLServer数据库要求管理员备份事务日志的结尾部分以获得尚未备份的日志记录。这个在还原操作之前对日志尾部执行的日志备份就叫做结尾日志备份。对于SQLServer数据库来说，在事务日志恢复之前进行事务日志的尾部备份是非常必要的。因为结尾日志备份作业可以防止用户修改数据的丢失并最终确保日志链的完整性。在利用事务日志将数据库恢复到某一个指定的点，如数据库故障点的时候，结尾日志备份是恢复计划中的最后一个相关备份。如果在还原之前无法备份日志的尾部，那么就只能够将数据库恢复为故障发生之前创建的最后一个备份。而不能够恢复到故障发生的那一点。所以说，结尾日志备份对于SQLServer数据库非常的重要。

二、 在何时该进行结尾日志备份?

从结尾日志备份的含义中，我们也可以看出，并不是在任何情况下都需要作结尾日志备份。也就是说，对于SQLServer数据库来说，并非所有的还原方案都需要执行结尾日志部分。如在数据库恢复的时候，不需要恢复到故障的那一点，就不需要进行结尾日志备份。同理，如果先前的日志备份中已经包含了恢复点，或者说管理员准备覆盖某个数据库或者移动数据库的时候，往往不需要进行结尾日志备份。另外需要的是，在某些特定情况下即使数据库管理员想进行事务日志尾部备份都不行。如当事务日志文件已经损坏时就无法继续进行事务日志尾部备份。此时虽然数据库管理员任人可以在不使用结尾日志备份的情况下恢复数据库，但是已经不能够恢复到故障发生的那一点。也就是说，最新日志备份后进行的任何数据修改工作与数据库结构调整工作都回丢失。

具体的来说，如果遇到如下两种情况，需要先对马上对事务日志进行尾部备份。

一是需要对数据库进行还原操作，而且是要还原到最近到的一个点时，那么需要先对数据库进行事务日志尾部备份。即在数据库处于联机状态时，如果数据库管理员需要对数据库进行的下一个操走就是还原操作，那么就需要在还原操作之前进行事务日志尾部备份。也就是说，在还原操作之前才能够进行事务日志尾部备份，即在事务日志备份备份与数据库还原之间不能够再进行任何的数据库修改作业。否则的话在还原后这个修改会丢失。另外需要注意的是，为了出现一些不必要的错误，最好在备份事务尾部日志的时候，采用NORECOVERY选项。这个选项主要是为了确保数据库事务日志尾部备份之后数据库不能够再被修改。也就是说，可以保证事务日志尾部备份到数据库还原中间的时间间隔之内，不再发生任何的数据库更改作业。以确保在利用事务日志尾部备份进行数据库还原的时候，能够还原到一个最近的时点。而不会有任何数据的丢失。这是在最正常的情况下对事务日志的尾部进行备份。

二是需要注意，有时候可能由于一些特殊的原因，数据库已经处于脱机状态，或者数据库重新启动后已经无法启动了，此时数据库管理员仍然要尝试着进行结尾日志备份。数据库管理员需要注意的是，此时数据库事务日志结尾备份不一定能够成功，但是数据库管理员在恢复数据库之前仍然要做一个最后的尝试。也许运气好的话，事务日志尾部备份能够成功进行。一般情况下，如果遇到数据库脱机或者无法启动时，即数据库发生故障时，只有当当前的事务日志文件没有受到损坏、数据库处于支持结尾日志备份的状态并且不包含任何大容量日志更改时，结尾日子会备份才能够同时成功。也就是说，当数据库损坏时，只有同时满足三个条件，分别为日志文件没有损坏、数据库处于支持结尾日志备份的状态、不包含任何大容量的日志更改，事务日志尾部备份才会成功。但是在实际工作中，发生这种情况时，要让数据库管理员判断数据库当前的状态是否符合这三种情况，往往具有一定的困难，甚至是一种苛刻的要求。所以笔者的建议是，数据库管理员如果遇到这种情况，先不管三七二十一，先对事务日志的尾部进行备份。另外需要注意的是，此时即使能够正确备份事务日志结尾部分，也有可能其中的部分数据不可用。即仍然有可能存在部分数据的丢失。虽然这是数据库管理员极不愿意看到的，但是这个事实毕竟存在。数据库管理员应该正确面对。在数据库损坏时如果要进行事务日志尾部备份，则需要采用比较特殊的选项。如一般需要在备份语句中采用NO_TRUNCATE选项，否则的话备份不会成功。