Logminer Errors

[Carlos Fernando Villacorta Padilla]

Hi,

I'm noticing errors and I'm kinda new in Oracle.

After a few days of letting the connector run, it stops with the following error.

Any idea why this might happen?

Can this be prevented when using the LogMiner mode?

    at io.debezium.connector.oracle.logminer.LogMinerStreamingChangeEventSource.execute(LogMinerStreamingChangeEventSource.java:173)
    ... 7 more
Caused by: Error : 16014, Position : 0,
    Sql = BEGIN DBMS_LOGMNR_D.BUILD (options => DBMS_LOGMNR_D.STORE_IN_REDO_LOGS); END;,
    OriginalSql = BEGIN DBMS_LOGMNR_D.BUILD (options => DBMS_LOGMNR_D.STORE_IN_REDO_LOGS); END;,
    Error Msg = ORA-16014: log 35 sequence# 9968 not archived, no available destinations
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 8103
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 4698
ORA-00312: online log 35 thread 2: '+LOG01/LEIF2TST/ONLINELOG/group_35.348.1043723651'
ORA-00312: online log 35 thread 2: '+LOG02/LEIF2TST/ONLINELOG/group_35.350.1043723653'
ORA-06512: at "SYS.DBMS_SQL", line 1721
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 1576
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 4640
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 7958
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 8117
ORA-06512: at "SYS.DBMS_LOGMNR_INTERNAL", line 8273
ORA-06512: at "SYS.DBMS_LOGMNR_D", line 61
ORA-06512: at line 1

Best,

Carlos

[Chris Cranford]

Hi Carlos -

This error typically indicates that the archive destination directories may not be configured correctly. 

Can you verify that the locations configured with "LOG_ARCHIVE_DEST_n" (where n = 1, 2, 3, ...31) are configured correctly? 
You can check this by running "SHOW PARAMETER LOG_ARCHIVE_DEST_n".

Chris

--
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 on the web visit https://groups.google.com/d/msgid/debezium/cfb101e8-ced1-4e01-bb91-3cfee765ba3an%40googlegroups.com.

[Carlos Fernando Villacorta Padilla]

I ran the command and I noticed that file doesn't exist anymore 🤔

There are certain operations in the database that I'm not aware of :/ it seems to be a heavy rotation of log files.

[Chris Cranford]

When you say heavy rotation of logs, do you mean the redo logs or archive log generation?

[Gunnar Morling]

Would be worth trying Debezium 1.5.0.Beta1 here (released yesterday, https://debezium.io/blog/2021/02/24/debezium-1-5-beta1-released/); there has been a number of fixes and improvements to the LogMiner-based connector.

--Gunnar

[Dmitry Buzz]

Hi All,

I see this issue with 2.0.0. Are there any explanation and workaround? Our DBA tried: ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH;

But this didn't help. Thanks!

[Chris Cranford]

Hi Dmitry -

So generally speaking ORA-16014 means that there is a problem with the archive log destination and the Oracle ARC process is unable to archive the log.  If this happens for an extended period of time, this can lead to Oracle completely becoming locked up and not allowing any user actions because there won't be any free redo log space available to capture the changes for recovery in case of a database crash.  In laymen terms, this is generally a critical error your DBA should be trying to solve so that your database isn't unstable and so that the ARC process can safely do its job without failure.

In the database alert log, you might find something like "ARCx: Archiving not possible: No primary destinations", "ARCx: Failed to archive log # xxxx seq# yyyy", or even "ARCH: Archival stopped, error occurred. Will continue retrying".  A lot of times in my experience, I've seen this happen more often than not on stand-by database instances rather than on primary instances, where this can have catastrophic user facing concerns.  Can you confirm, are you using your primary or a standby database?

If this is a primary database, has your DBA configured multiple archive locations?  If they have multiple configured, you will need to explicitly tell Debezium which location to prefer; otherwise it will pick the first one it finds in the SQL select.  In this case, you will need to supply the configuration option "log.mining.archive.destination.name" property with the connector, where you would specify the configured archive destination slot to use, such as "LOG_ARCHIVE_DEST_1" for the first slot.  Your DBA should be able to tell you specifically which destination to prefer based on their configurations and you could check if that helps with the problem.

Let me know if you have any specific questions.
Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/debezium/95260034-e491-4273-b69f-1b246a30a891n%40googlegroups.com.