Questions re datapump import

The scenerio is wholsale reversion of all objects in the schema.

I have no objection to dropping objects before importing.

I was just hopeing that there was an datapump import option simply to replace all objects, as there is with tables.  

From: "Mark W. Farnham" <mwf_at_rsiz.com>

Subject: RE: Questions re datapump import

Date: Thu, 19 Nov 2009 09:10:36 -0500

I'm a little confused by your goal. If you want to "revert" to an entire

earlier version of a schema, why do you NOT want to drop before

re-importing?

Are your developers not allowed to change schema objects? For example, might

they add a column to a table or drop an index?

Without looking in the utilities manual I frankly cannot remember whether

there is an option to replace object in their entirety (as opposed the the

options about rows mentioned earlier in the thread.)

But if you want back the prior versions of LIBRARY, TYPE, SEQUENCE, etc.,

then it seems to me it would be far easier to either drop the entire schema

or drop the desired object types with a script generated from the

dictionary. Then datapump wouldn't have to go into an error interpretation

mode.

So are you trying to essentially revert to a previous generation that you

exported or not? I would think you would have in mind two scenarios:

Wholesale reversion (in which case dropping before importing seems most

straight forward), and selective object reversion (in the event your

developer wants to undo changes to a limited set of objects without losing

progress on changes to other objects.) In that case you would probably do

well to drop the individual objects the developer(s) wanted to revert and

subsequently run import specifying those objects. I suppose if the

developers wanted to keep progress on just a few objects, then object

selective special exports, wholesale drop, wholesale reversion import,

selective drop and wholesale import of the selective import would be less

total work for the computer (but a few more steps for you, so I don't know

which would be a better scenario because I don't know the relative costs.)

But that is just the need I usually see. Your goals may be different. But

from what you've written I don't understand the value of avoiding the drop

and complicating the import.

Specifically in the case you cite below I'm pretty sure you are left with

the incumbent versions, not the ones you attempted to import.

mwf    

--

http://www.freelists.org/webpage/oracle-l Received on Fri Nov 20 2009 - 02:35:12 CST