alert日志中的两种ORA错误分析

今天在巡检系统的时候,发现alert日志中有两种类型的ora错误。
Errors in file /U01/app/Oracle/diag/rdbms/XX/XX/trace/xxdb_j002_20401.trc:
 ORA-12012: error on auto execute of job "XXDATA"."S_XXXX_HIST_OPS_SERINFO_K"
 ORA-12170: TNS:Connect timeout occurred
 ORA-06512: at "XXDATA.L_XXXX_HIST_OPS_SERINFO_K", line 6
 ...
 DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.
 Errors in file /U01/app/oracle/diag/rdbms/XX/XX/trace/xxdb_j003_21375.trc:
 ORA-20011: Approximate NDV failed: ORA-06564: object IMPDP20130506 does not exist
而且时间错误的间隔还很短,初步感觉这两种ORA错误似乎是有关联的,我们一个一个来分解这些ora错误。
首先查看第一种错误的trace日志,根据提示是job运行有问题,甚至指向了对应的代码部分,显示是超时错误。而在对应的代码里面可以看到其实是用到了db link,但是连接信息发生了变化,导致db link对应的数据库不可访问,结果就出现了超时的问题,最后在运行的时候抛错。
*** 2015-08-04 06:01:00.448
 *** SESSION ID:(389.3953) 2015-08-04 06:01:00.448
 *** CLIENT ID:() 2015-08-04 06:01:00.448
 *** SERVICE NAME:(SYS$USERS) 2015-08-04 06:01:00.448
 *** MODULE NAME:(DBMS_SCHEDULER) 2015-08-04 06:01:00.448
 *** ACTION NAME:(S_XXXX_HIST_OPS_SERINFO_K) 2015-08-04 06:01:00.448
 ORA-12012: error on auto execute of job "XXDATA"."S_XXXX_HIST_OPS_SERINFO_K"
 ORA-12170: TNS:Connect timeout occurred
 ORA-06512: at "XXDATA.L_XXXX_HIST_OPS_SERINFO_K", line 6
明白了问题,解决的思路相对来说就容易了很多,一种是解决db link的连接问题,另外一种是把job给禁用或者删除,经过确认选择第二种方法。
 使用dba_jobs来查看对应的job信息,竟然查不到对应的job,其实需要查看的是scheduler部分,在10g有了重大的改变。
select job_name ,status,owner from DBA_SCHEDULER_JOB_LOG where owner='xxxxx'
根据条件能够找到对应的job了,然后在sys下直接调用dbms_scheduler来禁用Job.

SQL>  exec dbms_scheduler.DISABLE('S_XXXX_HIST_OPS_SERINFO_INUSE',force=>true);

BEGIN dbms_scheduler.DISABLE('S_XXXX_HIST_OPS_SERINFO_INUSE',force=>true); END;
*

ERROR at line 1:

ORA-27476: "SYS.S_XXXX_HIST_OPS_SERINFO_INUSE" does not exist

ORA-06512: at "SYS.DBMS_ISCHED", line 4407

ORA-06512: at "SYS.DBMS_SCHEDULER", line 2737

ORA-06512: at line 1
报出的错误还是有些奇怪,仔细查看日志,其实默认是会从当前的schema下查找对应的job. 指定对应的schema就可以了。

SQL>  exec dbms_scheduler.DISABLE('XXDATA.S_XXXX_HIST_OPS_SERINFO_INUSE',force=>true);
PL/SQL procedure successfully completed.
第一类问题的解决告一段落,我们来看看第二种问题,是不是和第一类相关。
 第二类中的trace也比较有限,但是能够看出来是在做统计信息收集的时候报出了错误。所以从这一点来看应该和第一类问题没有直接的联系,根据错误提示是有一个对象找不到,通过字面意思可以看出来似乎和datapump有关。
DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.
 Errors in file /U01/app/oracle/diag/rdbms/xxxx/xxxx/trace/bidb_j003_21375.trc:
 ORA-20011: Approximate NDV failed: ORA-06564: object IMPDP20130506 does not exist
对于这个对象,问题还是能够简单复现的。
SQL> select count(*) from "ET$00E73C1D0001";
 select count(*) from "ET$00E73C1D0001"
                      *
 ERROR at line 1:
 ORA-06564: object IMPDP20130506 does not exist
对象既然不存在,那就使用desc来看看,到底可以不,但是desc又可以。
 从这一点来说,这个对象还是有点特别。
SQL> desc "ET$00E73C1D0001";
  Name                                                                                                              Null?    Type
  ----------------------------------------------------------------------------------------------------------------- -------- ----------------------------------------------------------------------------
 ID                                                                                                                        NUMBER(15)
  SN                                                                                                                        VARCHAR2(24)
  GROUP_ID                                                                                                                  NUMBER(6)
  SERVER_IP                                                                                                                  VARCHAR2(15)
  SERVER_NAME                                                                                                                VARCHAR2(40)
  WORD                                                                                                                      NUMBER(4)
  SERVER                                                                                                                    NUMBER(4)
  SCENE                                                                                                                      NUMBER(4)
  CN_GUID                                                                                                                    VARCHAR2(30)
  BUY_TIME                                                                                                                  DATE
  JEWEL_TOTAL                                                                                                                NUMBER(7)
  CN                                                                                                                        VARCHAR2(80)
  CHARACTER_PUT                                                                                                              VARCHAR2(50)
  IP                                                                                                                        VARCHAR2(15)
  WEAPONID                                                                                                                  NUMBER(15)
  PUT_DATE                                                                                                                  DATE
  WEAPONID_NEW                                                                                                              NUMBER(15)
  COUNT                                                                                                                      NUMBER
  USER_CLASS                                                                                                                NUMBER
  CONSUME_WAY                                                                                                                VARCHAR2(40)
通过上面的信息,可以很容易联想到应该是datapump中的临时表之类的,可能在上次datapump做expdp或者Impdp的时候出现了问题,结果这个临时表保留了下来。在做统计信息收集的时候就报出了错误。
 但是上面还仅仅是个猜想,怎么验证呢,还是通过一个数据字典表dba_external_tables
 select *from dba_external_tables where table_name='ET$00E73C1D0001';

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/92b0595d66fd3bc3348b63d066909bdd.html