There MAY be other considerations when refreshing prod into test with full.
Do you have snapshots in your prod database? Do you want them to use the
same source in test as they're using in prod? Do you have any code in prod
that updates/inserts/deletes anything in another database across a link? If
so will you want that same code to fire in test? Do you have objects in
test that you don't want to get rid of i.e. objects for the next release?
How will you preserve those objects? And how would you like to handle any
differences in users or roles between prod and test?
"Brian Peasland" <dba_at_remove_spam.peasland.com> wrote in message
news:3FA808A9.3E62376A_at_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 - 16:02:37 CST
