Uploaded image for project: 'Debezium'
  1. Debezium
  2. DBZ-5245

Dupicate SCNs on Oracle RAC installations incorrectly processed

XMLWordPrintable

      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';

       

            ccranfor@redhat.com Chris Cranford
            wangbangming1992 bangming wang (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: