AFAIK, RMAN has a duplicate command, which will initiate a backup, copy the
concerned datafiles onto the target host, and then perform an incomplete
recovery using the archived logs. This will also generate a unique DBID for
the new cloned database.  I have never used this. But am curious to know
now from someone from the list who's tried this, about the time taken,
compared to the cloning technique.

If you dont use the duplicate command, another way to work around the DBID
issue would be to create a new catalog under a different schema, and
register the cloned database there.

Raj



DENNIS WILLIAMS <[EMAIL PROTECTED]>@fatcity.com on 01/09/2002
04:45:31 PM

Please respond to [EMAIL PROTECTED]



Sent by:  [EMAIL PROTECTED]


To:   Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:


Oops, my bad. I meant to say that exp/imp time is nearly linear and cloning
is constant regardless of the database size.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]


-----Original Message-----
Sent: Wednesday, January 09, 2002 3:02 PM
To: Multiple recipients of list ORACLE-L


>From my point of view, exp/imp time is linear with the size of the database
and cloning is nearly linear except for the time to copy the files. For a
small database, I could do exp/imp much faster. I gave up creating test
databases using exp/imp on our largest production database when it grew
past
50-gig. That was when I learned how to clone it.
     I noticed that RMAN doesn't like you to clone your databases,
because it identifies databases by the DBID and that remains unchanged when
you clone the database. However, I notice RMAN has a feature to duplicate a
database and it does change the DBID then. I'm looking forward to learning
this technique. If anyone has found a pitfall with duplicate, please let me
know.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]


-----Original Message-----
Sent: Wednesday, January 09, 2002 10:45 AM
To: Multiple recipients of list ORACLE-L


With all my respect, this is not always the case
Best regards,
Serge

 -----Original Message-----
Sent:     Wednesday, January 09, 2002 10:15 AM
To:  Multiple recipients of list ORACLE-L

easier perhaps only if you have the exact same disk layouts and space
available.

and certainly MUCH more time to create -- an import takes anywhere from
2-4 times as long as the export did.

--- "Babich , Sergey" <[EMAIL PROTECTED]> wrote:
> Hi, Beatriz,
> If you want to create an identical copy of your production (that's my
> understanding), it is a lot easier to export it (FULL=Y) and then
> import the
> dump file into your new database. Let me know if you need more info.
> Regards,
> Sergey Babich, Oracle DBA
>
>  -----Original Message-----
> Sent:   Wednesday, January 09, 2002 4:50 AM
> To:     Multiple recipients of list ORACLE-L
> Subject:     Clone a database
>
> Hello list,
> I new to clone a database for changing between test to production.
> The new database is going to be in a different host.
> I have the copy obtained through the enterprise manager (I suppose
> it´s
> a cold backup).
> Which are the steps I should follow?
> A lot of thanks
>
> --


--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to