SQLServer实战日记--日志传送中断问题排查

来源:互联网 发布:国密算法 编辑:程序博客网 时间:2024/05/20 17:06

背景

给客户搭建了一个日志传送,从A服务器通过日志传送到B服务器,B服务器作为报表服务器,可以查询一些报表.架构如下图:


但是今天突然告诉我,他们的日志传送不同步了,辅助服务器上面没有最新的数据。

问题排查

打开辅助服务器上面的作业活动监视器,检查作业的执行情况:

果然还原日志的作业发生了错误。


点开查看详情,可以看到错误如下:原来是正在还原的文件太新了,无法应用到辅助服务器.此文件我2017-12-17 17:00的文件


但是查看上一条历史记录可以看,上次还原的日志记录是2017-12-17 16:30


所以问题是发生在2017-12-17 17:00 的备份上,  此时我们检查主服务器的日志备份:

SELECT    backup_set_id,        database_name,        (CASE type            WHEN 'd'THEN'完整'            WHEN 'i'THEN'差异数据库'            WHEN 'l'THEN'日志'            ELSE type          END)AS backuptype,        b.physical_device_name,        backup_start_date,        backup_finish_date,        recovery_model,first_lsn,last_lsn,checkpoint_lsn,database_backup_lsnFROM    msdb.dbo.backupset a        INNER JOIN msdb.dbo.backupmediafamily b ON a.media_set_id=b.media_set_id                  where backup_start_date>'2017-12-17 13:26:13.000'  --缩小范围到这个时间左右and database_name='dname'ORDER BY a.backup_finish_date

仔细检查这一时间段的日志备份,发现17:00 我们进行了两次日志备份,而他的后缀最后4位数字只是也非常接近,一个是0000,一个是0001


特别注意:上图中的备份文件后缀的时间和备份开始的时间是不匹配的。在查看日志记录的时候要以备份文件的后缀时间为准。

然后在对比,两个备份文件的first_lsn发现了问题所在:0001的first_lsn  是小于0000备份文件的first_lsn。但是在日志传送的还原日志作业中,会先还原0000这个日志文件。

所以,在最开始的错误会提示,日志文件太新的问题。


解决办法

对0000  和 0001两个文件互换后缀名。让日志传送的restore 作业先去还原日志序列号更早的那个文件。重新启动作业。从下图可以看到0000 这个文件,已经正常被还原。日志传送同步的问题解决。