>> The task is working fine, it triggers an email alerts sproadically.
Great. (Why did you not provide that information right away??)
>> I have attached an excerpt of the corresponding REPTASK_prod2 logfile masking some details.
Excellent. Next time, provide that right away!
>> There's no obvious error found except pointing to the driver.
The driver details are just informational telling us where the problem was reported, not the cause. Considering the lack of hard DML error, considering a simple 'prepare' failing for a normal predictable sql, considering the standard defensive re-attach actually succeeded my interpretation of this all is that the target dabase connection failed. Someone killed a process of a network connection, or even bounced the whole DB. You should focus on working with target DBA and Network folks to see if any glitches were reported in the timeframes indicated by the replicate logs.
My opinion here is that Replicate is working as designed and nicely warns you about environmental issues outside the control of Replicate. Replicate is the victim, not a cause. The failing statement could have been any statement but that truncate is a more likely candidate because it is the first statement to happen before getting ready to submit the next batch of changes and as such it is at the end of the longest gap between operations. It is the most likely to detect a connection issue. It may be executed after seconds even minutes of 'idle' time collecting the next batch whereas the subsequent activity would be rapid fire - sub second and less likely to catch a bad connection.
>> I could enable detail trace to verbose for target apply if alerts gets triggered again.
You might as well, just for a few days. Be sure to setup log management like rolling every day or every 100MB.
Hein.
