Forum Stats

  • 3,853,722 Users
  • 2,264,259 Discussions
  • 7,905,436 Comments

Discussions

Multiple Replicat -Transaction consistency

784624
784624 Member Posts: 28
edited Jan 7, 2011 8:26AM in GoldenGate
When using the the @RANGE function to divide the processing workload among multiple Replicats do we have the transaction commit orders preserved.If one REPLICAT is ahead of the other could it cause data inconsistency ?

For example, the following splits the replication workload into two ranges (between two Replicat processes) based on the ID
column of the source account table.

MAP Source.Account, TARGET Target.account, FILTER (@RANGE (1, 2, ID));

On the source we have the following order.

1)Update accounts set balance='NEGATIVE';

2)Update accounts set balance='ZERO';

3)Update accounts set balance='NEGATIVE';

4)Update accounts set balance='POSITIVE';


When we split the transactionS based on the Hash-value of the primary key and if we have 1,2 Assigned to Replicat1 and 3,4 Assigned to Replicat2 and if Replicat2 finishes before Replicat1 there will be data inconsistency.

Can we preserve the commit order when using Multiple Replicats.

Best Answer

  • Ericee-Oracle
    Ericee-Oracle Member Posts: 22
    Answer ✓
    hi,

    When using the @RANGE to split up transactions it is always possible that one replicat is quicker then the other one(s).
    This can result in the operations being applied in a different order then in the original transaction.
    But this "inconsistency" will only be for a very very short moment (unless one of the replicats has a huge delay, or is stopped)

    In your example you are using the ID field to calculate the hash value for the @RANGE function.
    As long as this ID field stays the same, the same record gets processed every time by the same replicat, so when the replicats are finished, the data is the same as on the source, no inconsistencies

    regards,
    Eric

Answers

  • Ericee-Oracle
    Ericee-Oracle Member Posts: 22
    Answer ✓
    hi,

    When using the @RANGE to split up transactions it is always possible that one replicat is quicker then the other one(s).
    This can result in the operations being applied in a different order then in the original transaction.
    But this "inconsistency" will only be for a very very short moment (unless one of the replicats has a huge delay, or is stopped)

    In your example you are using the ID field to calculate the hash value for the @RANGE function.
    As long as this ID field stays the same, the same record gets processed every time by the same replicat, so when the replicats are finished, the data is the same as on the source, no inconsistencies

    regards,
    Eric
This discussion has been closed.