With Qlik Replicate performance logging set to trace, you may find the following log entries:
PERFORMANCE ]T: Source latency x.x seconds, Target latency x.x seconds, Handling latency x
Examples:
This is how to identify what is causing the latency:
- With Qlik Replicate logging set at the performance trace level, we can see that there is Target latency, so our next step is to identify what is happening on the target. We set the task log Monitor/Tools/Log Management/TARGET_APPLY, Verbose and monitor for approximately 15 minutes.
- Afterwards, we review the log (use a text editor such as Notepad++) and search for:
- In our case we locate the following:
00004452: 2023-03-06T21:45:03:512870 [TARGET_APPLY ]V: Apply no Bulk Event - 'DELETE (5)' for table 68 (bulk_apply.c:2567)
00004452: 2023-03-06T21:45:03:514873 [TARGET_APPLY ]V: Delete statement
~{8wAAAAbfkCA2HbtSjNsuvYe0eihWpVFZaYVWoHxNzhTAS+jNq3BeRmPhCOnY5ak6C7udqTkWsF5wWEHzff/...
- We see that the Delete statement is encrypted because it sstartswith ~{xxx... ex. ~{8wAAAAbfkCA2HbtSjNsuv
- To find how what table 68 is, we have to decrypt the task log to see the delete statement on the table. See How to Decrypt Qlik Replicate Verbose Task Log Files
- After decryption, we can now see the table name.
- We now check for the following:
Does the table contain LOBs?
Does the table have PK on source and target?
- In our case, the table does not have PK on target, causing the task to apply no Bulk Event. This results in a latency on the task.
- A quick fix is to:
- Stop the task,
- remove the table that has no PK from the task,
- then resume the task.
Environment
Qlik Replicate 7.0 and above
The information in this article is provided as-is and to be used at own discretion. Depending on tool(s) used, customization(s), and/or other factors ongoing support on the solution below may not be provided by Qlik Support.