Modern enterprise architectures rarely live inside a single database engine anymore. It is very common to see operational data stored in relational systems like Oracle while analytics or distributed applications rely on NoSQL platforms such as Cassandra.
In several real-world projects I have worked on, Cassandra clusters were used to power high-volume applications while Oracle remained the authoritative system of record. In these cases, Oracle GoldenGate D23ai DAA becomes a powerful bridge that streams transactional changes from Oracle redo logs directly into Cassandra in near real time.
In this article we will walk through a complete end-to-end implementation of Oracle → DataStax Cassandra replication using Oracle GoldenGate.
The goal is to demonstrate:
• Initial data load
• Continuous change capture
• Replication of DML operations
• Validation on the Cassandra side
Source System : Oracle Database Server
Hostname: ora-prod01.lab.internal
IP: 10.10.10.11
Operating System: Oracle Linux 8
Database Version: Oracle 19c (19.21 RU)
GoldenGate Version: 23ai Classic Deployment
Target System: DataStax Enterprise Cassandra Node
Hostname: cass-node01.lab.internal
IP: 10.10.10.21
Operating System: Rocky Linux 8
Cassandra Distribution: DataStax Enterprise 6.8.50
GoldenGate Big Data / Java Adapter is installed on the Cassandra side.
Step 1 – Prepare Oracle Source Database
Oracle GoldenGate captures data changes directly from the Oracle redo logs, allowing near real-time replication without querying tables. To support this, the database must have ARCHIVELOG mode, force logging, and supplemental logging enabled so that all row-level changes are fully recorded and available for capture.
sqlplus / as sysdba
archive log list;
Database log mode No Archive Mode
Automatic archival Disabled
-- enable archivelog mode
shutdown immediate;
startup mount;
alter database archivelog;
alter database open;
-- enable force logging
alter database force logging;
-- enable supp logging
alter database add supplemental log data;
-- enabled GG parameter in source database
alter system set enable_goldengate_replication=true scope=both;
-- streams pool size
alter system set streams_pool_size=2G scope=both;
Step 2 – Create GoldenGate User in Oracle
A dedicated database user is required for GoldenGate to capture changes from the Oracle redo logs and access the necessary metadata. This user is granted the required privileges to read transaction logs, access dictionary information, and manage replication objects.
CREATE TABLESPACE ogg_ts
DATAFILE '/u02/oradata/ogg_ts01.dbf'
SIZE 500M AUTOEXTEND ON;
CREATE USER ggadmin IDENTIFIED BY "Welcome#123"
DEFAULT TABLESPACE ogg_ts
TEMPORARY TABLESPACE temp;
GRANT CONNECT, RESOURCE TO ggadmin;
GRANT SELECT ANY TABLE TO ggadmin;
GRANT SELECT ANY TRANSACTION TO ggadmin;
GRANT SELECT ANY DICTIONARY TO ggadmin;
GRANT FLASHBACK ANY TABLE TO ggadmin;
GRANT ALTER SYSTEM TO ggadmin;
GRANT UNLIMITED TABLESPACE TO ggadmin;
-- Granted OGG admin privs
exec dbms_goldengate_auth.grant_admin_privilege(
grantee => 'GGADMIN',
privilege_type => 'CAPTURE',
grant_select_privileges => TRUE,
do_grants => TRUE);
Step 3 – Create Source Table in Oracle
To validate the replication pipeline, create a sample table and insert a few test records in the Oracle source database. These records will later be used to verify that GoldenGate successfully captures and replicates the data to the DataStax Cassandra target.
CREATE TABLE SALES_TRANSACTIONS
(
TXN_ID NUMBER PRIMARY KEY,
CUSTOMER_NAME VARCHAR2(100),
PRODUCT_CODE VARCHAR2(50),
TXN_AMOUNT NUMBER,
TXN_TIMESTAMP DATE
);
INSERT INTO SALES_TRANSACTIONS VALUES
(101,'John Carter','PRD-A',1200,SYSDATE);
INSERT INTO SALES_TRANSACTIONS VALUES
(102,'Alice Brown','PRD-B',850,SYSDATE);
INSERT INTO SALES_TRANSACTIONS VALUES
(103,'Michael Lee','PRD-C',430,SYSDATE);
COMMIT;
select * from SALES_TRANSACTIONS;
TXN_ID CUSTOMER_NAME PRODUCT_CODE TXN_AMOUNT TXN_TIMESTAMP
-----------------------------------------------------------
101 John Carter PRD-A 1200 05-MAR-26
102 Alice Brown PRD-B 850 05-MAR-26
103 Michael Lee PRD-C 430 05-MAR-26
Step 4 – Install DataStax Cassandra
On the target node install DataStax Enterprise. Example repository configuration:
sudo vi /etc/yum.repos.d/datastax.repo
[datastax]
name=DataStax Repo
baseurl=https://rpm.datastax.com/enterprise
enabled=1
gpgcheck=0
-- Install DSE
sudo yum install dse-full-6.8.50 -y
-- Start DSE
sudo systemctl start dse
-- Veroify cluster/nodes status
nodetool status
Datacenter: DC1
===============
Status=Up/Down
|/ State=Normal
-- Address Load Tokens Owns Host ID Rack
UN 10.10.10.21 120 KB 256 100% 8c34a0c1-b8c1-4b35-a6a7-9c2d8bfae111 rack1
Step 5 – Create Cassandra Keyspace
In DataStax Cassandra, a keyspace is the top-level namespace that defines how data is replicated across the cluster. Before creating tables for replication, we first create a keyspace and configure its replication strategy and replication factor.
cqlsh 10.10.10.21 <port> -u xxxx -p xxx
CREATE KEYSPACE retail_ks
WITH replication = {
'class': 'NetworkTopologyStrategy',
'DC1': 1
};
-- verify
DESCRIBE KEYSPACES;
-- Created target tables in cassandra
USE retail_ks;
CREATE TABLE sales_transactions
(
txn_id int,
customer_name text,
product_code text,
txn_amount decimal,
txn_timestamp timestamp,
PRIMARY KEY(txn_id)
);
-- verofy table structure
DESCRIBE TABLE retail_ks.sales_transactions;
Step 6 – Install GoldenGate on Oracle
Oracle GoldenGate software must be installed on the source server to capture database changes. In production environments, the silent installation method is commonly used because it allows automated and repeatable deployments without manual interaction.
-- Unpack GoldenGate binaries.
unzip 231000_fbo_ggs_Linux_x64_Oracle.zip
-- Run silent installation. Respoonse file
INSTALL_OPTION=ora23ai
SOFTWARE_LOCATION=/u01/app/ogg
START_MANAGER=true
MANAGER_PORT=7809
DATABASE_LOCATION=/u01/app/oracle/product/19c
-- Install
./runInstaller -silent -responseFile ogg.rsp
-- LaUnch OGG
cd /u01/app/ogg
./ggsci
GGSCI> INFO ALL
Program Status
MANAGER RUNNING
Step 7 – Enable Table Level Replication
Login to database and enable supplemental logging for the table.
GGSCI> DBLOGIN USERID ggadmin PASSWORD Welcome#123
GGSCI> ADD TRANDATA SALES_TRANSACTIONS
OGG-15132 Logging supplemental redo data enabled
Step 8 – Configure Extract
Create parameter file.
GGSCI> EDIT PARAMS EXT_SALES
EXTRACT EXT_SALES
USERID ggadmin PASSWORD Welcome#123
EXTTRAIL ./dirdat/st
TRANLOGOPTIONS INTEGRATEDPARAMS (PARALLELISM 4)
TABLE SALES_TRANSACTIONS;
-- Create extract
ADD EXTRACT EXT_SALES INTEGRATED TRANLOG BEGIN NOW
ADD EXTTRAIL ./dirdat/st EXTRACT EXT_SALES
-- start & verifgy its status
START EXTRACT EXT_SALES
INFO EXTRACT EXT_SALES
EXTRACT EXT_SALES Last Started 2026-03-15 21:48 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:04 ago)
Process ID 32418
Log Read Checkpoint Oracle Redo Logs
SCN 845732918 (0x0000.3267a3b6)
2026-03-15 21:48:12
Step 9 – Configure Data Pump
The GoldenGate Data Pump reads captured changes from the local trail files and forwards them to the target GoldenGate deployment. This process improves reliability and allows data to be securely transported to the target environment.
EDIT PARAMS PUMP_SALES
EXTRACT PUMP_SALES
RMTHOST 10.10.10.21, MGRPORT 7809
RMTTRAIL ./dirdat/rt
TABLE SALES_TRANSACTIONS;
-- add pump
ADD EXTRACT PUMP_SALES EXTTRAILSOURCE ./dirdat/st
ADD RMTTRAIL ./dirdat/rt EXTRACT PUMP_SALES
-- Start Pump
START EXTRACT PUMP_SALES
INFO PUMP_SALES
EXTRACT PUMP_SALES Last Started 2026-03-15 21:48 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:02 ago)
Process ID 32455
Log Read Checkpoint File ./dirdat/es000000000
RBA 18425
Step 10 – Configure Cassandra Handler
On the GoldenGate Big Data / DAA node, configure the Cassandra handler properties so that the Replicat process knows how to connect to the DataStax Cassandra cluster and apply incoming changes. This configuration defines connection details, consistency level, datacenter information, and the Java classpath required for the Cassandra driver.
This configuration allows the GoldenGate Replicat process to establish a connection with the Cassandra cluster and apply transactional changes coming from the Oracle source database.
[oggadmin@cass-hub01 ~]$ vi /u01/app/ogg_23ai/dirprm/cassandra.props
gg.handlerlist=cassandra
gg.handler.cassandra.type=cassandra
gg.handler.cassandra.mode=op
gg.handler.cassandra.contactPoints=10.20.30.41
gg.handler.cassandra.port=9042
gg.handler.cassandra.keyspace=retail_ops_ks
gg.handler.cassandra.consistencyLevel=LOCAL_QUORUM
gg.handler.cassandra.cassandraMode=async
gg.handler.cassandra.compressedUpdates=true
gg.handler.cassandra.datacenter=DC_MAIN
gg.log=log4j
gg.log.level=INFO
gg.report.time=30sec
gg.classpath=/opt/datastax/cassandra/resources/cassandra/lib/*:/u01/app/ogg_23ai/DependencyDownloader/dependencies/cassandra_4.1/*
javawriter.stats.full=true
javawriter.stats.display=TRUE
-- If authentication is enabled in DataStax Cassandra, the property file can also include credentials depending on the adapter version and security model being used.
-- exampl;e
gg.handler.cassandra.username=oggsvc
gg.handler.cassandra.password=Str0ngPassw0rd
Step 11 – Configure Replicat
At this stage, the source-side Extract and Data Pump are already running and writing trail records to the remote trail on the target GoldenGate deployment. The next step is to configure the Replicat process on the Cassandra side so that trail records can be applied into the target DataStax Cassandra keyspace and table.
In a GoldenGate Big Data or DAA style deployment, the first thing you should always do is connect to the deployment administration interface and verify that the deployment is up before creating the Replicat.
-- Loginto deployment
[oggadmin@cass-hub01 ~]$ cd /u01/app/ogg_23ai/bin
[oggadmin@cass-hub01 bin]$ ./adminclient
Oracle GoldenGate Admin Client for Oracle
Version 23.10.0.25.10 OGGCORE_23.10.0.0.0_PLATFORMS_251018.0830
Copyright (C) 1995, 2025, Oracle and/or its affiliates. All rights reserved.
Linux, x64, 64bit (optimized), Generic on Oct 18 2025 14:00:54
Operating system character set identified as UTF-8.
-- connect to the deployment
OGG (not connected) 1> CONNECT http://10.10.40.25:9001 deployment CassandraDAA as oggadmin password "xxxxxx";
Successfully connected to CassandraDAA.
Before creating the Replicat, verify that the remote trail files are arriving from the Data Pump. This is a simple but important validation step. If the trail is not being written, the Replicat will start but will have nothing to process.
[oggadmin@cass-hub01 ~]$ cd /u01/app/ogg_23ai/var/lib/data
[oggadmin@cass-hub01 data]$ ls -ltr rt*
-rw-r----- 1 oggadmin oinstall 1048576 Mar 15 20:11 rt000000000
-rw-r----- 1 oggadmin oinstall 524288 Mar 15 20:16 rt000000001
This confirms that the remote trail prefix rt is present and the target deployment is receiving records from the source-side Pump process.
Next lets create the replicate.
OGG (http://10.10.40.25:9001 CassandraDAA as oggadmin@CassandraDAA) 3> EDIT PARAMS REP_CASS
REPLICAT REP_CASS
TARGETDB LIBFILE libggjava.so SET property=dirprm/cassandra.props
REPORTCOUNT EVERY 1 MINUTES, RATE
GROUPTRANSOPS 1000
DISCARDFILE ./var/lib/data/REP_CASS.dsc, APPEND, MEGABYTES 500
DISCARDROLLOVER AT 02:00
MAP APP_OWNER.SALES_ORDERS_SRC,
TARGET retail_ops_ks.sales_orders_rt;
-- add the repl process
OGG (http://10.10.40.25:9001 CassandraDAA as oggadmin@CassandraDAA) 4> ADD REPLICAT REP_CASS, EXTTRAIL ./var/lib/data/rt
REPLICAT added.
-- staret the process
OGG (http://10.10.40.25:9001 CassandraDAA as oggadmin@CassandraDAA) 5> START REPLICAT REP_CASS
Sending START request to Manager ...
REPLICAT REP_CASS starting.
REPLICAT REP_CASS Last Started 2026-03-15 21:49 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:01 ago)
Process ID 32504
Log Read Checkpoint File ./dirdat/rt000000000
RBA 18874
Params explanations …
REPLICAT REP_CASS defines the Replicat group name.
TARGETDB LIBFILE libggjava.so SET property=dirprm/cassandra.props tells GoldenGate to use the Java-based Big Data adapter library and load all Cassandra handler settings from the referenced properties file.
REPORTCOUNT EVERY 1 MINUTES, RATE prints transaction statistics regularly into the report file, which is very useful during initial testing and performance validation.
GROUPTRANSOPS 1000 batches operations to improve throughput. This value can be tuned depending on transaction profile, row size, and Cassandra write latency.
DISCARDFILE captures records that fail processing, while DISCARDROLLOVER keeps the discard file manageable.
The MAP statement defines the source Oracle table and the target DataStax Cassandra table.
In this example:
Oracle source table: APP_OWNER.SALES_ORDERS_SRC
Cassandra target table: retail_ops_ks.sales_orders_rt
Step 12 – Testing End-to-End Replication (Oracle to DataStax Cassandra)
In this section we will validate that the replication pipeline is working correctly by performing a few test transactions on the Oracle source database and confirming that the changes are applied on the DataStax Cassandra target table.
I am not going to discuss the initial load process here since it is relatively straightforward and typically performed using standard GoldenGate initial load methods or bulk data movement tools. For the purpose of this test, we assume that the base dataset has already been loaded into Cassandra and that GoldenGate is responsible only for capturing and replicating incremental changes.
-- Source DB
SQL*Plus: Release 19.0.0.0.0 - Production
Version 19.21.0.0.0
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0
SELECT * FROM SALES_ORDERS_SRC;
ORDER_ID CUSTOMER_NAME ORDER_STATUS ORDER_AMOUNT
-------- ------------- ------------ ------------
1001 NORTH RETAIL CREATED 450
1002 ALPHA STORES SHIPPED 720
1003 OMEGA MART CREATED 610
On Target/Cassandra cluster
cqlsh 10.20.30.41 9042 -u cassandra -p cassandra
Connected to RetailCluster at 10.20.30.41:9042
[cqlsh 6.1.0 | DSE 6.8.x | CQL spec 3.4.6]
USE retail_ops_ks;
SELECT * FROM sales_orders_rt;
order_id | customer_name | order_status | order_amount
---------+---------------+--------------+--------------
1001 | NORTH RETAIL | CREATED | 450
1002 | ALPHA STORES | SHIPPED | 720
1003 | OMEGA MART | CREATED | 610
-- This confirms that the initial dataset already exists on both systems.
Lets do some changes on source and see how it reaches on target.
INSERT INTO SALES_ORDERS_SRC
VALUES (1004,'PACIFIC TRADING','CREATED',980);
COMMIT;
1 row created.
Commit complete.
-- Veroify OGG
INFO EXTRACT EXT_SALES
EXTRACT EXT_SALES Last Started 2026-03-16 20:12 Status RUNNING
Checkpoint Lag 00:00:00
Log Read Checkpoint
SCN 845736122
-- scn moVED. This confirms that the Extract process captured the transaction from the Oracle redo logs.
Now lets check it on target
SELECT * FROM sales_orders_rt
WHERE order_id = 1004;
order_id | customer_name | order_status | order_amount
---------+------------------+--------------+--------------
1004 | PACIFIC TRADING | CREATED | 980
The inserted record has successfully replicated.
By performing these test operations, we validated that:
• GoldenGate Extract captured Oracle redo changes
• Data Pump delivered trail files to the target deployment
• Replicat applied changes into DataStax Cassandra
The Oracle —> GoldenGate —-> Cassandra replication pipeline is now functioning correctly.
Hope It Helped!
Prashant Dixit
Tales From A Lazy Fat DBA 