oracle数据泵导入分区表统计信息报错(五)导致问题的原因

现在已经找到了问题的原因,并且也找到了解决问题的方法,但是导致问题的原因还不清楚。

也就是说,要找到为什么这几个分区表的统计信息被锁住。

Oracle的DBMS_STATS包提供了LOCK_TABLE_STATS过程,但是当前的问题显然不是手工调用这个过程造成的。

所有了一下metalink,发现Oracle在文档Doc ID: 433240.1中描述了统计信息被锁定的可能性:

手工执行DBMS_STATS包的LOCK_TABLE_STATS过程;

使用imp或impdp,导入表的时候不加载数据,会锁住表的统计信息;

在升级过程中,队列表的统计信息可能被锁定。

前面已经排除了手工执行LOCK_TABLE_STATS的可能性,而出现问题的表又不是队列表,显然第二种情况导致问题的可能性最大。

由于迁移确实是用IMP和IMPDP实现的,但是由于距离迁移的时间太长,导致一些具体的操作已经记不清了。而且由于服务器空间的问题,一些迁移时的log脚本已经被清除掉了。因此找到当时具体的操作很困难了。

如果根据当时的迁移步骤,是不存在只导入结构而没有导入数据的情况的。

根据记忆描述一下迁移的步骤:

在9i的源数据库用exp导出了数据;

由于要转换表空间,以及去掉物化视图日志等信息,避免导入过程对产品环境导致的危害,设立了一个10g的中间数据库;

在中间数据库上手工建立了分区表,然后用imp指定ignore=y导入所有的表;

在中间数据库进行数据的清理工作;

在中间数据库执行expdp导出;

在目标数据库上执行impdp导入。

如果说发生过imp操作,可能在中间数据库上执行过。不过检查统计信息的生成时间,实在对象的创建之后,而且间隔几个小时之久:

SQL> conn zhejiang输入口令: 已连接。

SQL> set pages 100 lines 120

SQL> alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';

会话已更改。

SQL> select object_name, created

2 from user_objects a, user_part_tables b

3 where a.object_name = b.table_name

4 and a.object_type = 'TABLE';

OBJECT_NAME CREATED

------------------------------ -------------------

CON_LOG_LIST_ITEM 2007-05-03 10:17:40

ORD_ORDER 2007-05-03 10:18:06

ORD_ORDER_ITEM 2007-05-03 10:18:15

ORD_PURCHASE_ITEM 2007-05-03 10:18:26

ORD_LOG_HIT_COMM 2007-05-03 11:12:34

EMED_WEB_LOG 2008-06-24 17:06:59

已选择6行。

SQL> select a.table_name, last_analyzed

2 from user_tables a, user_part_tables b

3 where a.table_name = b.table_name;

TABLE_NAME LAST_ANALYZED

------------------------------ -------------------

CON_LOG_LIST_ITEM 2007-05-03 15:33:19

ORD_ORDER 2007-05-03 15:23:42

ORD_ORDER_ITEM 2007-05-03 15:30:25

ORD_PURCHASE_ITEM 2007-05-03 15:33:17

ORD_LOG_HIT_COMM 2007-05-03 15:33:45

EMED_WEB_LOG 2009-08-09 01:07:31

已选择6行。

这说明在对象导入后,成功的收集过一次统计信息。

莫非是在系统迁移之后,执行过IMP或IMPDP的导入,这个问题的产生和迁移没有关系。统计信息的收集时间与迁移时间发生在同一天,且间隔比较接近,而且此后这些分区表就没有再被分析过,要说这个问题和迁移没有关系,显然难以令人信服。更重要的是,除了迁移过程,平常基本上没有可能对产品环境执行IMP或IMPDP的操作。

由于系统上的日志信息已经都丢失了,只能依靠数据库中保存的信息了。

检查数据库中对象的创建时间,看看能否发现一些什么:

SQL> select object_name, object_type, created

2 from user_objects

3 where created < to_date('2007-5-4', 'yyyy-mm-dd')

4 order by created;

OBJECT_NAME OBJECT_TYPE CREATED

------------------------------ ------------------- -------------------

CON_LOG_LIST_ITEM TABLE PARTITION 2007-05-03 10:17:40

CON_LOG_LIST_ITEM TABLE PARTITION 2007-05-03 10:17:40

CON_LOG_LIST_ITEM TABLE 2007-05-03 10:17:40

CON_LOG_LIST_ITEM TABLE PARTITION 2007-05-03 10:17:40

CON_LOG_LIST_ITEM TABLE PARTITION 2007-05-03 10:17:40

CON_LOG_LIST_ITEM TABLE PARTITION 2007-05-03 10:17:40

ORD_ORDER TABLE PARTITION 2007-05-03 10:18:06

ORD_ORDER TABLE PARTITION 2007-05-03 10:18:06

ORD_ORDER TABLE 2007-05-03 10:18:06

本文URL地址:http://www.bianceng.cn/database/Oracle/201410/45383.htm

时间: 2024-10-07 09:58:30

oracle数据泵导入分区表统计信息报错(五)导致问题的原因的相关文章

oracle数据泵导入分区表统计信息报错(二) 深入研究问题的现象

