数据库11g升级中一次奇怪的问题 (30天)

客户的测试环境已经从10g升级到11g了。但是没过几天,数据hang住了,登都登不了了,而且通过sys,system,普通用户连接的错误都不一样

首先通过 一下命令来查看变量和进程是否都正常

 ps -ef|grep smon  
echo $ORACLE_SID

没发现问题

--使用sys,显示连接到一个空实例
sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Tue Aug 13 14:51:25 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> 
--使用system连接,显示是oracle不在状态,这和standby物理备库在apply的时候连接进来的情况类似,但是这个库压根没用dataguard。
sqlplus system/xxxx@TEST
SQL*Plus: Release 11.2.0.2.0 Production on Tue Aug 13 14:49:17 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
ERROR:
ORA-01033: ORACLE initialization or shutdown in progress
Process ID: 0
Session ID: 0 Serial number: 0
--使用普通用户连接,显示oracle实例不可用
sqlplus TEST/TEST
SQL*Plus: Release 11.2.0.2.0 Production on Tue Aug 13 14:52:51 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
ERROR:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory
Process ID: 0
Session ID: 0 Serial number: 0

我查看alert日志的时候就发现了如下的错误在日志中反复出现。

ORA-20011 ORA-29913 and ORA-29400 , KUP-XXXXX Errors
-----------------from alert log------------------------

Tue Aug 13 22:00:04 2013
XDB installed.
XDB initialized.
Tue Aug 13 22:00:17 2013
Begin automatic SQL Tuning Advisor run for special tuning task  "SYS_AUTO_SQL_TUNING_TASK"
End automatic SQL Tuning Advisor run for special tuning task  "SYS_AUTO_SQL_TUNING_TASK"
Tue Aug 13 22:00:24 2013
DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.
Errors in file /dbccbsPT1/oracle/xxxx/oradmp/bdump/diag/rdbms/xxxx/xxxx/trace/xxxx_j000_17725.trc:
ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout
ORA-29400: data cartridge error
KUP-11010: unable to open at least one dump file for fetch
Tue Aug 13 22:25:18 2013
Errors in file /dbccbsPT1/oracle/xxxx/oradmp/bdump/diag/rdbms/xxxx/xxxx/trace/xxxx_j002_17729.trc:
ORA-12012: error on auto execute of job "SYS"."ORA$AT_SA_SPC_SY_133"
ORA-20000: ORU-10027: buffer overflow, limit of 20000 bytes
ORA-06512: at "SYS.DBMS_ADVISOR", line 201
ORA-06512: at "SYS.DBMS_SPACE", line 2465
ORA-06512: at "SYS.DBMS_SPACE", line 2538
Wed Aug 14 02:00:00 2013
Closing scheduler window
Closing Resource Manager plan via scheduler window
Clearing Resource Manager plan via parameter

查看对应的trace文件,发现如下的日志

Starting background process VKRM
Tue Aug 13 22:00:00 2013
VKRM started with pid=31, OS id=17443 
trace file1:
*** 2013-08-13 22:00:24.222
*** SESSION ID:(6238.93) 2013-08-13 22:00:24.222
*** CLIENT ID:() 2013-08-13 22:00:24.222
*** SERVICE NAME:(SYS$USERS) 2013-08-13 22:00:24.222
*** MODULE NAME:(DBMS_SCHEDULER) 2013-08-13 22:00:24.222
*** ACTION NAME:(ORA$AT_OS_OPT_SY_132) 2013-08-13 22:00:24.222
ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout
ORA-29400: data cartridge error
KUP-11010: unable to open at least one dump file for fetch
*** 2013-08-13 22:00:24.230
DBMS_STATS: GATHER_STATS_JOB: GATHER_TABLE_STATS('"SYSTEM"','"TEST_TABLE_TARGET_EXT"','""', ...)
DBMS_STATS: ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout
ORA-29400: data cartridge error
KUP-11010: unable to open at least one dump file for fetch
*** 2013-08-13 22:00:24.252
DBMS_STATS: GATHER_STATS_JOB: GATHER_TABLE_STATS('"SYSTEM"','"TEST_TABLE_SOURCE_EXT"','""', ...)
DBMS_STATS: ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout
ORA-29400: data cartridge error
KUP-11010: unable to open at least one dump file for fetch

这个问题很容易和其他外部的原因联系起来,首先是实例不可用的问题,想要查问题,连都连不进去。 本来打算使用Hanganalyze来分析一下。但sqlplus连不进去,

sqlplus -prelim /nolog之后再connect / as sysdba也不行

最后和Unix team的人沟通了一下,他们有完整的备份,

我记得前几天storage好像有问题了,和他们的人确认了下,他们最后发现时storage的问题,及时的修复了。

实例可以连上了。查看alert还是发现会有如上alert里面的ora 错误,我就有点凌乱了。从metalink上可以看到这个问题很可能是datapump相关的问题导致的

排除了job中有datapump相关的job,注意力集中在了外部表上

我采用了如下的方式

SQL> spool obj.out
SQL> set linesize 200 trimspool on
SQL> set pagesize 2000
SQL> col owner form. a30
SQL> col created form. a25
SQL> col last_ddl_time form. a25
SQL> col object_name form. a30
SQL> col object_type form. a25
SQL> 
SQL> select OWNER,OBJECT_NAME,OBJECT_TYPE, status,
  2  to_char(CREATED,'dd-mon-yyyy hh24:mi:ss') created
  3  ,to_char(LAST_DDL_TIME , 'dd-mon-yyyy hh24:mi:ss') last_ddl_time
  4  from dba_objects
  5  where object_name like 'ET$%'
  6  /
