archivelog can't be read

[Johann Brandl]

I’m having an issue with a new Oracle database. It is the first multitenant database we are connecting to Debezium. Everything works fine as long as we are dealing with online redo logs. However, occasionally we need to access archived redo logs, and that’s when I get the following error messages in the log:

INFO  [io.deb.con.ora.log.LogFileCollector] (debezium-oracleconnector-oarc-change-event-source-coordinator) Redo Thread 1 is inconsistent; an archive log with sequence 154251 is not available

I suspect this is due to the multitenant configuration, though I’m not entirely sure. I first checked whether the file was still available and accessible. I executed the following statements as the Debezium user, and they ran without issues:

ALTER SESSION SET CONTAINER = CDB$ROOT;
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => '/dbarch1/DEZA08C1/1_154251_1209261737.dbf', OPTIONS => DBMS_LOGMNR.NEW);

I suspect that the following parameters might be causing problems when reading the archived redo logs:

source.database.dbname=ZA08.WORLD
source.database.pdb.name=trarch
source.database.connection.adapter=logminer
source.log.mining.strategy=hybrid

I assume it has something to do with CDB$ROOT, preventing me from reading the log file.

Does anyone have any tips?

Many thanks in advance.

[Chris Cranford]

Hi Johann -

This specific message is nothing to be concerned about on it's face, and it is very normal in Oracle. 

When any online redo log reaches full capacity or a DBA forces a log switch, this triggers the redo log to be archived by the ARC process. This is an asynchronous step, and depending on the number of ARC processes available at the time, the size of the redo log, and the current IO load on the database, this can happen instantly or it can take several seconds before the archive log is copied and an entry registered in V$ARCHIVED_LOG by the ARC process.

The reason this log message surfaces is when a connector detects the log switch has happened, but the ARC process has not yet registered the entry in V$ARCHIVED_LOG, which is the last step it performs. If the log lookup query fires during this window, this message is written indicating that the connector was unable to find a list of logs that have no gaps, because a log metadata entry is missing in the Oracle tables, thus Redo Thread 1 is inconsistent. 

In practice, this typically resolves itself on the next query or two, depending on the speed of the ARC process. The connector defines an internal property, internal.log.mining.log.query.max.retries, and it defaults to 5. This is used to control how many retries the connector executes before it gives up on a Redo Thread when its inconsistent. You can always increase this value more than 5 if you find your system is over-saturated and the ARC process is slower more often than not, leading to too many manual connector restarts.

But as the message is at INFO level, this is entirely normal, expected, and nothing to generally be concerned about.

Hope that helps.
-cc

Many thanks in advance. --
You received this message because you are subscribed to the Google Groups "debezium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debezium+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/debezium/6975ad8b-e5d6-4c0c-8623-1f935a577e95n%40googlegroups.com.

[Johann Brandl]

Hi Chris,

i just wanted to drop a quick note to say a huge thank you for your help. 

You’re always so supportive and your technical expertise is outstanding. 

I really appreciate you taking the time to help me out!  

Now i understand how debezium handles the archived log files and my concerns are put to rest.

Best regards