增量数据丢失的原因分析(三)(r8笔记第91天)

今天开发的同事找到我说,他们发现一个应用今天应该会同步过来一部分数据,但是今天却没有,所以想让我帮忙看看到底是怎么回事。 对于这类需求也算是轻门熟路,不光维护管理数据,补数据也在行。看来今天又不可避免要修复数据了,不过还是得明白原因是什么。 首先查看了近几天的数据同步情况,时间范围是5月1日~5月6日,但是查看却唯独缺少了5月5日的数据,因为是计算前一天的数据变化情况,所以5月6日应该会同步5月5日的数据变化。 TRUNC(UPDATE_DATE) COUNT(*) ------------------- ---------- 2016-05-02 00:00:00 6724 2016-05-03 00:00:00 6198 2016-05-04 00:00:00 5772 2016-05-01 00:00:00 7268 至于数据为什么没有同步,确实有些奇怪,这个时候先来理一理数据同步的原理,其实这个库是一个OLAP的库,会从OLTP的库中抓取变化的数据情况更新到OLAP的统计库中。而同步的驱动方式是通过scheduler的方式来完成,每天凌晨会定时同步。 使用下面的方式来查看最近10天的scheduler job的运行情况,发现只有今天运行失败。 select log_date,owner,job_name,status,ADDITIONAL_INFO from DBA_SCHEDULER_JOB_LOG where log_date>sysdate-10 and owner='TEST' and job_name like '%USER%' ORDER BY 1 ; LOG_DATE OWNER JOB_NAME STATUS ----------------------------------- -------------------------- ----------- 27-APR-16 03.28.14.044366 AM +08:00 TEST SYN_USERCENTER SUCCEEDED 。。。 05-MAY-16 03.28.32.538013 AM +08:00 TEST SYN_USERCENTER SUCCEEDED 06-MAY-16 03.28.23.809575 AM +08:00 TEST SYN_USERCENTER FAILED 那么问题就看起来有了方向,是由于scheduler job失败导致的数据同步失败。 到底是什么原因导致的呢,可以查看一个视图来得到一些相关的信息。 select log_date,owner,job_name,status,ADDITIONAL_INFO from DBA_SCHEDULER_JOB_RUN_DETAILS where log_date>sysdate-10 and owner='TEST' and job_name like '%USER%' ORDER BY 1 ; 得到的信息是一个ORA错误:ORA-12170: TNS:Connect timeout occurred 这个时候使用tnsping的方式来连接那个目标库,发现没有了响应,超时退出。 而这个问题明白了原因之后,依然很蹊跷,这个环境一直没有动过,也没有做过系统层面的网络变化,到底是什么原因导致的呢。 对于这个问题,从数据库层面,系统层面还真分析不出来什么特别之处。所以就求助网络组的同学。 目前是10.11.133.128的服务器去telnet 10.11.65.112的服务器,但是通过几次简单的测试,在65.112端看到133.128的ip却会有多种变化。有时候是10.11.133.128,有时候是10.11.134.129 # tcpdump -i eth0 host 10.11.133.128 and port 1528 -nn tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:49:57.314010 IP 10.11.133.128.51355 > 10.11.65.112.1528: Flags [F.], seq 1003407519, ack 3632754879, win 49640, length 0 16:49:57.314095 IP 10.11.65.112.1528 > 10.11.133.128.51355: Flags [F.], seq 1, ack 1, win 115, length 0 16:49:57.316199 IP 10.11.133.128.51355 > 10.11.65.112.1528: Flags [.], ack 2, win 49640, length 0 16:49:59.098833 IP 10.11.133.128.51382 > 10.11.65.112.1528: Flags [S], seq 1012926596, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0 16:49:59.098877 IP 10.11.65.112.1528 > 10.11.133.128.51382: Flags [S.], seq 233530546, ack 1012926597, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 16:49:59.101376 IP 10.11.133.128.51382 > 10.11.65.112.1528: Flags [.], ack 1, win 49640, length 0 # tcpdump -i eth0 host 10.11.134.129 and port 1528 -nn tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:41:25.055791 IP 10.11.134.129.50758 > 10.11.65.112.1528: Flags [S], seq 778963631, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0 16:41:25.055848 IP 10.11.65.112.1528 > 10.11.134.129.50758: Flags [S.], seq 3056729568, ack 778963632, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 16:41:30.126448 IP 10.11.65.112.1528 > 10.11.134.129.50758: Flags [S.], seq 3056729568, ack 778963632, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 16:41:30.211652 IP 10.11.134.129.50758 > 10.11.65.112.1528: Flags [R], seq 778963632, win 49640, length 0 对于这种情况,查看了133.128的网卡配置情况,e1000g0存在一个漂移的IP,即10.11.133.128,而另外一个IP 10.11.134.129则来自一个新的网卡e1000g1 e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.11.133.129 netmask ffffff00 broadcast 10.11.133.255 e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.11.133.128 netmask ffffff00 broadcast 10.11.133.255 e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4 inet 10.11.134.129 netmask ffffff00 broadcast 10.11.134.255 查看路由的信息,可以看到目前是存在两个默认路由,分别从133,134网段进行过滤。 $netstat -rn Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- default 10.11.133.254 UG 1 28179 default 10.11.134.254 UG 1 28129 10.11.133.0 10.11.133.128 U 1 7961 e1000g0:1 10.11.133.0 10.11.133.129 UG 1 0 10.11.134.0 10.11.134.129 U 1 1308 e1000g1 224.0.0.0 10.11.133.129 U 1 0 e1000g0 而这个也是目前导致测试中发现源端的IP一会是133.128,一会又是134.129 当然还有更多的网络内容我也没接受得了。不过可以看出网络这块还是存在着一小窍门。 最终在65.112开通了这两个IP的防火墙之后,看起来问题是初步解决了,后续还需要更多的验证。 而留给我的就是修复数据,这个还是需要结合里面的业务来根据需求来补充那部分没有同步的数据。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2016-05-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

