Re: IMP/EXP accross platforms: What will be missing?

Mark.Powell_at_eds.com (Mark D Powell) wrote:

>Rick, I am only going to add a couple of notes:
>1- Build your new db using locally managed uniform extent tablespaces
>for all user data tablespaces

And for the system tablaspace too, I guess.

>2- Perform the exports with compress=n so each object takes only as
>much room as it needs when recreated and initially loaded
Agree.
>3- you can use an export with full=y rows=n to capture public synonyms
>etc... that an imp with ignore=y will re-establish for you should
>something go wrong on the first import

I hope it will work that way.

>4- I would build my new db from scratch well in advance room
>permitting and precreate the owners with the necessary object grants.

I have had the problem that at import time, some specific tables would import into a wrong tablespace (it should go into the target user's default tablespace); and the import of this particular segment will fail if the schema owner at the target DB has no quota on this tablespace. Strange. It happened with tables containing records of type LONG.

>This would prevent errors due to the owners having objects of a type
>for which they do not currently have create privilege plus you can
>re-establish any grants on SYS owned objects that the imp will not
>contain and which are needed to support stored
>procedure/functions/packaged code that references v$ or dictionary
>views.

This is the best point: grants on sys objects won't come over.

And I was right. I am afraid that I forgot something. Shouldn't I set the COMPATIBLE parameter in the target DB so something based on the source DB? Remember, I am going from 8.1.7.0 to 9.2.0.4.

Thanks
Rick Denoire
>HTH -- Mark D Powell --
Received on Mon Nov 03 2003 - 17:22:34 CST