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.
I can tell you some of the 'magic' but not all of it. (NDA type stuff)
In all updates the redo logs contain the rowid for the row being modified (or piece of row in chained row cases) and we use that rowid to go back into the database and grab the PK information. All that is pretty simple, the real magic comes in when you do something like this...
(QA does this type of operation all the time)
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. :)
We've looked at turning on the supplemental logging and it causes more overhead then our quick search. And is not really on option for large environments like Oracle Apps or other ERP's that have 1000's of tables, many of them that don't have a PK at all.
-----Original Message-----
From: Jonathan Lewis [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 19, 2003 2:34 AM
To: Multiple recipients of list ORACLE-L
Subject: Re: quest SharePlex
Thanks for the reply.
That covers the object/data_object id problem, and gives
the ability to identify which columns in the dump are the
primary key columns.
But when you update a row, the redo will only contain the
primary key if the primary key has been modified, so you
should hardly ever find it in the redo.
Does this mean you trap the primary key on every insert
and keep a cross reference between primary keys and
rowids somewhere, or do you do a lookup back into the
database in real time to translate rowids into primary keys ?
Oracle, of course, gets around this problem in version 9
with the 'supplemental logging' feature - which Shareplex
could probably use to even better effect, but how do you
do it before 9 ?
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 <[EMAIL PROTECTED]>
Date: 18 January 2003 01:15
>You provide a 'configuration file' which is just a flat file of table
names
>on the source machine and table names on the target machine. Then
we go
>through an activation process that takes the table name on the source
and
>grabs the object id from Oracle and the primary key columns (if no
primary
>key, we use all the columns except for LOB's and LONGs). Then the
capture
>process scans through the redo logs only capturing changes to object
ids in
>our list.
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jonathan Lewis
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).
