Oracle CDC: Online DDL and EBR Compatibility

Why it is required

Without supplemental logging, redo records for UPDATE and DELETE may not contain enough information to identify the affected row. Oracle records only the minimum data needed for its own crash recovery. Supplemental logging instructs it to include additional columns.

Two configuration levels

Performance warning

Logging all columns is a performance anti-pattern. For a high-volume UPDATE on a 75-column table, enabling all-column supplemental logging increased redo size by over 300%. Key-based logging avoids this cost.

For GoldenGate, use ADD SCHEMATRANDATA rather than table-level ADD TRANDATA. It automatically covers all current and future tables in the schema and is a prerequisite for DDL replication.

Three components

The cutover moment

EBR cutover is a single DDL statement:

New sessions connect to the new edition. Existing sessions remain on the old one until they disconnect. A CDC tool that cannot capture this statement loses its edition context the moment the cutover fires.

The exclusive DDL lock

Oracle's online DDL allows schema modifications while DML continues, but at the completion of any online DDL operation, Oracle must acquire a brief exclusive DDL lock. A long-running transaction holding any lock on the object blocks this final phase.

While DDL waits, new DML sessions queue behind it, potentially stalling the application. CDC replication lag accumulates rapidly — the Extract process is starved of new redo. Once DDL completes, the connector faces a large backlog.

Oracle 23ai: Lock-Free Reservation

In Oracle 23ai, Lock-Free Reservation reduces this collateral damage. For numeric columns declared RESERVABLE, UPDATE statements do not take a standard row-level lock. The delta is recorded in a reservation journal and the lock is deferred until commit time.

If a long-running transaction blocks DDL's final lock, other sessions updating reservable columns in the same table can still proceed. The DDL still waits, but the blast radius is limited. GoldenGate 23ai explicitly supports capturing and replicating changes to reservable columns.

Oracle 19c mitigation

The recommended mitigation in 19c is to pause DML on the affected table, let the pipeline drain, execute the DDL, then resume. This is a controlled mini-outage rather than a silent one. Online DDL on 19c also has documented restrictions: ALTER TABLE ... MOVE PARTITION ONLINE is not permitted for index-organized tables or tables containing object types.

GoldenGate's Integrated Extract captures the edition context of each DDL statement and stores it in the trail file. The Replicat process on the target issues ALTER SESSION SET EDITION before applying the DDL, keeping the target in sync with the source's edition state throughout an upgrade.

Full EBR lifecycle capture

GoldenGate captures the full EBR lifecycle with no manual connector intervention during cutover:

• CREATE EDITION
• Editioning view changes
• Editioned PL/SQL object versions
• ALTER DATABASE DEFAULT EDITION — the cutover command

Enhanced in Oracle 23ai to handle previously blocking online DDL operations.

Known bugs as signs of maturity

Documented and patched. Oracle actively tests this scenario — this reflects maturity, not fragility.

XStream is built on Oracle Streams, deprecated as of Oracle 11g. It does not support ALTER DATABASE DDL commands. The outbound server ignores several DDL types including RENAME.

The EBR cutover problem

XStream cannot capture ALTER DATABASE DEFAULT EDITION, making it unable to track an EBR cutover. There is no workaround. An EBR cutover is invisible to XStream's outbound server.

Support status

XStream is included with Oracle Enterprise Edition at no additional license cost, but deprecated means no new feature development and eventual removal. Oracle does not recommend XStream for new deployments.

A connector session binds to the database's default edition at connect time. It has no mechanism to detect or respond to ALTER DATABASE DEFAULT EDITION.

When an EBR cutover occurs, the connector remains in the old edition context while new application sessions write data through new editioning views. Data written to new columns is invisible to the connector. This is not a bug — it is an architectural mismatch between a stateless external LogMiner client and Oracle's edition-scoped data model.

LogMiner strategy trade-offs

Required EBR cutover procedure

Every EBR cutover requires these manual steps:

1. Stop the connector
2. Delete the schema history Kafka topic
3. Restart the connector
4. Trigger an incremental snapshot for affected tables

Data written to new columns during the outage window is lost. This stop-reset-restart cycle is also an opportunity for operator error.

Feature strength (1 = poor, 5 = excellent)

Enable ARCHIVELOG mode with FORCE LOGGING. Use schema-level supplemental logging: run ADD SCHEMATRANDATA <schema_name> in GGSCI for each application schema. Configure Integrated Extract with the DDL parameter in both Extract and Replicat parameter files.

This configuration handles EBR upgrades automatically. No manual intervention during cutover.

Same configuration as above. Higher risk due to 19c lock contention patterns. Required mitigations:

• Test every DDL statement under production-equivalent load before deployment
• Schedule DDL for low-traffic periods
• Document a "pause DML" procedure for high-risk DDL on critical tables

If Debezium is unavoidable, use log.mining.strategy=redo_log_catalog. Set snapshot.locking.mode=none. Run the initial snapshot during a period with no DML or DDL on captured schemas.

Accept that every EBR cutover requires a manual stop, schema history topic deletion, connector restart, and incremental snapshot. Accept that data written to new columns during the outage window is lost.