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

最新推荐文章于 2023-12-12 20:50:42 发布

weixin_34129696

最新推荐文章于 2023-12-12 20:50:42 发布

阅读量141

点赞数

文章标签：数据库

原文链接：http://blog.51cto.com/19880614/1206624

版权

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

这篇文章描述导致问题的原因。

现在已经找到了问题的原因，并且也找到了解决问题的方法，但是导致问题的原因还不清楚。

也就是说，要找到为什么这几个分区表的统计信息被锁住。

Oracle的DBMS_STATS包提供了LOCK_TABLE_STATS过程，但是当前的问题显然不是手工调用这个过程造成的。

所有了一下metalink，发现Oracle在文档Doc ID: 433240.1中描述了统计信息被锁定的可能性：

手工执行DBMS_STATS包的LOCK_TABLE_STATS过程；

使用imp或impdp，导入表的时候不加载数据，会锁住表的统计信息；

在升级过程中，队列表的统计信息可能被锁定。

前面已经排除了手工执行LOCK_TABLE_STATS的可能性，而出现问题的表又不是队列表，显然第二种情况导致问题的可能性最大。

由于迁移确实是用IMP和IMPDP实现的，但是由于距离迁移的时间太长，导致一些具体的操作已经记不清了。而且由于服务器空间的问题，一些迁移时的log脚本已经被清除掉了。因此找到当时具体的操作很困难了。

如果根据当时的迁移步骤，是不存在只导入结构而没有导入数据的情况的。

根据记忆描述一下迁移的步骤：

在9i的源数据库用exp导出了数据；

由于要转换表空间，以及去掉物化视图日志等信息，避免导入过程对产品环境导致的危害，设立了一个10g的中间数据库；

在中间数据库上手工建立了分区表，然后用imp指定ignore=y导入所有的表；

在中间数据库进行数据的清理工作；

在中间数据库执行expdp导出；

在目标数据库上执行impdp导入。

如果说发生过imp操作，可能在中间数据库上执行过。不过检查统计信息的生成时间，实在对象的创建之后，而且间隔几个小时之久：

SQL> conn zhejiang输入口令: 已连接。

SQL> set pages 100 lines 120

SQL> alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';

会话已更改。

SQL> select object_name, created

2 from user_objects a, user_part_tables b

3 where a.object_name = b.table_name

4 and a.object_type = 'TABLE';

OBJECT_NAME CREATED

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

CON_LOG_LIST_ITEM 2007-05-03 10:17:40

ORD_ORDER 2007-05-03 10:18:06

ORD_ORDER_ITEM 2007-05-03 10:18:15

ORD_PURCHASE_ITEM 2007-05-03 10:18:26

ORD_LOG_HIT_COMM 2007-05-03 11:12:34

EMED_WEB_LOG 2008-06-24 17:06:59

已选择6行。

SQL> select a.table_name, last_analyzed

2 from user_tables a, user_part_tables b

3 where a.table_name = b.table_name;

TABLE_NAME LAST_ANALYZED

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

CON_LOG_LIST_ITEM 2007-05-03 15:33:19

ORD_ORDER 2007-05-03 15:23:42

ORD_ORDER_ITEM 2007-05-03 15:30:25

ORD_PURCHASE_ITEM 2007-05-03 15:33:17

ORD_LOG_HIT_COMM 2007-05-03 15:33:45

EMED_WEB_LOG 2009-08-09 01:07:31

已选择6行。

这说明在对象导入后，成功的收集过一次统计信息。

莫非是在系统迁移之后，执行过IMP或IMPDP的导入，这个问题的产生和迁移没有关系。统计信息的收集时间与迁移时间发生在同一天，且间隔比较接近，而且此后这些分区表就没有再被分析过，要说这个问题和迁移没有关系，显然难以令人信服。更重要的是，除了迁移过程，平常基本上没有可能对产品环境执行IMP或IMPDP的操作。

由于系统上的日志信息已经都丢失了，只能依靠数据库中保存的信息了。

检查数据库中对象的创建时间，看看能否发现一些什么：

SQL> select object_name, object_type, created

2 from user_objects

3 where created < to_date('2007-5-4', 'yyyy-mm-dd')

4 order by created;

OBJECT_NAME OBJECT_TYPE CREATED

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

CON_LOG_LIST_ITEM TABLE PARTITION 2007-05-03 10:17:40

CON_LOG_LIST_ITEM TABLE 2007-05-03 10:17:40

CON_LOG_LIST_ITEM TABLE PARTITION 2007-05-03 10:17:40

ORD_ORDER TABLE PARTITION 2007-05-03 10:18:06

ORD_ORDER TABLE 2007-05-03 10:18:06

ORD_ORDER TABLE PARTITION 2007-05-03 10:18:06

