Re: DB replication thru redo logs

From: Chuck Hamilton <chuckh_at_dvol.com>
Date: 1996/04/19
Message-ID: <3177898c.945533_at_news2.ios.com>#1/1


utrankas_at_coned.com (Sameer Utrankar) wrote:

>chuckh_at_dvol.com (Chuck Hamilton) wrote:
>
>>mainline_at_cloud9.net (Jeff Gironda) wrote:
 

>>>Does anyone know if its possible to perform periodic replication of an
>>>Oracle DB by "recovering" archived redo logs of DB #1 against DB #2 ?
 

>>I wouldn't try it. Mixing any of the database files from different
>>instances is inviting disaster. Why not just use the more conventional
>>replication options?
 

>>Even if you could do what you're asking, you'd only be able to
>>"replicate" with the database down. The conventional methods let you
>>do it with the database up.
>>xhole with anyone braver than yourself!
>
>Chuck,
>
>The reason such a thing is done is usually for a stand-by database.
>Live database is open and used by users and the other stand-by
>database is mounted but not open and keeps on applying logs from live
>db. In case of a failure on live db, as soon as you are done with
>applying last log on stand-by, you can swicth to stand-by database and
>you are back in business.
>
>So the purpose is different. This is not the purpose of
>replication/snapshots.
>
>------------------------------------
>Utrankas_at_coned.com (Sameer Utrankar)
>

This is interesting stuff.

Does the standby database have to use the same DB_NAME as the live database? I thought I remembered reading somewhere that all of a databases files (including redo logs) had the DB_NAME embedded in a header of some sort. The purpose being to prevent an instance from opening files associated with another DB.

Wouldn't this also require you to be running the live DB in archive log mode, and if so, how would the stand-by DB know when another log file needs to be applied (assuming it's supposed to happen as they become available)?

--
Chuck Hamilton
chuckh_at_dvol.com

Never share a foxhole with anyone braver than yourself!
Received on Fri Apr 19 1996 - 00:00:00 CEST

Original text of this message