RE: Oracle Advanced Replication

Quest also has excellent technical support and are quick with patches (day or 3) if you run into anything really funky.

> -----Original Message-----
> From: Nick Wagner [SMTP:Nick.Wagner_at_quest.com]
> Sent: Friday, February 15, 2002 2:09 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Oracle Advanced Replication
>
> All this talk of replication is really nice.
>
> SharePlex for Oracle, can handle master to master replication. Conflicts
> are handled via pl/sql procedures inside the database, where you can
> determine exactly what happens when there is a conflict. SharePlex
> performs really well whether it is a batch program doing massive DML
> operations, or many small OLTP type transactions. SharePlex can handle
> around 300-500 DML operations per second in most situations... more if the
> hardware and database are tuned properly.
>
> As for failover, it works VERY well, and can handle many of the datatypes
> that trigger based replication can not support. LONGs and LONG RAWs
> especially... One other thing SharePlex can replicate are sequences. If
> you have sequences that generate PK's or unique keys, then you should
> probably replicate them, otherwise after a failure, you will have to find
> out what the highest value for those sequences are for each of your
> tables, and then rebuild all the sequences. This can take a long time,
> even on a medium sized database.
>
> Just a couple of things to think over, when selecting a replication
> product.
>
> Nick
>
> -----Original Message-----
> From: Gary Weber [ <mailto:gweber_at_charlesjones.com>]
> Sent: Friday, February 15, 2002 10:14 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Oracle Advanced Replication
>
>
> Pete,
>
> I've implemented a very similar solution recently for BEA-based
> application.
> Two database servers, Multi-master replication between two databases, 1
> minute propagation interval. Works great on our hardware, which was
> designed
> for the purpose and is pretty fast. Small transactions - OLTP stuff - seem
>
> to replicate well. The same can not be said for large DML operations. So
> far, I've been unable to tune replication so that it is capable of
> propagated batch type changes for large amounts of data - the receiving
> site
> seems to be converting the DML based on internal algorithm, which throws
> my
> indexing approach out of the window. Oracle Support has been of no help,
> other then suggesting different indexing for failover site.
>
> Gary Weber
> Senior DBA
> Charles Jones, LLC||Superior Information Services, LLC
> 609-530-1144, ext 5529
>
> -----Original Message-----
> Sent: Thursday, February 14, 2002 5:04 PM
> To: Multiple recipients of list ORACLE-L
>
>
> 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
> pnbarne_at_regence.com
>
> __________________________________________________
> 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: regdba_at_yahoo.com
>
> 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: ListGuru_at_fatcity.com (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).
> --
> Please see the official ORACLE-L FAQ: <http://www.orafaq.com>
> --
> Author: DENNIS WILLIAMS
> INET: DWILLIAMS_at_LIFETOUCH.COM
>
> 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: ListGuru_at_fatcity.com (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).
>
> --
> Please see the official ORACLE-L FAQ: <http://www.orafaq.com>
> --
> Author: Gary Weber
> INET: gweber_at_charlesjones.com
>
> 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: ListGuru_at_fatcity.com (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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Dejam, Ruth
  INET: Ruth.Dejam_at_voicestream.com

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: ListGuru_at_fatcity.com (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).