oracle数据泵导入分区表统计信息报错（二）  

今天在进行数据泵导入操作时，发现一个bug。

上一篇记录了问题的现象，这一篇继续深入研究。

上一篇文章已经描述了问题的产生，而且提到了这个问题很难重现。无论如何去模拟实际的情况，都无法重现问题。

为了重现这个问题，在RAC数据库环境中，仿照问题表创建了分区表、并仿照问题数据库收集了统计信息的方式进行了统计信息的收集，都无法重现问题。

但是，利用问题数据库导出的统计信息，就可以重现问题。上周五发现的问题，但是由于数据不方便带回家，因此由于时间的限制仅仅测试了这么多。

今天一早到了公司，就继续这个问题的测试。周末的时候仔细思考了一下，既然在测试的数据库上无法重现问题，但是利用源数据库的数据可以重现问题，那么问题是否和数据本身有关，也就是说，是数据本身的问题导致了bug。

于是今天测试的时候尝试使用问题数据，在多个不同平台的Oracle10203的rac和单实例数据库上尝试执行数据泵导入，错误屡试不爽。这样看来，问题是源数据库本身造成的，也与源数据库目前的数据、统计信息有关。

这样将问题的目标从测试数据库转到的执行导出的源数据库中。

首先对比源数据库和导入数据库中表分析情况，可以发现只有分区表的统计信息没有导入，这就进一步确定了问题是发生在分区表中。

下面查询一下源数据库中表的分析情况：

SQL> SELECT TABLE_NAME, PARTITIONED, TEMPORARY, LAST_ANALYZED

2 FROM USER_TABLES

3 ORDER BY 4 DESC;

TABLE_NAME PAR T LAST_ANALYZED

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

ORD_HIT_COMM_TMP NO Y

CON_LIST_ITEM_SHARE_TMP NO Y

JOB_MONTH_STATS NO Y

ZZZ_PURCHASE_BUYER NO N 2008-03-02 02:14:45

ZZZ_YANGS_PRO NO N 2008-03-02 02:14:45

ZZZ_YANGS_ORDER3 NO N 2008-03-02 02:14:45

ZZZ_YANGS_ORDER2 NO N 2008-03-02 02:14:45

.

.

.

ASS_BBS_CATALOG NO N 2008-03-02 01:00:10

ASS_BBS_ARTICLE NO N 2008-03-02 01:00:09A NO N 2008-03-02 01:00:08

ORD_LOG_HIT_COMM YES N 2007-05-03 15:33:45

CON_LOG_LIST_ITEM YES N 2007-05-03 15:33:19

ORD_PURCHASE_ITEM YES N 2007-05-03 15:33:17

ORD_ORDER_ITEM YES N 2007-05-03 15:30:25

ORD_ORDER YES N 2007-05-03 15:23:42

已选择450行。

从这里就可以看到分区表的数据分析存在问题，其他表的分析都是近期的，只有分区表的分析已经很长时间没有更新了。

检查分区表的分析方法：

SQL> SELECT WHAT, LAST_DATE FROM USER_JOBS WHERE JOB = 291;

WHAT LAST_DATE

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

dbms_stats.gather_schema_stats(user, cascade => true); 2008-03-02 01:00:02

采用这种方式进行分析，默认应该分析分区表才对，接着检查分区表的各个分区是否分析过：

SQL> SELECT TABLE_NAME, PARTITION_NAME, LAST_ANALYZED

2 FROM USER_TAB_PARTITIONS

3 ORDER BY 1, 2;

TABLE_NAME PARTITION_NAME LAST_ANALYZED

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

CON_LOG_LIST_ITEM CON0610

CON_LOG_LIST_ITEM CON0611

CON_LOG_LIST_ITEM CON0612

CON_LOG_LIST_ITEM CON0701

CON_LOG_LIST_ITEM CON_MAX

ORD_LOG_HIT_COMM HLG0610

ORD_LOG_HIT_COMM HLG0611

.

.

.

ORD_PURCHASE_ITEM ORD0804

ORD_PURCHASE_ITEM ORD0807

ORD_PURCHASE_ITEM ORD0810

