RE: quest SharePlex

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.

-----Original Message-----
Sent: Wednesday, January 22, 2003 12:34 AM To: Multiple recipients of list ORACLE-L

Very cute - this tends to suggest that Shareplex is spotting the appearance of chains in the log and storing the list of rowids.

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 ? And does Shareplex guarantee that it will never report a 1555 error regardless of how long it is shut down ?

Your comment about supplemental logging is interesting - to me, one of the issues with using the official method for logical standby is that you have to have supplemental logging switched on at the database level. This means, as you have obviously spotted, that tables without primary keys get whole rows copied into the log. Worse still, because supplemental logging is effected through the UNDO, global temporary tables have an extra impact on the stream too.

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: 21 January 2003 19:01

>This is actually part of the 'magic' of SharePlex. The way we obtain
the PK
>information from the database if the PK was not modified is very
tricky.
>
>1) shutdown SharePlex (stop all processes on the source machine, so
>SharePlex is not even up and running)
>2) insert a row.
>3) update that row to cause chaining.
>4) update the row again in the chained piece and don't modify the PK.
>5) delete the row
>6) start SharePlex back up.
>
>Did everything replicate successfully? Yep. :)
>

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

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Nick Wagner
  INET: Nick.Wagner_at_quest.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).