apache/seatunnel · critical · DebeziumException

Failed to calculate oldest SCN available in logs

Error message

Failed to calculate oldest SCN available in logs

What it means

During LogMiner streaming startup, the connector queries V$ARCHIVED_LOG (via oldestFirstChangeQuery) to find the oldest SCN still available in archived/online redo logs. When the query returns no row (null SCN), the connector cannot determine where mining can safely start, so it throws this DebeziumException in getFirstScnInLogs. It effectively means Oracle has no redo information available from which to compute a starting point.

Source

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

    }

    /**
     * Gets the first system change number in both archive and redo logs.
     *
     * @param connection database connection, should not be {@code null}
     * @return the oldest system change number
     * @throws SQLException if a database exception occurred
     * @throws DebeziumException if the oldest system change number cannot be found due to no logs
     *     available
     */
    private Scn getFirstScnInLogs(OracleConnection connection) throws SQLException {
        String oldestScn =
                connection.singleOptionalValue(
                        SqlUtils.oldestFirstChangeQuery(
                                archiveLogRetention, archiveDestinationName),
                        rs -> rs.getString(1));
        if (oldestScn == null) {
            throw new DebeziumException("Failed to calculate oldest SCN available in logs");
        }
        LOGGER.trace("Oldest SCN in logs is '{}'", oldestScn);
        return Scn.valueOf(oldestScn);
    }

    private void initializeRedoLogsForMining(
            OracleConnection connection, boolean postEndMiningSession, Scn startScn)
            throws SQLException {
        if (!postEndMiningSession) {
            if (OracleConnectorConfig.LogMiningStrategy.CATALOG_IN_REDO.equals(strategy)) {
                buildDataDictionary(connection);
            }
            if (!isContinuousMining) {
                currentLogFiles =
                        setLogFilesForMining(
                                connection,
                                startScn,
                                archiveLogRetention,

View on GitHub (pinned to cf67b549a7)

Solutions

1. Verify archived logs exist: SELECT NAME, FIRST_CHANGE# FROM V$ARCHIVED_LOG WHERE DEST_ID=<archiveDestinationName> ORDER BY FIRST_CHANGE#.
2. Check archive log destination configuration matches connector's archiveDestinationName (query V$ARCHIVE_DEST / log_archive_dest_1).
3. Increase archiveLogRetention so the query window covers available logs, or lower the connector's starting SCN (reset offsets to an SCN still present in the logs).
4. If logs were purged, take a fresh consistent snapshot of the database and restart the connector from the new snapshot SCN.
5. Ensure ARCHIVELOG mode is enabled and archivelogs are actually being generated (ARCHIVE LOG LIST).

Example fix

// before: connector fails on start because dest mismatched
"archive.destination.name": "LOG_ARCHIVE_DEST_2"
// after: match actual destination label/name in V$ARCHIVED_LOG
"archive.destination.name": "LOG_ARCHIVE_DEST_1"

-- run as the log mining user before starting the connector
SELECT NVL(MAX(FIRST_CHANGE#), 0) FROM V$ARCHIVED_LOG
 WHERE DEST_ID = 1 AND FIRST_CHANGE# > 0;

When it happens

Trigger: getFirstScnInLogs runs the oldestFirstChangeQuery against the archive log destination (filtered by archiveLogRetention and archiveDestinationName) and receives null — no archive logs match the retention/destination filters and no usable SCN can be computed, e.g. right after offset-based restart when archived logs were deleted.

Common situations: Archive logs purged by RMAN retention before the connector's offset SCN; archive log destination (log_archive_dest) misconfigured so archiveDestinationName doesn't match; archive logging barely used so V$ARCHIVED_LOG has no rows for the destination; archiveLogRetention set smaller than the gap the connector needs to bridge.

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

• Cannot get maximum archive log SCN as no logs were available
• Cannot get maximum archive log SCN as no archive logs are pr
• Failed to resolve current SCN
• Failed to resolve snapshot offset
• Online REDO LOG files or archive log files do not contain th

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