apache/seatunnel · critical · DebeziumException

Cannot get maximum archive log SCN as no archive logs are pr

Error message

Cannot get maximum archive log SCN as no archive logs are present.

What it means

getMaxArchiveLogScn filters the discovered log files to those of type ARCHIVE and throws when none remain. Unlike the empty-list case, logs were found but all are ONLINE/redo logs — the connector cannot compute a maximum archived-log SCN. This typically happens when the required SCN range is no longer covered by archived logs.

Source

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

     *
     * @param logFiles the current logs that are part of the mining session
     * @return the maximum system change number from the archive logs
     * @throws DebeziumException if no logs are provided or if the provided logs has no archive log
     *     types
     */
    private Scn getMaxArchiveLogScn(List<LogFile> logFiles) {
        if (logFiles == null || logFiles.isEmpty()) {
            throw new DebeziumException(
                    "Cannot get maximum archive log SCN as no logs were available.");
        }

        final List<LogFile> archiveLogs =
                logFiles.stream()
                        .filter(log -> log.getType().equals(LogFile.Type.ARCHIVE))
                        .collect(Collectors.toList());

        if (archiveLogs.isEmpty()) {
            throw new DebeziumException(
                    "Cannot get maximum archive log SCN as no archive logs are present.");
        }

        Scn maxScn = archiveLogs.get(0).getNextScn();
        for (int i = 1; i < archiveLogs.size(); ++i) {
            Scn nextScn = archiveLogs.get(i).getNextScn();
            if (nextScn.compareTo(maxScn) > 0) {
                maxScn = nextScn;
            }
        }

        LOGGER.debug("Maximum archive log SCN resolved as {}", maxScn);
        return maxScn;
    }

    /**
     * Requests Oracle to build the data dictionary.
     *

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Force an archive log switch: ALTER SYSTEM SWITCH LOGFILE; wait for archiving, then restart the connector.
  2. Increase archiveLogRetention so recent archived logs fall within the discovery query window.
  3. Check that the archiver process is running (V$ARCHIVE_PROCESSES status should be STARTED/ACTIVE).
  4. If the offset SCN falls in an unarchived gap, take a new snapshot and restart from the fresh SCN.

Example fix

null
Defensive patterns

Strategy: retry

Validate before calling

-- ensure archived (not just online) logs cover the needed window
SELECT COUNT(*) FROM V$ARCHIVED_LOG
 WHERE FIRST_CHANGE# <= :offsetScn AND NEXT_CHANGE# > :offsetScn;

Try / catch

try {
    startConnector();
} catch (DebeziumException e) {
    if (e.getMessage().contains("no archive logs are present")) {
        // wait for a log switch, then retry
        Thread.sleep(60_000);
        startConnector();
    } else { throw e; }
}

Prevention

When it happens

Trigger: currentScn calls getMaxArchiveLogScn with a non-empty logFiles list, but the filter log.getType().equals(LogFile.Type.ARCHIVE) removes every entry, leaving archiveLogs empty — e.g. only online redo logs present for the queried window.

Common situations: Frequent log switches with slow archiving so current redo hasn't been archived; recent NOARCHIVELOG period creating a gap; short archiveLogRetention excluding recent archives; startup immediately after a database restart before any switch.

Understand the failure class

Background: EmptyResultError / "no results found": when an API or scraper succeeds but returns zero rows — this error's family across 9 libraries.

Related errors


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