Bug Report: Oracle connector crashes on redo entry without SQL_REDO for temporary tables

 

 

---

 

 

What Debezium connector do you use and what version?

 

• Connector: io.debezium.connector.oracle.OracleConnector

• Adapter: LogMiner

• Debezium version:3.1.1.Final 

 

 

---

 

What is the connector configuration?

 

Rendered Helm values (simplified for clarity, with secrets redacted):

database.connection.adapter: logminer
log.mining.strategy: redo_log_catalog
table.include.list: [ ... <real production tables> ... ]
snapshot.mode: initial
include.schema.changes: false
tombstones.on.delete: true
emit.old.row: false
heartbeat.interval.ms: 10000
schema.history.internal.kafka.topic: TDP.<ENV>.<APP>.schema-changes
key.converter: org.apache.kafka.connect.json.JsonConverter
value.converter: org.apache.kafka.connect.json.JsonConverter

 

Note: No temporary tables are included in table.include.list.

 

---

 

What is the captured database version and mode of deployment?

 

• Oracle: 19c (19.15)

• Mode: On-premises, connector running in Kubernetes as a KafkaConnector (Strimzi Operator)

 

---

 

What behavior do you expect?

 

Debezium should:

 

• Gracefully skip or ignore redo log entries that contain no SQL_REDO, such as those involving temporary tables.

• Continue processing remaining change events.

• Log a warning instead of crashing the connector task.

 

 

---

 

 

What behavior do you see?

 

 

When any DML is performed on a temporary table in Oracle, the redo log contains the message:

 

/* No SQL_REDO for temporary tables */

Debezium encounters this during log mining and throws the following error:

 

io.debezium.connector.oracle.logminer.parser.DmlParserException: DML statement couldn't be parsed. Please open a Jira issue with the statement '/* No SQL_REDO for temporary tables */'

Stack trace excerpt:

 

{{at LogMinerDmlParser.parse(LogMinerDmlParser.java:87)
at AbstractLogMinerEventProcessor.parseDmlStatement(AbstractLogMinerEventProcessor.java:1686)}}

➡️ This causes an unrecoverable failure of the connector task. It will not restart unless triggered manually or externally.

 

---

 

 

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

 

 

 Yes — issue verified in:

 

• 3.1.1.Final{}

 

 

---

 

 

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

 

 

Yes. Here’s the critical excerpt:

 

{{DmlParserException: DML statement couldn't be parsed. Please open a Jira issue with the statement '/* No SQL_REDO for temporary tables */'
Task is being killed and will not recover until manually restarted}}

Full logs available upon request.

 

---

 

 

How to reproduce the issue using our tutorial deployment?

 

 

1. Set up an Oracle 19c instance with a Debezium LogMiner connector.

1. In any session, run:

 

 

{{CREATE GLOBAL TEMPORARY TABLE temp_test (id NUMBER);
INSERT INTO temp_test VALUES (1);}}

 

1. Wait for LogMiner to reach this DML entry.

1. The connector crashes with DmlParserException due to the missing SQL_REDO.

 

 

---

 

 

Why this matters

 

 

This error can be triggered by any session in the Oracle DB — even those unrelated to CDC. In shared or production environments, temporary table DML (by apps, ETL, monitoring tools) is common and not preventable at the connector level.

 

---

 

 

Expected Fix / Proposal

 

 

Debezium should:

 

• Detect and gracefully skip redo entries with the known string /* No SQL_REDO for temporary tables */

• Optionally support a config like:

 

 

"oracle.logminer.skip.unparseable.sqlredo": true

 

• Still log a warning and optionally emit a heartbeat event

• Avoid crashing the connector

 

 

---

 

This would improve reliability in mixed-use Oracle environments and reduce false negatives in production CDC pipelines.

 

---