Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Announcements
Share your agentic AI experience, learn from others, and earn a new badge: Put Agentic AI to Work
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
JorgeManrique
Contributor II
Contributor II
3 weeks ago

Issues in Qlik after the DB2 LUW upgrade

Problem Description

The source IBM DB2 LUW database has been migrated to a new machine. The new machine retains the same connection configuration as the previous one, including the hostname, IP addresses, port, and database name.

The new installation uses:

 

DB2 LUW Server: 11.5.9
Qlik Replicate: November 2025 Initial Release
Qlik Build: 2025.11.0.285
DB2 Client used by Qlik: 11.5.8
Target: Kafka

 

After the migration, the old transaction logs were not copied to the new machine. For this reason, a Reload Target was performed to fully reload the data and establish a new CDC starting point based on the logs generated after the migration.

The Reload Target completed, and the task started replicating changes. However, the volume of data captured by Qlik is significantly lower than usual.

During specific time periods, millions of changes were replicated before the migration. After the migration, only approximately 5,000 changes are being captured during those same time periods.

Observed Behavior

The issue does not appear to be related to latency:

  • Qlik does not show any significant delay when reading the logs.
  • The task is running.
  • Qlik continues to advance through the stream position.
  • There is no backlog of millions of changes waiting to be applied.
  • The issue is that Qlik is capturing far fewer changes than expected.
  • The reduction occurred after the migration to DB2 LUW 11.5.9.

All tables included in the task have the following setting enabled:

 

DATA CAPTURE CHANGES

 

Therefore, the issue does not appear to be related to the absence of this setting.

Information About the DB2 Client Used by Qlik

The following information appears in the task log:

 

2026-09-12T22:18:09 [SOURCE_CAPTURE]I:
DB2 client version: 11.05.0800
(db2luw_endpoint_capture.c:127)

 

This confirms that Qlik Replicate is using:

 

DB2 Client 11.5.8

 

to connect to and read the logs from:

 

DB2 LUW Server 11.5.9

 

The current combination is therefore:

 

Qlik Replicate: 2025.11.0.285
DB2 Client: 11.5.8
DB2 LUW Server: 11.5.9

 

Qlik uses the native IBM API:

 

db2ReadLog

 

to read the DB2 LUW transaction log records.

Impact

The impact is critical because Qlik appears to be up to date, but the number of captured changes is significantly lower than the actual expected volume.

The observed behavior is approximately:

 

Typical volume before the migration: millions of changes
Volume captured after the migration: approximately 5,000 changes

 

This raises concerns about whether Qlik is correctly receiving or interpreting all propagatable log records returned by db2ReadLog.

There is a risk that not all changes made to the source tables are being published to Kafka.

Checks Performed

The following points have been confirmed so far:

  1. The database was migrated to a new machine.
  2. The new database uses DB2 LUW 11.5.9.
  3. The hostname, IP addresses, port, and database name remain unchanged.
  4. The old transaction logs are not available on the new machine.
  5. A Reload Target was performed after the migration.
  6. The Full Load completed, and Qlik started processing CDC.
  7. The task does not have a latency issue.
  8. All tables have DATA CAPTURE CHANGES enabled.
  9. Qlik continues to capture some changes, but the volume is abnormally low.
  10. The DB2 client loaded by SOURCE_CAPTURE is version 11.5.8.
  11. The DB2 server is running version 11.5.9.
  12. The Kafka target is available, and Qlik successfully retrieves metadata from all three brokers.

Kafka Target Evidence

The log also shows that Qlik connects successfully to all three Kafka brokers:

 

Kafka client version: 2.11.1
 
Broker 0:
b0.kafka.confluent.pro.allfunds.bank:443
 
Broker 1:
b1.kafka.confluent.pro.allfunds.bank:443
 
Broker 2:
b2.kafka.confluent.pro.allfunds.bank:443

 

However, the issue appears to be in the DB2 source capture stage, as the number of changes detected at the source is significantly lower than expected.

Request to Qlik Support

We would like Qlik Support to confirm the following points:

  1. Whether Qlik Replicate November 2025 Initial Release, build 2025.11.0.285, officially supports a DB2 LUW 11.5.9 server when using the DB2 11.5.8 client.

  2. Whether there are any known compatibility issues involving the following combination:

 

Qlik Replicate 2025.11.0.285
DB2 Client 11.5.8
DB2 LUW Server 11.5.9

 

  1. Whether there are any known issues with the db2ReadLog API or the Qlik parser when reading logs generated by DB2 LUW 11.5.9 through a DB2 11.5.8 client.

  2. Whether the DB2 client must be upgraded to version 11.5.9 to guarantee that all propagatable log records are read correctly.

  3. Whether Qlik Replicate November 2025 SR1 includes any DB2 LUW-related fixes that could affect change capture.

  4. Whether Qlik can continue advancing through the stream position even if certain DB2 log record types are not being correctly interpreted or counted.

Labels (2)
Labels
198 Views
0 Likes
0 Replies