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

最新推荐文章于 2024-06-05 15:57:05 发布

ckawt40802

最新推荐文章于 2024-06-05 15:57:05 发布

阅读量211

点赞数

文章标签：数据库网络

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

继续分析另一个错误信息。

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

数据泵导入分区表统计信息报错（二）：http://yangtingkun.itpub.net/post/468/456378

数据泵导入分区表统计信息报错（三）：http://yangtingkun.itpub.net/post/468/489067

数据泵导入分区表统计信息报错（四）：http://yangtingkun.itpub.net/post/468/489253

数据泵导入分区表统计信息报错（五）：http://yangtingkun.itpub.net/post/468/489433

数据泵导入分区表统计信息报错（六）：http://yangtingkun.itpub.net/post/468/492401

其实问题的引出是由于出现第一篇文章中描述的问题，不过随着问题的深入研究，挖掘出了一些隐藏的很深的问题，不过问题的研究也慢慢脱离了原本的问题。

在解决了表统计信息锁定的问题后，在回过头看看导致第一篇文章中错误的具体原因。

bash-2.03$ impdp test/test directory=d_test dumpfile=zhejiang_order.dp logfile=zhejiang_order.log remap_schema=zhejiang:test include=table/statistics

Import: Release 10.2.0.3.0 - 64bit Production on 星期二, 20 4月, 2010 18:42:01

