Re: Database reorg & export/import questions

The way to do it is to ensure the userid you are importing the data to have a valid default tablespace. When the data is imported, it will not find the USERS/INDEXES tablespace and default to DEFAULT and still work. As far as I remember it will use the default's tablespace space defaults (a lot of defaults)

.
SH

Jim Day wrote:

> I am running Oracle 8.0.5 on a Sun 450 running Solaris 2.6. I have 3
> instances running (dev, test, prod). Normally, I export our prod database
> every night and archive that file. I also perform full backups but the
> exports are very convenient. Then when needed I will take one of the
> exports and use that to populate the dev or test database. This has been
> working fine for the past couple of years. Recently we reorganized the prod
> database by moving many of the components to separate disks (on separate
> controllers, etc.). Another "tuning" function we performed was to separate
> the data and the indexes as previously they were in the same tablespace
> (USERS). Now I have the tablespace USERS on one set of disks and the
> tablespace INDEXES on another set. All has been well.
>
> Now, I understand that a full export is more or less a bunch of statements
> to be able to recreate the database objects (create table, etc) and a bunch
> of insert statements with the associated data....I know that's simplifying
> things a lot. So, my question: now with the way the prod database is
> organized, if I want to use one of these "new" exports to populate the dev
> or test database (both still have the data and indexes in the USERS
> tablespace) will this work? Will the import try and create its indexes in
> tablespace INDEXES (even though there is not an INDEXES tablespace) and
> therefore a) abort with an error or b) create the indexes in the "default"
> tablespace (which is USERS)?
>
> I plan to "reorganize" the other databases (dev, test) in the near future,
> but do I need to do this sooner than later to prevent possible problems?
>
> --
> Jim Day
> day_at_nettally.com
Received on Thu Jul 27 2000 - 00:00:00 CDT