Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: IMPORT - how many passes?

Re: IMPORT - how many passes?

From: Brian Peasland <dba_at_remove_spam.peasland.com>
Date: Tue, 4 Nov 2003 20:14:33 GMT
Message-ID: <3FA808A9.3E62376A@remove_spam.peasland.com>


> Well, for one, I'm moving the data from 8.1.6 to 9.2. Wouldn't a full
> import overwrite the data in the system and ctxsys tables (and some
> others)?

Hopefully, you don't have anything but the bare minimum owned by SYSTEM. As for CTXSYS, if you are using ConText, then don't you want that updated as well once you pull over all of your ConText stuff?  

> Also, wouldn't I get a boatload of errors as foreign keys fail to find
> their parent records, grant statements fail to find the referenced
> objects, views fail to find their underlying tables, etc.

This is only true if you leave the development objects there. But you are refreshing everything from production right? So why not drop all of the development objects and then import.  

> I can see a full import working if it's done just the right order, but I
> don't see how to guarantee it.

The import process guarantees this. It doesn't enable any constraints until after everything has been imported. Views don't get created until the end. So the tables are there when it gets time for views to be created. Want to see exactly the steps that import will take? Run import with SHOW=Y and LOG=some_log_file. The contents of some_log_file will show the DDL statements, in the order that import will take.

The only time you should have a problem with this is if you leave tables and constraints there. But why not drop the tables? You don't want the data that is in there anyway because you will be refreshing it from production via your dump file. In fact, you can even do the DROP USER command because the import file contains the DDL to create all the users/grants/etc. When I do refreshes from production I do exactly this. I don't want a developer leaving data that they have "logically corrupted" in the natural course of their development. The whole point of refreshing from production is to get to a point that has no corruptions like this so that you can do development on it without affecting production.

HTH,
Brian  

-- 
===================================================================

Brian Peasland
dba_at_remove_spam.peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
 the three"
Received on Tue Nov 04 2003 - 14:14:33 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US