針對資料泵匯出 (expdp) 和匯入 (impdp)工具效能降低問題的檢查表

mosdoc發表於2016-12-01

針對資料泵匯出 (expdp) 和匯入 (impdp)工具效能降低問題的檢查表 (文件 ID 1549185.1)


適用於:

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
 - - 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 
 -  - Export Data Pump runs out of memory (ORA-4030) when many tables are involved
 - - Consistent Export Data Pump is slow when exporting row data
 - - 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
 - - 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
 - - Export Data Pump runs out of memory (ORA-4030) when many tables are involved
 - - Consistent Export Data Pump is slow when exporting row data
 - - 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
- - Slow Datapump with wrong results due to subquery unnesting and complex view

10.2.0.4.0
- - Poor EXPDP performance when db COMPATIBLE=10.2.0.3 or 10.2.0.4 (duplicate of )
- - DataPump export is extremely slow when extracting schema
- - (affects earlier versions as well) Expdp domain index dump using RULE Optimizer and slow
- -DATAPUMP VIEW KU$_NTABLE_DATA_VIEW causes poor plan / slow Expdp
 
11.1.0.6.0
- - OCSSD.BIN consumes much too much CPU while running Datapump
- - DATAPUMP VIEW KU$_NTABLE_DATA_VIEW causes poor plan / slow Expdp

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

11.2.0.1
- - expdp slow with processing functional_and_bitmap/index
- - 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
- SLOW INDEX EXPORT DUE TO PERFORMANCE ISSUE WITH METADATA KU$_INDEX_COL_VIEW
- QUERY AGAINST KU$_INDEX_VIEW KU$ SLOW EVEN AFTER USING METADATA FROM 13844935
- - EXPDP of partitioned table can be slow
- - EXPDP TOO SLOW HAVING TOO MANY TABLESPACES
- - SLOW EXPDP AFTER 11.2.0.3 UPGRADE
- - TTS EXPDP TAKING 26 HOURS TO COMPLETE, MOST OF TIME PROCESSING INDEX INFO
- Bug 16856028 - EXPORT DATAPUMP SLOW ON DATAGUARD STANDBY INSTANCE
- - EXPDP slow showing base object lookup during datapump export causes full table scan per object
- - EXPORTING NON-STREAMS TABLE FROM STRADMIN SCHEMA OVER NETWORK LINK IS SLOW
- - DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY

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

2)
相對於，下邊兩個patch是更好的選擇：
11.2.0.3 -
11.2.0.3.3或更高 - MLR
這是因為這兩個patch包含了中所有的修復，同時還修復了其它一些之前patch沒有修復的效能問題。

3)
所有8個 bug 都在中修復並已包含11.2.0.4補丁集中，詳見：
Note 1562142.1 - 11.2.0.4 Patch Set - List of Bug Fixes by Problem Type

11.2.0.4
- - EXPDP TOO SLOW HAVING TOO MANY TABLESPACES
- Bug 16856028 - EXPORT DATAPUMP SLOW ON DATAGUARD STANDBY INSTANCE
- - Data pump export estimate phase takes a long time to determine if table is empty
- - EXPDP slow showing base object lookup during datapump export causes full table scan per object
- - EXPDP takes a long time when exporting a small table
- - "COMMENT ON COLUMN" statement waits 1 second on "Wait for Table Lock"
- - DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY
- - EXPDP HANG IN METADA_ONLY ON A PARTITION TABLE WITH AROUND 40000 SUBPARTITIONS
- - EXPORTING NON-STREAMS TABLE FROM STRADMIN SCHEMA OVER NETWORK LINK IS SLOW
- - EXPORT IS SLOW WAITING FOR "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
- - Data pump export estimate phase takes a long time to determine if table is empty
- - 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
- - "COMMENT ON COLUMN" statement waits 1 second on "Wait for Table Lock"

12.1.0.2
- - EXPDP slow showing base object lookup during datapump export causes full table scan per object
- - DATAPUMP EXPORT SLOW USING CONTENT=METADATA_ONLY
- Unpublished Bug 17662403 - DATA PUMP EXPORT: SLOW I/O PERFORMANCE WRITING TO NFS DISKS
- - EXPDP HANG IN METADA_ONLY ON A PARTITION TABLE WITH AROUND 40000 SUBPARTITIONS
- - 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
 - - 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
 - - 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
 - - 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
 - - Import Data Pump with REMAP_SCHEMA and REMAP_TABLESPACE is slow
 - - Import Data Pump runs out of memory (ORA-04030) and can be very slow on certain tables 
 - -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  