Oracle Database 12.2新特性详解

在2015年旧金山的Oracle OpenWorld大会上,Oracle发布了Database 12.2的Beta版本,虽然Beta版本只对部分用户开放,但是大...

3677
来自专栏IT大咖说

开源NewSQL – CockroachDB在百度内部的应用与实践

4222
来自专栏文渊之博

史上最大的CPU Bug(幽灵和熔断的OS&SQLServer补丁)

背景 原文地址(http://www.cnblogs.com/wenBlog/p/8435229.html) 最近针对我们的处理器出现了一系列的严重的bug。这...

3745
来自专栏美团技术团队

美团点评数据平台Kerberos优化实战

30510
来自专栏MongoDB中文社区

9月.精华文章推荐

1.《GDPR: Impact to Your Data Management Landscape:Part 3 》

1252
来自专栏数据和云

备份,迁移和克隆Docker镜像

编辑手记:上周我们分享了在MAC上安装Docker并部署Oracle 12.2数据库环境,基于Docker构建测试环境,非常快速和简捷。只通过以下几个步骤即可快...

5134
来自专栏微信终端开发团队的专栏

微信移动端数据库组件 WCDB 系列:数据库修复三板斧(二)

之前一篇文章《微信 SQLite 数据库修复实践》介绍了微信对SQLite数据库修复以及降低损坏率的实践, 这次再深入介绍一下微信数据库修复的具体方案和发展历程...

5850
来自专栏ThoughtWorks

phantomJs之殇,chrome-headless之生 | 洞见

技术雷达快讯:自2017年中以来,Chrome用户可以选择以headless模式运行浏览器。此功能非常适合运行前端浏览器测试,而无需在屏幕上显示操作过程。在此之...

4056
来自专栏数据库新发现

Oracle数据恢复:格式化、ASM及字典损坏案例三则

链接:http://www.eygle.com/archives/2010/06/asm_format_dictionary.html

1392
来自专栏杨建荣的学习笔记

一个简单的bigfile tablespace无法扩展的案例处理 (r8笔记第31天)

最近帮助开发的同学处理了一个简单的问题,想通过这个问题来反思一下。 在一天下午的时候,开发的同事突然找到我说,有一个开发的数据库貌似有些表空间的问题,...

2927

扫码关注云+社区

领取腾讯云代金券