ORD_PURCHASE_ITEM ORD0901

已选择97行。

所有的分区都没有分析过。检查数据库中其他SCHEMA下的分区表是否也存在相同的问题：

SQL> SELECT A.OWNER, A.TABLE_NAME, LAST_ANALYZED

2 FROM ALL_TABLES A, ALL_PART_TABLES B

3 WHERE A.TABLE_NAME = B.TABLE_NAME

4 AND A.OWNER = B.OWNER

5 AND A.OWNER IN ('ZHEJIANG', 'ANHUI', 'BEIJING')

6 ORDER BY 3;

OWNER TABLE_NAME LAST_ANALYZED

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

ZHEJIANG ORD_ORDER 2007-05-03 15:23:42

ZHEJIANG ORD_ORDER_ITEM 2007-05-03 15:30:25

ZHEJIANG ORD_PURCHASE_ITEM 2007-05-03 15:33:17

ZHEJIANG CON_LOG_LIST_ITEM 2007-05-03 15:33:19

ZHEJIANG ORD_LOG_HIT_COMM 2007-05-03 15:33:45

ANHUI CON_LOG_LIST_ITEM 2008-03-02 22:00:53

ANHUI ORD_LOG_HIT_COMM 2008-03-02 22:04:22

ANHUI ORD_ORDER 2008-03-02 22:04:52

ANHUI ORD_ORDER_ITEM 2008-03-02 22:05:38

ANHUI ORD_PURCHASE_ITEM 2008-03-02 22:06:39

BEIJING CON_LOG_LIST_ITEM 2008-03-03 16:07:10

BEIJING ORD_LOG_HIT_COMM 2008-03-03 16:37:01

BEIJING ORD_ORDER 2008-03-03 16:40:18

BEIJING ORD_ORDER_ITEM 2008-03-03 16:57:56

BEIJING ORD_ORDER_RECEIVE 2008-03-03 17:03:52

BEIJING ORD_ORDER_RETURN 2008-03-03 17:05:24

BEIJING ORD_PURCHASE_ITEM 2008-03-03 17:14:41

17 rows selected.

其他用户下的分区表最近都进行过分析，检查一下分区的分析情况：

SQL> SELECT A.TABLE_OWNER OWNER, A.TABLE_NAME, A.PARTITION_NAME, LAST_ANALYZED

2 FROM ALL_TAB_PARTITIONS A, ALL_PART_TABLES B

3 WHERE A.TABLE_NAME = B.TABLE_NAME

4 AND A.TABLE_OWNER = B.OWNER

5 AND B.OWNER IN ('ZHEJIANG', 'ANHUI', 'BEIJING')

6 AND A.TABLE_NAME = 'ORD_ORDER'

7 ORDER BY 4;

OWNER TABLE_NAME PARTITION_ LAST_ANALYZED

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

ANHUI ORD_ORDER ORD0201 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0204 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0610 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0607 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0207 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0210 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0301 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0304 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0307 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0310 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0401 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0404 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0407 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0410 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0501 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0504 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0507 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0510 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0601 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0604 2008-03-02 22:04:32

ANHUI ORD_ORDER ORD0701 2008-03-02 22:04:33

ANHUI ORD_ORDER ORD0704 2008-03-02 22:04:35

ANHUI ORD_ORDER ORD0707 2008-03-02 22:04:43

ANHUI ORD_ORDER ORD0710 2008-03-02 22:04:48

ANHUI ORD_ORDER ORD0901 2008-03-02 22:04:48

ANHUI ORD_ORDER ORD0810 2008-03-02 22:04:48

ANHUI ORD_ORDER ORD0807 2008-03-02 22:04:48

ANHUI ORD_ORDER ORD0804 2008-03-02 22:04:48

ANHUI ORD_ORDER ORD0801 2008-03-02 22:04:48

BEIJING ORD_ORDER ORD0201 2008-03-03 16:37:09

BEIJING ORD_ORDER ORD0204 2008-03-03 16:37:10

BEIJING ORD_ORDER ORD0207 2008-03-03 16:37:12

