What Debezium connector do you use and what version?

2.3, 2.6

What is the connector configuration?

Oracle 

What behaviour do you expect?

When setting a min and max batch size, we expect the batch size never to exceed the maximum

What behaviour do you see?

In the following edge case, the batch size will read from prev_scn up to current_scn regardless of the batch size. Note: `
Max batch size too small, using current SCN 1860859380612 as end SCN.`
```
2024-01-24 21:18:38,005 DEBUG [io.deb.con.ora.log.LogMinerStreamingChangeEventSource] (debezium-oracleconnector-PROD-X-change-event-source-coordinator) Using Top SCN calculation 1860858663640 as end SCN. currentScn 1860859262469, startScn 1860858653640

2024-01-24 21:18:38,031 DEBUG [io.deb.con.ora.log.LogMinerStreamingChangeEventSource] (debezium-oracleconnector-PROD-X-change-event-source-coordinator) Starting mining session startScn=1860858653640, endScn=1860858663640, strategy=ONLINE_CATALOG, continuous=false

2024-01-24 21:18:55,482 DEBUG [io.deb.con.ora.log.LogMinerStreamingChangeEventSource] (debezium-oracleconnector-PROD-X-change-event-source-coordinator) Oracle Session UGA 8.01MB (max = 8.63MB), PGA 12.69MB (max = 197.38MB)

2024-01-24 21:18:55,883 TRACE [io.deb.con.ora.log.LogMinerStreamingChangeEventSourceMetrics] (debezium-oracleconnector-PROD-X-change-event-source-coordinator) Timezone offset of database time is -21600 seconds.

2024-01-24 21:18:55,884 TRACE [io.deb.con.ora.log.LogMinerStreamingChangeEventSourceMetrics] (debezium-oracleconnector-PROD-X-change-event-source-coordinator) Current time 1706131135884 ms, database difference 0 ms

2024-01-24 21:18:55,891 DEBUG [io.deb.con.ora.log.LogMinerStreamingChangeEventSource] (debezium-oracleconnector-PROD-X-change-event-source-coordinator) Max batch size too small, using current SCN 1860859380612 as end SCN.

2024-01-24 21:18:55,926 DEBUG [io.deb.con.ora.log.LogMinerStreamingChangeEventSource] (debezium-oracleconnector-PROD-X-change-event-source-coordinator) Starting mining session startScn=1860858653640, endScn=1860859380612, strategy=ONLINE_CATALOG, continuous=false```

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

yes

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

How to reproduce the issue using our tutorial deployment?

To reproduce:

Collector accumualtes a backlog.

Collector does not find any relevant record in the loginer query (due to inactivity in relevant captured tables). However, database SCN moved forward.

prev_scn == end_scn and the code then set end_scn as current scn. 

This can result in an abnormally large batch size sent unintentionally.

Feature request or enhancement

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

This can be avoided using a heartbeat table that will send a relevant insert record periodically, but still a bug since this use case may happen in busy databases with low relevant activity for captured tables.

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

<Your answer>

Implementation ideas (optional)

<Your answer>