Comments on: Speeding-Up Oracle Export/Import Migration http://www.pythian.com/news/288/speeding-up-oracle-export-import-migration/ News and views from Pythian DBAs Fri, 10 Feb 2012 13:01:25 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Andrew Smith http://www.pythian.com/news/288/speeding-up-oracle-export-import-migration/#comment-27965 Andrew Smith Tue, 13 Mar 2007 20:47:43 +0000 http://www.pythian.com/blogs/288/speeding-up-oracle-exportimport-migration#comment-27965 If you could extract the biggest tables into ASCII and the load with sql loader then your total time would be less then a hour. Or even pipe to simulate cascade unload-load This doc might help: http://www.wisdomforce.com/dweb/resources/docs/UnloadLoadUsingFastReader.pdf If you could extract the biggest tables into ASCII and the load with sql loader then your total time would be less then a hour. Or even pipe to simulate cascade unload-load

This doc might help:
http://www.wisdomforce.com/dweb/resources/docs/UnloadLoadUsingFastReader.pdf

]]> By: Shakir Sadikali http://www.pythian.com/news/288/speeding-up-oracle-export-import-migration/#comment-13889 Shakir Sadikali Tue, 09 Jan 2007 14:57:32 +0000 http://www.pythian.com/blogs/288/speeding-up-oracle-exportimport-migration#comment-13889 Hi Dominic, In this type of situation, i like to do two separate upgrades. The first would be to move the DB to the new platform, and then a second to actually perform the upgrade. Changing platforms is a big step, and so is going from 8i to 9i. As such, to help isolate potential problems, it's always a good idea to let a system burn in a bit so that you can catch bugs before you get too many variables into the mix. Hi Dominic,

In this type of situation, i like to do two separate upgrades. The first would be to move the DB to the new platform, and then a second to actually perform the upgrade. Changing platforms is a big step, and so is going from 8i to 9i. As such, to help isolate potential problems, it’s always a good idea to let a system burn in a bit so that you can catch bugs before you get too many variables into the mix.

]]> By: Dominic http://www.pythian.com/news/288/speeding-up-oracle-export-import-migration/#comment-13856 Dominic Tue, 09 Jan 2007 11:21:05 +0000 http://www.pythian.com/blogs/288/speeding-up-oracle-exportimport-migration#comment-13856 Hi, You say "Now, whenever I run into a situation like this, we generally recommend a two–step process so that we can iron out bugs and be able to isolate causes". Without the time constraints mentioned above, can you detail your normally recommended two-step process? Thanks. Dominic Hi,

You say
“Now, whenever I run into a situation like this, we generally recommend a two–step process so that we can iron out bugs and be able to isolate causes”.

Without the time constraints mentioned above, can you detail your normally recommended two-step process?

Thanks.
Dominic

]]> By: sadikali http://www.pythian.com/news/288/speeding-up-oracle-export-import-migration/#comment-7006 sadikali Mon, 13 Nov 2006 15:00:05 +0000 http://www.pythian.com/blogs/288/speeding-up-oracle-exportimport-migration#comment-7006 That's true too! Unfortunately, this particular case involved everything being in 1 single schema so i completely overlooked it. Thanks for bringing it up! Shakir That’s true too! Unfortunately, this particular case involved everything being in 1 single schema so i completely overlooked it. Thanks for bringing it up!

Shakir

]]> By: Raj Jamadagni http://www.pythian.com/news/288/speeding-up-oracle-export-import-migration/#comment-6999 Raj Jamadagni Mon, 13 Nov 2006 12:39:39 +0000 http://www.pythian.com/blogs/288/speeding-up-oracle-exportimport-migration#comment-6999 You could further bring down the time for imp by doing parallel schema level imports from the same export file. I have done this in past (8i to 92 migration) with a lot of success. Of course this works best when you import data only, indexes is best left to last stage. Raj You could further bring down the time for imp by doing parallel schema level imports from the same export file. I have done this in past (8i to 92 migration) with a lot of success. Of course this works best when you import data only, indexes is best left to last stage.

Raj

]]> By: Maxim http://www.pythian.com/news/288/speeding-up-oracle-export-import-migration/#comment-6723 Maxim Sat, 11 Nov 2006 13:22:38 +0000 http://www.pythian.com/blogs/288/speeding-up-oracle-exportimport-migration#comment-6723 Sorry, misread your settings (written sort_area_size, imagined - pga_aggregate_target , it is probably to hard associated with workarea_size_policy) - need a cup coffe more ;-) Regards Sorry, misread your settings (written sort_area_size, imagined – pga_aggregate_target , it is probably to hard associated with workarea_size_policy) – need a cup coffe more ;-)

Regards

]]> By: Maxim http://www.pythian.com/news/288/speeding-up-oracle-export-import-migration/#comment-6722 Maxim Sat, 11 Nov 2006 13:18:43 +0000 http://www.pythian.com/blogs/288/speeding-up-oracle-exportimport-migration#comment-6722 Should it not be the 4) workarea_size_policy=auto ? Regards Should it not be the 4) workarea_size_policy=auto ?

Regards

]]>