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

看来通过检查数据字典信息是找不到什么问题的原因了,只有通过手工执行收集统计信息的过程来尝试发现问题。

为了避免bug意外被解决所导致的问题无法重现,同时也为了可以在解决bug的过程中使用一些特别的手段而不影响用户的使用,这里通过备份建立了一个测试环境,下面的操作是在测试环境中执行。

首先修改统计信息对应的JOB的NEXT_DATE,使其在后台执行,检查收集统计信息后,测试数据库上是否能重现问题:

SQL> SELECT JOB, WHAT FROM USER_JOBS;

JOB WHAT

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

27 dbms_stats.gather_schema_stats(user, cascade => true);

SQL> EXEC DBMS_JOB.NEXT_DATE(27, SYSDATE)

PL/SQL 过程已成功完成。

SQL> COMMIT;

提交完成。

等待一段时间后检查USER_TABLES,发现除了3个分区表外,其他的对象的统计信息都收集了:

SQL> SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TABLES;

TABLE_NAME LAST_ANALYZED

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

ORD_ORDER_CHECK 2009-08-07 16:11:55

ORD_ORDER_CHECK_TERM 2009-08-07 16:11:55

ORD_ORDER_ITEM_NO_FOSHAN 2009-08-07 16:11:55

ORD_ORDER_ITEM_NO_SHUDE 2009-08-07 16:11:55

ORD_ORDER_OOS_HISTORY 2009-08-07 16:11:57

ORD_ORDER_PAY 2009-08-07 16:12:02

ORD_ORDER_RETURN 2009-08-07 16:16:24

ORD_ORDER_TOTAL_FOSHAN 2009-08-07 16:16:26

ORD_ORDER_TOTAL_SHUDE 2009-08-07 16:16:26

ORD_PURCHASE 2009-08-07 16:16:37

ORD_PURCHASE_ITEM 2007-05-03 15:33:17

ORD_ORDER_ITEM 2007-05-03 15:30:25

ORD_ORDER 2007-05-03 15:23:42

ORD_ORDER_RECEIVE 2009-08-07 16:15:00

已选择14行。

SQL> SELECT TABLE_NAME FROM USER_PART_TABLES;

TABLE_NAME

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

ORD_ORDER

ORD_ORDER_ITEM

ORD_PURCHASE_ITEM

如果JOB自动运行存在问题,那么尝试手工调用RUN过程:

SQL> EXEC DBMS_JOB.RUN(27)

PL/SQL 过程已成功完成。

SQL> SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TABLES;

TABLE_NAME LAST_ANALYZED

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

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

ORD_ORDER_CHECK 2009-08-07 16:23:53

ORD_ORDER_CHECK_TERM 2009-08-07 16:23:54

ORD_ORDER_ITEM_NO_FOSHAN 2009-08-07 16:23:54

ORD_ORDER_ITEM_NO_SHUDE 2009-08-07 16:23:54

ORD_ORDER_OOS_HISTORY 2009-08-07 16:23:56

ORD_ORDER_PAY 2009-08-07 16:24:00

ORD_ORDER_RETURN 2009-08-07 16:29:14

ORD_ORDER_TOTAL_FOSHAN 2009-08-07 16:29:16

ORD_ORDER_TOTAL_SHUDE 2009-08-07 16:29:16

ORD_PURCHASE 2009-08-07 16:29:23

ORD_PURCHASE_ITEM 2007-05-03 15:33:17

ORD_ORDER_ITEM 2007-05-03 15:30:25

ORD_ORDER 2007-05-03 15:23:42

ORD_ORDER_RECEIVE 2009-08-07 16:27:04

已选择14行。

问题依旧,既然通过JOB调用存在问题,尝试手工执行DBMS_STATS包:

SQL> EXEC dbms_stats.gather_schema_stats(user, cascade => true);

PL/SQL 过程已成功完成。

SQL> SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TABLES;

TABLE_NAME LAST_ANALYZED

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

ORD_ORDER_CHECK 2009-08-07 16:39:25

ORD_ORDER_CHECK_TERM 2009-08-07 16:39:26

ORD_ORDER_ITEM_NO_FOSHAN 2009-08-07 16:39:26

ORD_ORDER_ITEM_NO_SHUDE 2009-08-07 16:39:26

ORD_ORDER_OOS_HISTORY 2009-08-07 16:39:28

ORD_ORDER_PAY 2009-08-07 16:39:33

时间: 2024-12-31 02:50:34

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数据泵导入分区表统计信息报错(五)导致问题的原因

现在已经找到了问题的原因,并且也找到了解决问题的方法,但是导致问题的原因还不清楚. 也就是说,要找到为什么这几个分区表的统计信息被锁住. Oracle的DBMS_STATS包提供了LOCK_TABLE_STATS过程,但是当前的问题显然不是手工调用这个过程造成的. 所有了一下metalink,发现Oracle在文档Doc ID: 433240.1中描述了统计信息被锁定的可能性: 手工执行DBMS_STATS包的LOCK_TABLE_STATS过程: 使用imp或impdp,导入表的时候不加载数据

oracle数据泵不同工作方式性能比较(四)测试外部表导出、导入方式

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

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. 一般来说我们希望数据泵使用直接路径的方式导入,因为导入的效率会很高.但是有的时候,我们并不需要采用直接路