zoukankan      html  css  js  c++  java
  • MSSQL日志传送出现“LSN 太晚,无法应用到数据库”

      一个月之前配置了日志传送的数据库,在今天早上收到作业警报:"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号,结果就导致不连续了。 

  • 相关阅读:
    使用Redis实现分布式锁
    SpringBoot 定时任务的使用
    HTTP请求调试软件 Postman
    ElasticSearch的安装
    全文搜索 简介
    SpringBoot整合Redis
    Git 操作远程仓库(Github)
    Git的使用
    Git 简介、下载安装、配置
    Vue 商城的一些小demo(后台添加商品、前台购物车、本地存储的使用)
  • 原文地址:https://www.cnblogs.com/cnzeno/p/6207066.html
Copyright © 2011-2022 走看看