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 这个文件,已经正常被还原。日志传送同步的问题解决。
阅读全文
1 0
- SQLServer实战日记--日志传送中断问题排查
- SQL实战日记--数据库文件还原问题排查
- SQLServer 事务日志传送
- SqlServer 日志传送
- SQLSERVER日志传送,设置,监控,角色转移
- SQLSERVER日志传送,设置,监控,角色转移
- sqlserver 2005 高可用性架构 日志传送
- sqlserver 2005 高可用性架构 日志传送
- sqlserver 2005 高可用性架构 日志传送
- sqlserver 2005 高可用性架构 日志传送
- 线上操作与线上问题排查实战
- 线上操作与线上问题排查实战
- 线上操作与线上问题排查实战
- 线上操作与线上问题排查实战
- 线上操作与线上问题排查实战
- spring问题排查-调低日志等级
- 通过jstack日志分析和问题排查
- sql server日志传送导致的问题
- MD与MT
- Linux下Tomcat8.5安装与环境配置图文教程
- caffe 安装方法(python)
- presenter
- python与自然语言处理之朴素贝叶斯下
- SQLServer实战日记--日志传送中断问题排查
- java练习题13
- 海外运营商码
- python 与自然语言处理之语言模型n-gram
- 老年代泄漏与MetaSpace
- Apache的安装
- Spark一些常用的数据处理方法-1.RDD计算
- HDFS中的三个node
- [数据][json格式] 2016年统计用区划代码和城乡划分代码