Re: quest SharePlex

Nick,

Thanks for the notes.
I've often wondered how Shareplex
did its thing.

Just for kicks - have you tried writing
a collision handler for streams ?

Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )

Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )

____England______January 21/23
____USA_(CA, TX)_August

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

-----Original Message-----
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Date: 22 January 2003 18:09

>Would the same thing work if you shut down the
>Shareplex processes after the row had chained,
>and restarted them before you updated the chained
>piece ?
>-- Yes
>
>And does Shareplex guarantee that it will
>never report a 1555 error regardless of how long it
>is shut down ?
>-- No, if there are massive amounts of transactions, we can still
blow
>rollback segments, nothing will happen to the source DB instance, but
it
>will effect replication. Part of the implementation goes through
checking
>the RBS to make sure that we can handle the volume and the amount of
>activity you are generating. We have had customers who have shut
down
>SharePlex for 2-3 hours, and when it comes up, replicates everything
during
>those 2-3 hours just fine... even if it has been moved into the
archive
>logs.
>
>yes, the supplemental logging is not the greatest thing Oracle ever
did, but
>it was probably one of the easiest ways to implement it. Just for
kicks...
>do a couple small batch jobs (maybe 2-3 million row changes) and see
how
>long it takes, and how much redo it generates. Then do the same
thing with
>Streams replicating that job... how long does it take, and how much
redo is
>generated. Streams uses the supplemental logging, and their capture
>process reads from the redo logs, then puts the transaction right
back into
>the database (in Advanced Queues) which generates more logs, then
they
>dequeue the operation (generating more logs again) to post it to the
target
>machine.
>
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jonathan Lewis
  INET: jonathan_at_jlcomp.demon.co.uk

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).