Oracle LogMiner CDC: downstream retains old column values — guidance on diagnosis and relevant known issues

[Ho1ySh1tC0d1ng]

Hi Debezium and Flink CDC community,

We are investigating missing updates in an Oracle CDC pipeline. Source/downstream differences are confirmed, but the root cause is NOT confirmed. We would appreciate diagnostic guidance and pointers to relevant known issues. This question is being cross-posted to Debezium Google Group and Flink CDC Discussions because it spans the embedded connector and Flink recovery boundaries.

Environment

• Oracle 19c RAC.
• Flink 1.20.3, Java 11.
• A customized Flink CDC distribution embedding Debezium Oracle 1.9.8.Final. We recognize that this is an old embedded version and that custom changes may affect applicability of upstream issues.
• LogMiner adapter, in-memory transaction buffer.
• log.mining.strategy=online_catalog
• log.mining.transaction.retention.hours=2
• LOB support is not explicitly enabled; the effective runtime setting still needs verification.
• Downstream: Hologres.

Observed behavior

Some existing records retain old downstream column values. For example, the same primary key ORDER_001 has status 8 in Oracle but status 4 downstream. The row exists on both sides, so matching row counts does not establish correctness.
The connector has replayed historical logs after restarts. A RUNNING job and successful Flink checkpoints have not established data completeness.

Investigation so far

1. Transaction abandonment
   We found logs such as:
   Transaction ... is being abandoned
   Event for abandoned transaction ..., skipped.
   These logs lack sufficient table/business-key information to associate the abandoned transactions with affected records. We are investigating retention during historical replay, but have NOT established a causal link.

2. Rollback warnings
   We also found:
   Cannot undo change ... since event with row-id ... was not found.
   Recent transactions reconstructable from available archive logs ultimately performed full rollbacks. Those samples therefore do not establish loss of committed changes.

3. Synthetic cache test
   Using MemoryTransaction.class extracted from the deployed connector, we tested:
   UPDATE row A before a savepoint
   UPDATE row A after the savepoint
   Apply one undo operation for row A
   The cache removed both buffered updates for row A. This suggests a potential partial-rollback risk, but only exercises the cache method. We have NOT completed an end-to-end connector reproduction or linked this result to affected production records.

Evidence limitations

• Archive logs covering the original problematic changes have already been removed.
• Existing logs lack transaction-to-table/business-key correlation.
• Recent samples do not establish whether the historical failure mechanism is still occurring.
• Business creation/update timestamps do not necessarily identify transaction commit time.

Related references found during investigation — applicability remains unconfirmed

A. Debezium 1.9 documentation says transactions exceeding log.mining.transaction.retention.hours are discarded entirely without emitting their operations:
https://debezium.io/documentation/reference/1.9/connectors/oracle.html#oracle-property-log-mining-transaction-retention-hours
A newer community explanation says retention is based on transaction duration in Oracle, rather than connector ingestion time:
https://groups.google.com/g/debezium/c/vuwnG1ON_7E
We do not assume this newer explanation proves the behavior of our customized 1.9.8 implementation. In particular, replaying logs older than two hours is not by itself proof that retention discarded a transaction. Which timestamps/SCNs and cutoff logic should we inspect in this older version?

B. Partial rollback reports:
debezium/dbz#1914
debezium/dbz#1917
debezium/debezium#7472
In debezium/dbz#1914 the reporter later corrected the initial statement: the reported problem requires lob.enabled=true, even if the table has no LOB column. debezium/dbz#1917 concerns LOB event consolidation across a savepoint. These reports use a much newer implementation, so we are asking about relevance to 1.9.8, not claiming the same bug.

C. Flink recovery/filtering candidate:
https://issues.apache.org/jira/browse/FLINK-40216
This report describes changed ordering of finished snapshot split metadata after restore, potentially causing incremental-framework connectors, including Oracle, to filter out changes for some key ranges. We have NOT established that our distribution uses the affected framework/code path or meets the trigger conditions. Which classes/configuration/state artifacts should we check to establish applicability?

Questions

1. What diagnostics best distinguish transaction abandonment, rollback handling, replay/recovery filtering, and downstream writes or ordering issues?
2. Are there known 1.9.8 Oracle issues matching stale downstream values, particularly during historical replay with nonzero retention? Are there specific later fixes worth testing or backporting?
3. Which loggers or instrumentation points should correlate XID, DML/commit SCN, redo thread, table, ROWID/business key, buffer enqueue/undo/abandon, and dispatch before archive logs expire?
4. Could the older MemoryTransaction undo behavior discard a legitimate pre-savepoint update without LOB support, independently of Non-idempotent partial rollbacks debezium/dbz#1914/Rollback to savepoint discards more then it should when LOBs enabled debezium/dbz#1917? What additional connector-level behavior must our synthetic test include?
5. What minimal end-to-end scenarios would you recommend? We are considering:
   • Existing row status 4; UPDATE to 8; SAVEPOINT; UPDATE to 9; ROLLBACK TO SAVEPOINT; COMMIT. Oracle and downstream should end at 8.
   • Repeat across a mining-session boundary and across checkpoint/restart recovery.
   • In an isolated environment, replay identical retained logs/from the same starting offset with retention=2 versus 0, including short and long source transactions.
   • Capture raw dispatched events, sink input/write acknowledgements, and final source/sink values to locate the first divergence.

We can provide sanitized configuration, logs, transaction event sequences, and isolated test results. We would appreciate guidance on the most useful evidence to collect first.

Thank you!

Cross-post status: the Debezium Google Group thread is now public: https://groups.google.com/g/debezium/c/EB-Z8JIIuD4