What I noticed
I recently investigated a case where changes made to an Oracle table were not streaming to Kafka. At first, it looked like a capture or connectivity issue because no changes were appearing on the target side. The interesting part was that several validation checks appeared completely healthy, yet replication still showed no activity.
The investigation started with basic Oracle validation. The database was confirmed to be running in ARCHIVELOG mode, and supplemental logging was present for the monitored table:
SELECT LOG_MODE FROM V$DATABASE
SELECT * FROM ALL_LOG_GROUPS WHERE table_name = 'CDC_TEST_CUSTOMER_2'
The results suggested that the capture prerequisites were in place. At the same time, monitoring showed zero captured changes.
Attention briefly shifted to Kafka because the logs showed the apply process successfully initializing and obtaining a Kafka commit ID. Connectivity appeared healthy, which made the lack of streaming even more puzzling.
The breakthrough came from a single log entry from the Change selector logs:
2026-03-18 17:44:32,823 [CSLogMiner5] INFO:Skipping transaction 11.7.147750 because user=CDCUSER
Starting timestamp=20260318044402000000 scn=7474827220330000
That message changed the direction of the investigation. The Oracle kernel and processes were running as CDCUSER, and changes were also being made to the source table using the same user account. After testing with a different Oracle user, data immediately began flowing into Kafka.
The behaviour was completely deterministic. The transactions were being skipped exactly as indicated in the logs, and replication resumed as soon as changes originated from another user.
Why this design works
Predictability : The reason transactions were not replicated was explicitly recorded in the logs.
Reliability : Repeated testing produced consistent results based on the transaction owner.
Operational Safety : Clear logging reduced guesswork and helped isolate the behaviour quickly.
What's different for Oracle
There is one extra step.
When troubleshooting Oracle replication, validating logging and capture settings may not be sufficient. The user generating the source transactions can also influence the observed behaviour.
No significant platform-specific variation was observed in this case.
Why this matters in production
This type of issue can easily be mistaken for a Kafka, network, or capture problem. Engineers may spend time validating infrastructure while the decisive clue already exists in the logs.
The real-world implication is simple: if the replication user is generating the source transactions, observing transaction-skipping messages can immediately explain why no data is reaching the target. Once a different user generated the changes, replication proceeded normally.
If you ever see transactions being skipped for a specific user, it is not random. It is Connect CDC doing exactly what it should.
What changed for me
I used to assume that missing data always pointed to capture or connectivity problems.
This investigation reminded me that the most valuable clue is often already in the logs. Once I focused on what was being skipped instead of what was missing, the behaviour became easy to explain.
That reinforced my confidence in following the evidence before chasing assumptions.
Takeaway
When Oracle changes are not streaming, successful logging validation and healthy Kafka connectivity do not always tell the full story. A single log message identifying skipped transactions can reveal the root cause much faster than deeper infrastructure analysis.
Closing community question
Have you encountered a replication issue where a single log entry completely changed the direction of your investigation?
------------------------------
Neha Goel
*Precisely Software Inc.
------------------------------