When debezium is processing a large batch of diffs all listed under the same scn and debezium shuts down in the middle of it, when it restarts it skips over the rest of the diffs in the batch transaction. lots of discussion reguarding this issue on this thread: https://debezium.zulipchat.com/#narrow/stream/348250-community-oracle/topic/Embedded.20Engine.20Shutdown.20and.20Lost.20Records/near/451023602

Bug report

For bug reports, provide this information, please:

What Debezium connector do you use and what version?

2.7.0 oracle connector
able to reproduce on 3.0.0.CR1 aswell

What is the connector configuration?

running INFINISPAN_EMBEDDED
was also able to reproduce on EHCACHE

What is the captured database version and mode of deployment?

oracle version 19 on premise 

What behavior do you expect?

when debezium starts back up after stopping in the middle of a batch transaction with all diffs having same scn, to restart mining at that scn

What behavior do you see?

debezium is skipping over the rest of the unfinished transaction:

sent a batch with 10,000 inserts and stopped debezium in the middle of it. all have same scn value.

first diff in batch:
commit_scn=484293992:1:0b00150005070000, snapshot_scn=476298986, scn=484293991

last diff sent on stop (5967 of 10,000 in batch, confirmed in destination db)
commit_scn=484293992:1:0b00150005070000, snapshot_scn=476298986, scn=484293991

offset file on stop (scn matches batch):

{"commit_scn":"484293992:1:0b00150005070000","snapshot_scn":"476298986","scn":"484293991"}

startup debezium message:
2048 records sent during previous 00:00:13.575, last recorded offset of {server} partition is {commit_scn=484293996:1:0d001b00a9020000, snapshot_scn=476298986, scn=484293995}

first diff processed on startup (skipped straight to next SCN, leaving the rest of batch dropped):
sourceOffset={commit_scn=484293996:1:0d001b00a9020000, snapshot_scn=476298986, scn=484293995}}

 

I also confirmed debezium never went back for the rest of the missed diffs attached to scn 484293991

Do you see the same behaviour using the latest released Debezium version?

yes, seeing this on 2.7.0-SNAPSHOT

Do you have the connector logs, ideally from start till finish?

(You might be asked later to provide DEBUG/TRACE level log)

<Your answer>

How to reproduce the issue using our tutorial deployment?

<Your answer>

Feature request or enhancement

For feature requests or enhancements, provide this information, please:

Which use case/requirement will be addressed by the proposed feature?

debezium being able to recover after shutdowns

Implementation ideas (optional)

may be similar issue to: https://issues.redhat.com/browse/DBZ-8014