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

今天处理的一个问题比较绕,花费了我不少的时间来分析,当然最后发现是拜拜忙碌一场空,还是有一些历史原因。 大体的环境情况如下,有一台线上库OLTP,其中也有会自己的存储过程,job,结合起来处理一些数据,当然作为统计系统而言,目前有两套统计系统STATDB1,STATDB2,都哟裇相关业务的划分,两者会有一些交集。 开发的同学找到我说,统计库STATDB2 有一张表,发现最近两天的数据没有更新,当然开发的同学无从查起,就想让我帮忙看看,现在还是流行逆性工程,所以这个工作就义不容辞交给了我。 我大体梳理了一下,这个表的数据是每天会更新一次,数据库里存在一个存储过程,里面是数据增量的一些逻辑,然后通过scheduler job来调度。 原以为看看存储过程,简单理一理逻辑就可以把数据补上了,但是一看自己也被惊到了,里面的逻辑竟然一环扣一环,大体是下面的情况。

根据STATDB2里面的存储过程的表述,表TABLE的数据会参考STATDB1里面的表TABLE的数据,两者是通过db link依赖。 而STATDB1里面的表TABLE数据是依赖于OLTP的数据,也就是说OLTP里面的数据才是真正的源头,流经STATDB1,STATDB2 看起来还是蛮有挑战,所以我就一层一层的开始解析,但是发现琢磨了一番,自己是实在看不明白了,因为数据的流动情况我自己都说服不了自己,感觉缺少了一些东西。 STATDB2的存储过程是下面的内容,通过一个cursor来从STATDB1里面取得前一天的增量数据,然后插入STATDB2 cursor c1 is select * from tlbb.TEST_USER_CENTER@db84 where FIRST_LOGIN >= trunc(sysdate, 'dd') - 1 and FIRST_LOGIN < trunc(sysdate, 'dd'); 但是我一路分析过来,到了STATDB1里面,发现STATDB1里面的表TABLE竟然没有增量数据,我把范围调整为了300天,发现还是没有任何数据。 SQL> select count(*) from tlbb.TEST_USER_CENTER where FIRST_LOGIN >= trunc(sysdate, 'dd') - 300 and FIRST_LOGIN < trunc(sysdate, 'dd'); COUNT(*) ---------- 0 而STATDB1里的表确实有不少的数据,随机取了几条,发现都是8年以前的了。 SQL> select first_login from tlbb.TEST_USER_CENTER where rownum<30; FIRST_LOGIN ------------------- 2007-03-15 11:31:02 2007-03-15 11:31:03 而在STATDB2里面查询最近的增量数据,数据情况如下: SQL> select count(1),to_char(first_login,'yyyy-mm-dd') from TEST_USER_CENTER where first_login>=to_date('2016-04-10','yyyy-mm-dd') and first_login<to_date('2016-04-23','yyyy-mm-dd') group by to_char(first_login,'yyyy-mm-dd') order by 2; COUNT(1) TO_CHAR(FI ---------- ---------- 5944 2016-04-10 5300 2016-04-11 6012 2016-04-12 5196 2016-04-13 5297 2016-04-14 5428 2016-04-15 6561 2016-04-16 6260 2016-04-17 5076 2016-04-18 所以自己就犯难了,这增量数据到底是哪里来的。 而且反复核对,发现STATDB2里的JOB是早上6点触发,而实际的数据变更是在3点左右,这个也是分析问题的关键,我是通过表数据变更从dba_tab_modification里面得到的论证。 表里的数据最新的变更是在4月19日的早上3点半。 INSERTS UPDATES DELETES CHG_TIMESTAMP TRU DROP_SEGMENTS -------- -------------- --------- -------------------- --- ------------- 207346 19540770 0 2016-04-19 03:30:19 NO 0 所以看来这个job实际上没有产生任何的作用,当然带着严谨的态度,我把这个用户下所有的JOB都看了一遍,重点查看了2点以后的JOB的变更,发现依旧没有任何线索。 最后还是STATDB1里面的JOB让我吃了一剂定心丸。这个JOB虽然存在,但是没有做任何实质性的操作,是个dummy的job. BEGIN dbms_scheduler.create_job('"LOAD_TEST_USER_CENTER"', job_type=>'PLSQL_BLOCK', job_action=> 'begin -- TEST.LOAD_TEST_USER_CENTER_PDAY; dbms_output.put_line(''''); end;' , number_of_arguments=>0, start_date=>TO_TIMESTAMP_TZ('24-NOV-2009 07.15.59.801866000 PM +08:00','DD-MON-RRRR HH.MI.SSXFF AM T ZR','NLS_DATE_LANGUAGE=english'), repeat_interval=> 'FREQ=DAILY;BYHOUR=6;BYMINUTE=0;BYSECOND=0' , end_date=>NULL, .... 所以我再次联系了开发的同学,让他们帮忙梳理一下是否有自定义的JOB,可能会触发数据的增量变化,我这边能够很肯定的证明,数据的增量变更不是在统计库中完成的。 当然在稍后和同事进行了了解,原来这个数据的增量变化是从OLTP主动向STATDB2推送的。 于是我在OLTP的库中查看了最近的调度情况,发现最近两天确实是运行失败的。

SQL>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                         ADDITIONAL
----------------------------------------  ------------------------------ --------------------  ------------------------------ ----------
12-APR-16 03.28.02.318938 AM +08:00      TEST                           SYN_USERCENTER       SUCCEEDED
13-APR-16 03.27.38.337060 AM +08:00      TEST                           SYN_USERCENTER       SUCCEEDED
14-APR-16 03.27.05.682359 AM +08:00      TEST                           SYN_USERCENTER       SUCCEEDED
15-APR-16 03.26.53.582698 AM +08:00      TEST                           SYN_USERCENTER       SUCCEEDED
16-APR-16 03.27.01.285333 AM +08:00      TEST                           SYN_USERCENTER       SUCCEEDED
17-APR-16 03.27.12.866612 AM +08:00      TEST                           SYN_USERCENTER       SUCCEEDED
18-APR-16 03.27.04.888449 AM +08:00      TEST                           SYN_USERCENTER       SUCCEEDED
19-APR-16 03.27.53.720007 AM +08:00      TEST                           SYN_USERCENTER       SUCCEEDED
20-APR-16 02.19.59.855840 AM +08:00      TEST                           SYN_USERCENTER       FAILED
21-APR-16 02.20.00.312195 AM +08:00      TEST                           SYN_USERCENTER       FAILED

而失败的原因,是否有一些方法查到蛛丝马迹。可以查看DBA_SCHEDULER_JOB_RUN_DETAILS找到对应的错误信息。 ORA-00604: error occurred at recursive SQL level 2 ORA-12170: TNS:Connect timeout occurred 有了错误信息,就有了问题分析的方向,很快发现是防火墙的权限不足导致OLTP库的db link连接失败导致增量数据问题。而进一步分析问题,为什么平时防火墙没有问题,最近有了,因为OLTP的库最近做了灾难切换,结果防火墙权限的地方出现了疏漏导致。 明白了这点之后修复就会很自然了。 而通过这个例子可以看出很多问题还是有很多的干扰信息,而且这类历史问题在处理的时候还是需要多了解一些环境的情况和实现方式,对于问题分析还是大有裨益。

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

原文发表时间:2016-04-21

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

分而治之:从多列到自动Oracle 12.2 分区新特性抢先一览

何剑敏 Oracle ACS华南区售后团队,首席技术工程师 曾供职于中国联通信息计费部、卓望数码、IBM。现供职于Oracle ACS华南区售后团队,首席技术...

2663
来自专栏Jerry的SAP技术分享

为什么CRM Opportunity的删除会触发一个通向BW系统的RFC

今天工作时我发现,我在SE38里用函数CRM_ORDER_DELETE删除一个Opportunity,居然弹出下图这个SAP Logon的屏幕,要连接BR1。这...

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

关于降低高水位线的尝试(r3笔记47天)

在前一段时间,生产环境中有几个很大的分区表,由于存在太多的碎片,导致表里的数据就几十条,但是查询的时候特别慢。很明显是高水位线导致的问题。 一般来说这类问题,使...

3456
来自专栏数据和云

深入解析:DB2 V10.5新特性列式存储表的优点与缺点

李培杨 云和恩墨西区交付技术顾问,有多年数据库运维经验,长期服务移动运营商行业客户,熟悉 DB2 数据库故障诊断,数据库迁移升级。

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

一条空间不足报警的分析(r7笔记第1天)

今天下午收到一条报警邮件 ZABBIX-监控系统: ------------------------------------ 报警内容: Free disk ...

3494
来自专栏数据和云

新书连载:深入剖析dump block对数据库的影响

编辑说明:《Oracle性能优化与诊断案例精选》出版以来,收到很多读者的来信和评论,我们会通过连载的形式将书中内容公布出来,希望书中内容能够帮助到更多的读者朋友...

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

结合EM快速解决复杂的配置问题(r4笔记第91天)

图形工具在学习中一般是不作为推荐工具使用的,很多时候可能工作环境都是字符界面,远程连接,基本没有可能接触到图形工具,图形工具的好处真是一把双刃剑,功能丰富全面而...

2956
来自专栏数据和云

【新书连载】诊断Cache buffers chains案例一则

题记:这是某移动运营商在SQL线下审核项目中,协助开发商完善数据库性能的过程。以往开发商遇到此问题总是怀疑是数据库的Bug,试图尝试重启Tuxedo、Weblo...

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

复杂SQL性能优化的剖析(二)(r11笔记第37天)

昨天的一篇文章复杂SQL性能优化的剖析(一)(r11笔记第36天) 分析了一个SQL语句导致的性能问题,问题也算暂时告一段落,因为这个语句的执行频率是1...

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

物化视图中的统计信息导致的查询问题分析和修复 (r7笔记第47天)

今天开发的同事下午反馈给我一个问题,说有操作直接卡住了,听这个描述,感觉很可能是查询慢了。 于是连接到环境中,查看了一下正在执行的sql语句情况,发现下面的语句...

3515

扫码关注云+社区

领取腾讯云代金券