topic Re: Source Latency Issue in Qlik Replicate

Source Latency Issue

FrancoHR — Mon, 04 Dec 2023 20:35:15 GMT

Replicate from Oracle to Aurora

The problem is that large volumes of pending changes from the origin are not noticed but a latency of 11 hours is still marked? The image shows a change pending commit.

Why is this? How can this be corrected?

Re: Source Latency Issue

Dana_Baldwin — Mon, 04 Dec 2023 21:55:06 GMT

Hi @FrancoHR

Are the incoming changes waiting for source commit? The following general information may help, please see if it is applicable - for example, perhaps the source changes at the moment are not related to the tables in the task:

Apply Latency gauge: A gauge that displays the latency information.
The latency values displayed in the Attunity Replicate Console measure the time delay
(latency) between the time when a change is visible to the source (and committed), and the
time when this same change is visible to the target. The display is always based on the
current change being applied.

You should take the following into consideration:
Latency when applying large transactions:
For example, when the most recent latency value was 10 seconds and now a transaction
of one million rows gets committed at the source endpoint, Attunity Replicate starts to
apply that transaction to the selected target and it will take some time to write all the
changes to the target (for example 60 seconds). During the next 60 seconds, the latency
value gradually grows to 70 seconds for the last change in the transaction. Once the
transaction is committed, the latency drops back to the 'regular' latency (10 seconds in
this case).

Latency when no transactions are being applied:
When a time period passes with no changes applied to the target, the latency calculation
is based on the time difference between the current time and the timestamp of the last
change event read from the transaction log. This could happen if, for example, there is
high activity on tables which are not selected for replication in the current task.
For additional details, you can also view a graph with Information about Apply Latency

Information about Apply Latency
Latency values for apply latency in a change-processing operation provide information about the
time delay (latency) between the time when a change is visible to the source (and committed),
and the time when this same change is visible to the target. The information is displayed in a
gauge in the Change-Processing graph section. The following figure shows the Apply Latency
gauge.

Re: Source Latency Issue

Heinvandenheuvel — Tue, 05 Dec 2023 04:19:03 GMT

Did it ever work properly?

Is there anything happening on the source? That reported transaction is unlikely to be meaning full.

I suspect you have trouble reading an Archive or Redo log. - not unlikely due to HA (mis)configuration.

Have you looked in the reptask log? You should! Start by switching on logging for PERFORMANCE to TRACE which will show whether this is indeed source latency or target latency.

If it is source latency roll the log (for a fresh start) enable logging for SOURCE_CAPTURE to TRACE (DEBUG) and let go for a few minutes or a few Megabytes - whichever comes first. Return logging to informational, roll the log again and study that before last, timestamped log.

Submit to support if need be in a case - along with task Json.

hth,

Hein.