當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

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

發(fā)布時(shí)間：2023/12/10 编程问答 37 豆豆

生活随笔收集整理的這篇文章主要介紹了 oracle数据泵导入分区表,数据泵导入分区表统计信息报错（七）小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

其實(shí)問題的引出是由于出現(xiàn)第一篇文章中描述的問題，不過隨著問題的深入研究，挖掘出了一些隱藏的很深的問題，不過問題的研究也慢慢脫離了原本的問題。

在解決了表統(tǒng)計(jì)信息鎖定的問題后，在回過頭看看導(dǎo)致第一篇文章中錯(cuò)誤的具體原因。

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"啟動(dòng)"TEST"."SYS_IMPORT_FULL_01":? test/******** directory=d_test dumpfile=zhejiang_order.dp logfile=zhejiang_order.log remap_schema=zhejiang:test include=table/statistics處理對(duì)象類型TABLE_EXPORT/TABLE/TABLE_DATA處理對(duì)象類型TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

ORA-39083:對(duì)象類型TABLE_STATISTICS創(chuàng)建失敗,出現(xiàn)錯(cuò)誤:

ORA-06550:第12行,第17列:

PL/SQL: ORA-00917:缺失逗號(hào)ORA-06550:第4行,第115列:

PL/SQL: SQL Statement ignored

ORA-06550:第20行,第17列:

PL/SQL: ORA-00917:缺失逗號(hào)ORA-06550:第12行,第161列:

PL/SQL: SQL Statement ignored

ORA-06550:第28行,第17列:

PL/SQL: ORA-00917:缺失逗號(hào)ORA-06550:第20行,第161列:

PL/SQL: SQL Statement ignored

ORA-06550:第36行,第17列:

PL/SQL: ORA-00917:缺失逗號(hào)ORA-06550:第28行,第1作業(yè)"TEST"."SYS_IMPORT_FULL_01"已經(jīng)完成,但是有1個(gè)錯(cuò)誤(于18:42:13完成)

顯然第一篇文章出現(xiàn)的錯(cuò)誤和上面幾篇文章描述的錯(cuò)誤還是有差距的，懷疑導(dǎo)致問題的原因出在DMP文件上。

下面通過TRACE的方式，檢查導(dǎo)致問題產(chǎn)生的具體原因。

設(shè)置TRACE的方式有很多種，但是對(duì)于這種執(zhí)行很快就結(jié)束的錯(cuò)誤，最好的辦法是通過登陸觸發(fā)器。不過使用登陸觸發(fā)器仍然有點(diǎn)復(fù)雜，其實(shí)了解IMPDP工作特性后，可以方便的利用DBMS_MONITOR包來設(shè)置TRACE。

在剛才執(zhí)行導(dǎo)入的時(shí)候，在另外的會(huì)話檢查數(shù)據(jù)泵后臺(tái)進(jìn)程對(duì)應(yīng)的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的會(huì)話的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過程已成功完成。

再次運(yùn)行導(dǎo)入，TRACE對(duì)應(yīng)的信息很簡(jiǎn)單：

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

這顯然不是我們要尋找的出錯(cuò)的導(dǎo)入會(huì)話，打開MODULE為udi@racnode1 (TNS V1-V3)的會(huì)話對(duì)應(yīng)的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過程已成功完成。

運(yùn)行導(dǎo)入，得到了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的會(huì)話的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運(yùn)行CURSOR #39是出現(xiàn)了錯(cuò)誤。這個(gè)錯(cuò)誤信息是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.

配合這個(gè)錯(cuò)誤信息和IMPDP輸出參數(shù)，懷疑是Oracle在執(zhí)行PL/SQL代碼的時(shí)候，由于輸入?yún)?shù)的錯(cuò)誤，導(dǎo)致了問題的產(chǎn)生。

下面看看CURSOR #39對(duì)應(yīng)的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

這個(gè)錯(cuò)誤發(fā)生在detach_queue的過程中，這個(gè)步驟應(yīng)該是impdp結(jié)束工作后進(jìn)行的收尾工作，基本上可以確認(rèn)impdp的錯(cuò)誤不會(huì)引起什么嚴(yán)重的問題。

總結(jié)

以上是生活随笔為你收集整理的oracle数据泵导入分区表,数据泵导入分区表统计信息报错（七）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：中国行政区边界shp下载（省，市，县）
下一篇：自定义安装mysql linux_lin