转载

增量数据丢失的原因分析（三)

今天开发的同事找到我说，他们发现一个应用今天应该会同步过来一部分数据，但是今天却没有，所以想让我帮忙看看到底是怎么回事。
对于这类需求也算是轻门熟路，不光维护管理数据，补数据也在行。看来今天又不可避免要修复数据了，不过还是得明白原因是什么。
首先查看了近几天的数据同步情况，时间范围是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的防火墙之后，看起来问题是初步解决了，后续还需要更多的验证。
而留给我的就是修复数据，这个还是需要结合里面的业务来根据需求来补充那部分没有同步的数据。

正文到此结束