Re: Export Tablespaces

"FlameDance" <FlameDance_at_gmx.de> wrote in message news:bq2ebr$475$07$1_at_news.t-online.com...
> Niall Litchfield wrote:
>
> > import will import wherever you tell it to. The only way that you could
> > overwrite production would be if the import script specified the
production
> > database as its destination. imp user/pass_at_testdb .......
>
> Not true if I understood the ORACLE documentation right:
>
http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76955/ch02.htm
> Look for DESTROY=Y

[Quoted] True. I'd missed that you were setting that parameter. Why you would set the parameter is beyond me though.

> >>Another problem is that there is a huge table in the database that uses
> >>1.7GB and that the Datafiles are only 2GB big. If the table get's
> >>fragmented over 2 datafiles, there's trouble ahead, I've been told (I
> >>haven't verified that yet).
> >
> > if the table is spread over 2 datafiles then.... nothing much will
happen.
> > What will happen however if you export with compress=y and the table is
> > larger than any single datafile is that there will be nowhere that the
table
> > can be created and import will fail. You should be using compress=n.
>
> Problem with commpress=n: If the MAX_EXTENDS are used during import you
> run into the same problem, they tell me. (I still need to verify that.)

I'd be setting max extents unlimited on all my objects and monitoring object growth. (or precreating the object with better extent sizes/in an appropriately sized locally manged tablespace). The point is that if all [Quoted] [Quoted] datafiles are 2gb and the table is larger than 2gb the create table statement in the import *will* fail. Actually if the table is 1.7gb and [Quoted] isn't in a tablespace on its own and isn't the first object imported the [Quoted] import is already likely to fail for lack of 1.7gb contiguous space to create the initial extent.

>
> > Not withstanding my suggestions above your key problem is this one
> > ORA-01034: ORACLE not available. You can check out the message at
> > tahiti.oracle.com but I'll give you this one for free. Your database
isn't
> > started.
>
> That would be an easy solution. ;-) It is started. Else
> exp system/password_at_instance file=mydump full=y
> wouldn't work either, would it?
>
> Or am I trying to access the wrong database?!?

[Quoted] I'd expect the scripts to actually look like

exp system/manager_at_prod ....
imp system/manager_at_test ...

i.e the export is from one database (which is up) and the import is to a second database (which isn't).

Niall Received on Wed Nov 26 2003 - 16:17:45 CET