Oracle change data capture and real-time data replication

• Oracle DBAs who must expose change data without handing out SYSDBA, without adding another replication product to the estate, and with a documented list of privileges, supplemental logging, and ARCHIVELOG requirements they can review before approving anything
• Data platform leads feeding Snowflake, BigQuery, data lakes, Kafka, MongoDB, or Couchbase from Oracle systems of record, who want one control plane for sources and targets instead of a Kafka Connect mesh
• Teams re-evaluating Oracle GoldenGate, Qlik Replicate, or Fivetran HVR renewals and looking for a commercial Oracle CDC path with best-in-class enterprise support, rated 4.9/5 by customers and heterogeneous targets
• Engineers who prototyped the Debezium Oracle connector and now own LogMiner session tuning, Connect clusters, schema history, and on-call for a pipeline the business considers infrastructure

Redo logs first, triggers when redo access is restricted

Three capture techniques cover Oracle Database, all exposed as the same pipeline in Core Hub. XStream and LogMiner read the redo logs; the two trigger-based agents audit with triggers for environments where the log cannot be exposed.

• XStream: the agent attaches to an XStream outbound server and receives Logical Change Records (LCRs) from the capture process. It shares the underlying architecture and APIs with Oracle GoldenGate, which is why it needs Enterprise Edition and the GoldenGate (XStream) license, and why it is the choice for high-throughput estates that already license it. Before and after images are included. XStream agent docs ↗
• LogMiner: the agent mines online and archived redo logs through Oracle's native LogMiner utility over a standard JDBC connection. Standard or Enterprise Edition, RAC supported, no GoldenGate license. This is the default recommendation for most Oracle estates. LogMiner agent docs ↗
• Triggers: the agent installs triggers that record changed row IDs and CRUD action types in a per-table CDC table, then reads committed rows from it. Any edition, single-tenant or CDB/PDB, RAC supported. It is the option when redo access is not permitted at all. Triggers agent docs ↗

What your DBA will be asked to enable

The log-based agents need the database to keep the change history they read, and a user with the minimum privileges to read it. Full statements are in each agent's setup guide.

• ARCHIVELOG mode for XStream and LogMiner. Archived redo must stay available until the agent has consumed it: an RMAN retention policy that prunes logs too early surfaces as ORA-01291: missing logfile, and the LogMiner troubleshooting guide covers the recovery steps.
• Supplemental logging. LogMiner needs database-level ADD SUPPLEMENTAL LOG DATA plus (PRIMARY KEY) COLUMNS. For every captured table, ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS is the recommended setting on both XStream and LogMiner, so before and after images come straight from the log and Gluesync does not have to query the source table for the full row.
• Least-privilege users. LogMiner uses a dedicated mining user granted CREATE SESSION, SELECT ANY TRANSACTION, SELECT ANY DICTIONARY, EXECUTE_CATALOG_ROLE, and LOGMINING, plus a separate application user for discovery and snapshots. XStream uses an admin user granted through DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGE and a connect user with SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE, and FLASHBACK ANY TABLE, with enable_goldengate_replication=true set at the instance. Triggers need a user dedicated to Gluesync with CREATE TABLE, CREATE TRIGGER, CREATE ANY SEQUENCE, and SELECT ANY TABLE. None of the runtime users is SYS or a schema owner.
• Scope the capture. On XStream, register only the tables you need in the outbound server and filter columns with subset rules; capturing an entire schema on an undersized instance is the usual cause of PAUSED FOR FLOW CONTROL. On LogMiner, supplemental logging increases redo volume, so size storage and network accordingly.

CDB/PDB, RAC, and connectivity

• Multitenant. XStream and LogMiner both document a multi-tenant setup: common C## users created in the CDB with CONTAINER=ALL, redo mined at the CDB level where all PDBs share it, tables and supplemental logging configured inside the PDB, and CDB name and PDB name set on the agent. The Triggers agents take the same two settings for multi-tenant scopes.
• RAC. LogMiner and Triggers support Oracle Real Application Clusters, and LogMiner exposes a dedicated Use Oracle RAC advanced setting. XStream documents connecting through a SCAN address.
• Connections. Connect by SID or SERVICE_NAME, through a SCAN DNS record so sessions land on the least loaded instance, or by pasting a full JDBC descriptor built from your existing tnsnames.ora entry. TLS and Oracle Wallet authentication are documented, with additional hosts for failover on LogMiner.

Resilience built for Oracle restarts and long transactions

The LogMiner agent persists committed changes in ArenaCache, the source-side cache now shared by other cache-enabled Gluesync agents, and spills large or long-running uncommitted transactions to an off-heap, memory-mapped file per transaction so JVM heap pressure stays flat regardless of transaction size. When the Oracle host restarts or the network blackholes, a configurable read timeout bounds the dead read, the worker drops orphaned in-flight state, reconnects, and resumes from the persisted SCN checkpoint without a software restart.

Redo SQL the parser cannot decode is recorded in a LOGMNR_PARSE_DLQ table, and an agent setting lets you choose fail-open continuity with an audit trail or strict blocking until an operator intervenes. On XStream, a low-watermark retention setting manages archive retention for quiet tables, and we provide a startup trigger snippet that restarts the outbound server after a database restart. The Triggers agent tracks a TRANSACTION_CONSUMED state per row so deferred commits from other tools writing to the same database are handled, and the CDC table has configurable retention and optional partitioning on Enterprise Edition.

Architecture around Core Hub

Lightweight agents sit close to each system. Core Hub is the central orchestrator for the web UI, APIs, and routing between source and target agents. Pipelines group a source agent, target agent, and entities. Every Oracle agent supports full-table snapshots to seed a target before CDC, bulk load for high-volume mirroring, and the source and target role, so Oracle can be the destination as well as the origin. Documented deployments include Docker, Docker Compose, and Kubernetes.

Explore the general CDC streaming architecture →

Use the integrations directory to pair Oracle Database as source or target with relational engines, NoSQL stores, cloud warehouses, object and lake storage, or event streams, subject to each agent's documented source and target role. Every Oracle agent also supports the target role, including bulk load into Oracle.

Gluesync keeps pace with your change volume at any scale. MOLO17 Professional Services can size the deployment with your team.

Target agents write in optimized batches, never row by row, and switch to native bulk load for both snapshots and CDC on targets such as Snowflake, Google BigQuery, Amazon Redshift, Microsoft SQL Server, and PostgreSQL.

• Offload reporting and API reads from Oracle to PostgreSQL, SQL Server, or a NoSQL store: see database offload
• Feed Snowflake, BigQuery, Amazon Redshift, or a data lake continuously with destination-native bulk loading: see warehouse sync
• Publish Oracle changes to Apache Kafka or another event-streaming platform for microservices and integration
• Run a snapshot plus CDC to keep an Oracle and a cloud target aligned until cutover: see cloud migration