2、删减事务日志

　　我在联机环境中见过的最普遍的设置之一就是下面的数据库维护计划表：

　　日志备份

　　索引重建

　　全备份

　　删减日志

　　每三十分钟做日志备份

　　在这里实际完成的是索引重建，而且执行了全备份。到目前为止，一切还算正常，不是吗?实际上，日志被删减会打断日志链，这会使所有日志备份变得无用，直到下次执行全备份。这是因为日志序列号（Log sequence Number，简称LSN）链被删减日志操作中断了。

　　无论什么时候事务出现时，事务日志中就会写进去一个日志序列号。在执行备份时，第一个日志序列号和最后一个日志序列号都包含在备份中，被写到了日志备份的头位置。在日志被恢复时，日志备份中的日志序列号必须是连续的。如果他们不连续，那么SQL Server就认为日志记录丢失了，日志备份不能恢复了。

　　在这种情况下，全备份可以恢复到数据库。不幸的是，所做的日志备份没用了。这是因为包括在事务日志备份中的最后一个日志序列号与在日志删减后的第一份事务日志备份中的日志序列号不相同，因为删减日志命令改变了日志的序列号。

　　我所见到的另一种十分常见的场景是删减日志，然后执行全备份。这中做法会好一点，但是也强不到哪里去。如果全备份被破坏的话，任何在删减（truncate）语句和下一次全备份之间的事务都不能被恢复。这是为什么呢?因为既然删减日志步骤会重置日志序列号，你就不能从两天前恢复全备份，然后向前滚动所有事务日志。是的，把日志转换为简单恢复模式做的实际也是一样的事。

　　如果你打算删减你的事务日志，以便你可以进行收缩，那么请将屏幕向上滚动，把上面的内容再读一遍。

　　现在，如果你不需要完整的事务日志记录，而是让数据库完全恢复，那么你应该把数据库改为简单恢复模式。这种方式的事务日志不会增长，因为日志条目将被覆盖，而不是保存到下一次日志备份。