The two strategies
redo_log_catalog
Oracle writes its data dictionary to the redo logs on each log switch. Debezium mines this embedded dictionary to track schema changes over time. Because the schema context travels with the data in the log stream, DDL changes are captured reliably without application downtime. The trade-off is increased redo and archive log volume and higher CPU during LogMiner operations.
online_catalog
Debezium queries the current live data dictionary of the PDB rather than reading an embedded copy from the logs. This avoids dictionary flush overhead, producing less archive log volume and faster mining. It has been the default strategy since Debezium 3.0. The risk: if DML occurs after a DDL change but before Debezium has processed and recorded that DDL, it will apply the new schema to old DML events, causing mapping errors or silent data corruption. A strict stop-DDL-start procedure is required.
Trade-off comparison
Higher values indicate higher impact or requirement
Feature comparison
| Feature | redo_log_catalog | online_catalog |
|---|---|---|
| DDL detection | Dictionary embedded in redo logs at each log switch | Live PDB dictionary queried by LogMiner |
| Interwoven DDL + DML | Safe: historical schema context travels with the logs | Risk: misinterpretation if stop-DDL-start is skipped |
| Performance | Lower: dictionary flush overhead, larger archive logs | Higher: no flush overhead, faster mining |
| Archive log volume | Increased by dictionary dumps | Normal volume |
| Debezium default | Older versions (pre-3.0) | Debezium 3.0+ |
| Multiple connectors | Not recommended (compounds redo overhead) | Supported |
redo_log_catalog approach
Oracle writes data dictionary snapshots to the redo logs on each log switch. Debezium reads these to track schema changes over time. Application downtime is generally not required for DDL changes to existing tables. For new tables not covered by a regex table.include.list, a connector restart is needed to add them to the config.
1. Verify Configuration
Before applying DDL, confirm Debezium Server is configured for redo_log_catalog and the schema history topic is accessible.
# application.properties debezium.source.log.mining.strategy=redo_log_catalog debezium.source.database.pdb.name=MYPDB debezium.source.schema.history.internal.kafka.topic=schema-history-topic
The table.include.list must use the pattern server.pdb.schema.table. A regex pattern (e.g. myserver\.mypdb\.myschema\..*) automatically picks up new tables without a connector restart.
online_catalog approach (strict procedure required)
Debezium queries the live PDB dictionary. It has no knowledge of historical schema states. If DML events from before a DDL change are still unprocessed when the schema changes, Debezium will apply the new schema to the old events, causing fatal mapping errors or silent data corruption. Application downtime and a strict stop-DDL-start procedure are required.
1. Stop Incoming Transactions
Stop the source application or block write access to the affected PDB schemas. All INSERT, UPDATE, and DELETE operations must cease before any DDL is applied.
If DML occurs after DDL and Debezium processes that DML after restarting, it will map the old data against the new schema via the live dictionary. The result is either a connector crash or silent corruption of downstream records.
MilliSecondsBehindSource in JMX and wait for it to reach 0.