Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: SharePlex info

Re: SharePlex info

From: Yechiel Adar <>
Date: Mon, 25 Aug 2003 00:09:41 -0800
Message-ID: <>

MessageSorry about the late reply but (if I remember correctly from my research about one year ago) Shareplex does something like log mining only on Unix systems. On NT it uses triggers just like replication.

Yechiel Adar

  You are correct in the first place. SharePlex works as you describe, it mines the log and sends only the absolute minimum to reassemble the transaction on the target. It doesn't send SQL. The target side processes take the data and rebuild a SQL statement from the DDL definitions it got from the data dictionaries of the source and target (just in case you only want a subset of the columns.) Sorry if I confused you.    

    -----Original Message-----
    From: Gorbounov,Vadim []     Sent: Thursday, August 21, 2003 5:01 PM     To: Aponte, Tony
    Subject: RE: SharePlex info


    My question was inspired by belief that SharePlex does log mining on the source DB and hence do not send unnecessary data over the network. Apparently, this is not the case. I didn't want to compare SharePlex to logical standby cause I know that logical standby definitely needs all logs transported to the target site where is does log mining.     We considering remote disaster recovery site where we want to have working data and we don't care much about "log" tables.      

    Thank you for valuable info.

      -----Original Message-----
      From: Aponte, Tony []
      Sent: Thursday, August 21, 2003 4:40 PM
      Subject: RE: SharePlex info

      Your bandwidth requirements will be the rate of changes to the actual data.  The traffic consists of the actual data and control information needed to reassemble the transaction on the target.  The source database's other redo payload (i.e., index operations, rollback segment maintenance, etc.) is not used by Shareplex.  
      In our environment of dual Sun 6800's, 10 CPU's each, we observe less that 1% CPU consumption on the source and target sides combined.  It varies according to the DML load on the source but not by much.  We've never had a problem with it consuming a noticeable amount.
      I have a question on the comparison between a physical standby and Shareplex replication.  Isn't 9i's logical standby feature better suited for the comparison to Shareplex?  I'm assuming that you are considering offloading some processing to another host since you are looking to replicate about 50% of the tables in the source database.
      Tony Aponte
        -----Original Message-----
        From: Gorbounov,Vadim []
        Sent: Thursday, August 21, 2003 1:49 PM
        To: Multiple recipients of list ORACLE-L
        Subject: SharePlex info

        Hi All, 
        I'm trying to find some technical details about SharePlex, that is:

- How much network bandwidth I'd expect to replicate from database, generating 1-5 MB/sec redo. Does SharePlex send SQL text over the network or data in some internal (hopefully compressed) format
- How much CPU on the source DB server side would it cost - just a ball park - very little- little - or a lot
- Of two options, using 9.2 physical async standby db and clone whole database vs replicate 50% (enough from business requirements) of tables using SharePlex, which one sounds preferrable keeping in mind minimizing CPU burden on the source database.
Any opinion or pointer to any benchmark is highly appreciated. Thanks a lot Vadim
Please see the official ORACLE-L FAQ:
Author: Yechiel Adar

Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message
to: (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).
Received on Mon Aug 25 2003 - 03:09:41 CDT

Original text of this message