In order to make your issue reports as actionable as possible, please provide the following information, depending on the issue type.

Bug report

For bug reports, provide this information, please:

What Debezium connector do you use and what version?

Debezium Server's Oracle Connector (2.5.0.Final)

What is the connector configuration?

debezium.sink.type=pubsub
debezium.sink.pubsub.project.id=bee-data-ingestion
debezium.sink.pubsub.ordering.enabled=false

debezium.source.connector.class=io.debezium.connector.oracle.OracleConnector
debezium.source.snapshot.mode=schema_only
debezium.source.topic.prefix=oracle-wms-ingestion
debezium.source.tombstones.on.delete=false

debezium.source.log.mining.strategy=online_catalog
debezium.source.log.mining.batch.size.min=50000
debezium.source.log.mining.batch.size.max=500000
debezium.source.log.mining.sleep.time.default.ms=600
debezium.source.log.mining.transaction.retention.ms=259200000
debezium.source.query.fetch.size=50000

debezium.source.offset.storage=io.debezium.storage.redis.offset.RedisOffsetBackingStore
debezium.source.offset.storage.redis.address=wl-data-integration-npf-redis.metaplane.cloud:6379
debezium.source.offset.storage.redis.password=${REDIS_PASSWORD}
debezium.source.offset.storage.redis.key=database-ingestion:oracle-wms-cdc:debezium-server:offset
debezium.source.offset.flush.interval.ms=30000

debezium.source.schema.history.internal.store.only.captured.tables.ddl=true
debezium.source.schema.history.internal=io.debezium.storage.redis.history.RedisSchemaHistory
debezium.source.schema.history.internal.redis.address=wl-data-integration-npf-redis.metaplane.cloud:6379
debezium.source.schema.history.internal.redis.password=${REDIS_PASSWORD}
debezium.source.schema.history.internal.redis.key=database-ingestion:oracle-wms-cdc:debezium-server:schema_history

debezium.source.decimal.handling.mode=string
debezium.source.key.converter.schemas.enable=false
debezium.source.value.converter.schemas.enable=false

debezium.transforms.Reroute.type=io.debezium.transforms.ByLogicalTableRouter
debezium.transforms.Reroute.topic.regex=.*
debezium.transforms.Reroute.topic.replacement=oracle-wms-ingestion
debezium.transforms=Reroute

quarkus.http.port=8080
quarkus.log.level=DEBUG

debezium.source.database.hostname=dbwmspr-scan.b2w
debezium.source.database.port=1521
debezium.source.database.dbname=SRV_OGG_WMS
debezium.source.table.include.list=# (list of 95 tables) 

What is the captured database version and mode of depoyment?

(E.g. on-premises, with a specific cloud provider, etc.)

Oracle RAC 19c (19.21)

What behaviour do you expect?

When the offset contains a SCN value that is available in the archived logs (that is, in a file not yet deleted from the current primary instance), the connector should be able to locate it and start a mining session from that point.

What behaviour do you see?

The connector seems to fail on locating the offset SCN on different occasions, including but necessarily limited to:

• database switchovers
• database upgrades
• when new threads are created (with existent ones being replaced or not)

Then it will shutdown with error `None of log files contains offset SCN: ***, re-snapshot is required.`

After database switchovers and threads creation, I've been able to bypass the error by manually replacing the offset's SCN with a more recent one (produced after the log changing event).

However, recently, after one of our source databases was upgraded from 11g to 19c, we were unable to recover the connector. No SCN replacement nor a complete offset reset could help it from failing with the "None of log files contains offset SCN" error.

Only by downgrading from 2.5.0.Final to 2.4.0.Final, the connector succeeded on mining logs from the same SCN it failed before.

Since a similar issue was treated on DBZ-7158, it seems it was only partially fixed on 2.4.1/2.5.0. Although, in the latest version, the connector works properly on ideal conditions, any log change or reset seems to trigger the issue again.

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

(Ideally, also verify with latest Alpha/Beta/CR version)

Yes, happening on 2.5.0.Final.

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

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

Yes, please find it attached as "wms_debug_logs_2.5.0.Final_fail.txt".

The logs from a sucessful run with the same context/offset, on version 2.4.0.Final, were also provided as "wms_debug_logs_2.4.0.Final_success.txt".