/*
服务器: 消息 4305，级别 16，状态 1，行 2
此备份集中的日志开始于 LSN 641000000005900001，该 LSN 太晚，无法应用到数据 库。包含 LSN 641000000005600001 的较早的日志备份可以还原。
服务器: 消息 3013，级别 16，状态 1，行 2
RESTORE LOG 操作异常终止。
*/
相信这个信息只要是做过备份的人都知道，在应用完整备份＋日志备份恢复数据库时提示只能应用数据库备份，而日志备份由于LSN太早或太晚无法应用，这是怎么回事阿？？？LSN表示事务日志记录的唯一序号，SQL SERVER会记录对数据库的每次操作，这些操作总有个先来后到的，LSN就是系统发给他们的顺序号，日志备份恢复时要求所有的备份集叠加时能生成一个连续的LSN链，这个就是问题所在(如果对上述日志概念不了解的话可以阅读精华区SQL日志概念这一篇,或是看BOL)。查看下备份文件就可以知道答案
restore headeronly from disk = 'd:\tohen_dat.bak' --数据库备份
restore headeronly from disk = 'd:\tohen_log.bak' --日志备份
结果（我只列出了比较有用的几项）
―――――――――――――――――――――――――――――――――――――
Position FirstLsn LastLsn
1 641000000005400001 641000000005600001 --数据备份
1 641000000005900001 641000000006100001 --日志备份
―――――――――――――――――――――――――――――――――――――
position表示这个设备中备份集的位置，不是可以在一个设备里多次备份的吗？每备份一次就生成一个备份集，按先后顺序一直排列下来，Position就可以定位你想应用那个备份集，对应于restore中的with file的值，这里我只备份了一次，所以就只有一个集
FirstLsn和LastLsn:分别标识这个备份集中的起始事务链号和终止事务链号
当你运用这两个备份还原数据库时，系统会读取备份集的头信息，判断这些链号是不是连续的，很显然数据备份最后的是641000000005600001，日志开头的是641000000005900001，中间差了一截，所以从这个以后的所有日志备份都不能运用了，就像火车车厢一样，前面断了，你后面连得再好也跑不起来，你会发现有时候日志的FirstLsn会小于数据的LastLsn,这个也征实了日志备份是从上次日志备份结尾处开始的说法，但日志备份的LastLsn不能小于数据备份的LastLsn
一般容易出现像这种日志脱节的操作是切换恢复模型，从简单切换到完全恢复，很多新手都是这样，数据库建好了用了几天，做个完整备份，然后在做日志备份，结果报错说简单模型不能做日志备份，于是切换到完全模型继续日志备份，这样日志链就脱节了，解决方法是备份后用restore headeronly查看下日志链是否完整，不完整的话需要重做完整备份或差异备份，再继续日志备份，如果到数据库出现故障时再检查，那你就准备卷铺盖走人吧