BEIJING ORD_ORDER ORD0210 2008-03-03 16:37:17

BEIJING ORD_ORDER ORD0301 2008-03-03 16:37:20

BEIJING ORD_ORDER ORD0304 2008-03-03 16:37:24

BEIJING ORD_ORDER ORD0307 2008-03-03 16:37:27

BEIJING ORD_ORDER ORD0310 2008-03-03 16:37:35

BEIJING ORD_ORDER ORD0401 2008-03-03 16:37:38

BEIJING ORD_ORDER ORD0404 2008-03-03 16:37:43

BEIJING ORD_ORDER ORD0407 2008-03-03 16:37:48

BEIJING ORD_ORDER ORD0410 2008-03-03 16:38:00

BEIJING ORD_ORDER ORD0501 2008-03-03 16:38:08

BEIJING ORD_ORDER ORD0504 2008-03-03 16:38:16

BEIJING ORD_ORDER ORD0507 2008-03-03 16:38:24

BEIJING ORD_ORDER ORD0510 2008-03-03 16:38:38

BEIJING ORD_ORDER ORD0601 2008-03-03 16:38:47

BEIJING ORD_ORDER ORD0604 2008-03-03 16:38:56

BEIJING ORD_ORDER ORD0607 2008-03-03 16:39:07

BEIJING ORD_ORDER ORD0610 2008-03-03 16:39:16

BEIJING ORD_ORDER ORD0701 2008-03-03 16:39:25

BEIJING ORD_ORDER ORD0704 2008-03-03 16:39:34

BEIJING ORD_ORDER ORD0707 2008-03-03 16:39:43

BEIJING ORD_ORDER ORD0801 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0710 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0901 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0812 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0811 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0810 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0809 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0808 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0807 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0802 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0803 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0806 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0805 2008-03-03 16:39:46

BEIJING ORD_ORDER ORD0804 2008-03-03 16:39:46

ZHEJIANG ORD_ORDER ORD0607

ZHEJIANG ORD_ORDER ORD0610

ZHEJIANG ORD_ORDER ORD0701

ZHEJIANG ORD_ORDER ORD0704

ZHEJIANG ORD_ORDER ORD0707

ZHEJIANG ORD_ORDER ORD0710

ZHEJIANG ORD_ORDER ORD0801

ZHEJIANG ORD_ORDER ORD0804

ZHEJIANG ORD_ORDER ORD0807

ZHEJIANG ORD_ORDER ORD0810

ZHEJIANG ORD_ORDER ORD0604

ZHEJIANG ORD_ORDER ORD0601

ZHEJIANG ORD_ORDER ORD0510

ZHEJIANG ORD_ORDER ORD0507

ZHEJIANG ORD_ORDER ORD0504

ZHEJIANG ORD_ORDER ORD0501

ZHEJIANG ORD_ORDER ORD0410

ZHEJIANG ORD_ORDER ORD0407

ZHEJIANG ORD_ORDER ORD0404

ZHEJIANG ORD_ORDER ORD0401

ZHEJIANG ORD_ORDER ORD0310

ZHEJIANG ORD_ORDER ORD0307

ZHEJIANG ORD_ORDER ORD0901

ZHEJIANG ORD_ORDER ORD0301

ZHEJIANG ORD_ORDER ORD0210

ZHEJIANG ORD_ORDER ORD0207

ZHEJIANG ORD_ORDER ORD0204

ZHEJIANG ORD_ORDER ORD0201

ZHEJIANG ORD_ORDER ORD0304

95 rows selected.

这个结果更加说明，其他SCHEMA中的分区表没有问题，而只有问题用户的分区表才出现错误。

莫非是收集统计信息的方法有差异：

SQL> SELECT LOG_USER, WHAT FROM DBA_JOBS

2 WHERE UPPER(WHAT) LIKE '%DBMS_STATS%'

3 AND LOG_USER IN ('ANHUI', 'BEIJING', 'ZHEJIANG');

LOG_USER WHAT

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

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

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

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

可以看到三个SCHEMA采用完全相同的方法来收集统计信息，但是得到的结果确不相同，问题变得越来越有意思了。

oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html