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.
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.
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.
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