Regarding 'Incoming Changes' of Replicate Change Processing User Interface

[iti-attunity-sup]

I would like to confirm that number shown in 'Incoming Changes' section.

My understanding is as follows, is this correct?

- 'Incoming Changes' is the total number of changes and transactions that are being read from the source database endpoint.
- The bar shows the total number of changes for the tables selected in the task.
- 'Transactions' shows number of all the transactions open in the source database.

For example,
The task's table is 'TBL_A, transaction updating TBL_B is running in the database,
That is, there is one transaction but no changes for TBL_A.
In this case, 'Incoming Changes' shows '0 (1 Transactions)' as shown below.

If I understand correctly, 'Transactions' is a bit confusing,
I assume it would be better to have some notes that it shows number of all the transactions in the source database.

[deepaksahirwar]

Dear @iti-attunity-sup ,

Your understanding is mostly correct, except for one point. 

The ‘Transactions’ number does not show all the transactions open in the source database, but only the ones that are relevant to the tables selected in the task. 

This means that if a transaction updates both TBL_A and TBL_B, it will be counted as one transaction in the ‘Incoming Changes’ section, even if there are no changes for TBL_A. 

However, if a transaction updates only TBL_B, it will not be counted at all, since TBL_B is not selected in the task.

To summarize, the ‘Incoming Changes’ section shows the following information:

‘Incoming Changes’ is the total number of changes and transactions that are being read from the source database endpoint for the tables selected in the task.

The bar shows the total number of changes for the tables selected in the task.

‘Transactions’ shows the number of transactions that affect the tables selected in the task, regardless of whether they have changes or not.

If our response has been helpful, please consider clicking "Accept as Solution". This will assist other users in easily finding the answer

Regards,

Deepak 

[iti-attunity-sup]

@deepaksahirwar 

Hello Deepak 

Thank you for your update.

However, may I confirm this issue again as I still have some questions?

As far as I have confirmed in house, ‘Transactions’ shows the number of all the transactions in the source database.

My test results are below:

- Qlik Replicate : v2023.11
- Source/Target : Oracle 19c

- Selected Tables : TBL_A

* Session#1 : update Selected Table (TBL_A) but no changes

SQL> update TBL_A set col2 = col2 where 1=2;

0 rows updated.

--> 0 rows / Transactions 0

* Session#2 : update *not* Selected Table (TBL_B), 10 rows are changed.

SQL> update TBL_A set col2 = 'UPDATE' ;

10 rows updated.

--> 0 rows / Transactions 1

So I'm wondering whether ‘Transactions’ shows the number of all the transactions.

But as of now, it is ok if I can confirm that when the bar shows no row, it means that there are no changes which affect the tables selected in the task regardless of the number of 'Transactions'.
Is my understanding correct?

Regards,
Kyoko Tajima

[deepaksahirwar · Accepted solution]

Dear @iti-attunity-sup (Kyoko Tajima)

Yes, your understanding is correct. In Qlik Replicate, the 'Transactions' count represents the total number of transactions that are open in the source database. This includes transactions that affect all tables in the database, not just the tables selected in your task.

From above image-So, if it’s showing 1 transaction with 0 incoming changes, it means that there is one transaction open in the source database, but it does not affect the tables selected in your task. In other words, a change has occurred in the database, but it’s not related to the tables you’re replicating, hence no incoming

The 'Incoming Changes' section shows the total number of changes and transactions that are being read from the source database endpoint. The bar shows the total number of changes for the tables selected in the task. So, if the bar shows no rows, it means that there are no changes which affect the tables selected in the task, regardless of the number of 'Transactions'.

However, it's important to note that '0 rows updated' can also occur in certain situations, such as when an UPDATE operation is performed on a table but no rows are actually changed. This could be due to the UPDATE statement's WHERE clause not matching any rows, or the columns being updated already having the specified values.

PFA doc for reference.

I hope this helps! Let me know if you have any other queries.

If our response has been helpful, please consider clicking "Accept as Solution". This will assist other users in easily finding the answer.

Regards,

Deepak

[DesmondWOO]

Hi Tajima san,

In reference to the Session#2,

SQL> update TBL_A set col2 = 'UPDATE' ;

I believe TBL_A should be replaced with TBL_B. Could you confirm if my understanding is correct?

Thanks,
Desmond

[iti-attunity-sup]

Hello Desmond

Yes,   you are correct. Thank you for pointing out.

Regards,

Kyoko Tajima

[DesmondWOO]

Hi Tajima san,

Do you have any additional questions? If you found Deepak’s response helpful, please consider clicking “Accept as Solution”.

Thanks!
Desmond

[slewis]

I have an additional question regarding Apply Latency. When the we have an Incoming Changes condition like is described above (0 Changes / >= 1 Transactions) the Apply Latency Time calculation continues to grow until the Transaction is cancelled or committed.

If the 1 transaction is open for a table not defined in the Task itself, why wouldn't the Apply Latency Time calculation get reset back to 00:00:00 as soon as the number of changes reaches 0?

With the Apply Latency time calculation being "blocked" by the transaction count I'm often getting false latency threshold error emails when the task actually has nothing to do.