一个月之前配置了日志传送的数据库，在今天早上收到作业警报："LSRestore_ServerName_Databasename"运行失败，到历史记录中查看，错误信息如下
消息 2016-12-21 09:05:16.58 *** 错误: 文件“R:\logshipbak\DatabaseName\DatabaseName_20161220211515.trn”太新，无法应用到辅助数据库“DatabaseName”。(Microsoft.SqlServer.Management.LogShipping) *** 2016-12-21 09:05:16.58 *** 错误: 此备份集中的日志开始于 LSN 20135000001405400001，该 LSN 太晚，无法应用到数据库。可以还原包含 LSN 20135000001404800001 的较早的日志备份。 RESTORE LOG 正在异常终止。(.Net SqlClient Data Provider) *** 2016-12-21 09:05:16.62 正在搜索更旧的日志备份文件。辅助数据库:“DatabaseName”
查看源库和目标库上的日志备份文件，并没有差别。而且“LSCopy_ServerName_DataBaseName”并没有出现过失败。
在这种情况下，LSN不应该会出现中断的。
翻查源端的SQLAgent，才发现在配置日志传送之前，这个库是有配置定时作业来备份日志的。
找到问题，那就容易解决了。
1、把定时作业备份的日志，传送到目标端
2、手动还原传送过来的备份日志
restore log DatabaseName from disk = 'R:\logshipbak\DataBaseName_backup_2016_12_21_050116_5617233.trn' with norecovery ;
3、对作业“LSRestore_ServerName_Databasename”手动开始步骤（这步可以省略，为了确保无误，还是建议执行一次）
4、停掉源端上的每天凌晨备份日志的作业（这步比较重要，否则，可能还会出现类似的问题）
思考：为什么日志传送都已经配置了那么久，到今天才会出现错误呢？
Answer：因为在配置之后到今天为止，在SQLAgent中定时执行备份日志时，几乎没有访问，就没有写入日志，所以LSN号保持不变，但在出错误的那个时间段内，源端的“LSBackup_ServerName_Databasename”这个作业产生的日志约25M。证明在那个时间段内是有事务在执行的。 而SQLAgent中定时执行备份日志备份了一部分的LSN号，结果就导致不连续了。