I suggest you take a peek at the waits for the Shareplex process on the source system. We found that the sp_ordr processes query the source tables via the rowid mined out of the redo stream. Sp_ocap also issues queries as well as perform DML on the Shareplex rowid map table.
I don't see how the single-row commits would have an impact on the replication. Shareplex doesn't wait for the source's commit before sending the update to the target so that activity remains the same. Upon encountering a commit in the redo stream, it then sends a message to the target so that it also does a commit. We do approximately 40 commits per second consisting of multiple DML operations and we don't any latency (when everything is working correctly.)
HTH
Tony Aponte
-----Original Message-----
From: Ji, Richard [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 30, 2002 1:09 PM
To: Multiple recipients of list ORACLE-L
Subject: urgent help: replication, shareplex
Hi All,
I needed some help here involving shareplex.
We run two databases (an OLTP type, and a repository type) on the same E10K
domain
which has 8 CPUs and 8GB of RAM, using Hatachi SAN (RAID 5). Shareplex is
being used
to replicate a table from the OLTP type to the repository. The current
volume we are getting
is about 40 inserts per second to the OLTP. And at this rate shareplex is
lagging behind
doing the replication, for 24 hours now. And I see the shareplex process
running at 10%
while all Oracle processes are below 1% of the CPU.
The situation is complicated, because it involves a hosting company. For
instance, I would
like to run the two databases on two separate domains but they chose not to.
So they
are blaming our application for doing commit on every insert being the
problem. I agree that
(and I will make the change) to commit every 1000 inserts or so. However, I
don't believe
that's the root of the problem. From what I understand, shareplex is log
based replication
and should not be as resource instensive. And 40 per/second isn't a huge
volume per se
and I am sure shareplex can handle a lot more than that.
So any suggestions, feedbacks are welcome.
Thanks
Richard
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Ji, Richard
INET: [EMAIL PROTECTED]
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: [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).
