3 Replies Latest reply on Mar 18, 2014 11:55 PM by Nick.W-Oracle

    What is the Default Behavior


      What would be the default behavior of Golden gate in the following scenario (Active-Active configuration)


      Site A:

      14010001111ABCD, AX


      Site B:




      ABCD, AX



      Case 1:

      Considering there's no CDR configured i.e. no GETBEFORECOLS parameter in extract param file,

      If a user in Site A updates Number column with value 5001110000 and another user in Site B updates Number with value 600111000 at nearly the same time (i.e before one gets replicated to the other),

      What will be the result? Since there's no GETBEFORECOLS paramater configured, will there be a conflict detected?


      Case 2:

      If GETBEFORECOLS is configured for both Number and Address columns, what will happen if two users at different sites, update different columns at nearly the same time.

      e.g User at Site A updates Number while User at Site B updates Address

      Will there be a conflict or will both sites have the updated values for both columns?


      Final Question:

      Is there a configuration to achieve both of the following objectives:

      1. In case 1, There should be a conflict detection since both are trying to update the same column.

      2. In case 2, There should be no conflict, since different columns were updated, and thus the final result should be updated values on both columns at both sites.


      Hope I was able to get my question across. Thanks

        • 1. Re: What is the Default Behavior

          Assuming that ID is the primary key... 


          Case #1 - the end result would be that both operations succeed in the replicat.  So Site B would end up having 5001110000 and Site A would end up having 600011110000.   OGG, by default, only uses the primary key (OR KEYCOLS) columns in the where clause.  Since the key is not changing and the UPDATE operation is executed successfully, what ends up happening is that both operations succeed.


          Case #2 - the result is the same here as in case #1.  Since the PK is the only value used in the where clause, both operations would be applied successfully.


          Final Questions:


          1) if you want a conflict to be triggered here, you can do two things, you can use COMPARECOLS to include all columns, and that forces the WHERE clause to include the NUMBER and ADDRESS columns as well as the ID column (primary key) and then the RESOLVECONFLICT portion of the MAP statement would kick in and you can use that to handle the conflict.


          2) Depending on the COMPARESCOLS settings and RESOLVECONFLICT settings, yes, you can get this to occur quite easily, where both succeed, however, you can also configure it so that one system overrides another.


          I would recommend reading up on the Active-Active white paper.   It's here:






          • 2. Re: What is the Default Behavior

            Thanks Nick. A bit more clarification needed.


            You said "Case #2 - the result is the same here as in case #1"

            But GETBEFORECOLS and COMPARECOLS will have to be configured here for all columns if I want case 1 to trigger conflict. In that case even if different columns are being updated, there will be a conflict since the trail has before images of all the columns.

            My question is, how can I configue GG so that case 1 triggers conflict AND case 2 doesnt.


            I hope you got what I'm trying to say.


            • 3. Re: What is the Default Behavior

              To get Case 1 to trigger and case 2 not to trigger, then that is configured in the COMPARECOLS section. 


              Your COMPARECOLS would not include the NUMBER and ADDRESS fields and would only contain the ID and timestamp column.