Details
-
Bug
-
Resolution: Done
-
Major
-
2.0.0.Final
-
None
-
False
-
None
-
False
Description
Bug report
What Debezium connector do you use and what version?
Connector: io.debezium.connector.oracle.OracleConnector
Version: 2.0.0Final
What is the connector configuration?
snapshot.locking.mode=shared connector.class=io.debezium.connector.oracle.OracleConnector consumer.session.timeout.ms=60000 max.queue.size=16192 rac.nodes=dbnode-1.our.company.local:1521,dbnode-2.our.company.local:1521 tasks.max=1 consumer.max.poll.interval.ms=90000 log.mining.strategy=redo_log_catalog schema.history.internal.store.only.captured.tables.ddl=true topic.prefix=datahub decimal.handling.mode=double schema.history.internal.kafka.topic=schema-changes.lus oracle.jdbc.useFetchSizeWithLongColumn=true signal.data.collection=PROME.FBILOGMINER.DBZ_SIGNALS lob.enabled=false snapshot.fetch.size=5000 database.user=fbilogminer database.dbname=PROME log.mining.batch.size.max=250000 database.connection.adapter=logminer database.url=jdbc:oracle:thin:@dbnode.our.company.local:1521/PROME.our.company.LOCAL time.precision.mode=connect database.server.name=PROME schema.history.internal.kafka.bootstrap.servers=kafka:9092 heartbeat.interval.ms=10000 schema.history.internal.skip.unparseable.ddl=true database.password=*********** log.mining.batch.size.default=50000 max.batch.size=2048 table.include.list=FBILOGMINER.DBZ_SIGNALS,LUS.ARTIKELSTAMM,LUS.PRODLINIE,... and +100 more tables snapshot.mode=initial
What is the captured database version and mode of depoyment?
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
On-Premise, RAC with two nodes
What behaviour do you expect?
Debezium should be able to undo changes without throwing warnings.
What behaviour do you see?
The adapter is sporadically throwing warnings like these:
Cannot undo change 'LogMinerEventRow{scn=13105258959661, tableId='PROME.LUS.ARTIKELSTAMM', tableName='ARTIKELSTAMM', tablespaceName='LUS', eventType=UPDATE, changeTime=2022-12-07T12:34:19Z, transactionId='83000700e7d20400', operation='UPDATE', userName='JOHNDOE', rowId='AAAXgpAAMAAICJIAAE', rollbackFlag=true, rsId= 0x014446.0000a09b.0054 , ssn=0, redoSql='update "LUS"."ARTIKELSTAMM" set "PMARTBEZ" = NULL, "GEAENDERT_AM" = TO_TIMESTAMP('2022-12-07 12:34:16.099607'), "REVISION" = '12';'}' since event with row-id AAAXgpAAMAAICJIAAE was not found. [io.debezium.connector.oracle.logminer.processor.memory.MemoryLogMinerEventProcessor]
We checked the SCN given in the warning with the following statement:
SELECT * FROM GV$ARCHIVED_LOG WHERE FIRST_CHANGE# <= 13105258959661AND NEXT_CHANGE# > 13105258959661;
The query returns archive logilfes what shows that the transaction bound to the SCN is still available in our logs:
+ORA_12_FRA/PROME/ARCHIVELOG/2022_12_07/thread_1_seq_83014.868.1122817775 +ORA_12_FRA/PROME/ARCHIVELOG/2022_12_07/thread_2_seq_80502.753.1122817995 +ORA_12_FRA/PROME/ARCHIVELOG/2022_12_07/thread_1_seq_83014.868.1122817775 +ORA_12_FRA/PROME/ARCHIVELOG/2022_12_07/thread_2_seq_80502.753.1122817995
Do you see the same behaviour using the latest relesead Debezium version?
We are using 2.0.0Final.
Do you have the connector logs, ideally from start till finish?
Logs can be provided on request.
How to reproduce the issue using our tutorial deployment?
Actually I'm unable to reproduce the error, because this is our prod environment. But in Debeziums Tulip's chat the user Tomoya Deng provided steps to reproduce it:
You can reporduce the case with these steps:
insert row1 with value= A
Begin a transaction
update row1 with value=B
savepoint a
update row1 with value=C
rollback to savepoint a
commit
The quote is from this thread: https://debezium.zulipchat.com/#narrow/stream/302529-users/topic/.E2.9C.94.20Cannot.20undo.20change
(Where I also was asked by vjuranek@redhat.com to create this issue.)
