-
Bug
-
Resolution: Done
-
Major
-
1.6.0.Final
-
None
-
False
-
False
-
Undefined
-
When trying to setup a fresh connection with a fresh snapshot to Oracle with Debezium 1.6 Final I am facing the issue that the logminer session fails to start. Which makes sense because the log switch did not occur. I was expecting to see the message as added in DBZ-3665 but instead I am getting the following error:
Caused by: Error : 1291, Position : 0, Sql = BEGIN sys.dbms_logmnr.start_logmnr(startScn => '14339560065717', endScn => '14339560087374', OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.NO_ROWID_IN_STMT);END;, OriginalSql = BEGIN sys.dbms_logmnr.start_logmnr(startScn => '14339560065717', endScn => '14339560087374', OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.NO_ROWID_IN_STMT);END;, Error Msg = ORA-01291: missing log file
I have tested with disabling the archive only mode and then it starts fine. Let it run overnight, then enabling archive mode again will fail because the SCN in the offsets is from the time when the snapshot was completed. This SCN is too old for us to resume working from:
[2021-07-05 13:57:36,761] INFO Snapshot ended with SnapshotResult [status=COMPLETED, offset=OracleOffsetContext [scn=14339560015717]] (io.debezium.pipeline.ChangeEventSourceCoordinator:114)
[2021-07-06 06:06:17,988] INFO Found previous offset OracleOffsetContext [scn=14339560015717] (io.debezium.connector.common.BaseSourceTask:316)
Online REDO LOG files or archive log files do not contain the offset scn 14339560015717. Please perform a new snapshot
(Look at the timestamps above to see the time between them)
Here is our config:
{
"name": "group1",
"config": {
"connector.class": "io.debezium.connector.oracle.OracleConnector",
"snapshot.mode": "initial",
"snapshot.locking.mode": "none",
"tasks.max": "1",
"database.server.name": "group1",
"database.url": "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=mydatabase)(PORT=1525))(CONNECT_DATA=(SERVICE_NAME=myservice)))",
"database.dbname": "my_service",
"event.processing.failure.handling.mode": "warn",
"topics": "group1",
"log.mining.sleep.time.min.ms": "1000",
"log.mining.sleep.time.max.ms": "10000",
"log.mining.batch.size.min": "10000",
"log.mining.batch.size.max": "200000",
"log.mining.view.fetch.size": "20000",
"log.mining.sleep.time.default.ms": "1000",
"log.mining.sleep.time.increment.ms": "2000",
"log.mining.archive.log.hours": "5",
"log.mining.archive.log.only.mode": "true",
"log.mining.transaction.retention.hours": "5",
"log.mining.archive.destination.name": "LOG_ARCHIVE_DEST_2",
"log.mining.strategy": "online_catalog",
"decimal.handling.mode": "string",
"tombstones.on.delete": "false",
"poll.interval.ms": "60000",
"database.history.kafka.bootstrap.servers": "kafka-bootstrap.mydomain",
"database.history.kafka.topic": "group1.history",
"database.history.store.only.captured.tables.ddl": "true",
"database.history.skip.unparseable.ddl": "true",
"table.include.list": "mytables"
},
)
It's also worth noting that if I start the snapshot in archive mode only, the snapshot will complete but Debezium considers the initial error (ORA-01291) a soft error, restarts the connector and does the snapshot again. It will end up snapshotting forever. This may be a separate issue but I figured to add here as well. Only with archive only mode off will the snapshot succeed and the streaming start.
