Re: Better method for importing?

"wayne" <no_at_email.please.com> wrote in message news:989sju$t6v_at_dispatch.concentric.net...
> > Can you rely on exp/imp for properly and cleanly "migrating" data
 from
> > one (7.3.4) database to another (8.1.7) database, or are there other
> > options?
>
> Yes you can rely on it. I have done it tons of times.
>

I have used it before, but I am looking for a "cleaner" way, if such exists...

> > A full+DBA export includes users, grants and such, but also objects
 of
> > sys and system schemas, which could lead to a rather messy import.
 If
> > not using full=y, then those things are not included (or so it
 seems).
>
> First of all, you can export with full=y, but not import with it. The
 users
> that do not own db objects (non-schema users) you should recreate
 (those are
> simple create user commands) before importing. You may need to
 pre-create
> the roles as well, but if you do, you do not need to grant the roles
 to any
> users, the import will do that. This is not so much work...

Hacking some small scripts for creating and running the necessary create user, role and such commands isn't so much work, but I'd prefer a better tool for the job. With many different applications it adds up and isn't always easy to verify either.

>
> When it comes time to import, do a full=n and use
 fromuser=(user1,user2,...)
> clause instead. Since the non-schema users are already there, they
 will be
> granted the appropriate rights.
>

When not using a full import, the procedure leaves out the non-schema stuff like tablespace, profiles, users, roles, resources, rollback, etc. definitions.

> Anyway, there are a million ways of doing this. you will be just fine
 with
> imp/exp, just do not import the system and sys schemas!
>

I'd like to leave them out, if possible. There should be a full_but_not_objects_of=(sys,system).

Maybe the Data Manager (in OEM) can be more useful?

Regards
/Fad Received on Sun Mar 11 2001 - 10:46:24 CST