Hello Peter

We implemented Advance Replication as part of dealing room.
We defined master to master real-time replication.
Synchronous, 2 phase commit, from the primary to the backup DB as each deal
is a
lot of money and standby database will not reflect updates since the last
log file was archived.
Since we need master to master we defined the replication from the backup DB
to the primary as asynchronous even though no body is using the backup DB.

I think that the cases are similar.

Points to take care off:

1) Prepare a script to drop the replication on each machine if the other
machine fails.
    Lets say that you got a CPU fault on the primary and you switch to the
backup.
    In this case you might get off with the asynchronous replication as
updates will
    accumulate in the backup machine until the CPU is replaced. When the
primary
    will come up the replication will update the primary DB with all the
changes.
    Now, if the disk drive fails on the primary you will probably have to
rebuild the
    DB from scratch (or from export from the backup). In this case there is
no point
    to accumulate updates in the backup machine.
   Also, if the backup machine fails you do not want the updates to the
primary to
    fail. In this case you drop replication and go on working.

2) Ensure that the log files, rollback segments, datafiles (size) and all
init ora are the
    same on both machines. You do not want to swap to the backup only to
find that
    the parameters are ok for one connection (replication) but fails when
working as
    a primary DB.

3) Hey, what happens if the air condition stopped working and ALL the
machines heats
    up and stopped working. Both machine will fail.
   Worse if that room gets on fire you are out of luck.
   Move the backup machine at least a couple of rooms away.

4) Use stand by database in another building so in case of a serious problem
(11 seqptember)
    you will not lose all your data, only the data since the last archive.

5) Test, Test, Test again all failure scenarios, and test again each month,
quarter or whatever.


Yechiel Adar, Mehish Computer Services
[EMAIL PROTECTED]

> -----Original Message-----
> From: Peter Barnett [SMTP:[EMAIL PROTECTED]]
> Sent: Fri, February 15, 2002 1:04 AM
> To:   Multiple recipients of list ORACLE-L
> Subject:      Oracle Advanced Replication
> 
> We are looking at Advanced Replication as a fail over
> option for a web site.  Straight forward installation,
> both boxes on the same subnet on their own dmz. The
> servers will be located on the same rack in the
> computer room. Very few tables storing data from an
> application that is tracking click through data.
> 
> Does anyone see any flaws with the basic plan?  Any
> hidden 'features' that we may run into?
> 
> Thanks
> 
> 
> 
> =====
> Pete Barnett
> Lead Database Administrator
> The Regence Group
> [EMAIL PROTECTED]
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE Valentine eCards with Yahoo! Greetings!
> http://greetings.yahoo.com
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> -- 
> Author: Peter Barnett
>   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).
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  This e-mail was scanned by the eSafe Mail Gateway 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: =?iso-8859-8?Q?=E0=E3=F8_=E9=E7=E9=E0=EC?=
  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