Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Cloning DB to different UNIX platform

Re: Cloning DB to different UNIX platform

From: Anton Buijs <aammbuijs_at_xs4all.nl>
Date: Sun, 18 Aug 2002 21:41:45 +0200
Message-ID: <ajot6c$r85$1@news1.xs4all.nl>


I don't agree on that one.
Create the new db on Linux with alll the tablespaces that exist on the old db.
It's very likely you need more space in the new db than in the old one, so it might be required to create larger datafiles as in the old db. This is because every row is an insert so less rows may go in one block. In the old db updates may have used remaining free space (pct_free storage parameter).

A full export will create all users and create everything in the same tablespace as where it came from. When the tablespace does not exist, the users default tablespace is choosen.
Just remember that objects of SYS are not part of the export (including grants given on SYS objects).
There are more users that are not exported, even in a full export: ORDSYS, MDSYS, CTXSYS and ORDPLUGINS. See 8i Utilities Guide, Chapter 1 - Export, paragraph Export Modes.
Ok, I know lots of things can go wrong but as said: export/import is the only way to port a db to another platform.

Rick Denoire <100.17706_at_germanynet.de> schreef in berichtnieuws 61rvluopmo1hnervl0sv5e1fsdjkk1cvbq_at_4ax.com...
| Pete Sharman <peter.sharman_at_oracle.com> wrote:
|
|
| >No, this won't work. Don't bother trying.
|
| OK, thanks for the clear answer.
|
| >>
| >>Of course, I also could go through export/import, but this is not
| >>adequate to "copy" a complete DB, and it is prone to errors.
| >
| >This is the easiest way to move from one platform to another. I don't
know why
| >you say it's not adequate and is prone to errors, though. It's the way
that
| >we've used to move databases from one platform to another for years. Can
you
| >clarify what problems you see here?
|
| The full export can only be done as SYS. Importing such a dump file in
| one step would render everything in the SYSTEM Tablespace - bad. Doing
| import one schema at a time would avoid this problem, but requires
| more work, since users, profiles, privileges and roles should be
| created beforehand - prone to errors.
|
| Even doing the export with the appropriate option, statistics must be
| generated in an additional step after the import. Besides,
| export/import gives you at times some headaches with character sets,
| index names, constraints, triggers...
|
| Well, it CAN be done, but, as I said, prone to errors.
|
| Bye
| Rick
|
Received on Sun Aug 18 2002 - 14:41:45 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US