以下在11.2.0.3上，2 cores+ext3文件系统， 导出schema下10G数据，使用compression+ parallel=2 ，耗时大越10分钟， 生成的dump文件总共4.7GB大小
[oracle@mlab1 ~]$ expdp dumpfile=HDUMP:bcm%U.dmp filesize=2048M compression=all schemas=bcm parallel=2 logfile=HDUMP:bcm.log Export: Release 11.2.0.3.0 - Production on Wed Sep 26 11:56:19 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Username: / as sysdba Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options Starting "SYS"."SYS_EXPORT_SCHEMA_01": /******** AS SYSDBA dumpfile=HDUMP:bcm%U.dmp filesize=2048M compression=all schemas=bcm parallel=2 logfile=HDUMP:bcm.log Estimate in progress using BLOCKS method... Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA Total estimation using BLOCKS method: 10.82 GB 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/PROCEDURE/PROCEDURE Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS . . exported "BCM"."C_CUSTOMER" 1.194 GB 3000000 rows . . exported "BCM"."C_STOCK" 2.311 GB 10000000 rows . . exported "BCM"."C_ORDER_LINE" 809.8 MB 30004095 rows . . exported "BCM"."E_TRADE" 81.05 MB 4419000 rows . . exported "BCM"."E_SETTLEMENT" 19.90 MB 4590000 rows . . exported "BCM"."E_CASH_TRANSACTION" 32.58 MB 4383000 rows . . exported "BCM"."E_DAILY_MARKET" 33.43 MB 3861000 rows . . exported "BCM"."C_HISTORY" 56.62 MB 3000115 rows . . exported "BCM"."E_TRADE_HISTORY" 6.042 MB 4481000 rows . . exported "BCM"."C_ORDER" 15.22 MB 3000128 rows . . exported "BCM"."E_WATCH_ITEM" 17.15 MB 4414000 rows . . exported "BCM"."E_FINANCIAL" 40.82 MB 1000000 rows . . exported "BCM"."E_ACCOUNT_PERMISSION" 9.659 MB 710000 rows . . exported "BCM"."E_NEWS_ITEM" 1.133 MB 100000 rows . . exported "BCM"."E_CUSTOMER" 3.526 MB 100000 rows . . exported "BCM"."E_ADDRESS" 1.731 MB 150000 rows . . exported "BCM"."E_COMPANY" 826.3 KB 50000 rows . . exported "BCM"."C_DISTRICT" 67.51 KB 1000 rows . . exported "BCM"."C_ITEM" 5.609 MB 100000 rows . . exported "BCM"."E_CUSTOMER_ACCOUNT" 6.697 MB 500000 rows . . exported "BCM"."C_WAREHOUSE" 12.47 KB 100 rows . . exported "BCM"."E_BROKER" 9.898 KB 1000 rows . . exported "BCM"."E_CHARGE" 4.968 KB 15 rows . . exported "BCM"."E_COMMISSION_RATE" 5.937 KB 240 rows . . exported "BCM"."E_COMPANY_COMPETITOR" 703.2 KB 150000 rows . . exported "BCM"."C_NEW_ORDER" 744.1 KB 900088 rows . . exported "BCM"."E_EXCHANGE" 5.468 KB 4 rows . . exported "BCM"."E_INDUSTRY" 6.460 KB 102 rows . . exported "BCM"."E_CUSTOMER_TAXRATE" 413.0 KB 200000 rows . . exported "BCM"."E_NEWS_XREF" 471.7 KB 100000 rows . . exported "BCM"."E_LAST_TRADE" 485.3 KB 68500 rows . . exported "BCM"."E_SECTOR" 5.039 KB 12 rows . . exported "BCM"."E_STATUS_TYPE" 4.867 KB 5 rows . . exported "BCM"."E_TAXRATE" 8.703 KB 320 rows . . exported "BCM"."E_TRADE_TYPE" 5.062 KB 5 rows . . exported "BCM"."E_SECURITY" 2.177 MB 68500 rows . . exported "BCM"."E_WATCH_LIST" 252.6 KB 100000 rows . . exported "BCM"."E_HOLDING" 0 KB 0 rows . . exported "BCM"."E_HOLDING_HISTORY" 0 KB 0 rows . . exported "BCM"."E_HOLDING_SUMMARY" 0 KB 0 rows . . exported "BCM"."E_TRADE_REQUEST" 0 KB 0 rows . . exported "BCM"."E_ZIP_CODE" 103.3 KB 14741 rows Master table "SYS"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded ****************************************************************************** Dump file set for SYS.SYS_EXPORT_SCHEMA_01 is: /home/oracle/dump/bcm01.dmp /home/oracle/dump/bcm02.dmp /home/oracle/dump/bcm03.dmp /home/oracle/dump/bcm04.dmp Job "SYS"."SYS_EXPORT_SCHEMA_01" successfully completed at 12:05:03 [oracle@mlab1 ~]$ cd /home/oracle/dump/ [oracle@mlab1 dump]$ ls -lh total 4.7G -rw-r----- 1 oracle asmadmin 2.0G Sep 26 12:03 bcm01.dmp -rw-r----- 1 oracle asmadmin 2.0G Sep 26 12:04 bcm02.dmp -rw-r----- 1 oracle asmadmin 521M Sep 26 12:05 bcm03.dmp -rw-r----- 1 oracle asmadmin 121M Sep 26 12:05 bcm04.dmp -rw-r--r-- 1 oracle asmadmin 4.9K Sep 26 12:05 bcm.log
由于以上dump文件已被压缩过，所以后续的bzip2或者gz压缩几乎没有意义，而且耗时超长且压缩比极低：
针对数据泵导出 (expdp) 和导入 (impdp)工具性能降低问题的检查表 (Doc ID 1549185.1)适用于:Oracle Database – Enterprise Edition – 版本 10.1.0.2 到 11.2.0.3 [发行版 10.1 到 11.2]本文档所含信息适用于所有平台用途本文档提供了有关使用数据泵导入导出工具传输数据时所遇到的性能相关问题的可能原因。适用范围本文的目标受众是 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 view10.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 Expdp11.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 OBJECTS11.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.711.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 13914808 QUERY AGAINST KU$_INDEX_VIEW KU$ SLOW EVEN AFTER USING METADATA FROM 13844935Note: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 ISSUE2)相对于Patch 16038089，下边两个patch是更好的选择：11.2.0.3 – Patch 1589370011.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 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 mode10.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 mode10.2.0.4.0 – Bug 7439689 – (affects earlier versions as well) Impdp workeer process spinning on MERGE statement11.1.0.6.0 – Bug 7585314 – OCSSD.BIN consumes much too much CPU while running Datapump11.1.0.7.0- Bug 8363441 – Very Expensive Sql Statement During Datapump Import With Many Subpartitions 缺陷详细信息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=:B1Bug 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”对于11.2.0.3, patch 16038089 中包含了以下修复: