CDC Replication Methods for Oracle Databases: XStream, LogMiner, and Direct Log Reading

‍‍

‍

Introduction: Why Capture Method Matters in Oracle

‍

Oracle remains the system of record for critical enterprise workloads in banking, insurance, logistics, and telecom. The databases often process thousands of transactions per second, and replicating those changes in real time is key to feeding downstream platforms - from analytics warehouses like Snowflake and BigQuery, to event streams like Kafka, to operational systems and AI models.

How you capture Oracle changes is not a minor implementation detail - it determines latency, CPU impact, licensing costs, and reliability. Oracle supports several official and semi-official mechanisms, while vendors have also developed direct log reading approaches.

‍

This post reviews the four most common approaches:

- XStream

- LogMiner (buffered by Oracle)

- LogMiner (buffered by Popsink)

- Direct redo log parsing

XStream - If you have a license

‍

What it is
XStream is Oracle’s native API for Change Data Capture. It was introduced in Oracle 11gR2 as part of the GoldenGate product family and is the most direct, officially maintained way to stream database changes from redo and undo logs. Connectors that use XStream attach to an outbound server inside Oracle, which publishes committed row-level changes as structured events.

‍

How it works
When a transaction commits, Oracle’s log writer records changes into redo logs. The XStream outbound server reads those logs, reconstructs row operations with full transaction context, and makes them available over the XStream API. Popsink subscribes to this API and streams the events to downstream systems. Because XStream handles transaction assembly inside Oracle, Popsink receives ready-to-consume change events in near real time.

‍

Pros:

- Very low latency (sub-second).

- High throughput; optimized for large transaction volumes.

- Provides full transaction context and schema information.

- Maintained and supported by Oracle across versions.

‍

Cons:

- Requires a GoldenGate license (additional cost).

- More complex to configure and operate than LogMiner.

- Tied to Oracle’s release and feature roadmap.

‍

‍

LogMiner (Buffered by Oracle) - Not recommended

‍

What it is
LogMiner is a long-standing Oracle feature that allows inspection of redo logs. In its buffered mode, Oracle itself parses redo entries and stages the results inside an internal view called V$LOGMNR_CONTENTS. CDC connectors then query these views to fetch changes.

‍

How it works
When transactions commit, Oracle reads redo log entries, converts them into row-level operations, and materializes them in memory or temporary structures. Popsink issues SQL queries against these views to retrieve committed changes. This shifts a portion of the workload to Oracle’s SQL engine, which handles both parsing and buffering, while Popsink primarily consumes the staged results.

‍

Pros:

- Included with Oracle (no separate license needed).

- Well-documented and available in most Oracle editions.

- Simple to integrate since changes are exposed as queryable rows.

‍

Cons:

- Slightly higher CPU overhead, since Oracle manages parsing and buffering.

- Latency tied to commit events and polling frequency, typically in the second.

- Scaling to high transaction volumes can affect database performance. 

‍

‍

LogMiner (Buffered by Popsink) - Recommended

‍

What it is
This approach still uses Oracle’s LogMiner API to access redo logs, but instead of relying on Oracle to buffer and stage results, Popsink takes on the responsibility of assembling transactions and managing state. Oracle provides raw redo records, and the Popsink processes them into change events.

‍

How it works
As redo entries are generated, Oracle exposes them through the LogMiner API. Popsink continuously fetches these entries and keeps them in its own memory until a transaction commits. Once the commit is seen, Popsink’s connector outputs the full set of changes in order. This design reduces pressure on the Oracle SQL engine compared to Oracle-managed buffering by shifting memory usage and transaction handling to Popsink itself.

‍

Pros:

- No additional license required.

- Lower CPU impact on Oracle compared to Oracle-buffered mode.

- Predictable performance at scale.

‍

Cons:

- Latency remains commit-based.

- Complexity sits on Popsink’s side which manages its own buffers and transaction assembly.

‍

‍

Direct Redo Log Parsing - For the highest efficiency

‍

What it is
Popsink’s CDC connector can bypass Oracle’s LogMiner API entirely and parses redo and archived log files directly. Popsink reads the binary redo stream, interprets the internal record formats, and reconstructs row-level changes. This can be done on the primary database or against a standby to offload the impact from production.

‍

How it works
The redo logs capture every change made to the database. Instead of invoking Oracle’s APIs to transform these entries,Popsink itself implements a parser that understands Oracle’s redo structures. It continuously tails the logs, decodes change vectors, and outputs them as CDC events. By handling parsing outside Oracle, this method removes load from the SQL engine and avoids license requirements tied to GoldenGate or LogMiner. The complexity lies in maintaining compatibility across Oracle versions, since redo internals can evolve.

‍

Pros:

- Very low Oracle CPU overhead.

- High throughput and low latency similar to XStream.

- No Oracle license needed.

- Can run from a standby database, isolating production from CDC workloads.

Cons:

- Complexity sits on Popsink’s side.

- Oracle version upgrades can require connector upgrades to support changes

- Requires vendor expertise in redo log internals.

‍

‍

Method

‍

‍

Conclusion: Choosing an Oracle CDC Method

‍

The right CDC approach depends on balancing performance, cost, and operational considerations.

- XStream: best suited for enterprises who already own a GoldenGate license. Oracle-maintained and suitable for high volume, low latency workloads. Best suited for workloads where license

- LogMiner (Oracle-buffered): Appropriate for smaller or less latency-sensitive environments where simplicity is preferred over efficiency. Useful when license constraints rule out XStream.

- LogMiner (Popsink-buffered): A great option that reduces Oracle overhead while avoiding license fees. Suitable for organizations that need predictable performance without additional costs but can accept commit-based latency (at the second level).

- Direct Redo Log Parsing: Well suited for high-throughput replication where minimizing production impact is critical. Compatibility with Oracle versions is handled by the platform, allowing teams to benefit from low overhead and sub-second latency without GoldenGate licensing.

‍