Re: Tablespaces and Export/Import

Hi Steve,

I don't think that Import is smart enough to figure out how to best distribute data and indexes across a RAID 5 setup. While I suspect there is a better way to do this the following worked for me.

What you can do is an Import with an indexfile specified. Import will then generate the file with the statements needed to create TABLES and CLUSTERS as comments along with the CREATE INDEX statements. You can then edit this file in order to specify the tablespaces for each table and index. (While you are at it you might as well set up the storage clauses to minimize the number of extents.)

You would then drop your existing tables and clusters and recreate them. Now run Import with the IGNORE option set so that Import will use your database definition.

Regards

Jerry   

Steve Sochacki wrote:
>
> I have a database on one physical server that has two drives, C: and D:. I
> have different tablespaces distributed across these drives. I did a full
> database export and went to import it on another server (which is RAID)
> with 5 drives and the same tablespaces spread across all 5. When the
> import runs, I get error mesages stating it can't create some directories,
> loads some of the tablepsaces correctly but most of the tables end up in
> the USER tablespace. The whole database is imported and works correctly
> but I lost the efficiency of having the indexes and data on separate
> drives. Is the import smart enough to look for the physical drives (C & D)
> and ignore the tablespaces on the other drives? Is there a better way to
> move all the database objects (stored procedures, tables, synonyms.....)
> than an export/import? Any help would be appreciated.
 

-- 
Jerry Gitomer               Since I know how to spell DBA I is one!
jgitomer_at_ictgroup.com
jgitomer_at_p3.net             Opinions are mine not those of ICT Group