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

Prefer archive logs over redo logs of the same SCN range

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 1.5.0.CR1
    • 1.5.0.Beta1
    • oracle-connector
    • None
    • False
    • False
    • Undefined
    • Hide

      I have not reproduced this issue, it came from reading code. To reproduce, a large log mining batch size, long pause between mining sessions, small redo log file sizes, a busy database and online_catalog could be helpful.

      Show
      I have not reproduced this issue, it came from reading code. To reproduce, a large log mining batch size, long pause between mining sessions, small redo log file sizes, a busy database and online_catalog could be helpful.

    Description

      In LogMinerHelper.java:setRedoLogFilesForMining(), the online redo log files are preferred over archived redo log files. This could cause an issue if a redo log switch occurs to a file that a logminer session is currently processing.

      The Oracle documentation on DBMS_LOGMNR at https://docs.oracle.com/database/121/ARPLS/d_logmnr.htm says:

      If a log switch occurs while LogMiner is reading an online redo log file, the database will overwrite what LogMiner is attempting to read. The data that LogMiner returns if the file it is trying to read gets overwritten by the database is unpredictable.

      Imagine if there are three redo log groups with one file each and

      • redo1.log is CURRENT
      • redo2.log is ACTIVE and not archived
      • redo3.log is INACTIVE and archived as archived3.log

      and the SCN range that shall be processed falls into redo3.log/archived3.log. Currently the LogMiner process is started for redo3.log. But redo3.log may become the CURRENT online redo log and be overwritten while LogMiner is working.

      In this scenario it could be avoided by preferring to work on the archived redo logs if they are available. It would also generally reduce the chances of something similar happening.

      Attachments

        Activity

          People

            ccranfor@redhat.com Chris Cranford
            christiankamm Christian Kamm (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: