Internal error: lcache.c: 5107: mismatch error (4263924)

Event Log:

1] 11/14/06 12:53 Warning: partial rollback - rowid mismatch (AAAYB1ADPAAACvRAAB:AAAYB1ADPAAACvRAAA) in session 7 [sp_opst_mt (for o.IRIPRD-o.IRISPP queue inventory_pq)/11421]
[1] 11/14/06 12:53 Internal error: lcache.c: 5107: mismatch error [sp_opst_mt (for o.IRIPRD-o.IRISPP queue inventory_pq)/11421]
[1] 11/14/06 12:53 Warning: Mismatch() partial rollback - messages counts mismatch(127:126) in session 7 [sp_opst_mt (for o.IRIPRD-o.IRISPP queue inventory_pq)/11421]
[1] 11/14/06 12:53 Notice: Transaction history for mismatch logged in /u07/splex/var/log/IRISPP_fb_11421_7.log. [sp_opst_mt (for o.IRIPRD-o.IRISPP queue inventory_pq)/11421]
[86] 11/14/06 12:55 Out of sync: table - "BOM"."BOM_CTO_ORDER_LINES" (rid:AAAYB1ADPAAACvJAAi) ORA-00001: unique constraint (BOM.BOM_CTO_ORDER_LINES_U1) violated. [sp_opst_mt (for o.IRIPRD-o.IRISPP queue inventory_pq)/11421]

The problem is that there are 2 forward messages with a forward count of 2 and a backward message with a forward count of -4.

To work around this issue you willl need to contact SharePlex support. Below is an explination of the problem

Explanation:

When capture generates the messages for Shareplex, if it parses operations for the same transaction and row in sequential order; it will combine those operations and generate one message. For example if capture encounters an insert for 'row A' followed directly by 2 updates to 'row A' in the same transaction; it will generate a queue message that contains an insert with a forward count (# of operations combined for this message) of '3'.

Capture is supposed to combine operations for rollbacks in the exact same fashion that it processed the forward operations. So in the example above, if it was rolled backed capture should see an update to 'row A' followed by another update and then an insert on 'row A' (rollbacks should show up in exact opposite order as the original transaction). Capture should combine in the same fashion and generate a rollback delete message that has a forward count of '-3'.

The problem encountered in this scenario is that the rollback message generated was not combined in the exact same order as the forward operations and this caused poster's counting to be off when processing the rollback.

There is a fix for this in 6.0 with changes in both capture and poster.

Additional Information:

All of the messages around these messages match. Since there are 2 forward and 1 backward message and Poster currently counts messages and not forward counts the outer messages don't match