惜分飞 » 逻辑备份/恢复

impdp报ORA-39083 ORA-14102错误处理

惜分飞 — Tue, 12 May 2026 09:32:02 +0000

最近两次遇到impdp 报 ORA-39083 ORA-14102错误

[oracle@localhost tmp]$ impdp "'/as sysdba'" directory=expdp_dir  full=y dumpfile=1.dmp 

Import: Release 11.2.0.1.0 - Production on Mon May 11 20:57:00 2026

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01":  "/******** AS SYSDBA" directory=expdp_dir full=y dumpfile=1.dmp
Processing object type TABLE_EXPORT/TABLE/TABLE
ORA-39083: Object type TABLE:"AAA"."XXXXX" failed to create with error:
ORA-14102: only one LOGGING or NOLOGGING clause may be specified
Failing sql is:
CREATE TABLE "AAA"."XXXX" ("OBJECT_ID" NUMBER(9,0) NOT NULL ENABLE, "OBJECT_TYPE" VARCHAR2(8 BYTE) NOT NULL ENABLE
……………………

这个错误比较明显由于AAA.XXXX表的创建语句中有多于一个LOGGING or NOLOGGING,从而导致该创建语句无法正常创建表.

[oracle@iZbp11c0qyuuo1gr7j98upZ ~]$ oerr ora 14102
14102, 00000, "only one LOGGING or NOLOGGING clause may be specified"
// *Cause: LOGGING was specified more than once, NOLOGGING was specified
//         more than once, or both LOGGING and NOLOGGING were specified.
// *Action: Remove all but one of the LOGGING or NOLOGGING clauses and
//          reissue the statement.

查看该表对应的expdp导出日志

[oracle@xff expdmp]$ expdp "'/as sysdba'"  tables="AAA"."XXXX" dumpfile=1.dmp compression=all EXCLUDE=STATISTICS,AUDIT  

Export: Release 11.2.0.4.0 - Production on Mon May 11 21:01:06 2026

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYS"."SYS_EXPORT_TABLE_01":  tables=AAA.XXXX dumpfile=1.dmp compression=all EXCLUDE=STATISTICS,AUDIT 
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 3.207 GB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
. . exported "AAA"."XXXX":"F_GTG"            5.430 MB  968776 rows
. . exported "AAA"."XXXX":"F_CONS"           4.734 MB  920007 rows
…………

比较明显AAA.XXXX表是一个分区表,而且是从11.2.0.4中导出,然后准备导入到11.2.0.1版本数据库中.通过DBMS_METADATA.get_ddl来获取该表的ddl语句确实有多个LOGGING/NOLOGGING(主要是每个分区都有NOLOGGING)

SET ECHO OFF
SET PAGESIZE 0
SET LINES 3000
SET LONG 200000
SET FEEDBACK OFF
SET HEADING OFF
SET SERVEROUTPUT ON SIZE 1000000
COLUMN TXT FORMAT A3000 WORD_WRAPPED
SQL> SQL> SELECT DBMS_METADATA.GET_DDL('TABLE','XXXX','AAA') TXT FROM DUAL;

  CREATE TABLE "AAA"."XXXX"
   (	"OBJECT_ID" NUMBER(9,0) NOT NULL ENABLE,
	"OBJECT_TYPE" VARCHAR2(8) NOT NULL ENABLE,
	"DL_TYPE" VARCHAR2(8) NOT NULL ENABLE,
        ………………
 	CONSTRAINT "PK_OBJECT_DL_DEF" PRIMARY KEY ("OBJECT_ID", "OBJECT_TYPE", "DL_TYPE")
  USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS NOLOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "USERS"  ENABLE
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255  NOLOGGING
  STORAGE(
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "USERS"
  PARTITION BY LIST ("OBJECT_TYPE")
 (PARTITION "F_SUBS"  VALUES ('1') SEGMENT CREATION IMMEDIATE
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
 NOCOMPRESS NOLOGGING
  STORAGE(INITIAL 8388608 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "USERS" ,
  ……………………

尝试在11.2.0.1环境中人工执行该sql创建表,直接报ORA-14020: 不能指定表分区的此物理属性错误

基于此基本上可以确认是由于11.2.0.1默认情况下不支持这样的语法,解决该问题的办法：
1. 重新导出来expdp dmp,加上version=11.2.0.1参数
2. impdp加上impdp TRANSFORM参数TRANSFORM=segment_attributes:n进行导入(impdp TRANSFORM参数)

exp dmp导入报IMP-00098: INTERNAL ERROR: impgst2故障处理

惜分飞 — Wed, 22 Apr 2026 06:09:32 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：exp dmp导入报IMP-00098: INTERNAL ERROR: impgst2故障处理

接到客户反馈,exp导出来的dmp无法导入到库中,而且原库已经被删除并且创建了新库,希望我们协助把dmp里面几个核心表给恢复出来
故障现象
imp导入dmp文件报 IMP-00098: INTERNAL ERROR: impgst2错误

imp导入操作直接终止,无法恢复需要的数据
故障原因
分析导出日志，发现”ORA-24801: 在 OCI lob 函数中非法的参数值” 错误

查询mos发现EXP-56 ORA-24801 During Export KB83982文章

进一步和客户确认，他们确实修改过该库的字符集。基本上可以确认是由于修改字符集导致lob数据损坏，然后exp导出dmp中这些损坏的lob破坏了dmp的完整性，使得dmp无法正常导入
故障解决
对于这样的情况,由于损坏的lob比较靠前,而且不是客户业务用户中数据.处理方法有两种：
1. 直接使用winhex把损坏的lob表从dmp中剔除掉，然后导入数据
2. 直接使用工具从dmp中提取需要的表数据,以前处理过类似文章:
解决imp导入数据报IMP-00098错误
IMP-00098: INTERNAL ERROR: impgst2
exp dmp文件损坏(坏块/corruption)恢复—跳过dmp坏块

expdp导出xml列报ORA-22924故障处理

惜分飞 — Sat, 14 Feb 2026 07:29:19 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：expdp导出xml列报ORA-22924故障处理

expdp导出xml列类型表报错

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
启动 "SYS"."EXPDP_TBA1":  "/******** AS SYSDBA" tables=XFF.XML_TAB dumpfile=XML_TAB.dmp
    DIRECTORY=expdp_dir logfile=expdp_XML_TAB.log EXCLUDE=STATISTICS job_name=expdp_tba1
正在使用 BLOCKS 方法进行估计...
处理对象类型 TABLE_EXPORT/TABLE/TABLE_DATA
使用 BLOCKS 方法的总估计: 13.12 GB
处理对象类型 TABLE_EXPORT/TABLE/TABLE
处理对象类型 TABLE_EXPORT/TABLE/INDEX/INDEX
处理对象类型 TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
处理对象类型 TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
ORA-31693: 表数据对象 "XFF"."XML_TAB" 无法加载/卸载并且被跳过, 错误如下:
ORA-29913: 执行 ODCIEXTTABLEPOPULATE 调出时出错
ORA-22924: 快照太旧
已成功加载/卸载了主表 "SYS"."EXPDP_TBA1"
******************************************************************************
SYS.EXPDP_TBA1 的转储文件集为:
  D:\XML_TAB.DMP
作业 "SYS"."EXPDP_TBA1" 已经完成, 但是有 1 个错误 (于 星期六 2月 14 09:01:26 2026 elapsed 0 00:04:15 完成)

一般对于这些问题的解决思路是找出来异常的行的rowid,然后导出跳过异常行或者把对应的xml列置空,关键就是如何找出来该记录,这里自己写了一个plsql来找出来异常rowid

SQL> declare
  2  page number;
  3  len number;
  4  c varchar2(10);
  5  charpp number := 8132/2;
  6  n number;
  7  v_sqlerrm varchar2(100);
  8  begin
  9  n := 0;
 10  for r in (select rowid rid from XFF.XML_TAB order by rowid) loop
 11  begin
 12  select dbms_lob.getlength (xmltype.getclobval(XML_COL)) into c from XFF.XML_TAB     where rowid = r.rid;
 13  v_sqlerrm := SQLERRM;
 14  insert into result values (n, r.rid, 'good', page, v_sqlerrm);
 15  commit;
 16  exception
 17  when others then
 18  dbms_output.put_line ('Error on rowid ' ||r.rid||' page '||page);
 19  dbms_output.put_line (sqlerrm);
 20  v_sqlerrm := SQLERRM;
 21  insert into result values (n, r.rid, 'bad',page,v_sqlerrm);
 22  commit;
 23  end;
 24  end loop;
 25  end;
 26  /
Error on rowid AAASO1AAKAAAH5bAAC page
ORA-22924: 快照太旧
ORA-06512: 在 "SYS.XMLTYPE", line 138
Error on rowid AAASO1AAKAAAIPtAAZ page
ORA-22924: 快照太旧
ORA-06512: 在 "SYS.XMLTYPE", line 138
Error on rowid AAASO1AAKAAAIRfAAU page
ORA-22924: 快照太旧
ORA-06512: 在 "SYS.XMLTYPE", line 138
Error on rowid AAASO1AAKAAAIS9AAW page
ORA-22924: 快照太旧
ORA-06512: 在 "SYS.XMLTYPE", line 138
Error on rowid AAASO1AAKAAAIT7AAW page
ORA-22924: 快照太旧
ORA-06512: 在 "SYS.XMLTYPE", line 138
Error on rowid AAASO1AAKAAAIT/AAG page
ORA-22924: 快照太旧
ORA-06512: 在 "SYS.XMLTYPE", line 138

PL/SQL 过程已成功完成。

然后expdp导出数据跳过这些异常的rowid的par文件

directory=expdp_dir
dumpfile=expdp_XFF.XML_TAB.dmp
logfile=expdp_XFF.XML_TAB.log
tables=XFF.XML_TAB
query="XFF.XML_TAB:WHERE rowid not IN  ('AAASO1AAKAAAH5bAAC','AAASO1AAKAAAIPtAAZ','AAASO1AAKAAAIT7AAW',
'AAASO1AAKAAAIT/AAG', 'AAASO1AAKAAAIRfAAU','AAASO1AAKAAAIS9AAW')"
job_name=exp_1

数据可以正常到导出

也可以通过update语句直接把异常的xml值直接置空

update XFF.XML_TAB
set XML_COL = XMLType.createXML('')
where rowid in (select checked_rowid from result where status='bad');

impdp导入数据丢失sys授权问题分析

惜分飞 — Mon, 20 Jan 2025 00:17:21 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：impdp导入数据丢失sys授权问题分析

在使用expdp/impdp迁移的过程中,偶尔会遇到用户中关于sys对象的授权丢失导致不少pl/sql程序无效,通过测试重现sys授权丢失现象
创建用户并进行sys对象授权给该用户

C:\Users\XFF>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Sun Jan 19 12:04:22 2025

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create user xff identified by oracle;

User created.

SQL> grant resource,connect to xff;

Grant succeeded.

SQL> grant select on sys.obj$ to xff;

Grant succeeded.

SQL> grant execute on sys.dbms_lock to xff;

Grant succeeded.

SQL> grant select on sys.v_$session to xff;

Grant succeeded.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

使用exp导出数据

C:\Users\XFF>expdp "'/ as sysdba'" dumpfile=xff.dmp schemas=xff

Export: Release 11.2.0.4.0 - Production on Sun Jan 19 12:05:35 2025

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYS"."SYS_EXPORT_SCHEMA_04":  "/******** AS SYSDBA" dumpfile=xff.dmp schemas=xff
Estimate in progress using BLOCKS method...
Total estimation using BLOCKS method: 0 KB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Master table "SYS"."SYS_EXPORT_SCHEMA_04" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.SYS_EXPORT_SCHEMA_04 is:
  C:\APP\XFF\ADMIN\ORCL\DPDUMP\XFF.DMP
Job "SYS"."SYS_EXPORT_SCHEMA_04" successfully completed at Sun Jan 19 12:05:37 2025 elapsed 0 00:00:02

使用impdp导入数据

C:\Users\XFF>impdp "'/ as sysdba'" dumpfile=xff.dmp remap_schema=xff:nxff

Import: Release 11.2.0.4.0 - Production on Sun Jan 19 12:06:22 2025

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01":  "/******** AS SYSDBA" dumpfile=xff.dmp remap_schema=xff:nxff
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Job "SYS"."SYS_IMPORT_FULL_01" successfully completed at Sun Jan 19 12:06:23 2025 elapsed 0 00:00:00

验证用户的权限

C:\Users\XFF>sqlplus xff/oracle

SQL*Plus: Release 11.2.0.4.0 Production on Sun Jan 19 12:09:21 2025

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show user;
USER is "XFF"
SQL> select count(1) from v$session;

  COUNT(1)
----------
        26

SQL> select count(1) from sys.obj$;

  COUNT(1)
----------
     90656

SQL> desc sys.dbms_lock
PROCEDURE ALLOCATE_UNIQUE
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 LOCKNAME                       VARCHAR2                IN
 LOCKHANDLE                     VARCHAR2                OUT
 EXPIRATION_SECS                NUMBER(38)              IN     DEFAULT
FUNCTION CONVERT RETURNS NUMBER(38)
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 ID                             NUMBER(38)              IN
 LOCKMODE                       NUMBER(38)              IN
 TIMEOUT                        NUMBER                  IN     DEFAULT
FUNCTION CONVERT RETURNS NUMBER(38)
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 LOCKHANDLE                     VARCHAR2                IN
 LOCKMODE                       NUMBER(38)              IN
 TIMEOUT                        NUMBER                  IN     DEFAULT
FUNCTION RELEASE RETURNS NUMBER(38)
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 ID                             NUMBER(38)              IN
FUNCTION RELEASE RETURNS NUMBER(38)
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 LOCKHANDLE                     VARCHAR2                IN
FUNCTION REQUEST RETURNS NUMBER(38)
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 ID                             NUMBER(38)              IN
 LOCKMODE                       NUMBER(38)              IN     DEFAULT
 TIMEOUT                        NUMBER(38)              IN     DEFAULT
 RELEASE_ON_COMMIT              BOOLEAN                 IN     DEFAULT
FUNCTION REQUEST RETURNS NUMBER(38)
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 LOCKHANDLE                     VARCHAR2                IN
 LOCKMODE                       NUMBER(38)              IN     DEFAULT
 TIMEOUT                        NUMBER(38)              IN     DEFAULT
 RELEASE_ON_COMMIT              BOOLEAN                 IN     DEFAULT
PROCEDURE SLEEP
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 SECONDS                        NUMBER                  IN

SQL> conn nxff/oracle
Connected.
SQL> desc sys.dbms_lock
ERROR:
ORA-04043: object sys.dbms_lock does not exist


SQL> select count(1) from sys.obj$;
select count(1) from sys.obj$
                         *
ERROR at line 1:
ORA-00942: table or view does not exist


SQL> select count(1) from v$session;
select count(1) from v$session
                     *
ERROR at line 1:
ORA-00942: table or view does not exist

确认通过impdp迁移过去的nxff用户没有之前xff用户里面sys授权的对象的访问权限.通过sqlfile查看expdp导出的dmp文件中ddl内容,确认确实没有sys部分的授权

出现这个问题的原因是由于expdp不会导出sys中对象,所以就丢失了这部分授权信息,可以通过获取语句获取权限,然后执行补全

SQL> select 'grant ' || privilege || ' on ' ||'"'||table_name ||'"'||
  2        ' to ' || grantee || ';' "GRANTS"
  3   from dba_tab_privs
  4  where owner = 'SYS' and privilege not in ('READ', 'WRITE')
  5    and grantee in ('XFF')
  6  order by 1;

GRANTS
--------------------------------------------------------------------------------
grant EXECUTE on "DBMS_LOCK" to XFF;
grant SELECT on "OBJ$" to XFF;
grant SELECT on "V_$SESSION" to XFF;

impdp 创建index提示ORA-00942: table or view does not exist

惜分飞 — Sun, 19 Jan 2025 03:57:57 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：impdp 创建index提示ORA-00942: table or view does not exist

在好几次的expdp/impdp迁移数据的过程中都遇到了index创建的过程中提示表不存在的现象提示类似：

通过观察可以发现index和table不在同一个用户下面,猜测是由于index的用户本身没有访问表的权限,而是通过其他用户比如sys/system或者有dba权限等有访问表和对index所在用户写入数据的用户操作导致,通过试验重现了该现象
创建两个用户,一个有dba权限（用来存放表数据）【xff1】，一个是resource权限用来创建index【xff2】

C:\Users\XFF>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Sun Jan 19 11:36:07 2025

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> CREATE USER XFF1 IDENTIFIED BY oracle ;

User created.

SQL> grant dba to xff1;

Grant succeeded.

SQL> CREATE USER XFF2 IDENTIFIED BY oracle ;

User created.

SQL> grant connect,resource to xff2;

Grant succeeded.

SQL> create table xff1.t_object as select * from dba_objects;

Table created.

SQL> create index xff2.i_object on xff1.t_object(object_id);

Index created.

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

使用expdp导出数据

C:\Users\XFF>expdp "'/ as sysdba'" dumpfile=xff.dmp schemas=xff1,xff2

Export: Release 11.2.0.4.0 - Production on Sun Jan 19 11:37:02 2025

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYS"."SYS_EXPORT_SCHEMA_04":  "/******** AS SYSDBA" dumpfile=xff.dmp schemas=xff1,xff2
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 11 MB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
. . exported "XFF1"."T_OBJECT"                           8.774 MB   90627 rows
Master table "SYS"."SYS_EXPORT_SCHEMA_04" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.SYS_EXPORT_SCHEMA_04 is:
  C:\APP\XFF\ADMIN\ORCL\DPDUMP\XFF.DMP
Job "SYS"."SYS_EXPORT_SCHEMA_04" successfully completed at Sun Jan 19 11:37:05 2025 elapsed 0 00:00:02

使用impdp导入数据（把xff用户映射到u中）

C:\Users\XFF>impdp "'/ as sysdba'" dumpfile=xff.dmp remap_schema=xff1:u1,xff2:u2

Import: Release 11.2.0.4.0 - Production on Sun Jan 19 11:37:16 2025

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01":  "/******** AS SYSDBA" dumpfile=xff.dmp remap_schema=xff1:u1,xff2:u2
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
. . imported "U1"."T_OBJECT"                             8.774 MB   90627 rows
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
ORA-39083: Object type INDEX failed to create with error:
ORA-00942: table or view does not exist
Failing sql is:
CREATE INDEX "U2"."I_OBJECT" ON "U1"."T_OBJECT" ("OBJECT_ID") PCTFREE 10 INITRANS 2 MAXTRANS 255  STORAGE
(INITIAL 65536 NEXT  1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "USERS" PARALLEL 1
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
ORA-39112: Dependent object type INDEX_STATISTICS skipped, base object type INDEX:"U2"."I_OBJECT" creation failed
Job "SYS"."SYS_IMPORT_FULL_01" completed with 2 error(s) at Sun Jan 19 11:37:17 2025 elapsed 0 00:00:00

重现了ORA-39083 ORA-00942错误,根据经验确认可能是由于impdp导入的时候,创建index切换到当前index所属用户进行,而该用户没有访问需要创建index对应的表的权限导致,通过impdp sqlfile解析出阿里.sql文件进行分析,确认是该情况导致.

建议一般情况下,不要把表和index创建到不同用户(schema)下面,更不要使用第三用户来操作.

数据泵导出 (expdp) 和导入 (impdp)工具性能降低分析参考

惜分飞 — Sat, 18 Jan 2025 14:15:34 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：数据泵导出 (expdp) 和导入 (impdp)工具性能降低分析参考

适用于:

Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) – 版本 N/A 和更高版本
Oracle Cloud Infrastructure – Database Service – 版本 N/A 和更高版本
Oracle Database Cloud Service – 版本 N/A 和更高版本
Oracle Database – Enterprise Edition – 版本 10.1.0.2 到 12.2.0.1 [发行版 10.1 到 12.2]
Oracle Database Backup Service – 版本 N/A 和更高版本
本文档所含信息适用于所有平台
用途

本文档提供了有关使用数据泵导入导出工具传输数据时所遇到的性能相关问题的可能原因。

适用范围

本文的目标受众是 Oracle10g 和 Oracle11g 数据库的用户，并且使用 Export Data pump 工具从 Oracle 源数据库中导出数据，并使用 Import Data pump 工具将这些数据导入到 Oracle 目标数据库中。本文档仅适用于新的 Export Data Pump (expdp) 和 Import Data Pump (impdp) 客户端，不适用于原始的导出 (exp) 和导入 (imp) 客户端。对于 Oracle10g 及更高版本，我们建议使用数据泵在 Oracle 数据库之间传输数据。

详细信息

简介

从版本 10g (10.1.0) 开始，Oracle 引入了新的 Oracle 数据泵技术，通过该项技术，用户能够以极快的速度将数据和元数据从一个数据库移动到另一个数据库。此项技术是 Oracle 新的数据移动工具（“Export Data pump”和“Import Data pump”）的基础。

在某些情况下，使用数据泵客户端卸载或加载数据时，可能会遇到性能问题。本文档将提供有关安装和配置设置的详细信息，这些设置可能会对数据泵客户端的性能产生影响；还将提供有关如何检查数据泵在某一特定时刻正在进行哪些操作的详细信息；此外，还将讨论一些会对性能产生影响的已知缺陷。

参数

在此部分列出了可能会对数据泵导出或导入作业的性能产生影响的数据泵参数。此外，还列出了一些通用数据库参数 (init.ora/spfile)，我们已知这些参数可能会对数据泵作业产生影响。
如果您遇到了数据泵性能问题并需要解决它，且作业中使用了以下一个或多个参数，请先检查以下备注，并查看在不使用该参数或以不同方式使用该参数的情况下此性能问题是否重现。

数据泵参数：PARALLEL
…
有关详细信息，另请参阅：
Note:365459.1 “Parallel Capabilities of Oracle Data Pump”
.
数据泵参数：DUMPFILE
…
.
Export Data Pump 参数：ESTIMATE
…
有关Export Data Pump 参数 ESTIMATE 的详细信息，另请参阅：
Note.786165.1 “Understanding the ESTIMATE and ESTIMATE_ONLY parameter in Export DataPump”
.
Export Data Pump 参数：FLASHBACK_SCN and FLASHBACK_TIME
…
.
Import Data Pump 参数：TABLE_EXISTS_ACTION
…
.
Import Data Pump 参数：REMAP_SCHEMA 或 REMAP_TABLESPACE
…
与此问题相关的详细信息，另请参阅下面的“缺陷详细信息”部分，以及：
Note:429846.1 “Slow Data Pump with REMAP_SCHEMA and REMAP_TABLESPACE parameters”
.
数据库参数： CURSOR_SHARING
…
与此问题相关的详细信息，另请参阅下面的“缺陷详细信息”部分，以及：
Note:94036.1 “Init.ora Parameter “CURSOR_SHARING” Reference Note”
Note:421441.1 “Datapump Import With dblink Going Slow With cursor_sharing Set to ‘force’”
.
导出/Import Data Pump 参数：STATUS
监视正在进行的数据泵作业。此状态信息仅写入到您的标准输出设备中，而不写入到日志文件中（如果存在一个有效的日志文件）。

检查数据泵的活动

已知缺陷概述

下面概述了各个 Oracle10g 和 Orace11g 版本中已知的性能相关缺陷。请参阅概述之后的内容部分，以了解有关这些缺陷和可能的变通方案的详细信息。

注意 1：除了数据泵特定的缺陷，其它组件例如与优化器相关的缺陷也会在数据泵作业期间对性能产生影响。下面仅列出了一些影响最大的缺陷。

注意 2：使用指定的 NETWORK_LINK 参数执行导入时，影响 Export Data Pump 的缺陷也会对 Import Data Pump 产生影响。这些缺陷只在 Export Data Pump 部分列出一次。

Export DataPump (expdp):

10.1.0.1.0 至 10.1.0.3.0
- Bug 3447032 – Import Data Pump is slow when importing statistics
- Bug:4513695 - Poor performance for SELECT with ROWNUM=1 with literal replacement
- Bug 5095025 – Export Data Pump runs out of memory (ORA-4030) when exporting many schema’s
- Bug:5464834 - Export Data Pump runs out of memory (ORA-4030) when many tables are involved
- Bug:5590185 - Consistent Export Data Pump is slow when exporting row data
- Bug:5928639 - Export Data Pump of table can be very slow if CURSOR_SHARING is not EXACT
- Bug 5929373 – Export Data Pump of a table can be very slow if database has many user tables

10.1.0.4.0 至 10.1.0.5.0 以及 10.2.0.1.0 至 10.2.0.3.0
- Bug:4513695 - Poor performance for SELECT with ROWNUM=1 with literal replacement
- Bug 5095025 – Export Data Pump runs out of memory (ORA-4030) when exporting many schema’s
- Bug:5464834 - Export Data Pump runs out of memory (ORA-4030) when many tables are involved
- Bug:5590185 - Consistent Export Data Pump is slow when exporting row data
- Bug:5928639 - Export Data Pump of table can be very slow if CURSOR_SHARING is not EXACT
- Bug 5929373 – Export Data Pump of a table can be very slow if database has many user tables
- Bug 5573425 - Slow Datapump with wrong results due to subquery unnesting and complex view

10.2.0.4.0
- Bug 7413726 - Poor EXPDP performance when db COMPATIBLE=10.2.0.3 or 10.2.0.4 (duplicate of Bug 7710931)
- Bug 7710931 - DataPump export is extremely slow when extracting schema
- Bug 6460304 - (affects earlier versions as well) Expdp domain index dump using RULE Optimizer and slow
- Bug 7722575 -DATAPUMP VIEW KU$_NTABLE_DATA_VIEW causes poor plan / slow Expdp

11.1.0.6.0
- Bug 7585314 - OCSSD.BIN consumes much too much CPU while running Datapump
- Bug 7722575 - DATAPUMP VIEW KU$_NTABLE_DATA_VIEW causes poor plan / slow Expdp

11.1.0.7.0
- Bug 8363441 - Very Expensive Sql Statement During Datapump Import With Many Subpartitions
- Bug 7722575 - DATAPUMP VIEW KU$_NTABLE_DATA_VIEW causes poor plan / slow Expdp
- Bug 8904037 - LT_CTX_PKG.SCHEMA_INFO_EXP IS TAKING MORE TIME WHILE EXPORTING PROCOBJ OBJECTS

11.2.0.1
- Bug 10178675 - expdp slow with processing functional_and_bitmap/index
- Bug 10194031 - EXPDP OF OR XML LEAKS MEMORY / RUNS SLOW 11.2.0.1 WORKS 11.1.0.7
11.2.0.2
- Unpublished Bug 12780993 DATA PUMP PERFORMANCE FOR ESTIMATE=STATISTICS IN EXPORT IS BAD
11.2.0.3
- DATA PUMP PERFORMANCE FOR ESTIMATE=STATISTICS IN EXPORT IS BAD
- Bug 13573203 SLOW INDEX EXPORT DUE TO PERFORMANCE ISSUE WITH METADATA KU$_INDEX_COL_VIEW
- Bug 13717234 - Datapump export for transport is slow handling a large number of objects
- Bug 13914808 QUERY AGAINST KU$_INDEX_VIEW KU$ SLOW EVEN AFTER USING METADATA FROM 13844935
- Bug 14192178 - EXPDP of partitioned table can be slow
- Bug 14794472 - EXPDP TOO SLOW HAVING TOO MANY TABLESPACES
- Bug 16138607 - SLOW EXPDP AFTER 11.2.0.3 UPGRADE
- Bug 16298117 - TTS EXPDP TAKING 26 HOURS TO COMPLETE, MOST OF TIME PROCESSING INDEX INFO
- Bug 16856028 - EXPORT DATAPUMP SLOW ON DATAGUARD STANDBY INSTANCE
- Bug 18793246 - EXPDP slow showing base object lookup during datapump export causes full table scan per object
- Bug 20446613 - EXPORTING NON-STREAMS TABLE FROM STRADMIN SCHEMA OVER NETWORK LINK IS SLOW
- Bug 20236523 - DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY

Note::
1)
对于11.2.0.3, patch 16038089 中包含了以下修复:
- Bug 12325243 - SLOW PERFORMANCE ON EXPDP FUNCTIONAL AND BITMAP INDEXES
- Unpublished Bug 12780993 – DATA PUMP PERFORMANCE FOR ESTIMATE=STATISTICS IN EXPORT IS BAD
- Bug 13573203 - SLOW INDEX EXPORT DUE TO PERFORMANCE ISSUE WITH METADATA KU$_INDEX_COL_VIEW
- Bug 13844935 - QUERY AGAINST KU$_INDEX_VIEW SLOW IN 11.2.0.3
- Bug 14192178 - BUG 14006804 FIX DOES NOT RESOLVE THE PERFORMANCE ISSUE

2)
相对于Patch 16038089，下边两个patch是更好的选择：
11.2.0.3 - Patch 15893700
11.2.0.3.3或更高 – MLR Patch 14742362
这是因为这两个patch包含了Patch 16038089中所有的修复，同时还修复了其它一些之前patch没有修复的性能问题。

3)
所有8个 bug 都在Patch 14742362中修复并已包含11.2.0.4补丁集中，详见：
Note 1562142.1 - 11.2.0.4 Patch Set – List of Bug Fixes by Problem Type

11.2.0.4
- Bug 14794472 - EXPDP TOO SLOW HAVING TOO MANY TABLESPACES
- Bug 13717234 - Datapump export for transport is slow handling a large number of objects
- Bug 16856028 - EXPORT DATAPUMP SLOW ON DATAGUARD STANDBY INSTANCE
- Bug 18469379 - Data pump export estimate phase takes a long time to determine if table is empty
- Bug 18793246 - EXPDP slow showing base object lookup during datapump export causes full table scan per object
- Bug 19674521 - EXPDP takes a long time when exporting a small table
- Bug 20111004 - “COMMENT ON COLUMN” statement waits 1 second on “Wait for Table Lock”
- Bug 20236523 - DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY
- Bug 20548904 - EXPDP HANG IN METADA_ONLY ON A PARTITION TABLE WITH AROUND 40000 SUBPARTITIONS
- Bug 20446613 - EXPORTING NON-STREAMS TABLE FROM STRADMIN SCHEMA OVER NETWORK LINK IS SLOW
- Bug 24560906 - HIGH CPU USAGE FOR PROCESS ORA_Q001_DBT11 AND ORA_Q007_DBT11
- BUG 27634991 - EXPDP FREQUENTLY WAITS ON ‘STREAMS AQ: ENQUEUE BLOCKED ON LOW MEMORY’
Note:
在11.2.0.4上发布的merge patch 20883577包含了以下bug的fix: 18469379, 18793246, 19674521, 20236523 and 20548904
在11.2.0.4上发布的merge patch 21443197包含了以下bug的fix: 18082965 18469379 18793246 20236523 19674521 20532904 20548904

12.1.0.1
- Bug 18469379 - Data pump export estimate phase takes a long time to determine if table is empty
- Bug 18793246 - EXPDP slow showing base object lookup during datapump export causes full table scan per object
- Unpublished Bug 18720801 – DATAPUMP EXPORT IS SLOW DUE TO EXPORT OF SYNOPSES
- Bug 20111004 - “COMMENT ON COLUMN” statement waits 1 second on “Wait for Table Lock”
Note:
MLR Patch 23526956 released on top of 12.1.0.1 contains the fixes for the bugs: 18469379, 18793246
12.1.0.2
- Bug 18793246 - EXPDP slow showing base object lookup during datapump export causes full table scan per object
- Bug 20236523 - DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY
- Bug 20548904 - EXPDP HANG IN METADA_ONLY ON A PARTITION TABLE WITH AROUND 40000 SUBPARTITIONS
- Bug 21128593 - UPDATING THE Primary TABLE AT THE END OF DP JOB IS SLOW STARTING WITH 12.1.0.2

Note:
在12.1.0.2上发布的merge patch 20687195包含了以下bug的fix: 18793246, 20236523 and 20548904
在12.1.0.2上发布的merge patch 21554480包含了以下bug的fix: 18793246, 20236523, 20548904 and 21128593.
在12.1.0.2上发布的merge patch 26949116包含了以下bug的fix: 18793246, 20236523, 20532904, 20548904, 21128593, 22273229, 22862597 and 25139545
12.2.0.1
- Bug 26368590 – EXPDP Is Slow While Updating Primary Table After Upgrade To 12.2
- Bug 27144324 – LONG WAIT TIME AT THE END OF 12.2.0.1 DATAPUMP EXPORT JOB
- Bug 27277810 – DATAPUMP EXPORT EXTREMELY SLOW FETCHING COMMENT OBJECTS
- Bug 24707852 – APPSST12201::PERFORMANCE ISSUE WITH EXPDP DURING FULL DATABASE EXPORT
- Bug 28100495 – DATAPUMP SLOW FOR EMPTY TABLES WHEN UNLOADING TABLE_DATA

- Bug 27634991 - EXPDP FREQUENTLY WAITS ON ‘STREAMS AQ: ENQUEUE BLOCKED ON LOW MEMORY’
- Uunpublished Bug 26736110 – DATAPUMP METADATA EXPORT IS SLOW FOR INDEXES WITH A HIGH PARTITION COUNT
- Bug 29959025 - EXPDP RUNNING LONG TIME QUERYING KU$_SUBPARTITION_EST_VIEW WHEN PROCESSING TABLE_DATA
- Uunpublished Bug 27277810 – DATAPUMP EXPORT EXTREMELY SLOW FETCHING COMMENT OBJECTS

Note:
MLR Patch 27194328 released on top of 12.2.0.1 contains the fixes for the bugs: 26368590 and 27144324
MLR Patch 28398639 released on top of 12.2.0.1 contains the fixes for the bugs: 24707852, 26117287, 26368590, 27144324 and 28100495

MLR Patch 29019842 released on top of 12.2.0.1 contains the fixes for the bugs: 28398639, 23103778, 24829009, 25786141, 27277810 and 27499636

MLR Patch 31189193 released on top of 12.2.0.1 contains the fixes for the bugs:
23103778, 24707852, 24829009, 25786141, 26117287, 26368590, 26736110, 27144324, 27277810, 27499636, 28100495, 28357349, 29613245, 29959025

MLR Patch 31176656 released on top of 12.2.0.1.200114 DBRU contains the fixes of the following bugs:
23103778, 24707852, 24829009, 2578614, 26117287, 26368590, 26736110, 27144324, 27277810, 27499636, 28100495, 28357349, 29613245, 29959025
MLR Patch 31567975 released on top of 12.2.0.1.200714DBJUL2020RU contains the fixes of the following bugs:
23103778,24707852,24829009,25786141,26117287,26368590,26736110,27144324,27277810,27499636,28100495,28357349,29613245,29959025

MLR Patch 31875265 released on top of 12.2.0.1.201020DBOCT2020RU contains the fixes of the following bugs:
23103778,24707852,24829009,25786141,26117287,26368590,26736110,27144324,27277810,27499636,28100495,29613245,29959025
MLR Patch 32370538 released on top of 12.2.0.1.210119DBJAN2021RU contains the fixes of the following bugs:
23103778,24707852, 24829009, 25786141,26117287,26368590,26736110,27144324,27277810,27499636,28100495,28357349,29613245,29959025

18.x.0.0
- Bug 27634991 – EXPDP FREQUENTLY WAITS ON ‘STREAMS AQ: ENQUEUE BLOCKED ON LOW MEMORY’
- Unpublished Bug 26736110 – DATAPUMP METADATA EXPORT IS SLOW FOR INDEXES WITH A HIGH PARTITION COUNT

- Bug 29959025 - EXPDP RUNNING LONG TIME QUERYING KU$_SUBPARTITION_EST_VIEW WHEN PROCESSING TABLE_DATA

- Unpublished Bug 27277810 – DATAPUMP EXPORT EXTREMELY SLOW FETCHING COMMENT OBJECTS
- Bug 28100495 - DATAPUMP SLOW FOR EMPTY TABLES WHEN UNLOADING TABLE_DATA
- Bug 27144324 - LONG WAIT TIME AT THE END OF 12.2.0.1 DATAPUMP EXPORT JOB

Note:
MLR Patch 29611052 released on top of 18.4.0.0.181016DBRU for Bugs: 27144324 and 28100495
MLR Patch 28770317 released on top of 18.3.0.0.180717DBRU for Bugs: 27144324 and 28100495
MLR Patch 30957858 released on top of 18.5.0.0.190115DBRU for Bugs: 26736110, 27144324, 28100495, 28555193 and 29959025
MLR Patch 30736363 released on top of 18.9.0.0.200114DBRU for Bugs: 26736110, 27144324, 27277810, 28100495 and 29959025

19.x.0.0
- Bug 29959025 - EXPDP RUNNING LONG TIME QUERYING KU$_SUBPARTITION_EST_VIEW WHEN PROCESSING TABLE_DATA

- unpublished Bug 28771564 – DATAPUMP EXPORT INVOKED BY A PRIVILEGE USER EXECUTES A QUERY FOR V$OPEN_CURSOR
- unpublished Bug 31050896 – PARALLEL DATAPUMP SLOW ON CONSTRAINTS WHEN USING PRIVILEGED USER
- unpublished Bug 30944402 – SELECT FROM Primary TABLE RUNS SLOW DURING TABLE_DATA EXPORT WHEN THERE ARE MANY SUBPARTITIONS
- Bug 32370367 - EXPDP IN 19.7 THREE TIMES SLOWER THAN IT WAS IN 11.2.0.4
- unpublished Bug 32551008 – CONSOLIDATED BUG OF IMPROVEMENTS TO DATA PUMP / MDAPI PATCHING PROCEDURES
- unpublished Bug 31050896 – Datapump Export Slow on Constraints When Using Privileged User

Note:
MLR Patch 32812124 released on top of 19.10.0.0.210119DBRU contains the fixes for the bugs: 28357349, 28555193, 28771564, 29276889, 29284656, 29613245, 29959025, 30155338,
30157766, 30662417, 30763851, 30822078, 30944402, 30978304, 31200854, 31412130, 31711479, 31976738, 32551008
Import DataPump (impdp):

10.1.0.1.0 至 10.1.0.3.0
- Bug 3447032 – Import Data Pump is slow when importing statistics
- Bug:5292551 - Import Data Pump runs out of memory (ORA-04030) and can be very slow on certain tables
- Bug 5555463 – Import Data Pump can be slow when importing small LOBs in External Table mode

10.1.0.4.0
- Bug:5292551 - Import Data Pump runs out of memory (ORA-04030) and can be very slow on certain tables
- Bug 5555463 – Import Data Pump can be slow when importing small LOBs in External Table mode

10.1.0.5.0
- Bug 3508675 – Import Data Pump is slow when importing TABLE_DATA
- Bug:5292551 - Import Data Pump runs out of memory (ORA-04030) and can be very slow on certain tables
- Bug 5555463 – Import Data Pump can be slow when importing small LOBs in External Table mode

10.2.0.1.0 至 10.2.0.3.0
- Bug:5071931 - Import Data Pump with REMAP_SCHEMA and REMAP_TABLESPACE is slow
- Bug:5292551 - Import Data Pump runs out of memory (ORA-04030) and can be very slow on certain tables
- Bug 6989875 -Transportable Tablespace Import Spins Using CPU
- Bug 5555463 – Import Data Pump can be slow when importing small LOBs in External Table mode

10.2.0.4.0
- Bug 7439689 - (affects earlier versions as well) Impdp workeer process spinning on MERGE statement

11.1.0.6.0
- Bug 7585314 - OCSSD.BIN consumes much too much CPU while running Datapump

11.1.0.7.0
- Bug 8363441 - Very Expensive Sql Statement During Datapump Import With Many Subpartitions

11.2.0.2
- Bug 13609098 - IMPORTING SMALL SECUREFILE LOBS USING DATA PUMP IS SLOW
- Bug 16396856 - TTS IMPDP SEEMS TO HANG AND CONSUME 100% CPU

11.2.0.3
- Bug 13609098 - IMPORTING SMALL SECUREFILE LOBS USING DATA PUMP IS SLOW
- Bug 14834638 - Import slow on create partitioned index
- Bug 16396856 - TTS IMPDP SEEMS TO HANG AND CONSUME 100% CPU
- Bug 19520061 - IMPDP: EXTREMELY SLOW IMPORT FOR A PARTITIONED TABLE
- Bug 20532904 DATAPUMP SLOW FOR PARTITIONED TABLE
- Bug 14192178 - EXPDP of partitioned table can be slow
注意：expdp的bug 14192178的fix对一些impdp/import以及一些DBMS_METADATA的查询也有帮助

11.2.0.4
- Bug 13609098 - IMPORTING SMALL SECUREFILE LOBS USING DATA PUMP IS SLOW
- Bug 19520061 - IMPDP: EXTREMELY SLOW IMPORT FOR A PARTITIONED TABLE

12.1.0.1
- Bug 16396856 - TTS IMPDP SEEMS TO HANG AND CONSUME 100% CPU

12.1.0.2
- Bug 24423416 - IMPDP FOR SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY TAKES HOURS
- Bug 22216154 - TTS IMPORT IS VERY SLOW WHEN THERE ARE A LOT OF OBJECTS INVOLVEDSev 1 SR

- Bug 25786141 – SLOW IMPDP ON THE SYS.KUPW$WORKER.MAIN EXECUTION
- Bug 26960528 – SLOW IMPDP ON THE SYS.KUPW$WORKER.MAIN

12.2.0.1
- Bug 25786141 – SLOW IMPDP ON THE SYS.KUPW$WORKER.MAIN EXECUTION

Note:
MLR Patch 29019842 released on top of 12.2.0.1 contains the fixes for the bugs: 28398639, 23103778, 24829009, 25786141, 27277810 and 27499636

18.x.0.0
- unpublished Bug 30822078 – IMPDP VERY SLOW DUE TO PROCESS REORDERING

19.x.0.0
- unpublished Bug 28950868 – KN:LNX:IMPORT (IMPDP) DOESNOT COMPLETE SINCE DW00 PROCESS SPINNING ON HIGH CPU USAGE
- unpublished Bug 30822078 – IMPDP VERY SLOW DUE TO PROCESS REORDERING

- unpublished BUG 31200854 – ADB-D: IMPORT PERFORMANCE OF PACKAGE_BODY

NOTE:
=====
1/当在12.1.0.2多租户环境下安装datapump patch的post步骤时可能会碰到Bug 23321125 - “DPLOAD DOESN’T CREATE THE SHARED OBJECTS ACROSS ALL PDBS”.
关于更多信息请参考:
Note 2175021.1 - Alert – Multitenant Customers: The objects created by the post-install steps of 12.1.0.2 Generic DataPump Patches Are not Shared Across All PDBS.
2/对于12.1.0.2版本，从April2019 Bundles开始，正确版本的dpload脚本是安装的一部分，并放置在rdbms / admin路径中。这就是为什么未发布的Bug 25139545 – TRACKING BUG TO INCLUDE DPLOAD.SQL FROM MAIN FOR FIXES ON 1120X AND 1210X,从2019年4月开始的DataPump Merge补丁中不再需要。
有关更多详细信息：Note 2539305.1 - ANNOUNCEMENT – DataPump Customers: Impact of Having the Correct Version of DPLOAD.SQL Part of 12.1.0.2 April2019 Bundles and Recommended Method to Rollback Any DataPump Patch That Conflicts With 12.1.0.2 April2019 Bundles
缺陷详细信息

Bug 3447032 – Import Data Pump is slow when importing statistics
- 缺陷：Bug 3447032“DBMS_STATS.SET_COLUMN_STATS can be slow (affects IMPORT)”（不是公开的 bug）
- 症状：导入 INDEX_STATISTICS 或 TABLE_STATISTICS 时，Import（传统客户端）或 Import Data Pump 作业可能显示很长的等待时间
- 版本：10.1.0.3.0 及更低版本
- 已在以下版本中修正：10.1.0.4.0 及更高版本；对于某些平台, Patch:3447032 提供了针对 10.1.0.3.0 的修正
- 打过补丁的文件：exuazo.o kustat.xsl
- 变通方案：排除统计信息导入 (EXCLUDE=statistics)，并在导入完成后手动创建统计信息
- 原因：如何在带有（许多）子分区的表中设置列统计信息的问题
- 跟踪：SQL 跟踪显示对 DBMS_STATS 包的引用
- 备注：必须在两个站点（源数据库和目标数据库）上都应用此 bug 的修正，且必须重新生成全部的 Export 或 Export Data Pump 转储文件，以便在导入时获取性能提升。
.
Bug 3508675 – Import Data Pump is slow when importing TABLE_DATA
- 缺陷：Bug 3508675“APPSST10G: BAD PLAN WHEN QUERYING ALL_POLICIES WHEN IMPORTING TABLE_DATA”（不是公开的 bug）
- 症状：在 TABLE_DATA 的导入阶段，impdp 作业可能会显示较高的 CPU 使用率和较慢的运行速度
- 版本：10.1.0.5.0
- 已在以下版本中修正：10.2.0.1.0 及更高版本； Patch:3508675 提供了可用于 10.1.0.5.0 的通用修正
- 打过补丁的文件：prvtbpdi.plb
- 变通方案：无
- 原因：伴随 Bug 3369744 的修正而产生，ALL_SYNONYMS 视图不显示同义词的同义词（不是公开的 bug）
- 跟踪：SQL 跟踪和 AWR 跟踪显示了查询的执行时间和较高 CPU 使用率：
SELECT count(*) FROM ALL_POLICIES WHERE enable = :y and ins = :y2 and object_name = :tname and object_owner = :sname
- 备注：该 bug 可能会出现在 Oracle Application 数据库（apps）或导入了许多个表的任何其他目标数据库的 impdp 作业期间。
.
Bug 4513695 – Export Data Pump of large table can be very slow when CURSOR_SHARING=SIMILAR
- 缺陷： Bug:4513695 “Poor performance for SELECT with ROWNUM=1 with literal replacement”
- 症状：大型表 (100+ Gb) 的 Export Data Pump 作业速度可能要比原始 exp 客户端的导出慢很多（例如，前者的导出时间超过 24 小时）
- 版本：10.1.0.x 和 10.2.0.3.0 及更低版本
- 已在以下版本中修正：10.2.0.4.0 及更高版本；对于某些平台，Patch:5481520 提供了针对 10.2.0.3.0 的修正
- 打过补丁的文件：apa.o kko.o kkofkr.o qerco.o
- 变通方案：如果可能，在开始 Export Data Pump 作业之前先设置 CURSOR_SHARING=EXACT
- 原因：将 cursor_sharing 设置为 similar 时，基于成本的优化器（Cost Base Optimizer，CBO）中出现查询优化问题
- 跟踪：Data Pump Worker 跟踪显示“SELECT NVL((SELECT /*+ NESTED_TABLE_GET_REFS */ :”SYS_B_0″ FROM … WHERE ROWNUM = :”SYS_B_1″), :”SYS_B_2″) FROM DUAL”的 elapsed fetch 时间值非常高
- 备注：针对此缺陷的修正只能作为 Bug:5481520 “Wrong results with ROWNUM and bind peeking”
的修正予以提供。
.
Bug 5071931 – Import Data Pump with REMAP_SCHEMA and REMAP_TABLESPACE is slow
- 缺陷：Bug:5071931 “DATAPUMP IMPORT WITH REMAP TABLESPACE, AND SCHEMA IS VERY SLOW”
- 症状：在 DDL 的导入阶段，使用 REMAP_SCHEMA 和 REMAP_TABLESPACE 进行的 impdp 作业运行缓慢，例如：TABLE、INDEX、OBJECT_GRANT
- 版本：10.2.0.1.0 至 10.2.0.3.0
- 已在以下版本中修正：10.2.0.4.0 及更高版本；Patch:5071931 提供了适用于 10.2.0.3.0 的通用修正，且对于某些平台，该补丁还提供了针对较低版本的修正
- 打过补丁的文件：prvtmeti.plb
- 变通方案：如果不需要，则不使用 REMAP_% 参数
- 原因：将多个转换链接在一起时出现了问题
- 跟踪：Data Pump Worker 跟踪显示“DBMS_METADATA.CONVERT called”与“DBMS_METADATA.CONVERT returned”之间的 elapsed 时间值较高
- 备注：此缺陷在 Oracle10g Release 1 中不会重现；有关详细信息，另请参阅
Note:429846.1 “Slow Data Pump with REMAP_SCHEMA and REMAP_TABLESPACE parameters”.
.
Bug 5095025 – Export Data Pump runs out of memory (ORA-4030) when exporting many schema’s
- 缺陷：Bug 5095025“ORA-4030 (KXS-HEAP-C,TEMPORARY MEMORY) USING EXPDP”（不是公开的 bug）
- 症状：在导出过程式的对象（比如 schema jobs）时，许多 schema（例如 50+）的 schema 级别 expdp 作业可能会因 PGA 耗尽（内存泄露）而失败
- 版本：10.1.0.x 和 10.2.0.3.0 及更低版本
- 已在以下版本中修正：10.2.0.4.0 和更高版本
- 打过补丁的文件：（ patchset 中）
- 变通方案：如果可能，运行多个 Export Data Pump 作业，使每个作业都导出较少的 schema
- 原因：查询优化问题（基于规则的优化器（Rule Based Optimizer，RBO），而不是基于成本的优化器 (CBO)）
- 跟踪：ORA-4030 和 Data Pump Worker 跟踪可能会显示对以下语句的引用：“SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2(‘PROCDEPOBJ_T’, …”
- 备注：与此缺陷相关的内容：Bug:5464834 、Bug:5928639 和 Bug 5929373（不是公开的 bug）
.
Bug 5292551 – Import Data Pump runs out of memory (ORA-04030) and can be very slow on certain tables
- 缺陷：Bug:5292551 “IMPDP VERY SLOW WHEN IMPORTING A TABLE WITH INITIALIZED COLUMN OF TYPE VARRAY”
- 症状：导入表数据时，特定表（例如包含 Spatial 数据 MDSYS.SDO_GEOMETRY 的表）的 impdp 作业速度可能会非常慢，且在加载这些表时，Data Pump Worker 进程显示内存使用量在不断增加
- 版本：10.1.0.x 和 10.2.0.3.0 及更低版本
- 已在以下版本中修正：10.2.0.4.0 及更高版本；对于某些平台，Patch:5292551 提供了针对 10.2.0.3.0 的修正
- 打过补丁的文件：kpudp.o
- 变通方案：如果可能，排除这些表：EXCLUDE=TABLE:”in(‘TAB_NAME’, …)，并在第二次的表级别 Import Data Pump 作业中单独导入这些表：TABLES=owner.tab_name
- 原因：内存没有释放，这导致存在较大数量的已分配内存
- 跟踪：Heapdump 显示多个 freeable chunk“reeable assoc with marc”或“klcalh:ld_hds”
- 备注：在运行数天之后，impdp 作业可能会失败，并出现错误，例如 ORA-4030（out of process memory when trying to allocate xxx bytes（在尝试分配 xxx 字节时进程内存不足））或 ORA-31626（job does not exist（作业不存在））或内部错误 ORA-00600 [729]、[12432]、[space leak]。
.
Bug 5464834 – Export Data Pump runs out of memory (ORA-4030) when many tables are involved
- 缺陷：Bug:5464834 “ORA-4030 (KXS-HEAP-C,TEMPORARY MEMORY) USING EXPDP”
- 症状：导出表数据时，许多表（例如 250+）的表级别 expdp 作业可能会因 PGA 耗尽（内存泄露）而失败
- 版本：10.1.0.x 和 10.2.0.3.0 及更低版本
- 已在以下版本中修正：10.2.0.4.0 及更高版本；Patch:5464834 提供了适用于 10.1.0.4.0 和 10.2.0.3.0 的通用修正
- 打过补丁的文件：catmeta.sql prvtmeti.plb
- 变通方案：如果可能，运行多个 Export Data Pump 作业，使每个作业都导出较少数量的表
- 原因：查询优化问题（基于规则的优化器 (RBO)，而不是基于成本的优化器 (CBO)）
- 跟踪：ORA-4030 和Data Pump Worker 跟踪可能显示对以下语句的引用：“SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2(‘TABLE_DATA_T’, …”
- 备注：与此缺陷相关的内容：Bug 5095025（不是公开的 bug）、Bug:5928639 和 Bug 5929373（不是公开的 bug）。
Bug 5555463 – Import Data Pump can be slow when importing small LOBs (under 256K)
- 缺陷：Bug 5555463“PERFORMANCE ISSUES FOR DATAPUMP IMPORT/EXTERNAL_TABLE MODE OF TABLES WITH LOBS”（不是公开的 bug）
- 症状：在导入包含小 LOB（小于 256 kb 的 LOB）的表时，发生性能下降、高 CPU 使用率以及 LOB redo 生成的情况
- 版本：10.1.0.x 和 10.2.0.3.0 及更低版本
- 已在以下版本中修正：10.2.0.4.0 及更高版本
- 打过补丁的文件：（在 patchset 中）
- 变通方案：无（如果可能，在“Direct Path”模式下运行加载：ACCESS_METHOD=DIRECT_PATH）
- 原因：在“External Table”模式下加载数据时使用临时 LOB
- 跟踪：（无详细信息）
- 备注：在“Direct Path”模式下，相同表数据的 impdp 作业显示更快的性能
.
Bug 5590185 – Consistent Export Data Pump is slow when exporting row data
- 缺陷：Bug:5590185 “CONSISTENT EXPORT DATA PUMP JOB (FLASHBACK_TIME) HAS SLOWER PERFORMANCE”
- 症状：在使用 FLASHBACK_TIME 或 FLASHBACK_SCN 时或在使用 logical standby 或 Streams 时，涉及较大数量表的 expdp 作业运行缓慢
- 版本：10.1.0.x 和 10.2.0.3.0 及更低版本
- 已在以下版本中修正：10.2.0.4.0 及更高版本；对于某些平台，Patch:5590185 提供了针对 10.2.0.2.0 的修正
- 打过补丁的文件：prvtbpm.plb
- 变通方案：如果不需要，则不运行一致性 Export Data Pump 作业
- 原因：针对数据泵主表的全表扫描
- 跟踪：SQL 跟踪显示以下语句的执行时间：
UPDATE “SYSTEM”.”SYS_EXPORT_SCHEMA_01″ SET scn = :1, flags = :2 WHERE (object_path_seqno = :3) AND (base_process_order = :4) AND (process_order > 0)
- 备注：如果正常的 expdp 作业需要 1 个小时，则现在相同的一致性作业可能需要 8 个小时以上的时间。
.
Bug 5928639 – Export Data Pump can be very slow if CURSOR_SHARING is not EXACT
- 缺陷：Bug:5928639 “DATAPUMP EXPORT SLOW WHEN CURSOR_SHARING is not EXACT”
- 症状：如果涉及到多个表且未将 init.ora 或 spfile 参数 CURSOR_SHARING 设置为 EXACT，则 Export Data Pump 作业的运行速度可能会比较慢
- 版本：10.1.0.x 和 10.2.0.3.0 及更低版本
- 已在以下版本中修正：10.2.0.4.0 及更高版本，已包含 Bug:5464834 的修正（见上文）
- 打过补丁的文件：catmeta.sql prvtmeti.plb
- 变通方案：设置 spfile 参数 CURSOR_SHARING=EXACT
- 原因：查询优化问题（基于规则的优化器 (RBO)，而不是基于成本的优化器 (CBO)）
- 跟踪：Data Pump Worker 跟踪文件显示调用 DBMS_METADATA.FETCH_XML_CLOB 的等待时间较长，SQL 跟踪文件显示对以下语句的引用：“SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2(‘TABLE_DATA_T’, …”
- 备注：与此缺陷相关的内容：Bug 5095025（不是公开的 bug）、Bug:5464834 和 Bug 5929373（不是公开的 bug）。
.
Bug 5929373 – Export Data Pump of a table can be very slow if database has many user tables
- 缺陷：Bug 5929373“APPS ST GSI – DATA PUMP TAKES LONG TIME TO EXPORT DATA”（不是公开的 bug）
- 症状：如果数据库具有多个用户表，则小表的 Export Data Pump 作业的运行速度可能会比较慢
- 版本：10.1.0.x 和 10.2.0.3.0 及更低版本
- 已在以下版本中修正：10.2.0.4.0 及更高版本，已包含 Bug:5464834 的修正（见上文）
- 打过补丁的文件：catmeta.sql prvtmeti.plb
- 变通方案：无
- 原因：查询优化问题（基于规则的优化器 (RBO)，而不是基于成本的优化器 (CBO)）
- 跟踪：Data Pump Worker 跟踪文件显示调用 DBMS_METADATA.FETCH_XML_CLOB 的等待时间较长，SQL 跟踪文件显示对以下语句的引用：“SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2(‘TABLE_DATA_T’, …”
- 备注：数据泵可能需一个小时以上的时间来处理表，而原始的导出客户端则只需要两三分钟；与此缺陷相关的内容：Bug 5095025（不是公开的 bug）、Bug:5464834 和 Bug:5928639。
Bug 7722575 -DATAPUMP VIEW KU$_NTABLE_DATA_VIEW causes poor plan / slow Expdp
- 缺陷：Bug 7722575“DATAPUMP VIEW KU$_NTABLE_DATA_VIEW CAUSES POOR PLAN / SLOW EXPDP”
- 症状：数据泵视图 KU$_NTABLE_DATA_VIEW 和
KU$_NTABLE_BYTES_ALLOC_VIEW 的定义可能会导致执行计划不甚理想以及数据泵导出视图的查询性能不佳
- 版本：10.2.0.x 和 11.1.0.X
- 已在以下版本中修正：10.2.0.5.0 和 11.2
- 打过补丁的文件：catmeta.sql
- 变通方案：无
- 原因：ku$_ntable_data_view 数据泵视图的定义不正确
- 跟踪：SQL 跟踪文件显示以下语句的执行计划成本过高：
SELECT /*+all_rows*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2(‘TABLE_DATA_T’, ’7′)), 0 ,KU$.BASE_OBJ.NAME , …
FROM SYS.KU$_TABLE_DATA_VIEW KU$ WHERE ……
Bug 10178675 – expdp slow with processing functional_and_bitmap/index
- 缺陷：Bug:10178675 “expdp slow with processing functional_and_bitmap/index”
- 症状：EXPDP 显示以下步骤消耗时间过长：
Processing object type SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_AND_BITMAP/INDEX
- 版本：10.2.0.4、11.1.0.7、11.2.0.1、11.2.0.2
- 已在以下版本中修正：11.2.0.3、12.1
- 打过补丁的文件：prvtmeta.plb、prvtmeti.plb
- 变通方案：无
- 原因：导出域索引时，其内部使用的是视图 ku$_2ndtab_info_view。使用 RBO时，此视图上的 select 会生成不良计划并耗费更多时间。
- 跟踪：Expdp Worker (DW) 显示，执行以下形式的 SQL 花费了很长时间：
SELECT INDEX_NAME, INDEX_SCHEMA, TYPE_NAME, TYPE_SCHEMA, FLAGS FROM SYS.KU$_2NDTAB_INFO_VIEW WHERE OBJ_NUM=:B1
Bug 10194031 – EXPDP OF OR XML LEAKS MEMORY / RUNS SLOW 11.2.0.1 WORKS 11.1.0.7
- 缺陷：Bug:10194031 - EXPDP OF OR XML LEAKS MEMORY / RUNS SLOW 11.2.0.1 WORKS 11.1.0.7
- 症状：产生 ORA-4030 错误之前，包含 XMLTYPE 列的表的导出速度可能会非常慢。在尝试导出整个用户表或单独的表时，会发生此问题。
- 版本：11.2.0.1、11.2.0.2
- 已在以下版本中修正：11.2.0.3、12.1
- 变通方案：无
- 原因：对包含 xmltype 数据的表运行 expdp 时，发生内存泄露
Bug 8904037 – LT_CTX_PKG.SCHEMA_INFO_EXP IS TAKING MORE TIME WHILE EXPORTING PROCOBJ OBJECTS
- 缺陷：Bug 8904037 - LT_CTX_PKG.SCHEMA_INFO_EXP IS TAKING MORE TIME WHILE EXPORTING PROCOBJ OBJECTS
- 症状：导出操作在对象类型为 DATABASE_EXPORT/SYSTEM_PROCOBJACT/POST_SYSTEM_ACTIONS/PROCACT_SYSTEM 上花费时间过长。
- 版本：11.1.0.7, 11.2.0.1
- 已在以下版本中修正：11.2.0.2, 12.1
- 变通方案：移除 Workspace Manager 选项
- 原因：由于在11.1.0.7中引入的函数”setCallStackAsValid”

参考：针对数据泵导出 (expdp) 和导入 (impdp)工具性能降低问题的检查表 (Doc ID 1549185.1)

数据泵迁移Wrapped PLSQL之后报PLS-00753

惜分飞 — Tue, 04 Jun 2024 14:49:35 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：数据泵迁移Wrapped PLSQL之后报PLS-00753

记录一个oracle datapump迁移库遇到Wrapped PLSQL无效的Bug 18881811 Data Pump Import of Wrapped PLSQL Corrupts the Body（主要影响版本11.2.0.4/12.1.0.2）

导入时提示:ORA-39082 Object type PACKAGE_BODY:created with compilation warnings.
尝试编译对象提示

SQL> alter package xx.xx compile body;

Warning: Package Body altered with compilation errors.

SQL> show error

PLS-00753: malformed or corrupted wrapped unit

由于涉及的package body 比较多,人工处理比较麻烦,采取临时解决方法
1. drop 掉所有报错的package
2. 使用exp导出所有的对象（rows=n）
3. 使用imp导入
4. 编译无效对象

impdp TRANSFORM参数

惜分飞 — Thu, 16 Dec 2021 13:18:05 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：impdp TRANSFORM参数

在impdp的参数中有一个transform参数,用来实现在创建对象的时候对一些存储参数进行修改,官方关于这个参数说明:

TRANSFORM
要应用于适用对象的元数据转换。
有效的关键字为: OID, PCTSPACE, SEGMENT_ATTRIBUTES 和 STORAGE。

对主要的SEGMENT_ATTRIBUTES和STORAGE参数进行测试

SQL> create user xff identified by oracle default tablespace users;

用户已创建。

SQL> grant dba to xff;

授权成功。

SQL> create table xff.t_1 as select * from dba_objects;

表已创建。

SQL> exit
从 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options 断开

C:\Users\XFF>expdp xff/oracle tables=t_1 dumpfile=t_1.dmp

Export: Release 11.2.0.4.0 - Production on 星期四 12月 16 20:56:50 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
启动 "XFF"."SYS_EXPORT_TABLE_01":  xff/******** tables=t_1 dumpfile=t_1.dmp
正在使用 BLOCKS 方法进行估计...
处理对象类型 TABLE_EXPORT/TABLE/TABLE_DATA
使用 BLOCKS 方法的总估计: 11 MB
处理对象类型 TABLE_EXPORT/TABLE/TABLE
. . 导出了 "XFF"."T_1"                                 8.709 MB   89959 行
已成功加载/卸载了主表 "XFF"."SYS_EXPORT_TABLE_01"
******************************************************************************
XFF.SYS_EXPORT_TABLE_01 的转储文件集为:
  C:\APP\XFF\ADMIN\ORCL\DPDUMP\T_1.DMP
作业 "XFF"."SYS_EXPORT_TABLE_01" 已于 星期四 12月 16 20:56:53 2021 elapsed 0 00:00:02 成功完成

不使用TRANSFORM参数导入效果

C:\Users\XFF>impdp xff/oracle sqlfile=t_2.sql full=y dumpfile=t_1.dmp

Import: Release 11.2.0.4.0 - Production on 星期四 12月 16 21:00:12 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
已成功加载/卸载了主表 "XFF"."SYS_SQL_FILE_FULL_01"
启动 "XFF"."SYS_SQL_FILE_FULL_01":  xff/******** sqlfile=t_2.sql full=y dumpfile=t_1.dmp
处理对象类型 TABLE_EXPORT/TABLE/TABLE
作业 "XFF"."SYS_SQL_FILE_FULL_01" 已于 星期四 12月 16 21:00:12 2021 elapsed 0 00:00:00 成功完成

对应的t_2.sql文件内容

transform=storage:n参数导入效果

C:\Users\XFF>impdp xff/oracle sqlfile=t_1.sql full=y dumpfile=t_1.dmp transform=storage:n

Import: Release 11.2.0.4.0 - Production on 星期四 12月 16 20:58:04 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
已成功加载/卸载了主表 "XFF"."SYS_SQL_FILE_FULL_01"
启动 "XFF"."SYS_SQL_FILE_FULL_01":  xff/******** sqlfile=t_1.sql full=y dumpfile=t_1.dmp transform=storage:n
处理对象类型 TABLE_EXPORT/TABLE/TABLE
作业 "XFF"."SYS_SQL_FILE_FULL_01" 已于 星期四 12月 16 20:58:04 2021 elapsed 0 00:00:00 成功完成

对应的t_1.sql文件内容

transform=segment_attributes:n参数导入效果

C:\Users\XFF>impdp xff/oracle sqlfile=t_3.sql full=y dumpfile=t_1.dmp  transform=segment_attributes:n

Import: Release 11.2.0.4.0 - Production on 星期四 12月 16 21:00:36 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
已成功加载/卸载了主表 "XFF"."SYS_SQL_FILE_FULL_01"
启动 "XFF"."SYS_SQL_FILE_FULL_01":  xff/******** sqlfile=t_3.sql full=y dumpfile=t_1.dmp transform=segment_attributes:n 
处理对象类型 TABLE_EXPORT/TABLE/TABLE
作业 "XFF"."SYS_SQL_FILE_FULL_01" 已于 星期四 12月 16 21:00:36 2021 elapsed 0 00:00:00 成功完成

对应的t_3.sql文件内容

transform=segment_attributes:n除掉了所有存储相关信息，对象数据直接导入到用户默认表空间中
transform=storage:n导入的时候除掉了STORAGE部分,表空间信息依旧存在(也就是说导入到表原始表空间中)

expdp 并行导出单表数据

惜分飞 — Fri, 18 Jun 2021 07:03:52 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：expdp 并行导出单表数据

在某些情况下,需要使用并行的方法使用 datapump 对单个对象并行导出,导入加快数据迁移的数据
expdp导出操作

#!/bin/bash
chunk=10
for ((i=0;i${chunk}\) = ${i}\" directory=DMP dumpfile=lob_test_${i}.dmp logfile= log_test_${i}.log &
  echo $i
done

impdp导入操作

#!/bin/bash
chunk=10
for ((i=0;idumpfile= lob_test_${i}.dmp logfile=TABLE_imp_log_test_${i}.log  DATA_OPTIONS=DISABLE_APPEND_HINT  CONTENT=DATA_ONLY &
 echo $i
done

在12c版本开始impdp可能会启用ENABLE_PARALLEL_DML特性,需要注意
参考:Optimising LOB Export and Import Performance via Oracle DataPump

datapump network_link遭遇ORA-12899错误

惜分飞 — Wed, 16 Jun 2021 05:23:08 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：datapump network_link遭遇ORA-12899错误

在给一个客户使用expdp+network_link导出数据,然后通过impdp导入数据的过程中遇到ORA-12899问题.

对原库和现在库进行分析

原库和目标库表结构一致,原库该表存储数据实际长度确实为1,但是在impdp导入的时候提示需要长度为3.通过分析,确认原库的nls_length_semantics参数设置为char了,直接使用impdp+network_link不落地方式导入该表数据成功

根据上述情况,查询相关文档,确认类似记录为:
ORA-12899 When Using IMPDP Over Network Link (Doc ID 414901.1)
ORA-26059 During Impdp Using Export Dump Taken With NETWORK_LINK Option (Doc ID 2266956.1)
虽然都不是完全匹配该问题,但是基本上可以确认expdp的network_link和nls_length_semantics参数是引起该问题的根本原因,在后续的迁移中,尽量保持nls_length_semantics参数一致.