apache/seatunnel · error · DebeziumException

Online REDO LOG files or archive log files do not contain th

Error message

Online REDO LOG files or archive log files do not contain the offset scn <startScn>.  Please perform a new snapshot.

What it means

When starting streaming, LogMinerStreamingChangeEventSource.execute computes the first available SCN from the online redo/archive logs and validates that the offset SCN (startScn, the exclusive lower bound) is not older than firstScn - 1. If the offset SCN has aged out of the retained logs, mining cannot start from it, so Debezium fails with this exception demanding a new snapshot (in continuous mining mode this check is skipped).

Source

Thrown at seatunnel-connectors-v2/connector-cdc/connector-cdc-oracle/src/main/java/io/debezium/connector/oracle/logminer/LogMinerStreamingChangeEventSource.java:171

            jdbcConnection.setAutoCommit(false);

            startScn = offsetContext.getScn();
            snapshotScn = offsetContext.getSnapshotScn();
            Scn firstScn = getFirstScnInLogs(jdbcConnection);
            if (startScn.compareTo(snapshotScn) == 0) {
                // This is the initial run of the streaming change event source.
                // We need to compute the correct start offset for mining. That is not the snapshot
                // offset,
                // but the start offset of the oldest transaction that was still pending when the
                // snapshot
                // was taken.
                computeStartScnForFirstMiningSession(offsetContext, firstScn);
            }

            try (LogWriterFlushStrategy flushStrategy = resolveFlushStrategy()) {
                if (!isContinuousMining && startScn.compareTo(firstScn.subtract(Scn.ONE)) < 0) {
                    // startScn is the exclusive lower bound, so must be >= (firstScn - 1)
                    throw new DebeziumException(
                            "Online REDO LOG files or archive log files do not contain the offset scn "
                                    + startScn
                                    + ".  Please perform a new snapshot.");
                }

                setNlsSessionParameters(jdbcConnection);
                checkDatabaseAndTableState(jdbcConnection, connectorConfig.getPdbName(), schema);

                try (LogMinerEventProcessor processor =
                        createProcessor(context, partition, offsetContext)) {

                    if (archiveLogOnlyMode && !waitForStartScnInArchiveLogs(context, startScn)) {
                        return;
                    }

                    initializeRedoLogsForMining(jdbcConnection, false, startScn);

                    int retryAttempts = 1;

View on GitHub (pinned to cf67b549a7)

Solutions

1. Perform a new snapshot so the offset SCN is within the available redo/archive window
2. Increase redo log size/count and archive log retention so the connector can tolerate restarts/lag
3. Enable (or rely on) continuous_mining behavior where supported to relax the boundary check after evaluating consistency implications
4. Resume streaming promptly after outages; monitor the gap between current SCN and offset SCN and alert before logs age out

-- Before restarting streaming, verify offset SCN is still minable:
-- offsetScn from connector offsets, then:
SELECT MIN(FIRST_CHANGE#) FROM V$ARCHIVED_LOG WHERE DELETED='NO';
-- if offsetScn < that value (minus 1), plan a new snapshot instead of restarting

try {
    source.execute(context);
} catch (DebeziumException e) {
    if (e.getMessage() != null && e.getMessage().contains("do not contain the offset scn")) {
        // offset SCN aged out of redo/archive logs: full re-snapshot required
        planner.recoverWithSnapshot();
    } else { throw e; }
}

When it happens

Trigger: execute -> computeStartScnForFirstMiningSession obtains firstScn from the oldest available log; the stored offset startScn < firstScn - 1 because logs were switched/archived/purged while the connector was stopped or lagging, and isContinuousMining is false.

Common situations: Connector offline longer than redo log retention; aggressive archivelog deletion by RMAN/DBA scripts; long snapshot duration letting logs rotate past the captured SCN; restarting an old saved offset after DB maintenance.

Related errors

• Failed to resolve current SCN
• Failed to resolve snapshot offset
• Failed to calculate oldest SCN available in logs
• Cannot get maximum archive log SCN as no logs were available
• Cannot get maximum archive log SCN as no archive logs are pr

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/993b7a3e4adac012. Report an issue: GitHub.