Re: best case scenarios for export/import

Hi,

That doesn't sound particularly healthy to me. Depends what you're running on I guess. We have a nightly batch job which does an import on 8.1.7, rather weedy 933MHz Intel, 50Mb SGA, 4 x SCSI disk Linux box. The dump file is 4.0Gb which turns out to be about 6Gb data, 1Gb indexes. It takes 3 hours, including all the index creation, and I've not even bothered trying to tune it *at all* (ie. default import parameters) because the window available for it is about 14 hours.

One thing to take care over with indexes=n is that this is does not disable the creation of constraint indexes (ie. Primary Key, Unique). You may need to adjust the sort_area_size for these (however, I've not bothered as I still have 11 hours of spare window). When I do need to do this, I bounce the instance and set the sort_area_size instance wide - maybe somebody can suggest a better way of doing it just for the import?

I guess your next step is to monitor the import itself and look at the wait events to see if something is obviously amiss.

• Bill.

At 06:04 20/12/2002 -0800, you wrote:
>Good day, all:
>
>I'm looking for real-life best-case scenarios for running import/export . .
>. I've been playing with this for quite some time and would like to know how
>"fast" I can really expect this to go, particularly for the import.
>
>I'd be interested to hear others' experiences - how fast have you been able
>to import data? what parameters have you used? etc. . . . it's both for
>informational purposes and as a sanity check.
>
>For example: I'm now trying to import a dump file of appx 6.5 Gb - breaks
>down into 12G data and 4G indexes.
>using the following params on the first import, to just get the data (I then
>rerun with the indexfile param to get the indexes):
>recordlength=65535
>buffer=15000000 (15M)
>commit=y
>indexes=n
>constraints=n
>grants=n
>
>This will import in appx 36 hours using a single 3 Gb rollback segment
>
>What kind of experiences have you had?
>
>Thanks
>bill
>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.net
>--
>Author: Magaliff, Bill
> INET: Bill.Magaliff_at_lendware.com
>
>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>San Diego, California -- Mailing list and web hosting services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Bill Buchan
  INET: wbuchan_at_uk.intasys.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).