Re: IMPORT - how many passes?

Brian Peasland wrote:
>
> > 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.

Brian,

I appreciate your patience and help. Let me try to understand what you're saying -

Are you saying that I can create an Oracle 9.2 database, drop all the users except for sys and system, and then simply run import with full=y using a dmp file that's a full export from 8.1.6?

This sounds too easy.

For one, the 9.2 database is created with a locally managed system tablespace, which means that dictionary managed tablespaces are verboten. I've looked at the output of a show=y full=y import and it tries (and fails) to create all the tablespaces as dictionary managed.

Can I just precreate the tablespaces? Or is there more to it than that?

-- 
//-Walt
// 
// The Volkl Conspiracy