ORD_ORDER_ITEM TABLE PARTITION 2007-05-03 10:18:15

ORD_ORDER_ITEM TABLE 2007-05-03 10:18:15

ORD_ORDER_ITEM TABLE PARTITION 2007-05-03 10:18:15

ORD_PURCHASE_ITEM TABLE PARTITION 2007-05-03 10:18:26

ORD_PURCHASE_ITEM TABLE 2007-05-03 10:18:26

ORD_PURCHASE_ITEM TABLE PARTITION 2007-05-03 10:18:26

ORD_PURCHASE_ITEM TABLE PARTITION 2007-05-03 10:18:27

TU_ORD_ORDER_PLAT_ID INDEX PARTITION 2007-05-03 10:18:32

TU_ORD_ORDER_PLAT_ID INDEX 2007-05-03 10:18:32

TU_ORD_ORDER_PLAT_ID INDEX PARTITION 2007-05-03 10:18:32

TU_ORD_ORDER_PLAT_ID INDEX PARTITION 2007-05-03 10:18:32A_DATA SYNONYM 2007-05-03 10:25:44

BACKUP_SQL SYNONYM 2007-05-03 10:25:44

CAT_INVITE_COMM_DATA SYNONYM 2007-05-03 10:25:44

T_LINK TYPE 2007-05-03 10:25:44

CAT_REGION_MERCHANDISE_DATA SYNONYM 2007-05-03 10:25:44

TEMP_FIRST_PRODUCT SYNONYM 2007-05-03 10:25:44

TEMP_SECOND_CATEGORY SYNONYM 2007-05-03 10:25:44

CAT_INVITE_COMM_SEND_DATA SYNONYM 2007-05-03 10:25:44

DATA01.US.ORACLE.COM DATABASE LINK 2007-05-03 10:25:45

TRANSFER SEQUENCE 2007-05-03 10:25:45

HI_TEMPTOTAL_ID SEQUENCE 2007-05-03 10:25:45

IMP_SYS_TMP SEQUENCE 2007-05-03 10:25:45

JOB_ID SEQUENCE 2007-05-03 10:25:45

TRANFER SEQUENCE 2007-05-03 10:25:45

GOV_SEQ SEQUENCE 2007-05-03 10:25:45

ASS_BBS_USERINFO TABLE 2007-05-03 10:25:46

ASS_COMPLAIN_ORG_SCORE TABLE 2007-05-03 10:25:46

ASS_COMPLAIN_RECORD TABLE 2007-05-03 10:25:46

ASS_COMPLAIN_REPLY TABLE 2007-05-03 10:25:46

ASS_BBS_CATALOG TABLE 2007-05-03 10:25:46

ASS_NEWS TABLE 2007-05-03 10:25:46

ASS_NEWS_TYPE TABLE 2007-05-03 10:25:46A TABLE 2007-05-03 10:25:46

ASS_BBS_ARTICLE TABLE 2007-05-03 10:25:46

ASS_COMPLAIN_TYPE TABLE 2007-05-03 10:25:46

ZZZ_YANGS_ORDER2 TABLE 2007-05-03 10:26:25

ZZZ_YANGS_ORDER3 TABLE 2007-05-03 10:26:25

ZZZ_YANGS_PRO TABLE 2007-05-03 10:26:25

ORD_PAYMENT_ORG TABLE 2007-05-03 10:26:25

SYS_LOB0000061644C00004$$ LOB 2007-05-03 10:26:25

SYS_LOB0000061644C00003$$ LOB 2007-05-03 10:26:25

CON_LIST_ITEM_SHARE_TMP TABLE 2007-05-03 10:26:25

JOB_MONTH_STATS TABLE 2007-05-03 10:26:25

ZJ_PRODUCT TABLE 2007-05-03 10:26:25

PK_ORD_PAYMENT_ORG_MERCHID INDEX 2007-05-03 10:39:11

TU_OD_PAYMENT_ORG_BID_ORG INDEX 2007-05-03 10:39:11

PK_ASS_BBS_ARTICLE INDEX 2007-05-03 10:39:11

PK_ASS_BBS_CATALOG INDEX 2007-05-03 10:39:11

PK_ASS_BBS_USERINFO INDEX 2007-05-03 10:39:11

PK_ASS_NEWS INDEX 2007-05-03 10:39:12

SYS_C0014351 INDEX 2007-05-03 10:52:55

SYS_C0014352 INDEX 2007-05-03 10:52:55

CHANGE_PRICE_1 FUNCTION 2007-05-03 10:53:32

P_UPDATE_TEMP_PRICE PACKAGE 2007-05-03 10:53:32

PA_UPDATE_ORD_HIT_COMM PACKAGE 2007-05-03 10:53:32

