Export/import various tables in separate jobs run in parallel (assuming
you have more than one CPU and plenty of spindles). Not sure why you
are running a full export as sysdba anyway.
As an extension of the above, if any given table is still "too big", get
the Partitioning Option and break your tables into multiple segments,
then exp/imp those in parallel.
You didn't state, but it sounds like you have a lot of LOB storage.
There might be some tablespace storage parameters you can tinker with
specifically for LOB's, but I'm not aware that there's anything you can
do at the exp/imp level to help with them.
-- Mark Bole http://www.bincomputing.com
We have a big oracle 9.2.0.4 database, in the 2 TB size range. The database
stores aerial imagery and 99% of the storage is in 15-20 tables. Our tables
are huge. Query performance from the database is great, but importing the
export of this database takes a good deal of time, as one might expect.
I made the decision to do import/export because we don't have archive logging and I can't bring the database down long enough to copy the datafiles, and import/export is easier to test. [...]
-- //www.freelists.org/webpage/oracle-l
