RE: import table scan

I think Mark's idea of separate export/import files is a good idea in your case because you only have 20 tables to process. You could be running 5 import jobs at once (each with 4 tables in them).

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark Bole Sent: Thursday, June 23, 2005 10:55 AM
Cc: oracle-l_at_freelists.org
Subject: Re: import table scan

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


oracle-l-bounce_at_freelists.org wrote:


> 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. [...]



--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l