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: Your views on Quest - Shareplex

Re: Your views on Quest - Shareplex

From: Oriole account <sfaroult_at_oriole.com>
Date: Tue, 29 May 2001 15:58:02 -0700
Message-ID: <F001.00312D37.20010529154026@fatcity.com>

Just something. First of all, I have never seen Shareplex in operation so this is my gut feeling, chiefly based on how I would have coded it. Most of the arguments against Shareplex has been about their using undocumented features - which I admit may be a concern but wouldn't keep me awake at night. The main difference I see between log-based replication and traditional, trigger-based replication is that with trigger-based replication the log is part of the transaction - in other words, you only see committed changes. With the logs, the picture is different, because you may have uncommitted as well as committed changes in them - you are a bit closer to what people do. Either they wait for transactions to have committed before forwarding them - which I think unlikely because at the first massive update they can go BANG, if what happens to rollback segments from time to time is anything to go by, or, and that's how I would have done it, they forward changes as they come, forwarding commits and rollbacks as well. And in my view, the problem is not on the source, but on the target side. I presume that one, or in the best of case, a limited number of sessions are replaying the original changes; if you have many concurrent sessions on the source, you have a kind of funnelling. Because of Oracle read consistency, the original transactions, if they are working on the same data, may not see exactly the same thing at the same moment. Oracle locks take care of that, but if you multiplex everything I do not see how to keep a consistent picture at the other end, even when strictly respecting chronology. A secondary, and relatively minor compared to the first one, concern would be what happens if a replication process crashes (I know, it's not supposed to happen) and if this is not spotted immediately? I presume that ARCHIVELOG is mandatory, but anyway you must probably have tight operations. It must be perfect for some operations, but I would feel uncomfortable using it on the case-study OLTP database.

My 2 cents.

Stéphane Faroult  

"Rao, Maheswara" wrote:
>
> List,
>
> My company is considering Quest - Shareplex.
>
> We are considering to use this in our dataware house. Basically, this will
> pull all the transactions from OLTP database and populate staging area in
> the dataware house.
>
> Could you please give your experiences and the pros and cons of this
> Shareplex product.
>
> Thanks,
>
> Rao
> --

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Oriole account
  INET: sfaroult_at_oriole.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).
Received on Tue May 29 2001 - 17:58:02 CDT

Original text of this message

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