August 10th, 2010 by TheBonsai
Recently I hacked a on-demand-export for a user. After his (small) data loading, an export is triggered to have his data in a backupable and tranmsportable file. The total amount of all tables was about 7MB only.
The export routines were done with datapump export. I watched a manual run and…
- datapump started and connected to a database server process: 3 seconds
- datapump estimated and analyzed the data to export: 36 minutes
- datapump exported the relevant tables: 4 seconds
Do you see what I see? Yes? Right, datapump played with itself. Over 36 minutes of runtime, where 99% of the time not one bit of data was moved. Reproducable 100%. A datapump TRACE=480300 generated trace set revealed a huge delay in the worker process when calling DBMS_METADATA.FETCH_XML_CLOB (exactly my 36 minutes).
The solution was a patch for bug
- 7710931: DATAPUMP EXPORT IS EXTREMELY SLOW WHEN EXTRACTING SCHEMA
Now datapump does what it’s designed for: Pumping data without playing with itself!
This entry was posted on Tuesday, August 10th, 2010 at 05:53 and is filed under english, Oracle. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.