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

最新推荐文章于 2023-05-13 09:55:11 发布
最新推荐文章于 2023-05-13 09:55:11 发布
阅读量1.7k 收藏 1
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xxjj2003/article/details/50805727
版权
转到底部转到底部

文档内容

用途
 适用范围
 详细信息
 简介
 参数
 检查数据泵的活动
 已知缺陷概述
 参考

适用于:

Oracle Database - Enterprise Edition - 版本 10.1.0.2 到 12.1.0.2 [发行版 10.1 到 12.1]
本文档所含信息适用于所有平台

用途

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

适用范围

本文的目标受众是 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)，我们已知这些参数可能会对数据泵作业产生影响。
如果您遇到了数据泵性能问题并需要解决它，且作业中使用了以下一个或多个参数，请先检查以下备注，并查看在不使用该参数或以不同方式使用该参数的情况下此性能问题是否重现。

  1. 数据泵参数：PARALLEL
    ...
    有关详细信息，另请参阅：
    Note:365459.1 "Parallel Capabilities of Oracle Data Pump"
    .
  2. 数据泵参数：DUMPFILE
    ...
    .
  3. Export Data Pump 参数：ESTIMATE
    ...
    有关Export Data Pump 参数 ESTIMATE 的详细信息，另请参阅：
    Note.786165.1 "Understanding the ESTIMATE and ESTIMATE_ONLY parameter in Export DataPump"
    .
  4. Export Data Pump 参数：FLASHBACK_SCN and FLASHBACK_TIME
    ...
    .
  5. Import Data Pump 参数：TABLE_EXISTS_ACTION
    ...
    .
  6. Import Data Pump 参数：REMAP_SCHEMA 或 REMAP_TABLESPACE
    ...
    与此问题相关的详细信息，另请参阅下面的“缺陷详细信息”部分，以及：
    Note:429846.1 "Slow Data Pump with REMAP_SCHEMA and REMAP_TABLESPACE parameters"
    .
  7. 数据库参数： 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'" 
    .
  8. 导出/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.3
- <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 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 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

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"

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
- Unpublished Bug 17662403 - DATA PUMP EXPORT: SLOW I/O PERFORMANCE WRITING TO NFS DISKS  
-   Bug 20548904  - EXPDP HANG IN METADA_ONLY ON A PARTITION TABLE WITH AROUND 40000 SUBPARTITIONS
-   Bug 21128593  - UPDATING THE MASTER 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.


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

 缺陷详细信息

  1. 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 转储文件，以便在导入时获取性能提升。
    .
  2. 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 作业期间。
    .
  3. 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”
    的修正予以提供。
    .
  4. 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".
    .
  5. 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）
    .
  6. 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]。
    .
  7. 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）。

  8. 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 作业显示更快的性能
    .
  9. 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 个小时以上的时间。
    .
  10. 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）。
    .
  11. 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。
  12. 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 ......
  13. 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
  14. 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 时，发生内存泄露
  15. 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 中包含了以下修复:

参考

BUG:7413726  - POOR EXPDP PERFORMANCE WHEN DB COMPATIBLE=10.2.0.3 OR 10.2.0.4

NOTE:223730.1  - Automatic PGA Memory Management
BUG:10194031  - EXPDP OF OR XML LEAKS MEMORY / RUNS SLOW 11.2.0.1 WORKS 11.1.0.7
BUG:10416375  - DATA PUMP EXPDP JUST HANG ON KU$_TEMP_SUBPARTDATA_VIEW



BUG:4438573  - DATAPUMP RUNS VERY SLOW OVER NETWORK FOR TABLES WITH CLOBS
BUG:4513695  - SELECT WITH ROWNUM=1 PERFORMANCE IS TOO LATE USING CURSOR_SHARING=SIMILAR
BUG:5573425  - NON-CORRELATED SUBQUERY RETURNS WRONG RESULTS, LIKE A CARTESIAN JOIN
BUG:5590185  - CONSISTENT EXPORT DATA PUMP JOB HAS SLOWER PERFORMANCE
BUG:8225599  - ER: CTAS WITH LOB ACCESS ACROSS DATABASE LINK IS SLOW
NOTE:286496.1  - Export/Import DataPump Parameter TRACE - How to Diagnose Oracle Data Pump
BUG:6460304  - EXPDP TAKES MORE TIME
NOTE:1290574.1  - Datapump Performance Issue With Content=Metadata_only
BUG:5071931  - DATAPUMP IMPORT WITH REMAP TABLESPACE, AND SCHEMA IS VERY SLOW

BUG:5292551  - IMPDP VERY SLOW WHEN IMPORTING A TABLE WITH INITIALIZED COLUMN OF TYPE VARRAY


