Last quarter I migrated a 4TB on-prem Oracle order-management database to OCI Autonomous Database with a change window of exactly zero minutes. No maintenance page, no "please don't place orders between 2 and 4 AM." The tool that made that possible was Oracle GoldenGate 23ai, and if you're still running the classic architecture from a few years ago, the upgrade path itself is worth knowing about before you touch a single extract.
Here's what actually changed, why it matters for cloud migrations specifically, and where I got bitten during setup.
What GoldenGate 23ai actually is
GoldenGate has always done one thing: capture committed changes from a source database's redo/transaction logs and apply them to a target, in near real time, without touching the source workload. 23ai (GA since April 2024, still shipping incremental releases under that name) adds a few things that matter if your target is a cloud database:
-
Microservices architecture is now the only architecture. Classic GGSCI-only deployments are on their way out. Everything runs as a set of REST-managed services (Administration Server, Distribution Server, Receiver Server) fronted by a browser console, managed through
adminclientinstead of the oldggscishell alone. -
AI vector data type support. GoldenGate can now replicate Oracle 23ai
VECTORcolumns in real time, including to non-Oracle vector stores like pgvector, MySQL HeatWave, and OpenSearch, as long as the embedding algorithm and dimensions match on both sides. - Data Streams. DDL and DML changes can be exposed as JSON CloudEvents over AsyncAPI, so a downstream microservice can subscribe to a table's changes without you writing a Kafka Connect pipeline for it.
- OCI GoldenGate as a managed service. Fully managed deployments across 45+ OCI regions with elastic autoscaling, so you're not babysitting a VM running the hub.
For a straight database migration, the piece that matters most is still the boring one: extract, trail, replicat. Let's build it.
Setting up real-time replication to the cloud
Assume an on-prem Oracle 19c/23ai source and an OCI Autonomous Database (or Oracle on RDS, the pattern is nearly identical) as target. First, enable supplemental logging on the source. Do this at the PDB level, not the CDB root, unless you're specifically doing downstream mining, Oracle explicitly does not recommend root-level capture with a common user for normal replication.
-- Run inside the source PDB, connected as the GoldenGate admin user
ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATION=TRUE SCOPE=BOTH;
ALTER TABLE ORDERS.ORDER_HEADER ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
Then, from the admin client (or GGSCI if you're still mid-upgrade), enable trandata and add the extract:
GGSCI> DBLOGIN USERID ggadmin@ORCLPDB1, PASSWORD ******
GGSCI> ADD TRANDATA ORDERS.ORDER_HEADER
GGSCI> ADD EXTRACT EXTORD, TRANLOG, INTEGRATED TRANLOG, BEGIN NOW
GGSCI> ADD EXTTRAIL /u01/ogg/dirdat/ab, EXTRACT EXTORD, MEGABYTES 200
The extract's parameter file is where you actually tell it what to capture:
EXTRACT EXTORD
USERID ggadmin@ORCLPDB1, PASSWORD ******
EXTTRAIL /u01/ogg/dirdat/ab
TRANLOGOPTIONS EXCLUDEUSER GGADMIN
TABLE ORDERS.ORDER_HEADER;
TABLE ORDERS.ORDER_LINES;
On the target side (Autonomous Database, connecting over the wallet TNS alias), add the replicat against a checkpoint table:
GGSCI> DBLOGIN USERID ggadmin@ORCLADB_HIGH, PASSWORD ******
GGSCI> ADD CHECKPOINTTABLE ggadmin.ggchkpt
GGSCI> ADD REPLICAT REPORD, EXTTRAIL /u01/ogg/dirdat/ab, CHECKPOINTTABLE ggadmin.ggchkpt
And its parameter file:
REPLICAT REPORD
USERID ggadmin@ORCLADB_HIGH, PASSWORD ******
ASSUMETARGETDEFS
MAP ORDERS.ORDER_HEADER, TARGET ORDERS.ORDER_HEADER;
MAP ORDERS.ORDER_LINES, TARGET ORDERS.ORDER_LINES;
Start both, watch the lag, and once REPORD reports zero lag against a quiet source, you cut over the application's connection string. That's the whole trick to a zero-downtime migration: the cutover is a DNS/connection-string change, not a data-loading exercise.
GGSCI> START EXTRACT EXTORD
GGSCI> START REPLICAT REPORD
GGSCI> INFO REPLICAT REPORD, DETAIL
Where this requires care
A few things cost me real time on that migration, and I'd rather you skip them:
The classic-to-microservices jump isn't optional anymore. If you're on an older GoldenGate install, plan a separate upgrade step before the migration project, not during it. Trying to learn adminclient REST semantics on the same day you're cutting a production database over is a bad combination.
Autonomous Database needs the wallet, and the wallet needs network ACLs. GoldenGate connects to Autonomous Database over TLS using the downloaded wallet's TNS entry. If your GoldenGate host can't reach the ADB's public or private endpoint, or the ACL on the ADB instance hasn't been opened for that host, you'll get a connection failure that looks like a credentials problem and isn't.
Trail files will eat your disk if replicat lags. On a large initial sync, extract runs ahead of replicat easily. Watch trail directory growth, not just lag in seconds, especially if the target is on a slower network path like a cross-region OCI link.
Vector column replication has real constraints. It's not a magic heterogeneous conversion. Source and target vector dimensions and distance metric need to line up, or you're replicating garbage embeddings that happen to be the right data type.
Root-level capture with a common user works but isn't the recommended path. If you inherited a GoldenGate config that captures from the CDB root, budget time to migrate it to per-PDB extracts before you lean on it for a cloud migration you actually care about.
My take
GoldenGate 23ai's headline features (vector replication, Data Streams, the AI service integrations) are the interesting demo material, but the reason it's worth learning right now is much less flashy: it's the most reliable way I've found to move a live Oracle database to the cloud without asking the business for a maintenance window. The microservices architecture switch is a real cost if you're upgrading from an old classic install, but once it's running, the extract-trail-replicat pattern is the same discipline it's always been, just pointed at a cloud endpoint instead of a second on-prem box.
Top comments (0)