Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

RE: SharePlex info

From: Tim Onions <tim.onions_at_speechmachines.com>
Date: Mon, 25 Aug 2003 01:07:27 -0800
Message-ID: <F001.005CCF15.20030825010727@fatcity.com>


Shareplex does not use triggers on NT it uses the same underlying technology as it does on Unix "reading" the log files and shipping SQL to the target database. It uses a 3rd party tool called "Knutcracker" to allow it to some of its UNIX commands on NT.  

T¬-----Original Message-----
Sent: 25 August 2003 09:10
To: Multiple recipients of list ORACLE-L

Sorry 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
Mehish

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.  

Tony

-----Original Message-----
Sent: Thursday, August 21, 2003 5:01 PM
To: Aponte, Tony

Tony,  

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-----
Sent: Thursday, August 21, 2003 4:40 PM
To: ORACLE-L_at_fatcity.com
Cc: vadim.gorbounov_at_liberate.com

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.  

HTH
Tony Aponte    

-----Original Message-----
Sent: Thursday, August 21, 2003 1:49 PM
To: Multiple recipients of list ORACLE-L

Hi All,  

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

Any opinion or pointer to any benchmark is highly appreciated.  

Thanks a lot
Vadim

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tim Onions
  INET: tim.onions_at_speechmachines.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
Received on Mon Aug 25 2003 - 04:07:27 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US