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

今天开发的同事找到我,让我帮他们补一部分数据,因为有一个表的数据已经快一个月没有增量数据了,这个需求听起来有些奇怪是不? 问题的背景是在统计库中存在一个表,供部分应用做统计分析,每天会根据时间生成一条记录,这条记录汇总的数据会作为统计分析所用。但是每天的这一条增量数据的源头来自于另外两个在线交易库。两个库中的数据会做一些关联,大体的实现思路就是下面的形式。 现在OLAP的库中的表里的部分增量数据没有按照时间增加,所以对前端应用的统计造成了一定的影响。 当然对于DBA而言,这部分逻辑还是未知的,可能跨业务部门的原因,开发的同事也是一头雾水,所以这个问题还得我来捋一捋。 有了基本的思路,这个问题的分析其实也是水到渠成。因为之前也做过类似的一些数据修补工作。 首先确定了用户和环境,对应的表为POINT_PEIPING,而且得知每天会定时往这个表中插入数据,那么一个很明显的思路就是使用了scheduler或者crontab插入数据了。 crontab很容易排除了,那么只有scheduler了。看看TEST用户下有哪些对象。 $ sh findobj.sh TEST peiping ################################# OWNER OBJECT_NAME OBJECT_TYPE STATUS CREATE_DAT -------------------- ------------------------------ -------------------- ------- ---------- TEST POINT_PEIPING TABLE VALID 2011-03-01 TEST PEIPING PROCEDURE VALID 2011-12-02 TEST LOAD_PEIPING JOB VALID 2011-03-02 ################################# 有了这个结果,马上就有了思路和方向,对应的存储过程应该是PEIPING,在JOB load_peiping中调用,然后把数据插入point_peiping中。 存储过程PEIPING的代码为: procedure peiping as begin insert into point_peiping_tl select a.created,a.remark||b.remark from test.sum_user_point@db70 a, test.SUM_USER_PRESENT_POINT@gcdb b where trunc(a.created,'dd')=trunc(b.created,'dd') and a.created=to_date('20111201','yyyymmdd'); commit; end; 但是仔细查看,联系业务数据,总是感觉哪里不对劲,因为这个存储过程实现不了增量的数据插入,只能满足2011年的某一天的业务需求,所以这个存储过程的有效性还有待验证。 那么我们来看看JOB的定义。 JOB的定义可以使用如下的语句得到。可以看到确实没有使用刚所说的存储过程PEIPING,而是直接采用了pl/sql的形式,放在了job定义里面。 从下面的这个逻辑可以很清楚的看到还是两个数据源,采用了db link的形式进行关联,插入的是按照时间来界定的增量数据。 SQL>select dbms_metadata.get_ddl('PROCOBJ', 'LOAD_PEIPING',SCHEMA=>'TLBB') from dual; BEGIN dbms_scheduler.create_job('"LOAD_PEIPING"', job_type=>'PLSQL_BLOCK', job_action=> 'begin insert into point_peiping_tl select a.created,a.remark||b.remark from test.sum_user_point@db70 a, test.SUM_USER_PRESENT_POINT@gcdb b where a.created >=trunc(sysdate,''dd'') and b.created>=trunc(sysdate,''dd'') and trunc(a.created,''dd'')=trunc(b.created,''dd''); commit; end;' , number_of_arguments=>0, start_date=>TO_TIMESTAMP_TZ('01-MAR-2011 12.00.00.000000000 AM +08:00','DD-MON-R RRR HH.MI.SSXFF AM TZR','NLS_DATE_LANGUAGE=english'), repeat_interval=> 'FREQ=DAILY;BYHOUR=2;BYMINUTE=0;BYSECOND=0' , end_date=>NULL, job_class=>'"DEFAULT_JOB_CLASS"', enabled=>FALSE, auto_drop=>FALSE,comments=> NULL ); dbms_scheduler.set_attribute('"LOAD_PEIPING"','logging_level',DBMS_SCHEDULER.LOG GING_RUNS); dbms_scheduler.enable('"LOAD_PEIPING"'); COMMIT; END; 那么问题到此就有些奇怪了,看JOB定义也没有问题,那为什么增量数据会插入不了呢。 开发的同事坚称之前是好好的,突然有一段时间就收不到数据了。当然我们还是需要验证一下,是否这个JOB发生了些变更。 JOB执行的历史情况可以采用下面的方式来过滤查询。我们查看TEST用户在100天以内的JOB执行情况。 select log_date,owner,job_name,status,ADDITIONAL_INFO from DBA_SCHEDULER_JOB_LOG where log_date>sysdate-100 and owner='TEST' and job_name='LOAD_PEIPING' and rownum<10; 29-NOV-15 02.00.02.558857 AM +08:00 TLBB LOAD_PEIPING SUCCEEDED 01-DEC-15 02.00.02.002850 AM +08:00 TLBB LOAD_PEIPING SUCCEEDED 可以看到在去年年底的时候确实是执行成功的。 那么现在为什么不执行了呢,自己也花了一些时间去查看JOB的定义和有效性是否有问题,当然还是带着疑问查看了最近的执行情况。 SQL> select log_date,owner,job_name,status from DBA_SCHEDULER_JOB_LOG where log_date>sysdate-2 and owner='TLBB' and job_name='LOAD_PEIPING' and rownum<10; 02-MAR-16 02.00.00.511295 AM +08:00 TLBB LOAD_PEIPING FAILED 01-MAR-16 02.00.00.415397 AM +08:00 TLBB LOAD_PEIPING FAILED JOB最近确实执行了,不过从执行情况来看是执行失败了。那么为什么执行失败了呢,如果这个问题能够定义到,对于解决问题来说就是如何添翼了。 最后一顿翻箱倒柜,发现有个视图会定义一个概要的信息 select * from DBA_SCHEDULER_JOB_RUN_DETAILS where log_date>sysdate-2 and owner='TEST' and job_name='LOAD_PEIPING' and rownum<10 1662118 02-MAR-16 02.00.00.512815 AM +08:00 ORA-12541: TNS:no listener ORA-06512: at line 2 1661601 01-MAR-16 02.00.00.416300 AM +08:00 ORA-12541: TNS:no listener 信息显示在最近两天JOB确实都执行了,但是抛出了ORA-12541的错误,相关联的一个错误是TNS的错误。 明白了这一点,排查问题就有了明确的方向,对job中涉及的db link进行连接检查。发现确实抛出了同样的问题。 $ tnsping TLBB_GAMECENTER Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.127.xxxxx)(PORT = 1529))) (CONNECT_DATA = (SERVICE_NAME = gcdb)(server=dedicated))) TNS-12541: TNS:no listener ORA-06512: at line 2 明白了这一点之后,问题的分析就很顺畅了。发现原来是某一台OLTP的库做了灾难切换,但是在这个统计库中没有修改对应的连接IP地址,导致了JOB从那个时候起就不再同步增量数据了。 所以修复了这个问题之后,以后就不会担心开发的同学每隔一段时间就找我来补数据了。

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

