I do not believe that you "are supposed"
to import objects from sys' (nor system's) schema.
There are probably other schema's
you are not typically supposed to import either.
This fact causes complications such as
you need to run a script in the exporting
database to write the create statements
for public synonyms, as they are owned
by Sys, as one issue I've heard about. Perhaps in your case some
triggers managed to be owned by Sys
and they also will have to be dealt with separately.
A lot of books talk about how one can
upgrade or transport a database via
export/import but they fail to go into these points. I am working on
this
very topic myself right now. There are
many issues to be dealt with in such an
operation. BTW importing sys objects
will change the sys password to the
ones in the source database, to name
one problem. Oracle would do well to
create a smart front end to import IMHO,
instead of everyone finding these things out for themselves, why not
just automate it? Presumably there exists an
occasion in which it would be appropriate to do a full import including
sys and system, since the import allows
this to be done. It would be good to
figure this out. I for one would like the
export/import experience to be a lot of
experiential (just try it and then fix stuff
and do it over and...) and a lot more logical and predicatable.
Received on Thu Jul 21 2005 - 14:10:36 CDT
