Qlik Community

Ask a Question

Qlik Replicate Discussions

Discussion board for collaboration on Qlik Replicate.

Announcements
Join us March 10th, 7 Ways Modern Analytics Can Help You Take Smarter Action. REGISTER NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
TaylorN
Contributor II
Contributor II

Bulk apply operation failed

I am getting many of the below errors in my task log. My source is Oracle 11g and target is Azure SQL DB. The updates do indeed get applied, but I would prefer they are done in bulk (much faster)

00003336: 2020-02-20T13:48:35 [TARGET_APPLY ]I: Bulk apply operation failed. Trying to execute bulk statements in 'one-by-one' mode (bulk_apply.c:2312)
00003336: 2020-02-20T13:48:35 [TARGET_APPLY ]I: Applying UPDATES one-by-one for table '<tablename>' (56) (bulk_apply.c:4810)
00003336: 2020-02-20T13:48:35 [TARGET_APPLY ]I: Switch back to bulk apply mode (bulk_apply.c:4907)

1 Solution

Accepted Solutions
Ted_Manka
Support
Support

@TaylorN  we didn't find anything that was fixed or causing tasks to be forced into 1 by 1 mode.  I would suggest increasing target_apply logging to at least trace if not verbose to see errors that are coming out.  Please increase, reproduce the problem then look to see what error / problem happened just before it got kicked to 1 by 1 mode.

 

Thank you,

Ted Manka

View solution in original post

9 Replies
Ted_Manka
Support
Support

Please check your target database for 'attrep_apply_exceptions' table for details on the issue that is leading to the the one-by-one.

TaylorN
Contributor II
Contributor II

There were no exceptions in the table. I ended up just switching to transactional apply anyway, as I need to ensure referential integrity is maintained.

Ted_Manka
Support
Support

Hello @TaylorN ,

Correct, you need to get to the root problem that is causing the task to exit batch apply mode and forcing it into 1-1.  Did you check the target database for 'attrep_apply_exceptions' table yet?

Thank you,

Ted Manka

TaylorN
Contributor II
Contributor II

@Ted_Manka as I said, there were no exceptions in the table 

Ted_Manka
Support
Support

Hello @TaylorN ,

 

I apologize I missed your statement before, clearly you stated that, I am sorry.  

 

If there is nothing in the table then we need to up the logs on target_apply and start looking for errors / warnings.   Also what version are you on?  I have been told by the team that there has been fixes so solve similar issues.

 

Can you also check your exception handling for the task and ensure it is set to write the record to the exception table?

 

Thank you,

Ted Mankaexception handling.png

TaylorN
Contributor II
Contributor II

@Ted_Manka , no worries 🙂

I have all exceptions being logged except for the update statement. That now performs an insert if the target row is missing. 

I believe I’m running v6.4 (not sure which build)

Ted_Manka
Support
Support

@TaylorN ,

 

You can find the exact version number at the very top of your task log file.

 

Thank you,

Ted Manka

TaylorN
Contributor II
Contributor II

@Ted_Manka , version is 6.4.0.457

Ted_Manka
Support
Support

@TaylorN  we didn't find anything that was fixed or causing tasks to be forced into 1 by 1 mode.  I would suggest increasing target_apply logging to at least trace if not verbose to see errors that are coming out.  Please increase, reproduce the problem then look to see what error / problem happened just before it got kicked to 1 by 1 mode.

 

Thank you,

Ted Manka

View solution in original post

Community Browser