概述

在導出導入過程中，偶爾會遇到一些性能問題，可以會因主機資源，數據庫版本，PSU版本，datapump本身bug等原因導致。

這里首先可根據需求判斷是在哪個環節出問題，導出/導入元數據還是數據時出現性能問題;是否是導出/導入特定對象遇到性能問題?

[[274495]]

對于這些問題，MOS上提供了如下3種診斷方法(只演示第三種)：

方法一

在expdp/imdp命令中添加參數METRICS=Y TRACE=480300 (或者 480301 捕獲SQL trace) 并重新運行expdp/impdp

方法二

對DataPump Master (DM) 和 Worker (DW)進程啟用level 12的10046 trace

-- 版本>= 11g and < 12c  
SQL> alter system set events 'sql_trace {process : pname = dw | pname = dm} level=12';  
-- 版本= 12c  
SQL> alter system set events 'sql_trace {process: pname = dw | process: pname = dm} level=12'; 
然后用參數METRICS = Y加入命令行啟動expdp/impdp 

方法三：(推薦)

1、查看運行的DataPump 導出進程

connect / as sysdba  
set lines 350 pages 400 numwidth 7  
col program for a38  
col username for a10  
col spid for a7  
select to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') "DATE", 
 s.program, 
 s.sid, 
 s.status, 
 s.username, 
 d.job_name, 
 p.spid, 
 s.serial#, 
 p.pid 
 from v$session s, v$process p, dba_datapump_sessions d 
 where p.addr = s.paddr 
 and s.saddr = d.saddr 
 and (UPPER(s.program) LIKE '%DM0%' or UPPER(s.program) LIKE '%DW0%'); 

2、跟蹤已經開始運行的DataPump 導出進程

--確認Data Pump Worker SID 和 SERIAL#（例如. 對于 DM 和DW 進程）， 以level 12跟蹤 Master/Worker 進程 (bind和wait信息)： 
SQL> exec sys.dbms_system.set_ev (SID, SERIAL#, 10046, 12, ''); 

說明：

DM00是Data Pump Master Process 
The Data Pump master (control) process is started during job creation and coordinates all tasks performed by the Data Pump job. It handles all client interactions and communication, establishes all job contexts, and coordinates all worker process activities on behalf of the job. 
數據泵主（控制）過程在作業創建期間啟動，并協調數據泵作業執行的所有任務。 它處理所有客戶端交互和通信，建立所有作業上下文，并代表作業協調所有工作進程活動。 
DW00是Data Pump Worker Process 
The Data Pump worker process is responsible for performing tasks that are assigned by the Data Pump master process, such as the loading and unloading of metadata and data. 
Data Pump工作進程負責執行由Data Pump主進程分配的任務，例如元數據和數據的加載和卸載。 

3、結束跟蹤

等待一段時間 (至少1 小時) 以捕獲足夠的信息。

--結束跟蹤 
SQL> exec sys.dbms_system.set_ev (SID, SERIAL#, 10046, 0, ''); 

對于所有方法，DataPump Master 和Worker trace文件都被寫到BACKGROUND_DUMP_DEST 或者 /trace。

4、捕獲trace文件

SQL> show parameter BACKGROUND_DUMP_DEST; 
SQL> select * from v$diag_info WHERE name='Default Trace File'; 

以上為MOS提供的診斷方法，可靈活的使用，查詢出DataPump進程的SID后可以查詢是否有會話阻塞，異常等待事件是什么?

比如由于“StreamsAQ: enqueue blocked on low memory”等待事件導致expdp / impdp命令出現嚴重性能問題，是因為Bug 27634991引起的(在版本19.1及更高版本中修復了)。