java.sql.SQLException: ORA-00310: archived log contains sequence 291845; sequence

[Abhishek Chauhan]

Hi,

In debezium 3.2.6 we are are facing this error, will it restart the connector/task? If not then the log inconsistent state, how we can maintain or handle this ??
This specific error can often mean that the redo state is changing faster than Debezium can consume it, and this means that the log state in LogMiner has become outdated. How we can handle this scenario??

Error:  

{"time":"2026-07-28T14:40:30.518820806Z","stream":"stdout","_p":"F","log":"Caused by: java.sql.SQLException: ORA-00310: archived log contains sequence 291845; sequence 291841 required",pod_ip":"1.240.29.207","container_name":"generic{"time":"2026-07-28T14:40:30.51897671Z","stream":"stdout","_p":"P","log":"Caused by: Error : 310, Position : 0, Sql = SELECT SCN, SQL_REDO, OPERATION_CODE, TIMESTAMP, XID, CSF, TABLE_NAME, SEG_OWNER, OPERATION, USERNAME, ROW_ID, ROLLBACK, RS_ID, STATUS, INFO, SSN, THREAD#, DATA_OBJ#, DATA_OBJV#, DATA_OBJD#, CLIENT_ID, START_SCN, COMMIT_SCN, START_TIMESTAMP, COMMIT_TIMESTAMP, SEQUENCE# FROM V$LOGMNR_CONTENTS WHERE SCN > :1  AND SCN <= :2  AND (OPERATION_CODE IN (1,2,3,6,7,27,34,36,255) OR (OPERATION_CODE = 5 AND INFO NOT LIKE 'INTERNAL DDL%')) AND (SEG_OWNER IS NULL OR UPPER(SEG_OWNER) IN ('UNKNOWN','CUSTOMER_I','OPUS_CORE','CUSTOMER')) AND (TABLE_NAME IS NULL OR UPPER(SEG_OWNER || '.' || TABLE_NAME) IN (), Error Msg = ORA-00310: archived log contains sequence 291845; sequence 291841 

[Chris Cranford]

Hi,

Please share the output of these queries:

    # Shows the number of log groups, their redo log sizes, and number of logs per group
    SELECT GROUP#, MAX(BYTES), COUNT(1) 
    FROM V$LOG 
    GROUP BY GROUP#;

    # Shows the number of entries maintained in control file for archive logs
    SELECT TYPE, RECORDS_TOTAL, RECORDS_USED
    FROM V$CONTROLFILE_RECORD_SECTION
    WHERE TYPE = 'ARCHIVE LOG';

It would also be useful if you could jump all of the connector's JMX metrics to a text file and attach those.

Thanks,
-cc

--
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/6ba19d5d-64e7-47c7-8625-3466edde4e2an%40googlegroups.com.

[Abhishek Chauhan]

SQL> SELECT GROUP#, MAX(BYTES), COUNT(1)

    FROM V$LOG
    GROUP BY GROUP#;  

    GROUP# MAX(BYTES)   COUNT(1)
---------- ---------- ----------
         6  524288000          1
         1  524288000          1
         7  524288000          1
         2  524288000          1
         8  524288000          1
         4  524288000          1
         5  524288000          1
         3  524288000          1

8 rows selected.

no rows selected

SQL> SELECT TYPE, RECORDS_TOTAL, RECORDS_USED
    FROM V$CONTROLFILE_RECORD_SECTION
    WHERE TYPE = 'ARCHIVE LOG';  2    3

no rows selected

Cant fetch JMX metrics 

[Abhishek Chauhan]

SELECT sequence#, name, deleted FROM v$archived_log WHERE sequence# BETWEEN 292083 AND 292087;





We already have this sequence isn Archival log, then why debezium is thorws errror ORA-00310: archived log contains sequence 292087; sequence required 292083

Since source DB is RAC, it has Node 1 and Node 2. The thread 2 which dated 16 JULY have been deleted. But I do not think your CDC is referring to archive log dated 16 JULY. It should be the archive log dated 29 JULY. No one will keep archive log dated 16 JULY, which is 2 weeks ago.
Can you please help me with this.??

[Chris Cranford]

Oracle can parallelize work across threads, so for consistency and reconstruction, all logs across all threads must be retained for the same period of time. But what can happen in low activity RAC environments, if you had a transaction that still showed up in the logs on 07/29 that referred to a change on Node 2 from 07/16, because it remains idle for several weeks, that could trigger this corner case. Without having the DBA do a LOG dump or more aptly restore all logs from 07/16 and review the full transaction across both nodes, its hard to give any definitive answers.

The one thing I will say, 500MB for a redo log file for production, especially if its under load, is often considered inadequate. Most production systems that have medium to high loads typically prefer to have their log file sizes in the GBs, 2GB - 4GB to minimize log switches. A log switch with CDC tooling requires a full tear down and reconstruction of the mining context, so any time you can reduce the switch frequency, you gain better overall performance. The only time low log sizes are fine are in development or local testing environments.

Hope that helps.
-cc

To view this discussion visit https://groups.google.com/d/msgid/debezium/165561d3-8201-4f09-86ce-1d0959138518n%40googlegroups.com.

[Abhishek Chauhan]

We have changed from 500 MB to 2GB, also now we are upgrading to 3.6.Final. I'll check and let u know the progress.