-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
2.6.0.Final
-
None
-
None
-
False
-
None
-
False
-
Important
Bug report
What Debezium connector do you use and what version?
Debezium 2.6.0.Final
Connectors: postgres, oracle, mssql, mysql; all on 2.6.0.Final
What is the connector configuration?
Default configuration across the board
What is the captured database version and mode of depoyment?
Any Oracle, tested with 19
What behaviour do you expect?
Snapshot stage runs without any exceptions in default configuration.
What behaviour do you see?
An exception is thrown multiple times (once per table).
Do you see the same behaviour using the latest relesead Debezium version?
Yes.
Do you have the connector logs, ideally from start till finish?
2024-04-03 15:12:00,230 WARN [pool-9-thread-1] com.mongodb.migrator.application.migration.job.MigrationJobService: Migration job finished with exception oracle.jdbc.OracleDatabaseException: ORA-01737: valid modes: [ROW] SHARE, [[SHARE] ROW] EXCLUSIVE, SHARE UPDATE at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:637) at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:564) at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1151) at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:771) at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:299) at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:498) at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:112) at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:1011) at oracle.jdbc.driver.OracleStatement.executeSQLStatement(OracleStatement.java:1531) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1311) at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:2163) at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:2118) at oracle.jdbc.driver.OracleStatementWrapper.execute(OracleStatementWrapper.java:328) at io.debezium.connector.oracle.OracleSnapshotChangeEventSource.lockTablesForSchemaSnapshot(OracleSnapshotChangeEventSource.java:106) at io.debezium.relational.RelationalSnapshotChangeEventSource.doExecute(RelationalSnapshotChangeEventSource.java:147) at io.debezium.pipeline.source.AbstractSnapshotChangeEventSource.execute(AbstractSnapshotChangeEventSource.java:94) at io.debezium.pipeline.ChangeEventSourceCoordinator.doSnapshot(ChangeEventSourceCoordinator.java:253) at io.debezium.pipeline.ChangeEventSourceCoordinator.doSnapshot(ChangeEventSourceCoordinator.java:237) at io.debezium.pipeline.ChangeEventSourceCoordinator.executeChangeEventSources(ChangeEventSourceCoordinator.java:189) at io.debezium.pipeline.ChangeEventSourceCoordinator.lambda$start$0(ChangeEventSourceCoordinator.java:140) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829)
How to reproduce the issue using our tutorial deployment?
- Have multiple connectors on CLASSPATH
- Start snapshot job for Oracle database
- Observe the log messages
Implementation ideas (optional)
Currently there are two services with the same name registered for SnapshotLock class - io.debezium.connector.postgresql.snapshot.lock.SharedSnapshotLock and io.debezium.connector.oracle.snapshot.lock.SharedSnapshotLock. I assume this is causing the use of the PostgreSQL-specific SQL statement for Oracle database:
Should use
LOCK TABLE %s IN ROW SHARE MODE
But instead uses
LOCK TABLE %s IN ACCESS SHARE MODE
Which is not recognized by Oracle.
The easy fix would be to rename the locking mechanisms to be different for the different connectors (e.g. ROW_SHARED and ACCESS_SHARE for Oracle and Postgres correspondingly).
- duplicates
-
-
- Closed
-
