import time consuming

[smacattack]

Can anybody help regarding quicking up an import of tables.
I am importing without the indexes but it seems to be taking forever to do.
What params can i look towards changing to quicken this procedure up.

Need major help when this machine goes live i cannot afford the downtime its taken to do this test import.
The export only took 4/5 hours. The import has taken days!

HELP?!

 

[nwardez]

Hi,

According to my poor experience, constraints are very time consuming too, when doing an import. But you can't always disabling them.

Are you re-importing into the same database ? Else, do blocks size parameters match filesystem ?

 

[evatype2]

Are you looking at the import as a method of recovery or to refresh a development environment? If your db takes 4/5 hours to export, it is a medium large database. It may be time to look at other methods of refresh/recovery. I'd take a look at RMAN. It can be used to restore a database in its own or another environment(e.g. test/development). I wouldn't throw out the export if you can continue to run it. An export is great when you need to restore a few tables. You could also look at cold backups. Check the Oracle doc on recovery. It is fairly reasonable.

 

[rcurva]

It is important to know the purpose of this backup strategy, frequency and the size of the database.

But let's assume that you really need to do this the exp/imp way.

1. Drop the references and constraints involved.
2. Increase the BUFFER
3. Make sure that the rollback segments are sufficient
4. Check also if there are other processes hogging the CPU

Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided" -- Art of War

 

[smacattack]

Much appreciated your thoughts but unfortunately the export is from a different archetecture and this is why i had to plum for the export import option.
The development box has only the import runing on it the buffer size was increased to 409600 for the import.
This exercise is critical when we go live after this the dev box and live box will be on the same archetecture and i can then do refreshes on the dev box via filesytem dumps.
I cannot afford to put the final cutover of the database to live and it takes 5 days to complete.
I must be able to speed up the import!

HELP!

god created the world in 7 days, whats happening to oracle databases!

 

[rcurva]

What do you mean by different architecture? Do you intend to put the data from the dev to prod via this import procedure (one-time)? Update by import to the dev in the future?

You can still do a copy of datafiles from dev to prod by recreating the controlfile of the prod. If your concern is the difference in the filesystems/directory of the prod with the dev.
Robbie

"The rule is, not to besiege walled cities if it can possibly be avoided" -- Art of War