alert日志中的两种ORA错误分析(r6笔记第21天)

今天在巡检系统的时候,发现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';

OWNER                          TABLE_NAME                     TYP  TYPE_NAME                      DEF DEFAULT_DIRECTORY_NAME          REJECT_LIMIT                      ACCESS_
------------------------------  ------------------------------ --- ------------------------------ ---  ------------------------------ ----------------------------------------  -------
ACCESS_PARAMETERS                                                                 PROPERTY
--------------------------------------------------------------------------------  ----------
SYS                            ET$00E73C1D0001                SYS  ORACLE_DATAPUMP                SYS IMPDP20130506                   UNLIMITED                         CLOB
DEBUG = (0 , 0) DATAPUMP INTERNAL  TABLE "XXDATA"."CONSUME_LOG_XXXX_BEFORE201201    ALL

可以清晰的看到是在之前做impdp的时候抛出了错误,这个表是Impdp过程中产生的临时表。 还有一个思路就是在expdp/impdp等操作时,在数据库日志中也会有一定的信息标识,但是尝试查看数据库日志,这个问题是好几年前的了,几年前的alert日志已经被清空了,所以也无法求证在当时问题发生的时候到底是什么样的一个情况。 解决问题的步骤就很简单了,需要直接删除这个外部表即可。

SQL> drop table "ET$00E73C1D0001"; Table dropped. 通过这个案例可以看到,对于这些ORA错误还是需要通过日志来一步一步分析,逐个击破,可以大胆猜想,但是要小心求证,问题了解清楚了,解决起来都是很容易的。

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

原文发表时间:2015-08-07

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏乐沙弥的世界

Oracle 实例恢复

Oracle实例失败多为实例非一致性关闭所致,通常称为崩溃(crash)。实例失败的结果等同于shutdown abort。

14550
来自专栏乐沙弥的世界

Oracle 基于用户管理恢复的处理

Oracle支持多种方式来管理数据文件的备份与恢复来保证数据库的可靠与完整。除了使用RMAN工具以及第三方备份与恢复工具之外,基于

7320
来自专栏Hadoop实操

如何使用StreamSets实现Oracle中变化数据实时写入Kudu

1.1K50
来自专栏「3306 Pai」社区

浅析ProxySQL用户管理

对于读写分离特别重要,保证了同一个事务中所有的语句都会路由到同一组示例,防止出现同一个事务中,上下文数据不一致的情况。例如,在不开启这个属性的情况下:

32910
来自专栏数据和云

案发现场:被注入的软件及 ORA-600 16703 灾难的恢复

最近帮助一个客户恢复数据库,遇到了如下这个问题。让我们再一次惊醒于数据安全,如果不做好防范,问题总是会来得猝不及防。

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

关于Oracle重启数据库的一个bug(r5笔记第50天)

关于drop database在oracle中是致命的操作,这个操作自己在测试环境中体验过,会完全删除数据文件,因此这个操作非常敏感但是实用性不强,不过话说过来...

36640
来自专栏乐沙弥的世界

Oracle 表空间时点恢复(TSPITR)

表空间时点恢复,是Oracle在基于冷备,热备恢复以外的一种以表空间为粒度的,不完全恢复的形式来将表空间恢复到过去某个特定的时间点的一种恢复方式。它整合了RMA...

15320
来自专栏乐沙弥的世界

SYSAUX表空间管理及恢复

SYSAUX表空间是在10g之后引入的一个新的表空间,主要用于减轻对SYSTEM表空间的压力而作为SYSTEM表空间的辅助表空间。

12320
来自专栏乐沙弥的世界

关于undo表空间配置错误的ORA-30012

      undo表空间是Oracle体系结构的重要组成部分,为什么我们可以回滚,就是因为有它。数据库任意数据的修改都会在undo表空间里生成前镜像,一是可以...

7710
来自专栏C++

Windows核心编程:第5章 作业

16010

扫码关注云+社区

领取腾讯云代金券