RE: Questions re datapump import
Date: Fri, 20 Nov 2009 10:22:31 -0500
That would be consistent with the documentation, but regrettably is not in practice. Datapump only replaces tables and not the other stuff that comes with it, like packages, procedures, java, sequences. And it doesn't tell you either.
Senior Oracle DBA/NA Team Lead
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of John Dunn Sent: Friday, November 20, 2009 3:35 AM
Cc: oracle-l digest users
Subject: 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
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
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.
mwfReceived on Fri Nov 20 2009 - 09:22:31 CST