PA_PLAN_REPORT PACKAGE 2007-05-03 10:53:32

CON_LIST_ITEM_SHIFT PACKAGE 2007-05-03 10:53:32F_LINK FUNCTION 2007-05-03 10:53:32F_GET_EXP_TAB_NAME FUNCTION 2007-05-03 10:53:32

CHANGE_PRICE_2 FUNCTION 2007-05-03 10:53:32

DELPUR PROCEDURE 2007-05-03 10:53:34

GETFULLSQL PROCEDURE 2007-05-03 10:53:34

P_SCHEMA_STATS PROCEDURE 2007-05-03 10:53:35

PA_UPDATE_ORD_HIT_COMM PACKAGE BODY 2007-05-03 10:53:40

P_UPDATE_TEMP_PRICE PACKAGE BODY 2007-05-03 10:53:40

CON_LIST_ITEM_SHIFT PACKAGE BODY 2007-05-03 10:53:40

PA_PLAN_REPORT PACKAGE BODY 2007-05-03 10:53:41

T_LINK TYPE BODY 2007-05-03 10:53:41

T_PURCHASE_PURCHASE_TYPE INDEX 2007-05-03 10:53:44

TU_ORD_BUY_WAR_SYNC_STATE INDEX 2007-05-03 10:53:44

T_ORDER_RECEIVE_PP INDEX 2007-05-03 10:53:45

T_PURCHASE_APPROVE_USERID INDEX 2007-05-03 10:53:45

T_PURCHASE_CREATE_USERID INDEX 2007-05-03 10:53:45

T_ORDER_RECEIVE_PLAT_ID INDEX 2007-05-03 10:53:45

TU_A_TEMP_CLIT_BUYER_FLAG INDEX 2007-05-03 10:53:45

ORD_LOG_HIT_COMM TABLE 2007-05-03 11:12:34

ORD_LOG_HIT_COMM TABLE PARTITION 2007-05-03 11:12:34

CAT_ZONE_HOLIDAY SYNONYM 2007-05-03 11:29:24

CAT_ZONE_DEALER SYNONYM 2007-05-03 11:29:24

MBR_PRODUCT_GRANTOR SYNONYM 2007-05-03 11:29:26

MBR_NOTICE SYNONYM 2007-05-03 11:29:26

USR_USER TABLE 2007-05-03 14:28:06

PK_USR_USER INDEX 2007-05-03 14:28:07

UN1_USR_USER INDEX 2007-05-03 14:28:07

TU_USR_USER INDEX 2007-05-03 14:28:07

TU_USR_USER_USERNAME INDEX 2007-05-03 14:28:08

USR_ROLE TABLE 2007-05-03 14:28:09

PK_USR_ROLE INDEX 2007-05-03 14:28:09

USR_USER_ROLE TABLE 2007-05-03 14:28:10

PK_USR_US_PLAT_ROLE INDEX 2007-05-03 14:28:11

TU_USR_USER_ROLE_ROLE_ID INDEX 2007-05-03 14:28:11

TU_USR_USER_ROLE_USER_ID INDEX 2007-05-03 14:28:11

PK_T_ORDER INDEX 2007-05-03 15:22:41

TU_ORD_ORDERITEM_SENDER_ORGID INDEX 2007-05-03 15:22:55

TU_ORD_ORDER_BUYER INDEX 2007-05-03 15:23:03

TU_ORD_ORDER_CODE INDEX 2007-05-03 15:23:10

TU_ORD_ORDER_PURCHASE_ID INDEX 2007-05-03 15:23:16

TU_ORD_ORDER_SALER_ORGID INDEX 2007-05-03 15:23:23

IND_ORD_ORDER_CREATE_DATE INDEX 2007-05-03 15:23:31

IND_ORD_ORDER_MODIFY_DATE INDEX 2007-05-03 15:23:37

PK_T_ORDER_ITEM INDEX 2007-05-03 15:23:43

TU_ORD_ORDER_ITEM_BID_ORG INDEX 2007-05-03 15:24:32

TU_ORD_ORDER_ITEM_BUY INDEX 2007-05-03 15:25:01

TU_ORD_ORDER_ITEM_ORDERID INDEX 2007-05-03 15:25:24

TU_ORD_ORDER_ITEM_PLATID INDEX 2007-05-03 15:25:45

TU_ORD_ORDER_ITEM_PUR_ITEM INDEX 2007-05-03 15:26:06

TU_ORD_ORDER_ITEM_P_BUYER INDEX 2007-05-03 15:26:26

TU_ORD_ORDER_ITEM_SALER INDEX 2007-05-03 15:27:00

TU_ORD_ORDER_ITEM_SEND INDEX 2007-05-03 15:27:23

