GoldenGate has been the quiet workhorse of Oracle estates for two decades: the technology that reads a database's change logs and applies those changes somewhere else, continuously, while the source keeps running. On OCI it arrives as a managed service, which removes the part of GoldenGate that practitioners actually feared, the care and feeding of the replication infrastructure itself, and leaves the part that matters, the replication design. This guide covers what OCI GoldenGate is, the five patterns it gets used for in real estates, how the billing model behaves, and the implementation sequence that avoids the classic failure modes.
GoldenGate is the change data capture backbone of the OCI data platform, and choosing between it and Data Guard is one of the most common questions we field, so we wrote that decision up separately in data replication strategies on OCI.
What OCI GoldenGate actually is
OCI GoldenGate is a fully managed deployment of GoldenGate's capture and apply engines. You create a deployment in the console, point it at sources and targets through database registrations, and design the replication paths in a browser. The service handles provisioning, patching, availability, and scaling of the replication infrastructure; you never see the VM it runs on. Sources and targets are not limited to Oracle Database: MySQL, PostgreSQL, SQL Server, Kafka compatible streams, and object storage targets are all in scope, which is what turns GoldenGate from an Oracle tool into a general data distribution layer.
The essential property to hold onto is that GoldenGate is logical, log based, and continuous. It does not lock tables, it does not query the application schema under load, and it does not need downtime on the source. That property is what every pattern below exploits.
The five patterns
| Pattern | What it does | Typical use |
|---|---|---|
| Zero downtime migration | Initial load plus continuous sync until cutover | Moving production databases to OCI without an outage window |
| Active standby distribution | Continuous one way replication to a second region or cloud | Read offload, reporting copies, cross cloud distribution |
| Active active | Bidirectional replication with conflict rules | Two live sites, geographic load split |
| Analytics feed | Continuous delivery into warehouse or lakehouse targets | Fresh analytics without touching the source application |
| Stream integration | Change events published to Kafka compatible topics | Event driven architectures fed from existing databases |
Migration, the gateway pattern
Most teams meet GoldenGate during a migration. The pattern is an initial load of the target, then continuous capture of source changes applied to the target until the two are in lockstep, then a cutover that lasts as long as a connection string change. The application keeps running through all of it, and the fallback is equally graceful, because replication can be reversed to flow back to the source after cutover, keeping the old system current as an insurance policy during the bedding in period. If you would rather consume this pattern as a packaged workflow than design it yourself, that is exactly what OCI Database Migration Service wraps around GoldenGate, and our article covers when the wrapper fits and when to go direct.
Active active, the pattern that needs adult supervision
Bidirectional replication between two live databases is the most powerful pattern and the one that punishes casual design. The technology handles it; the hard part is conflict policy: what happens when both sites change the same row inside the replication lag window. Real deployments succeed by making conflicts structurally rare, partitioning writes by geography or by key range, and then defining explicit resolution rules for the residue. Teams that skip the policy work discover it in production, with interest.
Feeding the lakehouse
The analytics feed pattern deserves more attention than it gets. GoldenGate delivering change streams into object storage or a warehouse means the analytic estate is minutes behind production instead of a day, without a single query landing on the source application. It is the freshness backbone of the lakehouse architecture we describe in this series, and it routinely replaces fleets of nightly extract jobs that nobody remembers building and everybody fears touching.
Billing and sizing
OCI GoldenGate bills by OCPU hours consumed by the deployment, with auto scaling between a floor you set and the demand the replication load generates. Cost therefore tracks change volume, not database size, which surprises people in both directions: a huge, quiet database replicates cheaply, while a modest database with a brutal update rate does not. Sizing starts from change volume, redo generation rate on Oracle sources is the usual proxy, and the floor should be set from sustained load with headroom left to the auto scaler rather than provisioned for peak. Watching the first month's scaling behaviour and trimming the floor is a standard part of how we run these deployments under a managed retainer.
Operational realities the brochure skips
Three operational facts decide whether a GoldenGate deployment stays healthy. The first is that lag is a product metric, not an infrastructure metric: the business agreed to a freshness promise, so lag must be graphed, alerted, and reviewed like any other service level, with the deployment's auto scaling watched alongside it, because sustained scaling on the ceiling is a sizing message. The second is schema change. Replication binds two schemas together, and an uncoordinated column change on the source becomes an apply error on the target at the worst possible hour. Mature teams route schema changes through a process that knows replication exists, and test them in a lower environment with replication running. The third is drift verification. Log based replication is reliable, but trust is cheaper to maintain than to rebuild, so periodic row count and checksum comparisons between source and target belong on the calendar, especially before and after cutovers. None of this is difficult, all of it is regularly skipped, and the deployments we inherit in distress are nearly always missing the third item.
A six step implementation framework
- Define the pattern and the lag budget. Which of the five patterns is this, and what replication lag can the business actually tolerate. Every later decision keys off these two answers.
- Audit the source for replication readiness. Supplemental logging, unsupported data types, tables without keys, and sequence handling are the classic snags. Find them on paper, not in flight.
- Design topology and conflict policy. One deployment or several, which direction each path flows, and for active active, the write partitioning and resolution rules in writing.
- Run the initial load with verification. Load the target, start capture from a consistent point, and verify with row counts and checksums before trusting the stream.
- Soak before you switch. Run replication under production load long enough to see the weekly peak, watching lag and apply rate, before any cutover or consumer goes live.
- Monitor lag as a service level. Alert on lag thresholds, watch deployment scaling, and review cost monthly. Replication is a product with users; run it like one.
Bringing it together
OCI GoldenGate turns the most battle proven replication engine in the Oracle world into a service you design rather than operate, and the five patterns above cover most of what real estates need: migrations without downtime, distribution without load, analytics without staleness, and events without rewrites. The design decisions, lag budgets, conflict policy, and sizing floors, are where experience pays. We build these topologies inside our disaster recovery practice and run them day to day for managed clients, and if a migration is the immediate question, an assessment will put a concrete replication design and cutover plan on the table.
Free white paper
Go deeper on this topic with The Exadata Cloud Decision Guide, Database Service vs Cloud@Customer vs Autonomous, and how to choose. An independent analyst style report with comparison tables and recommendations, free with a work email. Prefer a monthly summary instead? The OCI Brief delivers one practical OCI briefing a month.
Part of a series
This guide is part of Oracle Database on OCI — our complete pillar guide on the topic.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings.