Printable View
Hi,
My two cents:
1) Add DB writer processes (parameter DB_WRITER_PROCESSES, requires bounce)
2) Increase SORT_AREA_SIZE in order to reduce Temporary (disk,hence slower) usage when index creation takes place.
and DIRECT=y is only valid for export, not for import (unless it's undocumented)
nolog=y?
wtf LOL
Yeah, that too Pando... NOLOG[FILE] is for datapump.
Are you serious? are you seriously suggesting to alter SGA, add DBWR and recycle the instance just to process an import?Quote:
Originally Posted by OracleDisected
If some of my guys comes to my desk with such an idea I would certainly hit him/her in the head with a frying pan but don't worry, I don't know you and I'm a very polite person so you have a free pass :rolleyes:
Sure, have you tried to build a 30Gb index with a 64K SORT_AREA_SIZE? it takes days... specially when storage is internal disks.
About the DBWR, well ... it works for us and takes account of queueing theory...
Regarding the bounce issue, I must say we use this approach for test and development environments ... and I know and share the principle of not-bounce the DB unless you strictly need it, but also I've realized it's a pre-Oracle 8i precept or taboo, back those days a database may not return from a shutdown and anybody in that situation surely sweated blood
In case that 'no-frying-pan' courtesy is a one day offer, I'll be prepared with butter, hotcakes and honey.:D
I'm surprised that no one mentioned transportable tablespaces. If this is something that you want to do on a regular basis, than transportable tablespaces could work. You might also consider replication, or read only standby database, depending on what your need is.
The main reason why imports take longer than exports is that imports generate redo, and export do not. There is also the business of creating indexes and foreign keys. With a normal import there will always be some sort of redo.