SQLServer实战日记--日志传送中断问题排查
2017-12-21 12:06
232 查看
背景
给客户搭建了一个日志传送,从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_lsn
FROM 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 这个文件,已经正常被还原。日志传送同步的问题解决。相关文章推荐
- SQL实战日记--数据库文件还原问题排查
- dubbo 获取application和ip 打印日志,以便排查问题.
- 一次CMS GC问题排查过程(理解原理+读懂GC日志)
- SQLSERVER日志传送,设置,监控,角色转移
- MySQL实战:MySQL二进制包安装及启动问题排查
- 线上操作与线上问题排查实战
- SQL Server 2000之日志传送功能 - 问题解决
- logrotate 日志清理后 rsyslog中断问题
- myrocks复制中断问题排查
- SQL调优日记--并行等待的原理和问题排查
- 诊断SQLSERVER问题常用的日志
- Sqlserver推荐参数配置及日志收缩问题
- sqlserver 2005 高可用性架构 日志传送
- logrotate 日志清理后 rsyslog中断问题
- 实战 SQL Server 2008 日志传送(Log Shipping)
- SQLServer 2005&08镜像导致日志文件LDF过大的问题解决
- sqlserver 数据库日志文件过大的问题
- 网卡中断占用CPU过高问题排查
- log4j配置日志不显示问题排查方法
- 同时使用数据库镜像和日志传送的问题