Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I've noticed an issue where some records are not being brought across from the source DB. Some of the errors in the apply_exceptions table are updates with 0 rows affected because the original row was never inserted.
The one with most of the errors, the source table has 102 318 367 rows and the target has 102 315 014 rows which is a bit of a concern.
I have set the error handling rule to insert the row if missing, but I’m still concerned as to why these inserts are missing in the first place.
Edit: I hadn't restarted the task since changing the above setting, now it fails to start as it tries to enable supplemental logging on every column of every table! Is this necessary for the "No record found for applying an UPDATE: INSERT the missing target record" setting to work?
The issue seemed to go away after a restart one day. Obviously I had tried restarting the process several times to no avail. So I am not sure exactly what fixed it, but it just started working.
Hi TaylorN,
Do you know what was the issue and how it got resolved? I am new to the Attunity world and have observed similar issues on our end too.
Thanks
AU
I don't have an active support agreement, and I would prefer not to pay such a large amount of money to fix what appears to be a bug with the software 🙂
The issue seemed to go away after a restart one day. Obviously I had tried restarting the process several times to no avail. So I am not sure exactly what fixed it, but it just started working.
@TaylorN Thanks for your response. Do you mind sharing if the source and the target database are oracle in your case and how long the archive log kept on the source ? We have been running into issue of Attunity not able to pace with the changes from source and ending up error with missing the below error in production. I am looking for how this tool is successfully configured with huge changes occurring in seconds.
Archived Redo log with the sequence #### does not exist, thread 1.
Thanks
I am replicating Oracle to Azure SQL.
However, I have also encountered that error before. That happens when the archived redo logs are deleted before Attunity is able to process them. I’m assuming you have a highly transactional system? How often are backups being taken?
Sorry for the very late response. Yes, it's a highly transactional system and the archive logs get deleted after two days. If replication does not happen as fast as the changes demand then that error occurs. By restarting the task does solve the issue putting the tasks back to run but the historical data in the target table will be lost because the restart will again fetch and update all data that exists in the source causing duplicate or throw constraint error so emptying the target is the only the temporary solution.