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