NOTE:331221.1  - 10g Export/Import Process for Oracle Applications Release 11i
NOTE:362205.1  - 10g Release 2 Export/Import Process for Oracle Applications Release 11i
NOTE:365459.1  - Parallel Capabilities of Oracle Data Pump
BUG:7439689  - IMPDP HANGS ON IDLE EVENT 'WAIT FOR UNREAD MESSAGE ON BROADCAST CHANNEL'
NOTE:421441.1  - DataPump Import Via NETWORK_LINK Is Slow With CURSOR_SHARING=FORCE
NOTE:762160.1  - DataPump Import (IMPDP) Hangs When Using Parameters TRANSPORT_DATAFILES and REMAP_DATAFILE
NOTE:786165.1  - Understanding the ESTIMATE and ESTIMATE_ONLY Parameters in Export DataPump
BUG:6807289  - IMPDP WITH REMAP_SCHEMA AND REMAP_TABLESPACE HANGS AT TABLE STATISTICS
BUG:6989875  - TRANSPORTABLE TABLESPACE IMPORT SPINS USING CPU
BUG:5464834  - ORA-4030 USING EXPDP
BUG:5928639  - DATAPUMP EXPORT SLOW WHEN CURSOR_SHARING != EXACT

BUG:7722575  - DATAPUMP VIEW KU$_NTABLE_DATA_VIEW CAUSES POOR PLAN / SLOW EXPDP
BUG:5481520  - WRONG RESULTS WITH ROWNUM AND BIND PEEKING
NOTE:429846.1  - Slow Data Pump with REMAP_SCHEMA and REMAP_TABLESPACE parameters
NOTE:94036.1  - Init.ora Parameter "CURSOR_SHARING" Reference Note
NOTE:155477.1  - Parameter DIRECT: Conventional Path Export Versus Direct Path Export