TU_ORD_ORDER_ITEM_SOURCE INDEX 2007-05-03 15:27:47

TU_ORD_ORD_ITEM_PRODUCT_ID INDEX 2007-05-03 15:28:15

TU_ORD_ORD_IT_COMB_PLAT_ORDID INDEX 2007-05-03 15:28:39

TU_ORD_ITEM_CREATE_DATE INDEX 2007-05-03 15:29:10

TU_ORD_ITEM_CD_SD INDEX 2007-05-03 15:29:30

TU_ORD_ITEM_HIT_COMM_ID INDEX 2007-05-03 15:30:00

PK_T_PURCHASE_ITEM INDEX 2007-05-03 15:30:27

TU_ORD_PURCHASE_ITEM_BUYER INDEX 2007-05-03 15:31:04

TU_ORD_PURCHASE_ITEM_PROD_ID INDEX 2007-05-03 15:31:25

TU_ORD_PUR_ITEM_HITCOMMID INDEX 2007-05-03 15:31:47

TU_ORD_PUR_ITEM_PURCHASE_ID INDEX 2007-05-03 15:32:12

TU_ORD_PUR_ITEM_SEND_ID INDEX 2007-05-03 15:32:33

UN_PURCHASE_TEMP INDEX 2007-05-03 15:32:57

TU_CON_LOG_LIST_ITEM_OPER_DATE INDEX 2007-05-03 15:33:18

TU_ORD_LOG_HIT_COMM_BUYER INDEX 2007-05-03 15:33:20

T_MEDICAL VIEW 2007-05-03 15:55:59

S_USER VIEW 2007-05-03 15:55:59

V_PRODUCT VIEW 2007-05-03 15:56:00

JOB_PCONTRACT_SHOW PROCEDURE 2007-05-03 16:09:38

MLOG$_CON_LIST TABLE 2007-05-03 17:20:45

RUPD$_ORD_ORDER_RETURN TABLE 2007-05-03 17:20:47

已选择1514行。

下面根据对象的创建顺序进行分析：首先创建的对象是手工建立的分区表。然后执行的数据泵导入过程，先导入了同义词和序列，然后是表和索引，最后是过程、函数和包。最后导入了几个BITMAP索引，数据泵在10:53:45秒导入结束。

SQL> select index_type from user_indexes

2 where index_name = 'T_ORDER_RECEIVE_PLAT_ID';

INDEX_TYPE

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

BITMAP

最后补建了一个分区表。而此后的同义词的建立是在数据泵导入完成后，通过pl/sql代码实现的。

此后在14:28分的时候使用imp导入了一些USR开头的表和索引，不过这和当前的问题没有关系。

关键的时刻到了，在15:22分到15:33分的时间段内，建立了这些出问题的分区表的索引。如果和这些分区表的统计信息的最后收集时间进行比较，可以发现二者时间惊人的接近，这显然不是巧合，多半是导入索引信息的时候，将统计信息一起导入。

到了这个时候，总算想起当时的操作了。由于其他的表都是通过exp导出，并使用imp导入，因此包含完整的索引定义。而这些表是手工建立，在建立表的时候没有建立表的索引。因此发现了这一点后，利用exp或expdp从源数据库导出了索引定义，并导入到目标数据库中。

正是由于这个操作，将分区表的统计信息锁定。这也解释了为什么只有分区表没有收集新的统计信息，而其他表没有同样的问题。

这个例子说明两个问题：

对于迁移或升级这种大型变更，一定要留下尽量详细的资料备查。包括迁移计划、迁移步骤、导出导入工具的日志信息、升级后执行catupgrd.sql的输出文件等等。这些信息对于日后出现问题后进行分析异常重要。

应该尽可能深入了解每个工具的特性，即使是这么常用的exp和expdp工具，都可能隐藏着这种隐蔽的操作。详细的计划和必要的上线测试可以避免绝大部分问题的发生，但是无法杜绝所有的问题，尤其是一些突发的时间。在这个时候所使用的工具是否能够完成目标而没有任何副作用，所选择的方法是否足够高效且没有危害，这些就要靠平时的积累来完成了。

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

转载于:https://blog.51cto.com/19880614/1206624

weixin_34129696

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
oracle数据泵导入分区表统计信息报错（五）

今天在进行数据泵导入操作时，发现一个bug。这篇文章描述导致问题的原因。现在已经找到了问题的原因，并且也找到了解决问题的方法，但是导致问题的原因还不清楚。也就是说，要找到为什么这几个分区表的统计信息被锁住。Oracle的DBMS_STATS包提供了LOCK_TABLE_STATS过程，但是当前的问题显然不是手工调用这个过程造成的。所有了一下metalink，发现Oracle在...
复制链接

扫一扫