Langsames Estimate bei expdp

Seit vielen Jahren benutze ich Data Pump zum Transferieren und - ich geb es zu - auch zum Sichern größerer Datenmengen. Aber erst in den letzten Wochen ist mir aufgefallen, die groß der Overhead des Estimate-Schrittes zu Beginn des Exports ist, bei dem ermittelt wird, wie groß das Datenvolumen ist, das exportiert werden soll. Besonders auffällig wird das Verhalten, wenn der Export einzelne kleine Tabellen betrifft. Für eine Test-Tabelle mit 1.000 rows und 12 KB (!!) Datenvolumen ergaben sich in meinem Test für expdp folgende Gesamtlaufzeiten:

• DB 11.1.0.7: 12 min
• DB 10.2.0.4: 4 min

Im Fall 11.1.0.7 habe ich mir die zugehörigen Prozesse während des Exports etwas genauer angeschaut und dabei folgende Beobachtungen gemacht:

• expdp.exe: geringe DBTime (v$sess_time_model); Waits fast ausschließlich für event 60 "wait for unread message on broadcast channel" (v$session_event)
• Data Pump Master: geringe DBTime (v$sess_time_model); Waits fast ausschließlich für event 60 "wait for unread message on broadcast channel" (v$session_event)
• Data Pump Worker: hohe DBTime (v$sess_time_model); sehr viele Waits für event 137 "db file sequential read" (in der Regel Index-Zugriff) (v$session_event)

Ein 10046er Trace für die worker Session (die offenbar tatsächlich die ganze Arbeit leistet) enthält vor allem zwei Queries mit höherer Laufzeit. Erwähnenswert ist dabei vielleicht auch noch, dass das worker-Trace-File in 11.1.0.7 einen Namen _dw01_.trc trägt und sich im trace-Verzeichnis des üblichen diag-Pfades findet.

SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), 
  XMLFORMAT.createFormat2('TABLE_DATA_T', '7')), 0 ,KU$.BASE_OBJ.NAME ,
  KU$.BASE_OBJ.OWNER_NAME ,'TABLE' ,to_char(KU$.BYTES_ALLOC) ,
  to_char(KU$.ET_PARALLEL) ,KU$.FGAC ,KU$.NONSCOPED_REF ,KU$.XMLSCHEMACOLS ,
  KU$.NAME ,KU$.NAME ,'TABLE_DATA' ,KU$.PART_NAME ,KU$.PARTTYPE ,KU$.PROPERTY 
  ,KU$.REFPAR_LEVEL ,KU$.SCHEMA_OBJ.OWNER_NAME ,KU$.TS_NAME ,
  KU$.SCHEMA_OBJ.NAME ,KU$.TRIGFLAG ,decode(KU$.SCHEMA_OBJ.TYPE_NUM,2, 
  decode(bitand(KU$.PROPERTY,8224),8224,'NESTED PARTITION',8192,'NESTED 
  TABLE','TABLE'),19, decode(bitand(KU$.PROPERTY,8224),8224,'NESTED 
  PARTITION','PARTITION'),20,'PARTITION','SUBPARTITION') ,
  to_char(KU$.UNLOAD_METHOD) ,KU$.XMLTYPE_FMTS 
FROM
 SYS.KU$_TABLE_DATA_VIEW KU$ WHERE NOT BITAND(KU$.BASE_OBJ.FLAGS,128)!=0 AND  
  NOT (BITAND (KU$.BASE_OBJ.FLAGS,16)=16) AND  NOT XML_OUTOFLINE='Y' AND   
  KU$.BASE_OBJ.OBJ_NUM IN (SELECT * FROM 
  TABLE(DBMS_METADATA.FETCH_OBJNUMS(100001)))
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1    751.00     752.83      39060   10309856        347           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3    751.00     752.83      39060   10309856        347           1 

--> der Zugriffsplan spottet jeder Beschreibung
 
SELECT LVL 
FROM
 SYS.KU$_REF_PAR_LEVEL_VIEW WHERE OBJ# = :B1 
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute   8452      1.24       1.38          0          0          0           0
Fetch     8452    706.21     707.06          1    8866148          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total    16905    707.46     708.44          1    8866148          0           0 

--> auch hier spare ich mit den Execution Plan 

In MOS findet man zum Verhalten und zur ersten Query mehrere Hinweise, die die Schuld an der hohen Laufzeit dem RULE-Hint geben:

• Expdp Is Slow During Estimate Step [ID 1253955.1]: caused by internal Bug 7362589; die dort vorgeschlagenen Workarounds  (expdp with parameter VERSION=10.2.0.2; Use parameter INCLUDE=TABLE:"IN('EMP')" instead of parameter TABLES) funktionieren leider nicht
• Expdp Slow for a Small Table [ID 950995.1]: empfiehlt Patch 7362589 für 11.1.0.7
• Checklist for Slow Performance of Export Data Pump (expdp) and Import DataPump (impdp) [ID 453895.1]: mit einem Überblick über diverse Performance-Probleme und ihre Ursachen.

Vermutlich wäre hier tatsächlich Patch 7362589 das Mittel der Wahl. Gelegentlich sollte ich vielleicht auch noch das Verhalten in 10.2.0.4 genauer betrachten, denn auch dort scheint der Schätzungs-Overhead beträchtlich zu sein.