BUG:8363441  - VERY EXPENSIVE SQL STATEMENT DURING DATAPUMP IMPORT WITH MANY SUBPARTITIONS
BUG:5996665  - EXPDP HANGING MORE THAN 5 HOURS
NOTE:277905.1  - Export/Import DataPump Parameter TABLES - How to Export and Import Tables Residing in Different Schemas
BUG:10178675  - EXPDP SLOW WITH PROCESSING FUNCTIONAL_AND_BITMAP/INDEX
BUG:7585314  - OCSSD.BIN CONSUMING 6 TIMES MORE CPU IF EXCESSIVE DATAPUMP IS RUNNING ON NODE
BUG:7710931  - DATAPUMP EXPORT IS EXTREMELY SLOW WHEN EXTRACTING SCHEMA
NOTE:14834638.8  - Bug 14834638 - IMPDP import slow on create partitioned index
NOTE:1673445.1  - EXPDP Estimate Phase Takes a Long Time With 12.1.0.1
NOTE:885388.1  - DataPump Export Is Slow After Upgrade To 11g When Workspace Manager Is Installed
BUG:7710931  - DATAPUMP EXPORT IS EXTREMELY SLOW WHEN EXTRACTING SCHEMA
desert_xu
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Linux：Oracle导出导入数据泵（EXPDP，IMPDP）
12-14
数据泵技术是Oracle Database 10g 中的新技术，它比原来导入/导出(imp,exp)技术快15－45倍。速度的提高源于使用了并行技术来读写导出转储文件。 expdp/impdp和exp/imp的区别 exp和imp是客户端工具程序，它们既可以在客户端使用，也可以在服务端使用。 expdp和impdp是服务端的工具程序，他们只能在Oracle服务端使用，不能在客户端使用。 imp只适用于exp导出的文件，不适用于expdp导出文件；impdp只适用于expdp导出的文件，而不适用于exp导出文件。 对于10g以上的服务器，使用exp通常不能导出0行数据的空表，而此时必须使用exp
Oracle 10g Data Pump Expdp/Impdp 详解
小宝老豆的专栏
09-28 2633
一. 官网说明 1.  Oracle 10g文档如下： http://download.oracle.com/docs/cd/B19306_01/server.102/b14215/dp_overview.htm#i1010293   Data Pump Components Oracle Data Pump is made up of three distinct parts: （1
数据泵导入导出
limingjie01的专栏
02-03 715
a. 导出时指定导出schema，即带上schemas=xx用户的参数，排除掉统计分析信息，即带上exclude=statistics参数； b. 导入时分三步或两走： B.1先导入全部数据，但排除掉索引和约束，排除掉约束的话可以把约束相对应的索引也排除掉，否则是排除不掉的，即带入exclude=index,constraint参数。  B.2再（且只）导入所有约束，即把exclude=i
oracle 11g 系统死机,Oracle 11g IMPDP卡死出现wait for unread message on broadcast channel等待事件处理...
weixin_39580715的博客
04-05 1774
背景介绍11g数据库在进行IMPDP数据恢复的时候，有时候恢复操作一直卡这不动，这时候可以查询下该恢复会话的等待事件，如果看到等待事件是“wait for unread message on broadcast channel”，通过以下思路解决。原因分析一般造成该问题的原因有两种：出现可能是假死或者导入对象为大对象，造成表象为卡顿的现象。首先观察数据库告警日志，发现告警日志中显示正常，并未提示表...
Expdp For Metadata Is Slow In 11.2.0.3 With Partitioned Objects [ID 1466040.1]
DBA never sleep-DBA，永不眠
07-07 6430
Applies to: Oracle Server - Enterprise Edition - Version 11.2.0.3 to 11.2.0.3 [Release 11.2] Information in this document applies to any platform. Symptoms - 11.2 Database with partitioned objec
oracle 数据泵排除表,【impdp】使用impdp工具排除特定表的导入
weixin_39981041的博客
04-07 1495
在《【imp】使用imp工具迁移数据时迂回地排除特定表的导入》(http://space.itpub.net/519536/viewspace-672170)文中提到使用imp工具迂回的完成排除特定表导入问题。使用impdp工具可以非常容易的实现。1.环境准备1)创建用户sec并给予sys@ora10g> drop user sec cascade;sys@ora10g> create...
数据库泵（expdp/impdp）排除 exclude表
lltfjsy的博客
05-13 2745
数据库泵（expdp/impdp）排除 exclude表
expdp 数据泵导出排除多个表
热门推荐
halley333的专栏
03-10 1万+
在做expdp数据泵备份的时候，常常遇到这样的情况：某些临时表很大，但是数据并不需要备份。我们需要将这些表排除掉，以避免浪费不必要的磁盘空间。 我们有这样的需求，需要排除MV开头和TMP开头的所有表。 如果只是简单的排除以MV开头的表，使用如下命令即可： expdp username/password dumpfile=$EXPFILE logfile=$
【impdp】使用impdp工具排除特定表的导入
weixin_33860722的博客
08-15 4446
http://space.itpub.net/519536/viewspace-672402 在《【imp】使用imp工具迁移数据时迂回地排除特定表的导入》（http://space.itpub.net/519536/viewspace-672170）文中提到使用imp工具迂回的完成排除特定表导入问题。使用impdp工具可以非常容易的实现。1.环境准备1）创建用户sec并给...
oracle11g 数据泵 vs 客户端命令备份最佳实践
04-15
本例为oracle11g版本下整理的oracle数据备份恢复的实际操作，简单实用； * oracle客户端命令备份与恢复 * oracle服务端命令备份与恢复 * oracle数据泵备份恢复大量数据的操作 各例均为笔者亲自实践所整理，大家尽可放心使用，谢谢。
oracle的impdp和expdp数据泵导入导出全备数据库-详细笔记文档总结
06-30
oracle的impdp和expdp数据泵导入导出全备数据库-详细笔记文档总结
Oracle expdp-impdp 数据泵导入导出（远程）
12-14
2、创建逻辑目录用于导出导入数据（目录一定要真实存在） create or replace directory out_dir as 'C:\out'; --out_dir（逻辑目录名，可以随便取） 3、也可以将这个逻辑目录授权给其他用户 grant read,write on ...
账单中心数据泵expdp和impdp异机导入导出工作案例
06-30
账单中心数据泵expdp和impdp异机导入导出工作案例
oracle11g expdp impdp 分区表重映射导出导入数据迁移方案
12-06
oracle expdp impdp 分区表重映射导出导入 数据迁移方案，以SI01用户为例子，将用户分区表导出后，将分区表重映射到新的表空间，完成数据迁移和检查。照方案例子按步去做，一定能成功。
多图表实现员工满意度调查数据分析python
04-22
员工满意度是指员工对于工作环境、待遇、职业发展和组织管理等方面的满意程度。它是衡量员工对工作的整体感受和情绪状态的重要指标。
2020届软件工程本科毕业生毕业设计项目.zip
04-22
2020届软件工程本科毕业生毕业设计项目
基于stm32平衡小车
04-22
平衡小车 基于stm32 平衡小车 基于stm32 平衡小车 基于stm32
c语言火车票订票管理源码.rar
最新发布
04-22
c语言火车票订票管理源码.rar
如何使用expdp和impdp工具进行数据导入导出？
02-28
expdp和impdp是Oracle数据库提供的工具，用于进行数据的导出和导入操作。下面是使用expdp和impdp工具进行数据导入导出的步骤： 1. 导出数据（使用expdp）： - 打开命令行窗口或终端，并登录到Oracle数据库。 - ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值