Details
-
Bug
-
Resolution: Done
-
Critical
-
2.0.0.Alpha3
-
None
-
False
-
None
-
False
-
- Run multiple data generator to insert data (commit in batch or commit single)
- Run multiple debezium oracle connector on RAC mode
Description
What Debezium connector do you use and what version?
2.0.0.Alpha3
What is the captured database version and mode of depoyment?
Oracle 19
PDB
What behaviour do you expect?
No missing transaction
What behaviour do you see?
Transaction 7D001200A36D0000 proceeded
Transaction 17000A001A7B0600 has been skipped due to duplicate SCNs on Thread 2.
SCN,START_SCN,COMMIT_SCN,TIMESTAMP,START_TIMESTAMP,COMMIT_TIMESTAMP,XIDUSN,XIDSLT,XIDSQN,XID,PXIDUSN,PXIDSLT,PXIDSQN,PXID,TX_NAME,OPERATION,OPERATION_CODE,ROLLBACK,SEG_OWNER,SEG_NAME,TABLE_NAME,SEG_TYPE,SEG_TYPE_NAME,TABLE_SPACE,ROW_ID,USERNAME,OS_USERNAME,MACHINE_NAME,AUDIT_SESSIONID,SESSION#,SERIAL#,SESSION_INFO,THREAD#,SEQUENCE#,RBASQN,RBABLK,RBABYTE,UBAFIL,UBABLK,UBAREC,UBASQN,ABS_FILE#,REL_FILE#,DATA_BLK#,DATA_OBJ#,DATA_OBJV#,DATA_OBJD#,SQL_REDO,SQL_UNDO,RS_ID,SSN,CSF,INFO,STATUS,REDO_VALUE,UNDO_VALUE,SAFE_RESUME_SCN,CSCN,OBJECT_ID,EDITION_NAME,CLIENT_ID,SRC_CON_NAME,SRC_CON_ID,SRC_CON_UID,SRC_CON_DBID,SRC_CON_GUID,CON_ID "3,307,587,376","3,307,586,951","3,307,587,376",2022-07-22 04:22:15.000,2022-07-22 04:22:14.000,2022-07-22 04:22:15.000,125,18,"28,067",7D001200A36D0000,125,18,"28,067",7D001200A36D0000,[NULL],COMMIT,7,0,[NULL],[NULL],[NULL],0,[NULL],[NULL],AAAAAAAAAAAAAAAAAA,AVENGERSDEVGTPPICKING,liquibase,gen-data-picking,"34,580,665","3,105","64,414",login_username=AVENGERSDEVGTPPICKING client_info= OS_username=liquibase Machine_name=gen-data-picking OS_terminal=gen-data-picking OS_process_id=1 OS_program_name=datagen,2,1,"3,555","1,793,347",468,"1,131",0,0,0,4,0,0,0,0,0,commit;,[NULL], 0x000de3.001b5d43.01d4 ,0,0,[NULL],0,"2,624,496","2,624,497","3,307,577,278","3,307,587,376",[NULL],[NULL],[NULL],DB,0,0,0,[NULL],0 "3,307,587,376","3,307,586,805","3,307,587,376",2022-07-22 04:22:15.000,2022-07-22 04:22:14.000,2022-07-22 04:22:15.000,23,10,"424,730",17000A001A7B0600,23,10,"424,730",17000A001A7B0600,[NULL],COMMIT,7,0,[NULL],[NULL],[NULL],0,[NULL],[NULL],AAAAAAAAAAAAAAAAAA,AVENGERSDEVGTPPICKING,liquibase,gen-data-picking,"34,580,664",930,"37,587",login_username=AVENGERSDEVGTPPICKING client_info= OS_username=liquibase Machine_name=gen-data-picking OS_terminal=gen-data-picking OS_process_id=1 OS_program_name=datagen,2,1,"3,555","1,793,348",156,"1,131",0,0,0,4,0,0,0,0,0,commit;,[NULL], 0x000de3.001b5d44.009c ,0,0,[NULL],0,"2,624,498","2,624,499","3,307,577,278","3,307,587,376",[NULL],[NULL],[NULL],DB,0,0,0,[NULL],0
Do you see the same behaviour using the latest relesead Debezium version?
Yes
Implementation ideas (optional)
After some researches about SCN not increase in Oracle. I found these links:
https://asktom.oracle.com/pls/apex/f?p=100:11:::::P11_QUESTION_ID:9541604100346416882
https://fritshoogland.wordpress.com/2016/10/22/transactions-and-scns/
They said:
The changes itself do just read and pick the current global SCN from the instance, a commit of these changes does increase the global SCN, but as little as possible. You might find multiple changes in the same SCN, and you might even find commits with the same SCNs.
=> Use recentCommittedTxCache to check processed transaction condition (currently use commit_scn)