Oracle增量数据丢失的原因分析

今天开发的同事找到我，让我帮他们补一部分数据，因为有一个表的数据已经快一个月没有增量数据了，这个需求听起来有些奇怪是不？
问题的背景是在统计库中存在一个表，供部分应用做统计分析，每天会根据时间生成一条记录，这条记录汇总的数据会作为统计分析所用。但是每天的这一条增量数据的源头来自于另外两个在线交易库。两个库中的数据会做一些关联，大体的实现思路就是下面的形式。

现在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从那个时候起就不再同步增量数据了。
所以修复了这个问题之后，以后就不会担心开发的同学每隔一段时间就找我来补数据了。更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx？tid=12本文永久更新链接地址