ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 数据泵导入分区表统计信息报错(二)

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

原创 Linux操作系统 作者:yangtingkun 时间:2008-03-03 23:41:42 0 删除 编辑

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

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

数据泵导入分区表统计信息报错(一):http://yangtingkun.itpub.net/post/468/456176

 

 

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

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

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

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

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

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

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

 

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

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:
09
A                              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采用完全相同的方法来收集统计信息,但是得到的结果确不相同,问题变得越来越有意思了。

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-199243/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10365834