今天在进行数据泵导入操作时,发现一个bug. 上一篇记录了问题的现象,这一篇继续深入研究. 上一篇文章已经描述了问题的产生,而且提到了这个问题很难重现.无论如何去模拟实际的情况,都无法重现问题. 为了重现这个问题,在RAC数据库环境中,仿照问题表创建了分区表.并仿照问题数据库收集了统计信息的方式进行了统计信息的收集,都无法重现问题. 但是,利用问题数据库导出的统计信息,就可以重现问题.上周五发现的问题,但是由于数据不方便带回家,因此由于时间的限制仅仅测试了这么多. 今天一早到了公司,就继续这个问

oracle数据泵导入分区表统计信息报错(一) 问题的现象

今天在进行数据泵导入操作时,发现一个bug. 数据库版本Oracle 10203 for Solaris RAC,执行导入在处理表的统计信息时报错,错误信息为:ORA-39083和ORA-917. 经过仔细排查,对比源数据库分析情况和目标数据库的表分析情况,发现所有的分区表的统计信息都没有导入. 基本确认问题是IMPDP在处理分区表的统计信息时出现了问题. 可惜现在问题无法通过构造案例来重现:在目标数据库中(RAC环境)尝试建立分区表并执行数据泵的导出和导入,无法重现问题.将源数据库中出现问题的

oracle数据泵导入分区表统计信息报错(三)

前不久检查了一篇以往的BLOG,意外的发现这个bug居然被我忘记了,时隔一年继续解决这个问题. 根据上一篇文章所介绍的分析过程,基本上可以确认和这几张分区表的统计信息本身有关. 由于当前数据库是从920环境EXP导出,IMP导入到同版本的中间数据库,最终通过数据泵IMPDP导入到当前数据库的.而分区表由于无法解决表空间的转换问题,因此在中间数据库手工创建,在IMP导入的时候指定了IGNORE=Y参数. 而现在恰好问题出在这个用户的所有分区表上,难道问题和迁移的过程有关系.检查了当时的脚本,没有发

oracle数据泵导入分区表统计信息报错(四)问题的解决过程

看来通过检查数据字典信息是找不到什么问题的原因了,只有通过手工执行收集统计信息的过程来尝试发现问题. 为了避免bug意外被解决所导致的问题无法重现,同时也为了可以在解决bug的过程中使用一些特别的手段而不影响用户的使用,这里通过备份建立了一个测试环境,下面的操作是在测试环境中执行. 首先修改统计信息对应的JOB的NEXT_DATE,使其在后台执行,检查收集统计信息后,测试数据库上是否能重现问题: SQL> SELECT JOB, WHAT FROM USER_JOBS; JOB WHAT ---

oracle数据泵不同工作方式性能比较(五)测试NETWORK_LINK导入方式

根据Oracle的文档的描述,数据泵采用不同的方式导出导入,性能也会有明显的差别,这次正好有机会测试一下,迁移表空间.直接路径.外部表方式,以及数据库链方式导出.导入的性能差异. 这篇测试NETWORK_LINK导入方式. 首先清除上一篇文章中导入的用户和表空间,并重新建立测试用户和表空间. SQL> DROP USER TJSQ_NDMAIN CASCADE; User dropped. SQL> DROP USER TJSQ_TRADE CASCADE; User dropped. SQL

oracle 数据泵导入导出介绍_oracle

1.首先建立目录: create directory 目录名称 as '数据库服务器上的一个目录',如: create directory 别名 as 'd:\服务器目录名'; 将导入或导出的文件放在这个目录下 2.导出及导入 以SID=orcl,导出dmp的账号为test,导入dmp的账号为test为例. 若将数据从sfz中导出: expdp test/test@orcl directory=别名 dumpfile=导出文件名 导入到test中: impdp test/test@orcl di

Oracle数据泵导出导入与传统导出导入的区别

 估计有不少的朋友不清楚Oracle数据泵导出导入与传统导出导入的区别吧,下面小编为各位介绍一下,有兴趣的朋友不防进入一起参考.   先来看一下Oracle数据泵导出导入例子 1.首先建立目录: create directory 目录名称 as '数据库服务器上的一个目录',如:  create directory 别名 as 'd:\服务器目录名';  将导入或导出的文件放在这个目录下 2.导出及导入 以SID=orcl,导出dmp的账号为test,导入dmp的账号为test为例. 若将数据从

oracle 10g数据泵和导入导出性能对比(五)影响数据泵导入性能的最大因素

前一段时间在一次迁移中同时用到了数据泵和EXP,发现二者效率的差别还是相当大的.这里通过一个例子简单比较一下. 这篇文章讨论影响数据泵导入性能的最大因素. 前面写了几篇文章,分别介绍EXP/IMP与EXPDP/IMPDP的性能对比,根据前面几篇文章的描述,如果不使用并行,似乎IMPDP的效率要比IMP没有一个数量级的提示.对于当前的环境而言,事实确实如此.不过前面一直没有描述一个重要的因素,当然的数据库环境由于配置了STANDBY数据库,因此不但处于归档模式,还设置了FORCE LOGGING:

Oracle 11g r2数据泵新特性简介(四)数据泵导入新增的DATA_OPTIONS

Oracle的11gr2版本中,并没有对数据泵做出多大的改动,主要是增加了对原始版本参数的支持,并且去掉了一些小的限制. 这一篇介绍数据泵导入新增的DATA_OPTIONS参数. 在11.2之前,数据泵的导入只提供了一个DATA_OPTIONS--SKIP_CONSTRAINT_ERRORS,而在11.2中,DATA_OPTIONS又增加了一个可用的值:DIABLE_APPEND_HINT. 一般来说我们希望数据泵使用直接路径的方式导入,因为导入的效率会很高.但是有的时候,我们并不需要采用直接路