@NakulanR - you are replying to an older topic, which is just fine as the issue seems to be very much the same. Bu in case there are further developments specific to your customer situation you may want to consider your own follow up topic with clear subject and perhaps a back link.
If this source "LOB lookup: row was already deleted" is indeed a regular occurrence, then you may wish to review the handling of that table in general. . Maybe it needs it's own task or placement in a dedicated task for trouble tables with lower levels of warning settings. Maybe it needs a different LOB setting - which is unfortunately a task-wide setting, not table specific.
Does that table have 'soft deletes thru using an 'operation_indicator' transformation? Maybe it needs transactional mode for more instant lob lookup or just a task with lower source latency in general. Is the task running with seconds of latency or hours of latency in general - in the later case the chances for a deleted source row are obviously higher. Or if those rows are indeed frequently deleted after soon after insert (seconds - or not much more than task latency, then maybe much higher batch apply tuning setting for timeout is in order. If the task were to apply changes only after collecting for minutes then maybe the delete is seen before the insert is processed and the whole row activity is optimized away? - one can dream right? Note- this would not 'solve' the issue, just potentially reduce the occurrence. The insert could easily happen at the end of one batch cycle and the delete in the next and there would be no cancelling.
Anyway, I hope it is clear that some analysis of what is typically happening to that table on the source is in order and it might just need special handling, different from most tables in the task.
Cheers,
Hein.
