Does all Oracle Threads MUST BE PUBLIC in RAC Cluster to ensure all redo log / archived log can be read?

[Min-Jen Chang]

Hi Debezium Community,

We had problem for Oracle CDC.

We created CDC environment on Oracle RAC Cluster (with 2 instances).

When it just started, it worked normally, but after hours, connector always reported messages like below:

INFO Redo Thread 1 is inconsistent; expected archive log with range just before scn 19818505320085.

Caused by: io.debezium.connector.oracle.logminer.LogFileNotFoundException: None of the log files contain offset SCN: 19818505320085, re-snapshot is required.
 

But we checked that SCN, we beleived it still in redo log files or archived log files.

We noticed that this message:

Redo thread 2 is marked private, excluded.

We read comments on source code (OracleConnection.java):

// Redo threads that are marked PRIVATE are used solely for instance recovery, and

// therefore should be ignored by Debezium.

For our Oracle RAC Cluster, 1 thread is PUBLIC, another is PRIVATE.

Does this is root cause why our CDC always become inconsistent?

How Debezium handle PRIVATE thread?

Does all threads in Oracle RAC Cluster MUST BE PUBLIC to ensure Oracle CDC work nomally?

Thanks.

Min-Jen Chang

[Chris Cranford]

Hi -

Did the DBA convert a thread that was previously PUBLIC to be PRIVATE? 
If so, this was recently raised in the GH issue tracker, and you can see my response here [2]. 

The TL;DR is that its nearly impossible for any external CDC tool to fully exclude private redo threads when a DBA mixes the same thread across two visibility settings. Oracle only ever provides the current visibility of the thread and not its historical behavior to understand what break points are PUBLIC vs PRIVATE. So your DBA team should avoid reusing the same thread for such purposes.

[1]: https://github.com/debezium/dbz/issues/2049#issuecomment-4666003605

--
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/07e26cec-d8ac-4cd4-a9cc-9abedcbf3eecn%40googlegroups.com.

[Min-Jen Chang]

Hi, Chris,

Thanks for your reply.

We confirmed with DBA, DBA did not sure why 2 threads would be 1 PUBLIC and 1 PRIVATE, DBA did not change this setting, but DBA was sure that 2 instances were bound to specific thread, that is, instance 1 bound to thread 1 (PUBLIC), instance 2 bound to thread 2 (PRIVATE).

Does this settings still not workable for Debezium?

Does it means we must ask DBA changes thread 2 to PUBLIC to let Debezium work?

And for another situation we noticed, source connector's SCN stuck on the same number for long time, even we set log.mining.transaction.retention.ms: 3600000, then it finally failed since archived log files were purged. Did this situation was caused by our thread setting, too?

Thank you.

Min-Jen Chang

Chris Cranford 在 2026年6月18日 星期四下午1:31:15 [UTC+8] 的信中寫道：

[Chris Cranford]

Hi -

I'm afraid the exclusion of PRIVATE threads is only a "half-solution" in the current code. We exclude private threads in the redo thread metadata to avoid validating those threads, but as the reporter mentioned, we still enqueue those logs as part of the LogMiner log list for mining. So this could be leading to some inconsistency that creates the issue you see.

The only solution I see that might work would be to exclude PRIVATE threads across the spectrum, but the open question is whether LogMiner will be happy with that setup across all mining strategies. Some are more strict than others, and aren't as willing to mine with gaps across redo threads, regardless of their visibility status. Otherwise, we may need to always mine them, but them do the thread exclusion when we process events. Given that the thread is private, there should never be any transaction that crosses thread boundaries where the visibility differs, so that may be the safest option, but all this requires a code change.

I've reopened dbz#2049 [1], as I do think we can at least satisfy this aspect of the issue. We'd likely need a way to identify when a thread shifts visibility state in the logs, but that should be easily tracked and logged, just so that for the mix case, with logs, it can be tracked.

Would that at least help in your case Min-Jen?

-cc

[1]: https://github.com/debezium/dbz/issues/2049#issuecomment-4741502904 

To view this discussion visit https://groups.google.com/d/msgid/debezium/452632b9-999f-432a-ac92-1b72c3b64841n%40googlegroups.com.