连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
已成功加载/卸载了主表 "TEST"."SYS_IMPORT_FULL_01"
启动 "TEST"."SYS_IMPORT_FULL_01": test/******** directory=d_test dumpfile=zhejiang_order.dp logfile=zhejiang_order.log remap_schema=zhejiang:test include=table/statistics
处理对象类型 TABLE_EXPORT/TABLE/TABLE_DATA
处理对象类型 TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
ORA-39083: 对象类型 TABLE_STATISTICS 创建失败, 出现错误:
ORA-06550: 第 12 行, 第 17 列:
PL/SQL: ORA-00917: 缺失逗号
ORA-06550: 第 4 行, 第 115 列:
PL/SQL: SQL Statement ignored
ORA-06550: 第 20 行, 第 17 列:
PL/SQL: ORA-00917: 缺失逗号
ORA-06550: 第 12 行, 第 161 列:
PL/SQL: SQL Statement ignored
ORA-06550: 第 28 行, 第 17 列:
PL/SQL: ORA-00917: 缺失逗号
ORA-06550: 第 20 行, 第 161 列:
PL/SQL: SQL Statement ignored
ORA-06550: 第 36 行, 第 17 列:
PL/SQL: ORA-00917: 缺失逗号
ORA-06550: 第 28 行, 第 1
作业 "TEST"."SYS_IMPORT_FULL_01" 已经完成, 但是有 1 个错误 (于 18:42:13 完成)

显然第一篇文章出现的错误和上面几篇文章描述的错误还是有差距的，怀疑导致问题的原因出在DMP文件上。

下面通过TRACE的方式，检查导致问题产生的具体原因。

设置TRACE的方式有很多种，但是对于这种执行很快就结束的错误，最好的办法是通过登陆触发器。不过使用登陆触发器仍然有点复杂，其实了解IMPDP工作特性后，可以方便的利用DBMS_MONITOR包来设置TRACE。

在刚才执行导入的时候，在另外的会话检查数据泵后台进程对应的MODULE和SERVICE_NAME信息：

SQL> SELECT SID, MODULE, ACTION, SERVICE_NAME
2 FROM V$SESSION
3 WHERE USERNAME = 'TEST';

SID MODULE ACTION SERVICE_NAME
---------- ------------------------------ ------------------------------ --------------------
300 udi@racnode1 (TNS V1-V3) SYS$USERS

SQL> SELECT SID, MODULE, ACTION, SERVICE_NAME
2 FROM V$SESSION
3 WHERE USERNAME = 'TEST';

       SID MODULE                         ACTION                         SERVICE_NAME
---------- ------------------------------ ------------------------------ --------------------
       292 Data Pump Master               SYS_IMPORT_FULL_01             SYS$USERS
       300 udi@racnode1 (TNS V1-V3)                                      SYS$USERS

SQL> SELECT SID, MODULE, ACTION, SERVICE_NAME
2 FROM V$SESSION
3 WHERE USERNAME = 'TEST';

       SID MODULE                         ACTION                         SERVICE_NAME
---------- ------------------------------ ------------------------------ --------------------
       283 udi@racnode1 (TNS V1-V3)                                      SYS$USERS
       292 Data Pump Master               SYS_IMPORT_FULL_01             SYS$USERS
       300 udi@racnode1 (TNS V1-V3)                                      SYS$USERS

下面打开MODULE为Data Pump Master，且SERVICE为SYS$USERS的会话的TRACE：

SQL> BEGIN
2 DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(
3 'SYS$USERS',
4 'Data Pump Worker',
5 'SYS_IMPORT_FULL_01',
6 TRUE,
7 TRUE);
8 END;
9 /

PL/SQL 过程已成功完成。

再次运行导入，TRACE对应的信息很简单：

bash-2.03$ more testrac1_ora_841.trc
/data/oracle/admin/testrac/udump/testrac1_ora_841.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
ORACLE_HOME = /data/oracle/product/10.2/database
System name:    SunOS
Node name:      racnode1
Release:        5.8
Version:        Generic_117350-46
Machine:        sun4u
Instance name: testrac1
Redo thread mounted by this instance: 1
Oracle process number: 33
Unix process pid: 841, image: oracle@racnode1 (TNS V1-V3)

*** SERVICE NAME:(SYS$USERS) 2010-04-20 19:05:34.808
*** SESSION ID:(288.16791) 2010-04-20 19:05:34.808
kswscrs: deleted entry : svcid = 13, count=13
kswscrs: deleted entry : svcid = 14, count=14

这显然不是我们要寻找的出错的导入会话，打开MODULE为udi@racnode1 (TNS V1-V3)的会话对应的TRACE：

SQL> BEGIN
2 DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(
3 'SYS$USERS',
4 'udi@racnode1 (TNS V1-V3)',
5 DBMS_MONITOR.ALL_ACTIONS,
6 TRUE,
7 TRUE);
8 END;
9 /

PL/SQL 过程已成功完成。

运行导入，得到了TRACE信息：

kswscrs: deleted entry : svcid = 13, count=13
kswscrs: deleted entry : svcid = 14, count=14
SKGXPSEGRCV: MESSAGE TRUNCATED user data 48 bytes payload 2024 bytes
SKGXPSEGRCV: trucated message buffer data skgxpmsg meta. data header 0xffffffff7fff4108 len 48 bytes
SKGXPLOSTACK: message truncation expected
SKGXPLOSTACK: data sent to port with no buffers queued from
SKGXPGPID ffffffff7fff4028 Internet address 10.0.0.3 UDP port number 56083
SKGXPLOSTACK: sent seq 32763 expecting 32764
SKGXPLOSTACK: lost ack detected retransmit ack

显然信息仍然不够，于是直接打开所有SERVICE为SYS$USERS的会话的TRACE：

SQL> BEGIN
2 DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(
3 'SYS$USERS',
4 'Data Pump Worker',
5 'SYS_IMPORT_FULL_01');
6 END;
7 /

PL/SQL 过程已成功完成。

SQL> BEGIN
2 DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(
3 'SYS$USERS',
4 'udi@racnode1 (TNS V1-V3)',
5 DBMS_MONITOR.ALL_ACTIONS);
6 END;
7 /

PL/SQL 过程已成功完成。

SQL> BEGIN
2 DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(
3 'SYS$USERS',
4 DBMS_MONITOR.ALL_MODULES,
5 DBMS_MONITOR.ALL_ACTIONS,
6 TRUE,
7 TRUE);
8 END;
9 /

PL/SQL 过程已成功完成。

检查生成的TRACE文件：

BINDS #39:
kkscoacd
Bind#0
acdty=02 mxl=22(21) mxlc=00 mal=00 scl=00 pre=00
acflg=13 fl2=206001 frm=00 csi=00 siz=24 ff=0
kxsbbbfp=ffffffff7b337e78 bln=22 avl=02 flg=09
value=45
EXEC #39:c=0,e=450,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=4903541916613
ERROR #39:err=39096 tim=502122692
WAIT #9: nam='SQL*Net message to client' ela= 3 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=4903541917005
EXEC #9:c=0,e=2679,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=4903541917063
WAIT #9: nam='SQL*Net message from client' ela= 694 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=4903541917910
XCTEND rlbk=0, rd_only=1

在文件的最后部分，可以看到，Oracle运行CURSOR #39是出现了错误。这个错误信息是ORA-39096：

ORA-39096: invalid input value string for parameter string
Cause: A NULL or invalid value was supplied for the parameter.
Action: Correct the input value and try the call again.

配合这个错误信息和IMPDP输出参数，怀疑是Oracle在执行PL/SQL代码的时候，由于输入参数的错误，导致了问题的产生。

下面看看CURSOR #39对应的SQL：

PARSING IN CURSOR #39 len=46 dep=1 uid=0 ct=47 lid=0 tim=4903540014137 hv=2056630971 ad='ed715768'
BEGIN sys.kupc$que_int.detach_queues(:1); END;
END OF STMT
PARSE #39:c=0,e=135,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=4903540014127
BINDS #39:
kkscoacd
Bind#0
acdty=02 mxl=22(21) mxlc=00 mal=00 scl=00 pre=00
acflg=13 fl2=206001 frm=00 csi=00 siz=24 ff=0
kxsbbbfp=ffffffff7b338128 bln=22 avl=02 flg=09
value=45

这个错误发生在detach_queue的过程中，这个步骤应该是impdp结束工作后进行的收尾工作，基本上可以确认impdp的错误不会引起什么严重的问题。

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

转载于:http://blog.itpub.net/4227/viewspace-660383/

ckawt40802

关注

0
点赞
踩
0

收藏

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

今天在进行数据泵导入操作时，发现一个bug。继续分析另一个错误信息。数据泵导入分区表统计信息报错（一）：http://yangtingkun.itpub.net/post/468/456176数据泵导入分区表统计信息...
复制链接

扫一扫