Oracle Debezium connector not progressing when offset SCN is no longer in online redo logs

Sri Rezeki

unread,

Mar 24, 2026, 11:08:49 AM (8 days ago) Mar 24

to debezium

Hi

We have an Oracle Debezium connector that is stuck trying to resume from:
offsetScn=17769326489
But the oldest SCN available in online redo logs is: oldestScn=17769326490

So the connector is 1 SCN behind the earliest online redo log.

It is possible the required SCN still exists in archived redo logs on disk.

We added:"config.action.reload": "none" which stopped repeated stop/start cycles, but the connector still does not make progress and we do not see commit messages.

We also tried:
"log.mining.archive.log.only.mode": "false",
"log.mining.archive.log.hours": "72",
"archive.destination.name": "LOG_ARCHIVE_DEST_1"

but this did not help.

Current relevant debezium settings:

{
"connector.class": "io.debezium.connector.oracle.OracleConnector",
"snapshot.mode": "no_data",
"log.mining.strategy": "online_catalog",
"log.mining.archive.log.only.mode": "false",
"log.mining.archive.log.hours": "72",
"archive.destination.name": "LOG_ARCHIVE_DEST_1",
"config.action.reload": "none",
"lob.enabled": "true",
"data.query.mode": "function",
"max.iteration.transactions": "1000",
"log.mining.query.filter.mode": "in",
"tasks.max": "1"
}

Our questions are:
- If the offset SCN is no longer in online redo logs but still exists in archive logs, should Debezium automatically recover from archive logs?
- Does the absence of commit messages indicate Debezium is not actually mining archive logs?
- Is online_catalog a likely reason this is not recovering?
- Should we move to redo_log_catalog to recover from this situation?
- If the SCN is no longer available anywhere, is offset reset / re-snapshot the only option?

Any guidance on expected behaviour and recommended recovery would be appreciated.

Thanks
Sri

Chris Cranford

unread,

Mar 24, 2026, 11:14:53 AM (8 days ago) Mar 24

to debe...@googlegroups.com

Hi -

When the SCN no longer exists in the archive logs, you could restore the archive logs that have the SCN if the DBA has a backup. If that isn't an option, you can either set `snapshot.mode` to `when_needed`, and let the connector re-capture all historical data from your captured tables in Oracle, or remove the offsets and history topic and restart the connector so it starts like it was freshly deployed.
Well, in your current state, there would be no messages because the connector is incapable of starting due to offset position validation failures.
No, this has nothing to do with mining strategy but the fact your archive logs that have that SCN no longer are on the system.
No, this won't change anything, see my answer to (3).
See my answer to (1)

Hope that helps.
-cc

Sri --
You received this message because you are subscribed to the Google Groups "debezium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debezium+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/debezium/2363055e-9c63-4e65-a4a7-10b412efb0b5n%40googlegroups.com.

Sri Rezeki

unread,

Mar 24, 2026, 10:02:20 PM (8 days ago) Mar 24

to debezium

Hi Chris

Thanks for your response.

You mis-understood. The required SCN still exists in archived redo logs but the connector just did not read it.

Any guidance on expected behaviour and recommended recovery would be appreciated.

Cheers
Sri

Chris Cranford

unread,

Mar 24, 2026, 10:32:53 PM (8 days ago) Mar 24

to debe...@googlegroups.com

Hi,

My apologies, I saw "oldest SCN available in" and overlooked "online redo logs", sorry for that.
Which Debezium version are you currently using?

-cc

To view this discussion visit https://groups.google.com/d/msgid/debezium/94bc8d2e-ceaf-47d0-9482-d9bb2b933132n%40googlegroups.com.

Sri Rezeki

unread,

Mar 24, 2026, 10:57:49 PM (8 days ago) Mar 24

to debe...@googlegroups.com

Thanks Chris.

We use Debezium Oracle plugin: 3.4.0.

Regards

Sri

From: debe...@googlegroups.com <debe...@googlegroups.com> On Behalf Of Chris Cranford
Sent: Wednesday, 25 March 2026 3:33 pm
To: debe...@googlegroups.com
Subject: Re: [debezium] Oracle Debezium connector not progressing when offset SCN is no longer in online redo logs

Hi, My apologies, I saw "oldest SCN available in" and overlooked "online redo logs", sorry for that. Which Debezium version are you currently using? -cc On 3/24/26 10: 02 PM, 'Sri Rezeki' via debezium wrote: Hi Chris Thanks for your response.

ZjQcmQRYFpfptBannerStart

This email is from an external sender

Do not open attachments or click links unless you recognise the sender, and know that the content is safe

Report Suspicious ‌

ZjQcmQRYFpfptBannerEnd

"archive.destination.name [archive.destination.name]": "LOG_ARCHIVE_DEST_1"

but this did not help.

Current relevant debezium settings:

{
"connector.class": "io.debezium.connector.oracle.OracleConnector",
"snapshot.mode": "no_data",
"log.mining.strategy": "online_catalog",
"log.mining.archive.log.only.mode": "false",
"log.mining.archive.log.hours": "72",

"archive.destination.name [archive.destination.name]": "LOG_ARCHIVE_DEST_1",

"config.action.reload": "none",
"lob.enabled": "true",
"data.query.mode": "function",
"max.iteration.transactions": "1000",
"log.mining.query.filter.mode": "in",
"tasks.max": "1"
}

Our questions are:
- If the offset SCN is no longer in online redo logs but still exists in archive logs, should Debezium automatically recover from archive logs?
- Does the absence of commit messages indicate Debezium is not actually mining archive logs?
- Is online_catalog a likely reason this is not recovering?
- Should we move to redo_log_catalog to recover from this situation?
- If the SCN is no longer available anywhere, is offset reset / re-snapshot the only option?

Any guidance on expected behaviour and recommended recovery would be appreciated.

Thanks

Sri --
You received this message because you are subscribed to the Google Groups "debezium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debezium+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/debezium/2363055e-9c63-4e65-a4a7-10b412efb0b5n%40googlegroups.com [groups.google.com].

--
You received this message because you are subscribed to the Google Groups "debezium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debezium+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/debezium/94bc8d2e-ceaf-47d0-9482-d9bb2b933132n%40googlegroups.com [groups.google.com].

--
You received this message because you are subscribed to a topic in the Google Groups "debezium" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/debezium/j6wpqDQha58/unsubscribe [groups.google.com].
To unsubscribe from this group and all its topics, send an email to debezium+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/debezium/69ba73b8-aa16-431c-9b1f-7307e6f18c6b%40gmail.com [groups.google.com].

This message has been sent from Foodstuffs North Island Limited

The information contained in this email is intended only for the person or entity to which it is addressed. If you received this message in error, please contact the sender immediately by return email and delete this message and your reply. If you received this message in error you are prohibited from using any information in this email in any other way.

Chris Cranford

unread,

Mar 31, 2026, 3:01:22 AM (yesterday) Mar 31

to debe...@googlegroups.com

Hi -

What you are observing is a regression from this issue [1]. This was later fixed in #dbz#1560 [2]. Please update to Debezium 3.4.3.Final.

[1]: https://github.com/debezium/dbz/issues/1435
[2]: https://github.com/debezium/dbz/issues/1560

To view this discussion visit https://groups.google.com/d/msgid/debezium/SY0P300MB0742A3475705CA7F134DBA13AD49A%40SY0P300MB0742.AUSP300.PROD.OUTLOOK.COM.

Reply all

Reply to author

Forward