Best way to parallelize ddl statements

Question

The short story:
We have a file of ddl statements (output from datapump metadata_only) that we want to run in parallel as fast as possible. We have paresh working pretty well, but for large files, it goes rather slow. We have been working on a procedure to read the file in as an external table with really good results.
What we have now is the external table with some additional columns that identify the ddl (owner, object_name, statement type, an order id based on statement type, a unique statement id). The idea is that we want to do all the Primary Keys first, then normal indexes, followed by foreign keys and index/table stats. Right now, I grab the next statement and mark all statements for that object_name so that no other worker processes can work on that object (reduces contention). Unfortunately, we have introduced contention on the external table (doing a select .. for update). I can think of a couple ideas to try, but wondering if any experts out there had a slick way of accomplishing this.
Feel free to ask questions. I do not think it matters, but we are working with an export from 10.2.0.2, import into 10.2.0.3.
Here is a snippet of the current code:
   -- c2 Fetches the next sql statement to be worked on. To reduce contention,
   -- we avoid working on objects that are currently INPROGRESS. The objects
   -- are also ordered such that we work on Primary keys first, then normal indexes,
   -- with foreign keys and statistics last.
   -- The "FOR UPDATE" will keep the records locked until the transaction is committed,
   -- thereby guaranteeing that we are only working on one object at a time.
   CURSOR c2 is
    SELECT p1.STMNT_ID, p1.object_name
      FROM ORACLE.PARESH_SQL_STMNT p1
      WHERE p1.STATUS ='READY'
       and p1.ORDER_PREF > 0
       -- and p1.object_type is not null
       and p1.STMNT_ID||p1.object_name = (
         SELECT max(STMNT_ID||object_name) keep (dense_rank first order by order_pref, stmnt_id)
           FROM ORACLE.PARESH_SQL_STMNT
           WHERE STATUS ='READY'
            and ORDER_PREF > 0
            -- and object_type is not null
    for update of p1.object_name;
BEGIN
  i_status:='';
  open c2;
  -- fetch only one row (highest order_pref)
  fetch c2 into l_stmnt_id, l_object_name;
  -- Set the status INPROGRESS so no other statements for this object are run
  update oracle.paresh_sql_stmnt
  set status='INPROGRESS'
  where object_name=l_object_name
  and status='READY';
  close c2;
  commit;

Answer 1

I would look at an o/s based solution and not PL/SQL (but SQL*Plus).
I would make it generic as the basic idea is to give a process a table-to-go and have it do the end-to-end steps for you.. and then run multiple of these in parallel.
The process can be a shell script (Linux/bash - sorry, I am very biased ;-) ). It uses the data dictionary to determine the indexes, constraints and triggers and what not that needs to be DDL'ed. It runs DBMS_METADATA via a SQL*Plus script to create the DDLs.
It only applies the create DDL to the destination. Next it creates a FIFO pipe. It starts SQL*Loader (parallel/direct/whatever options being fancied) on this pipe as a background process.
With SQL*Loader hungrily waiting for data, the process fires up SQL*Plus again, set array size large, etc - and run a SELECT on the source table. It does not use SQL*Plus' spool feature. It has SQL*Plus writing the data it is fetching direct to STDOUT.
However, when the process started SQL*Plus, it redirected STDOUT to the FIFO pipe.
A block is written by SQL*Plus into the pipe. That same block is then read by SQL*Loader and loaded into the destination database.
Reading and writing essentially are thus basically done in parallel - and not serial. Once the SQL*Plus completed unloading the data into the pipe, the rest of the DDLs are applied - indexes created, etc. (constraints created as disabled of course - these will need to be enabled all over the destination database after all the load processes have completed)
And as mentioned, I will have multiple of the scripts running, one per table to process.
Many years ago, I did exactly this. Only a tad more complex. Went something like this. Process unloads data into a pipe. Compression process read that pipe and write compress/zipped data into a "compression" pipe. FTP process reads that pipe, sends the compressed data across the network, where the FTP server writes in into yet another pipe. There a decompression process reads the ftp pipe, unzips the data, and write the decompressed data into a "decompression" pipe. Where SQL*Loader does the rest - reading the now unzipped data and chucking it into the database.
It work pretty well. And fast. Faster than any commercial ELT tool that 3rd party vendors tried to sell me to "do the job". :-)