Re: Export Tablespaces
Date: Wed, 26 Nov 2003 15:46:24 +0100
Message-ID: <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] >>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.)
> 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.
[Quoted] 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?!?
Thanks for your input, valuable pointers!
Stephan Received on Wed Nov 26 2003 - 15:46:24 CET