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

前不久检查了一篇以往的BLOG,意外的发现这个bug居然被我忘记了,时隔一年继续解决这个问题。

根据上一篇文章所介绍的分析过程,基本上可以确认和这几张分区表的统计信息本身有关。

由于当前数据库是从920环境EXP导出,IMP导入到同版本的中间数据库,最终通过数据泵IMPDP导入到当前数据库的。而分区表由于无法解决表空间的转换问题,因此在中间数据库手工创建,在IMP导入的时候指定了IGNORE=Y参数。

而现在恰好问题出在这个用户的所有分区表上,难道问题和迁移的过程有关系。检查了当时的脚本,没有发现异常之处。

不过由于原始数据的版本是9204,而迁移后的版本是10203,有可能是版本的不同导致了迁移过程中某些参数的设置发生了变化。

表的存储参数中与统计信息相关的就是MONITORING了。这个存储参数比较有意思,从9i开始引入,到了10g及以后版本中,这个参数又消失了。并不是Oracle认为这个参数没有意义而去掉了,而是Oracle认为这个MONITORING功能的代价很小,而对于统计信息十分有帮助,因此变成了Oracle的默认的行为,只留下了一个隐含参数来控制是否进行MONITORING的操作。

检查这几个表的MONITORING属性,发现值都是YES:

SQL> SELECT TABLE_NAME, MONITORING

2 FROM USER_TABLES

3 WHERE TABLE_NAME IN

4 (SELECT TABLE_NAME FROM USER_PART_TABLES);

TABLE_NAME MON

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

EMED_WEB_LOG YES

ORD_LOG_HIT_COMM YES

ORD_PURCHASE_ITEM YES

ORD_ORDER_ITEM YES

ORD_ORDER YES

CON_LOG_LIST_ITEM YES

已选择6行。

但是10g和9i的数据字典中MONITORING的值的来源是不同的,在9i中:

SQL> SELECT TEXT FROM DBA_VIEWS WHERE VIEW_NAME = 'DBA_TABLES';

TEXT

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

select u.name, o.name, decode(bitand(t.property, 4194400), 0, ts.name, null),

decode(bitand(t.property, 1024), 0, null, co.name),

decode((bitand(t.property, 512)+bitand(t.flags, 536870912)),

0, null, co.name),

decode(bitand(t.property, 32+64), 0, mod(t.pctfree$, 100), 64, 0, null),

decode(bitand(ts.flags, 32), 32, to_number(NULL),

decode(bitand(t.property, 32+64), 0, t.pctused$, 64, 0, null)),

decode(bitand(t.property, 32), 0, t.initrans, null),

decode(bitand(t.property, 32), 0, t.maxtrans, null),

s.iniexts * ts.blocksize,

decode(bitand(ts.flags, 3), 1, to_number(NULL),

s.extsize * ts.blocksize),

s.minexts, s.maxexts,

decode(bitand(ts.flags, 3), 1, to_number(NULL),

s.extpct),

decode(bitand(ts.flags, 32), 32, to_number(NULL),

decode(bitand(o.flags, 2), 2, 1, decode(s.lists, 0, 1, s.lists))),

decode(bitand(ts.flags, 32), 32, to_number(NULL),

decode(bitand(o.flags, 2), 2, 1, decode(s.groups, 0, 1, s.groups))),

decode(bitand(t.property, 32), 32, null,

decode(bitand(t.flags, 32), 0, 'YES', 'NO')),

decode(bitand(t.flags,1), 0, 'Y', 1, 'N', '?'),

t.rowcnt,

decode(bitand(t.property, 64), 0, t.blkcnt, null),

decode(bitand(t.property, 64), 0, t.empcnt, null),

t.avgspc, t.chncnt, t.avgrln, t.avgspc_flb,

decode(bitand(t.property, 64), 0, t.flbcnt, null),

lpad(decode(t.degree, 32767, 'DEFAULT', nvl(t.degree,1)),10),

lpad(decode(t.instances, 32767, 'DEFAULT', nvl(t.instances,1)),10),

lpad(decode(bitand(t.flags, 8), 8, 'Y', 'N'),5),

decode(bitand(t.flags, 6), 0, 'ENABLED', 'DISABLED'),

t.samplesize, t.analyzetime,

decode(bitand(t.property, 32), 32, 'YES', 'NO'),

decode(bitand(t.property, 64), 64, 'IOT',

decode(bitand(t.property, 512), 512, 'IOT_OVERFLOW',

decode(bitand(t.flags, 536870912), 536870912, 'IOT_MAPPING', null

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

时间: 2024-09-17 04:25:13

oracle数据泵导入分区表统计信息报错(三)的相关文章

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

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

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

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

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

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

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

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

oracle数据泵不同工作方式性能比较(三)测试直接路径导出、导入方式

根据Oracle的文档的描述,数据泵采用不同的方式导出导入,性能也会有明显的差别,这次正好有机会测试一下,迁移表空间.直接路径.外部表方式,以及数据库链方式导出.导入的性能差异. 这篇测试直接路径导出.导入方式. 首先清除上一篇文章中导入的用户和表空间,并重新建立测试用户和表空间. 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. 一般来说我们希望数据泵使用直接路径的方式导入,因为导入的效率会很高.但是有的时候,我们并不需要采用直接路