Dupicate SCNs on Oracle RAC installations incorrectly processed

What Debezium connector do you use and what version?

1.9.2.Final

What is the captured database version and mode of depoyment?

Oracle 12C 12.2.0.1

PDB

What behaviour do you see?

When we use a in the production environment, we find that when the source database changes frequently, a small amount of data will be lost every day. When we check the dbz-oracle-connect logs and manually mining from source database. we found that dbz-oracle-connector collected the data but skipped it. 

[2022-06-10 19:18:49,965] DEBUG Transaction 140017003d063703 has already been processed. Offset Commit SCN [18963481848232|tel:18963481848232], Transaction Commit SCN [18963481848232|tel:18963481848232], Last Seen Commit SCN [18963481848232|tel:18963481848232]. (io.debezium.connector.oracle.logminer.processor.AbstractLogMinerEventProcessor:349)

USERNAME                                          SCN                       COMMIT_SCN RS_ID                                 SSN TIMESTAMP            SQL_REDO                                     OPERATION_CODE START_TIMESTAMP                                            COMMIT_TIMESTAMP
-------------------- -------------------------------- -------------------------------- ------------------------------ ---------- -------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------- --------------------------------------------------------- ---------------------------------------------------------
SCHEMA                                18963481848230                   18963481848232  0x001a83.0008e62e.0094                 0 2022-06-10 19:19:03  update "schema"."table" set "BIZ_TIME" = TO_TIMESTAMP('10-JUN-22 07.19.03.931298 PM'), "OP" = 'update', "LOAD_TIME" = TO_TIMESTAMP('10-JUN-22 07.19.03.931298 PM') where "BAZ159" = '123' and "AAC001" = '777' and "AAC002" = '3' and "AAC003" = 'abc' and "AAC058" = '01' and "AAC147" = '33' and "AAB001" = '331' and "BAB010" = '2' and "BIZ_TIME" = TO_TIMESTAMP('10-JUN-22 10.04.33.376251 AM') and "OP" = 'update' and "LOAD_TIME" = TO_TIMESTAMP('10-JUN-22 10.04.33.376251 AM') and ROWID = 'AAAz1VA
                                                                                                                                                      AtAAE3t3AAK';

SCHEMA                                18963481848227                   18963481848232  0x000c73.000856f1.00b0                 0 2022-06-10 19:19:03  update "schema"."table" set "BIZ_TIME" = TO_TIMESTAMP('10-JUN-22 07.19.03.927067 PM'), "OP" = 'update', "LOAD_TIME" = TO_TIMESTAMP('10-JUN-22 07.19.03.927067 PM') where "BAZ159" = '3' and "AAC001" = '3' and "AAC002" = '33' and "AAC003" = 'BCD' and "AAC058" = '01' and "AAC147" = '33' and "AAB001" = '330' and "BAB010" = '5' "BIZ_TIME" = TO_TIMESTAMP('10-JUN-22 04.58.46.935656 PM') and "OP" = 'update' and "LOAD_TIME" = TO_TIMESTAMP('10-JUN-22 04.58.46.935656 PM') and ROWID = 'AAAz1VA
                                                                                                                                                      AuAAC/tYAAh';