- - (affects earlier versions as well) Impdp workeer process spinning on MERGE statement

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

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

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

11.2.0.3
- - IMPORTING SMALL SECUREFILE LOBS USING DATA PUMP IS SLOW
- - Import slow on create partitioned index
- - TTS IMPDP SEEMS TO HANG AND CONSUME 100% CPU
- - IMPDP: EXTREMELY SLOW IMPORT FOR A PARTITIONED TABLE
- DATAPUMP SLOW FOR PARTITIONED TABLE
- - EXPDP of partitioned table can be slow
注意：expdp的bug 14192178的fix對一些impdp/import以及一些DBMS_METADA他的查詢也有幫助

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

12.1.0.1
- - 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 及更高版本；對於某些平臺, 提供了針對 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 及更高版本； 提供了可用於 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
    - 缺陷：  "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 及更高版本；對於某些平臺， 提供了針對 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 時間值非常高
    - 備註：針對此缺陷的修正只能作為 “Wrong results with ROWNUM and bind peeking”
    的修正予以提供。
    .
  4. Bug 5071931 - Import Data Pump with REMAP_SCHEMA and REMAP_TABLESPACE is slow
    - 缺陷： “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 及更高版本； 提供了適用於 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 5929373（不是公開的 bug）
    .
  6. Bug 5292551 - Import Data Pump runs out of memory (ORA-04030) and can be very slow on certain tables
    - 缺陷： “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 及更高版本；對於某些平臺， 提供了針對 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
    - 缺陷： “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 及更高版本； 提供了適用於 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 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
    - 缺陷： “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 及更高版本；對於某些平臺， 提供了針對 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
    - 缺陷： “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 及更高版本，已包含 的修正（見上文）
    - 打過補丁的檔案：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 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 及更高版本，已包含 的修正（見上文）
    - 打過補丁的檔案：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）、 和 。
  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
    - 缺陷： “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
    - 缺陷： - 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
    - 缺陷： - 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, 中包含了以下修復:

參考

NOTE:1290574.1 - Datapump Performance Issue With Content=Metadata_only
- DATAPUMP IMPORT WITH REMAP TABLESPACE, AND SCHEMA IS VERY SLOW

- 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
- 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
- IMPDP WITH REMAP_SCHEMA AND REMAP_TABLESPACE HANGS AT TABLE STATISTICS
- TRANSPORTABLE TABLESPACE IMPORT SPINS USING CPU
- ORA-4030 USING EXPDP
- DATAPUMP EXPORT SLOW WHEN CURSOR_SHARING != EXACT

- DATAPUMP VIEW KU$_NTABLE_DATA_VIEW CAUSES POOR PLAN / SLOW EXPDP
- 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

- VERY EXPENSIVE SQL STATEMENT DURING DATAPUMP IMPORT WITH MANY SUBPARTITIONS
- EXPDP HANGING MORE THAN 5 HOURS
NOTE:277905.1 - Export/Import DataPump Parameter TABLES - How to Export and Import Tables Residing in Different Schemas
- EXPDP SLOW WITH PROCESSING FUNCTIONAL_AND_BITMAP/INDEX
- OCSSD.BIN CONSUMING 6 TIMES MORE CPU IF EXCESSIVE DATAPUMP IS RUNNING ON NODE
- 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
- POOR EXPDP PERFORMANCE WHEN DB COMPATIBLE=10.2.0.3 OR 10.2.0.4

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



- DATAPUMP EXPORT IS EXTREMELY SLOW WHEN EXTRACTING SCHEMA
- DATAPUMP RUNS VERY SLOW OVER NETWORK FOR TABLES WITH CLOBS
- SELECT WITH ROWNUM=1 PERFORMANCE IS TOO LATE USING CURSOR_SHARING=SIMILAR
- NON-CORRELATED SUBQUERY RETURNS WRONG RESULTS, LIKE A CARTESIAN JOIN
- CONSISTENT EXPORT DATA PUMP JOB HAS SLOWER PERFORMANCE
- ER: CTAS WITH LOB ACCESS ACROSS DATABASE LINK IS SLOW
NOTE:286496.1 - Export/Import DataPump Parameter TRACE - How to Diagnose Oracle Data Pump
- EXPDP TAKES MORE TIME

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31393455/viewspace-2129445/，如需轉載，請註明出處，否則將追究法律責任。

相關文章