Monitoring replication in Lakehouse Turbo

Learn how to monitor and troubleshoot replication in Lakehouse Turbo.

Tables for monitoring

Replication is logged in the PROGRESS_LOG, REPLICATION_LOG, and REPLICATION_TABLE_STATUS tables in the EXA_DLHC schema. You can query these tables to monitor and troubleshoot the replication process.

The other tables in the EXA_DLHC schema are only for internal use. Do not query or alter these tables, as this may produce unexpected results and impact functionality.

REPLICATION_LOG

This table will contain two rows for each replication attempt: one for the start and one for the end, correlated by the run cycle id. A replication is only attempted when the version available in the Exasol database is lower than the version in the source system.

The table can be truncated if needed. The size of the table can be estimated based on the number of updates happening on the source tables.

Column	Description
`RUN_CYCLE_ID`	Internal ID of the replication run
`STATUS`	Replication status (`IN_PROGRESS`, `SUCCESS`, `ERROR`, `ABORTED`) `ERROR` = Replication failed `ABORTED` = Replication was cancelled mid-run because its configuration changed or the app shut down while it was running
`EVENT_TS`	Timestamp of the replication event
`SOURCE_CATALOG`	The name of the catalog in the data source
`SOURCE_SCHEMA`	The name of the schema in the catalog
`SOURCE_TABLE`	The name of the source table
`TARGET_SCHEMA`	The name of the target schema in the Exasol database
`TARGET_VIEW`	The name of the target view in the Exasol database (when replicating views)
`TABLE_DELTA_VERSION`	The source table’s version as of this replication run The same value is written to `REPLICATION_TABLE_STATUS.VERSION` for that table. Only meaningful for `SUCCESS` rows — for IN_PROGRESS/ERROR/ABORTED rows it is effectively 0, since it is only set after the table status update step completes.
`REPLICATION_MODE`	The replication mode (`INCREMENTAL` or `FULL_LOAD`)
`INSERTED_ROWS`	The number of inserted rows
`DELETED_ROWS`	The number of deleted rows
`INSERTED_FILES`	The number of inserted files
`DELETED_FILES`	The number of deleted files
`ERROR_MESSAGE`	Error messages generated by the replication run (truncated to 2000 characters)
`INFO_MESSAGE`	List of source columns that were skipped during the replication run(for example, due to unsupported data type) If no columns were skipped, the column value is `NULL`
`SOURCE_SYSTEM`	Name of the source system that the log entry belongs to

REPLICATION_TABLE_STATUS

This table tracks the last version/timestamp and filter for tables that have been replicated. This can be useful to get an overview of all tables that are available and at which version.

The table only contains one row per replicated table, indicating the last successful replication. For example, if TableA replicates sucessfully for version 1, it will contain a record for that. If the source table is updated at version 2, and the replication fails, the row for Table A, version 1 will still be there indicating that this is the available version in the Exasol database. The record is only updated if replication succeeds.

REPLICATION_TABLE_STATUS is an internal table and should not be altered.

Column	Description
`TARGET_SCHEMA`	The target schema in the Exasol database
`TABLE_NAME`	The target table in the Exasol database
`VERSION`	A watermark used to detect whether the source table has changed since the last replication. The format depends on the source table format: Delta Lake: the Delta transaction log snapshot version (monotonically increasing integer). Iceberg: the last-metadata-update timestamp (epoch millis) — not a counter.
`FILTER`	The row/partition filter that was applied and is currently reflected in the target table’s data. If the value is different from the currently configured filter in the source system, a full re-replication is triggered even if the `VERSION` has not changed.

PROGRESS_LOG

This table contains detailed information about all operations on the replication tables. For example, it will contain the information when Lakehouse Turbo checks if the version of the source is newer that the version tracked in Exasol for a table.

PROGRESS_LOG is insert-only with no built-in retention/cleanup. We recommend that you truncate this table periodically as it can grow very large over time.

Column	Description
`EVENT_TS`	Timestamp of the replication event
`TARGET_SCHEMA`	The name of the target schema in the Exasol database
`TABLE_NAME`	The name of the target table in the Exasol database
`LOG_LEVEL`	Log message level (`DEBUG`, `INFO`, `WARN`) Failures show up as a `WARN` entry plus the corresponding `REPLICATION_LOG.STATUS` (see below)
`MESSAGE`	The log message
`SOURCE_SYSTEM`	Name of the source system this progress entry belongs to

Examples

Copy

SELECT * FROM EXA_DLHC.PROGRESS_LOG

EVENT_TS	TARGET_SCHEMA	TABLE_NAME	LOG_LEVEL	MESSAGE
2026-06-15 11:57:59	retail_2020	sales	INFO	Starting replication
2026-06-15 11:58:00	retail_2020	dim_date	INFO	Target table is up-to-date with source version 1, filter [null]: No replication required.

Message examples:

PROGRESS_LOG.MESSAGE
Target table is up-to-date ... No replication required.	This is the expected/normal steady-state message, not a warning
Source table version %d is newer than version %d of target table. Starting replication.	Version has been bumped on the source, normal incremental trigger.
Source filter [%s] and target filter [%s] are different. Starting replication.	Someone changed the table's filter config. Expect a full re-replication of that table even though the source version may not have moved.
PROGRESS_LOG.MESSAGE / REPLICATION_LOG.ERROR_MESSAGE
Table 'X': target version (N) is greater than source version (M)	This usually means the source table was dropped and re-created in the source system (its version counter reset). Fix: Drop the Exasol target table and its metadata, then let replication re-run from scratch.
REPLICATION_LOG.STATUS
ABORTED	This is not necessarily a problem, it means the run was cancelled because its replication config changed mid-flight or the service restarted. Check the next run for the table before treating an aborted run as a failure.
ERROR	See ERROR_MESSAGE in the table row for a summary of the error. For more detail, cross-reference PROGRESS_LOG for the same TARGET_SCHEMA/TABLE_NAME around the same EVENT_TS (look for WARN/DEBUG entries).