3 Replies Latest reply: Jan 31, 2014 8:33 AM by Partha Sarathy S RSS

    Replication rule

    902923


      Hi Experts,

       

      We have a replication requirement between two oracle databases, its a uni directional database replication . but already there is a replication happning with different technology like stream, we decided to migrate this with goldengate. there are lots of data transformation required to replicate the data from source oracle to target, the main part is, once configured goldengate , the customer want to run both stream replication as well new goldengate replication also for some time.

      if configured ogg with stream , the replication flow will be two ways from source , one is from OGG another one from stream, these two replications will be replicated the data to same set of tables.

       

      here we want to set the rule like, if stream user replicated the data first into target tables,  then OGG user should not replicate the same data into target tables, like vice versa , if ogg user replicated the source data first in to target tables then stream user should not replicate the data which is coming from stream configuration , we need to set this rule in target database,  can any one please help on this to achive this?  that would be very much helpful us to start the ogg replication processes.  Thanks in Advance,

        • 1. Re: Replication rule
          jjk

          I dont think so. This approach is not correct at first place. I think it is be your duty to test the GG replication in UAT/Test envs and convince client based on the test results to use only one of them instead of both.

           

          however, assuming,

          1. that the replication is Oracle-Oracle

          2. Both, source & target are different databases

          3. Both are being used by different applications

           

          if your tables have primary or unique key, then and only then, you can check if "handlecollision" in GG replicat helps. Ideally, that parameter should never be used in production since that might not produce a correct replica of the source data.

          • 2. Re: Replication rule
            onkar.nath

            I agree with jjk. This approach is not good and moreover this is complicating a simple migration job. If client wanted to make sure that GG replication works fine then setup a test environment, configure replication there, run application against this test environment (let the production run the way it is unless testing is done) and when client is satisfied then configure replication on production.

             

            It has many benefits:

             

            1. You dont have to complicate the simple migration task.

            2. You dont have to disturb production so even if something goes wrong, you have nothing to loose

            3. Your setup will be tested so you will be ready with any likely problems may arise during actual move.

             

            -Onkar

            • 3. Re: Replication rule
              Partha Sarathy S

              This doesn't seem to be a good idea. Because GoldenGate doesn't work like,  "look for availability of rows in target and if not replicate.". So if you want to test GG, test in some lower environments and then use it in PROD. Else the one possible option would be to use REPERROR parameter to report Oracle error numbers instead of REPLICAT abending out. You can just think of the possible errors, when Streams user updated a row , that row will be made available in target. So when GoldenGate tries to update the same, since it is already updated, you may get " ora:1403 - NO DATA FOUND" error. So similarly you have to think for other INSERT and DELETE scenarios and use REPERROR for those error numbers. Also it will report out and not abend when these errors occur during replication also. Make sure you cover all possible errors. But this is not a good way to do. I am just giving an idea if you are not able to convince your client.

               

              Message was edited by: Parth272025