今天在进行数据泵导入操作时，发现一个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