no rows selected
SQL> select owner, TABLE_NAME, DEFAULT_DIRECTORY_NAME, ACCESS_TYPE
  2  from dba_external_tables
  3  order by 1,2
  4  /
OWNER                          TABLE_NAME                     DEFAULT_DIRECTORY_NAME         ACCESS_
------------------------------ ------------------------------ ------------------------------ -------
SYSTEM                         TEST_TABLE_SOURCE_EXT        DATA_PUMP_DIR                  CLOB
SYSTEM                         TEST_TABLE_TARGET_EXT        DATA_PUMP_DIR                  CLOB

查询到如上的两个外部表,基本可以找到问题了。

--使用system连接上来,看看那个表

SQL> conn system/xxx
Connected.
SQL> select count(*)from  TEST_TABLE_SOURCE_EXT;
select count(*)from  TEST_TABLE_SOURCE_EXT
*
ERROR at line 1:
ORA-29913: error in executing ODCIEXTTABLEOPEN callout
ORA-29400: data cartridge error
KUP-11010: unable to open at least one dump file for fetch

发现 报错正式alert中的错误,仔细分析了下,是因为我的这个外部表的directory当时是用了系统中默认的data_pump_dir,升级以后ORACLE_HOME改变了,所以原本的dump所在的目录就不可用了。

因为那两个外部表是之前临时抽取数据用的,所以可以删掉了。

SQL> drop table TEST_TABLE_SOURCE_EXT;
Table dropped.
SQL> drop table TEST_TABLE_TARGET_EXT;
Table dropped.

隐患排除了,alert再没有报这个错。一切正常了。

metalink中对于这个问题的原因描述如下:Doc ID 1274653.1

CAUSE

The primary cause of this issue is that an external table existed at some point in time but does not now. However, the database still believes the table exists since the dictionary information about the object has not been modified to reflect the change. When DBMS_STATS is run against the table in question, it makes a call out to the external table which fails because the object is not there. There are many reasons that an external table may not exist including:

  • Temporary Datapump external tables have not been cleaned up properly. The dictionary information should have been dropped when the DataPump jobs completed.
  • An External table has been removed without clearing up the corresponding data dictionary information. For example: Oracle Demo Schema Tables such as the external table “SALES_TRANSACTIONS_EXT” may have been removed but the dictionary has not been updated to reflect this. The "SALES_TRANSACTIONS_EXT" table is an external table in the "SH" schema which is one of Demo Schema provided by Oracle.

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

原文发表时间:2014-04-02

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏乐沙弥的世界

PL/SQL 包编译时hang住的处理

       最近PL/SQL包在编译时被hang住,起初以为是所依赖的对象被锁住。结果出乎意料之外。下面直接看代码演示。

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

创建index 使用Online导致的问题(95天)

在本地的测试库中,本来空间就不足,结果创建了一个表有600多万条记录,想创建一个index. 物理段有340多M. 临时段大小有100M,结果想创建一个索引,总...

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

备库查询导致的ORA-01110错误及修复(r8笔记第67天)

最近帮助业务部门解决了一个技术问题,因为发现有数据问题需要对存在问题的数据做分析。当然一个难点就是把数据给筛选出来,当我看到他们提供的语句,在备 库做了简单的数...

3467
来自专栏乐沙弥的世界

Oracle expdp 时遭遇ORA-39125 ORA-04063

    数据库在使用DataPump导出时碰到了ORA-39125与ORA-04063。完整的ORA-39125提示是Worker unexpected fat...

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

关于exp/imp的总结学习(r4笔记第26天)

关于exp/imp,是很常用的数据导出导入工具,在10g开始推出的数据泵datapump相当于是exp/imp的补充和升级版本。在后续章节再做一个总结。 exp...

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

生产环境sql语句调优实战第六篇(r2笔记91天)

生产环境中有大量的sql语句在运行,尽管有awr,ash做数据的收集统计,但是dba的调优工作大多数情况都是在问题已经发生后做排查的,有些sql语句可能执行的时...

2784
来自专栏乐沙弥的世界

Linux/Unix shell 自动发送AWR report

     观察Oracle数据库性能,Oracle自带的awr 功能为我们提供了一个近乎完美的解决方案,通过awr特性我们可以随时从数据库提取awr报告。不过...

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

ORA-01113问题的简单分析(r6笔记第3天)

在启动数据库的时候,open阶段总是可能出现各种各样的问题, 比如让人胆战心惊的错误。 ORA-01113: file 1 needs media recov...

2955
来自专栏乐沙弥的世界

Linux/Unix shell 自动导出Oracle数据库

       使用shell脚本实现对Oracle数据库的监控与管理将大大简化DBA的工作负担,如常见的对实例的监控,监听的监控,告警日志的监控,以及数据库的备...

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

关于两个简单问题的分析(r9笔记第10天)

工作中碰到问题当然是见怪不怪了,而处理这些问题也是我们的价值所在。 今天处理了几个看起来比较有意思的小问题,当然究其原因,要不是不规范,要不就是基本功不够扎实。...

3054

扫码关注云+社区

领取腾讯云代金券