原文发表时间:2016-03-02

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

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

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

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

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

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

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

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

关于enq: TX - allocate ITL entry的问题分析(r3笔记第66天)

今天发现系统在下午1点左右的时候负载比较高,就抓取了一个最新的awr报告. Snap IdSnap TimeSessionsCursors/SessionB...

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

dataguard添加临时数据文件的bug(r7笔记第27天)

有一个环境是10gR2,一主两备,因为10g的备库还不是active,所以有一些查询的需求的时候,我们还是会打开相应的窗口时间。 开发的同学需要做一个大查询,数...

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

数据库负载急剧提高的应急处理(二) (r9笔记第55天)

对于之前碰到的一个数据库负载急剧提升的问题,做了应急处理之后,我们需要再冷静下来,来看看是哪些地方出现了问题,还需要哪些改进。 首先第一个问题就是为什么会突然负...

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

DBA和开发同事的一些代沟(三)(r7笔记第29天)

之前写了两篇关于DBA和开发同事的一些代沟,产生了一些共鸣,本身写这个的目的就是能够让DBA也试着从开发的角度来理解问题,开发同学也能够多学习一些DB的知识,D...

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

linux kernel引发的oracle问题及解决

最近测试环境的连接数老是不够用,session/process 都相应的从5000提到了8000,但还是不够,而且还是不断有新环境需要增加。最后根据评估,ses...

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

关于dblink锁定带来的问题(r3笔记第20天)

可能在一些分布式环境中,有一些数据访问都需要用到db link。从某种程度上来说dblink是很方便,但是从性能上来说还是有一些的隐患。如果两个环境之间的网络情...

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

通过shell绑定系统进程调优 (r4笔记第34天)

数据库的性能调优,需要基于操作系统的性能指标,如果操作系统级发生了一些状况,那么会潜移默化的影响到数据库层面。而数据库中对应的进程和操作系统级也有一定的映射关系...

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

记一次数据同步需求的改进(二) (r7笔记第5天)

在之前写过记一次数据同步需求的改进(一) (r7笔记第2天)之后,就开始着手对这个需求进行实践。 所谓实践出真知,在实际做的时候才发现可能计划的再好,做的时候还...

3998

扫码关注云+社区

领取腾讯云代金券